Release notes for the IntraLogic platform.
These notes track development milestones during IntraLogic’s preview, ahead of general availability in the first quarter of 2027 — feature enhancements, model updates, security improvements, and governance capabilities across versions.
Feature notes, UX refinements, integration updates, security improvements, and platform maturity.
Documented changes to infrastructure logic, simulation behavior, state snapshots, and rule interpretation.
Platform history
Expand any release to see what it introduced. Everything below is marked Preview: the platform is in preview until general availability in the first quarter of 2027, so nothing here is yet covered by a general-availability commitment.
Credentials and discovery settings become reusable objects owned by the client, instead of configuration trapped inside one agent.
- NewDefine a credential once and reuse it everywhere a discovery needs it.
- NewDiscovery profiles belong to the client, not the agent — so replacing an agent no longer means re-entering its configuration.
- NewAttach, copy, or clone a profile, with a duplicate guard and an audit trail behind each action.
- NewAn agents overview across every client, plus a per-client dashboard for the agents serving that client.
- ImprovedEnrollment tokens are scoped to a client.
- ImprovedDiscovery imports no longer have to run in a set order. Every import re-reconciles what is already in the model, so a datastore imported before its storage array, or a host before its switch, is folded onto the real object by identity as soon as that object arrives — rather than being stranded as a placeholder until someone re-runs the whole sequence.
Discovery configuration becomes part of the client’s record rather than a property of whichever agent happens to be installed.
One append-only event store now sits behind every activity surface in the platform.
- NewModel changes, agent actions, and assistant actions all record to the same feed.
- NewField-level change detection, so an entry says which value changed and what it changed from.
- NewOne correlation identifier per request ties an action to everything it caused.
- NewFailed sign-ins and agent security actions appear in that feed alongside everything else.
- ImprovedNinety days stay immediately searchable; older events are archived and remain searchable.
Answering “who changed this, and when” stops being a reconstruction.
What changed under the hood
Activity used to be written by each feature into its own log, which is why answering “who changed this?” meant reconciling three sources that disagreed. Every surface now writes to one append-only event store instead.
That single write path is what makes field-level detail possible: an incoming record is compared against the stored one attribute by attribute, and the delta is recorded rather than just the fact that an edit happened — so an entry reads “capacity changed from 4 TB to 8 TB”, not “array updated”.
Each inbound request carries one correlation identifier for its whole lifetime. A discovery run, the model changes it produced and an assistant action taken afterwards all resolve to a single thread, so a cascade can be read end to end instead of inferred from timestamps.
Failed sign-ins and agent security actions write to the same feed rather than a separate security log. Ninety days stay immediately searchable; older events move to archive storage and remain searchable there rather than being discarded.
Discovered infrastructure is correlated into one dependency graph, and every object gets a record page of its own.
- NewCross-domain correlation by MAC address and SCSI identity, so a device found by two connectors stays one object.
- NewEvery relationship records the evidence behind it.
- NewLow-confidence matches go to review rather than into the model.
- NewFull-page records for hosts, virtual machines, switches, and storage arrays.
- ImprovedThe graph is versioned, with compare and rollback.
- ImprovedSimulation follows discovered connections, not only the ones drawn by hand.
Every link in the model can be traced back to what was actually observed.
What changed under the hood
The dependency graph is stored rather than recalculated on demand. Relationships are written as first-class records with a type and a direction, so the same graph answers “what does this depend on?” and “what depends on this?” without rebuilding it per question.
The most consequential fix in this release was in path tracing. It previously walked only manually drawn rack connections, which meant an environment with rich discovered topology and no hand-entered cabling traced nothing at all — the feature looked broken when in fact it was reading the wrong source. Tracing now traverses discovered adjacency as well, and de-duplicates against manual entries so a link recorded both ways is drawn once.
Device records became full pages rather than table rows, with each tab populated only where real data exists. Where a value was never collected the page says so, rather than rendering an empty field that reads like a zero.
Read-only connectors collect what is actually running, and nothing enters the model without review.
- NewRead-only connectors across virtualization, storage, network, and hardware platforms — every one of them outbound-only.
- NewEverything discovered goes to a review step before it becomes part of the model.
- NewDiscovery runs on a schedule or on demand.
- NewDiscovered inventory is searchable, and the assistant can answer questions about it.
- ImprovedSSH is restricted to an allowlist of read-only commands, and running-config collection was removed entirely.
- ImprovedOne discovery can use more than one method against the same platform — a primary API call and an SSH supplement in the same run, for the parts one protocol can reach and the other cannot. Where two methods report the same field, a source policy decides which wins and records which one did, so a later run reconciles against it instead of overwriting it.
- ImprovedNow that discovery keeps the model moving, published client documentation is fingerprinted against it — a change to sites, racks, devices, virtual machines, storage, core roles, applications, backups or WAN links marks that document out of date and names what moved, rather than leaving it quietly wrong.
Scheduled discovery is new.
It accepts intervals from fifteen minutes to a week; cron expressions are not supported yet, and the scheduler has had no field soak. On-demand discovery is the well-travelled path.
Discovery narrows the gap between the documented model and the running environment.
What changed under the hood
Discovery is deliberately split into three steps — collect, review, import — and nothing reaches the model until a human approves it. Placing an object into the review set is not the same as importing it, which is what keeps a bad scan from rewriting an environment.
Normalisation is where most of the work sits. The same disk can be reported one way by a hypervisor and another by an array, so identifiers are canonicalised before anything is matched — SCSI identifiers are reduced to a common form, datastore names are recovered from file paths when they are not reported directly, and hosts are matched on stable identity rather than on a name that may have changed.
Reconciliation is order-independent: importing storage before virtualisation, or the reverse, converges on the same model. Cross-domain links resolve on the second import, once both halves of a relationship exist.
Living, AI-generated client documentation — always current with the live model and fully version-controlled.
- NewGenerate client-facing documentation directly from the infrastructure model.
- NewVersion history so every revision is tracked, compared, and restorable.
- NewNarrative carry-forward preserves context across regenerations; edit details or raw HTML.
- NewPublished per client under a dedicated Documentation area.
Documentation stays in step with the environment instead of drifting out of date.
What changed under the hood
Generated documentation carries a fingerprint of the environment it was written from — a structured summary of the objects and relationships that existed at generation time.
Staleness is then a comparison rather than a guess. The current environment is fingerprinted again and the two are diffed, so the platform can say not just that a document is out of date but what changed underneath it — three hosts added, a pool removed — and phrase it in ordinary language rather than as a diff.
This is the difference between documentation that is dated and documentation that knows it is dated. A wiki page cannot tell you it is wrong; a document tied to a fingerprint of the model can tell you exactly which part of it drifted, and how far.
A release entirely about the front door. Security is a first-order concern here, not a section at the end of the deck — and the parts a security review reaches first are the parts worth documenting precisely.
- NewMulti-factor authentication, with two methods: a six-digit code sent by email, or an authenticator app using standard time-based one-time passwords.
- NewMFA is required by default and managed per user, with an enrolment grace window. Only a super administrator can exempt an account — a tenant administrator has no way to switch it off, for themselves or for anyone else.
- NewEvery sign-in attempt is recorded with its source IP and user agent, whether MFA was presented and whether it passed, which flow it came through — password, MFA, or password reset — and, when it failed, why.
- NewA self-service profile page: a user can review their own sign-in history, step up to MFA, and set a recovery address without raising a ticket.
- NewAccounts can be enabled and disabled, and the record keeps who disabled one and when.
- ImprovedPassword-reset links and emailed codes are single-use and time-limited, and are marked consumed the moment they are used.
- ImprovedAuthenticator secrets are encrypted at rest rather than stored in the clear.
None of this is a compliance claim — it is the account layer described plainly, so a security review can check it rather than take it on trust. What we cannot claim yet is on the trust centre, stated just as plainly.
What changed under the hood
Two factors are offered and they are implemented differently on purpose. Emailed codes are six digits with a ten-minute lifetime, and the code itself is never stored — only a hash of it. Issuing a new code invalidates any outstanding one for that user and purpose, so a code from an earlier attempt cannot be replayed. Authenticator enrolment uses standard time-based one-time passwords — six digits on a thirty-second window — so any mainstream authenticator app works, and the shared secret is encrypted at rest rather than held in the clear.
There is deliberately no SMS option. SMS is the factor vulnerable to SIM-swap, so leaving it out is a decision rather than an omission.
Sign-in attempts are recorded whether they succeed or fail, with the source address, the client, which flow was used and — on failure — the reason. Reset links and codes are marked consumed the moment they are used.
An optional, outbound-only agent that checks your documented model against what's actually running.
- NewLightweight Windows agent (MSI) that collects read-only inventory and reports back securely.
- NewOutbound-only by design — no inbound ports and no agent-side control surface.
- NewCompares discovered reality against the documented model to surface drift and gaps.
- NewClient-scoped enrollment with credentials encrypted at rest and split agent / operational logging on short retention.
Closes the loop between documentation and live infrastructure.
What changed under the hood
The agent is a small Windows service that runs inside the network and reaches outward only. There is no inbound port, no firewall exception and no NAT entry to create, because nothing ever connects to it — it polls out over HTTPS and posts results back.
It is read-only by construction, not by policy. It collects inventory and configuration; there is no remote shell, no file transfer and no script delivery path, so the credential it holds cannot be used to change the environment it is reading.
When it cannot reach the platform it does not discard what it has collected. Results queue on the machine and upload once connectivity returns, which is why a site losing its internet connection produces a delay rather than a hole in the record.
Lifecycle tracking for every device — warranty, support, and end-of-life in one place.
- NewCapture purchase, warranty, support-contract, and end-of-life dates per device.
- NewAsset Management dashboard with filters and CSV, PDF, and HTML reports.
- NewAutomated expiration alerts so renewals and refreshes never slip.
- ImprovedLifecycle findings surfaced in the health score and dashboard widgets.
Hardware lifecycle becomes a managed, reportable part of the environment.
What changed under the hood
Asset facts were previously scattered across whichever view happened to display them, so the same device could carry a serial number in one place and a different one in another. This release gave hardware a single record and made every other surface read from it.
That matters most for the questions asked outside engineering — what is under support, what is approaching end of life, what was bought when. Those are answerable only if the underlying facts live in one place and are attached to the same object the dependency graph already knows about, rather than kept in a parallel spreadsheet that drifts.
A rich AI assistant joins the platform — a helper layered on top of the engine. The model and simulation engine stay deterministic and auditable; the assistant does not replace them.
- NewAdd objects by describing them — sites, devices, roles, storage, and VMs drafted into the structured model for review.
- NewSet up what-if tests in plain language; the deterministic engine runs the simulation.
- NewAsk questions about the live model — dependencies, impact, and findings — and get answers in context.
- NewRead-only and review-first: the assistant proposes, you confirm before anything is published.
AI accelerates how the model is built and explored, without changing what the engine is.
What changed under the hood
The assistant is grounded in the tenant’s own model rather than answering from general knowledge. Before a question reaches the model, context is assembled from that specific environment — the objects involved, their relationships and their current state — so the answer is about this estate, not about infrastructure in the abstract.
That is the distinction between an assistant that explains what RAID is and one that can say which arrays this client runs and what depends on them. It is also why the assistant is read-only and tenant-scoped: it can only see and describe the model it was given, and it cannot act on it.
Point-in-time versions of the environment model, with side-by-side comparison across approved baselines.
- NewCapture published versions of the model as the environment evolves.
- NewCompare any two versions to see exactly what changed and when.
- NewApprove official baselines your team works from.
- ImprovedVersion-aware reporting and audit evidence.
The platform becomes a system of record for how infrastructure changes over time.
What changed under the hood
The model is versioned rather than continuously overwritten, so a published state can be pointed at, compared and returned to. Comparison is between versions of the model itself, not between exported documents — which means a difference is expressed as objects and relationships that were added, removed or changed, rather than as text that happens to differ.
The practical value is in review and in audit: the question “what does this environment look like now versus at the last review?” becomes answerable without keeping a folder of dated exports.
Enterprise reporting now spans every module, with the export formats teams actually need.
- NewExport to CSV, PDF, and interactive HTML from any module or the whole environment.
- NewScheduled and on-demand email reports for stakeholders and leadership.
- ImprovedConsistent enterprise letterhead across inventory, dependencies, health scores, and alert snapshots.
- ImprovedPer-module reports for Sites, Physical, Roles, Storage, and Virtual — plus a combined environment report.
Reporting becomes a first-class capability across the entire product, not a single screen.
What changed under the hood
Reporting stopped being a page and became a capability available from wherever the data already is. The same underlying model renders to HTML for reading in the browser, PDF for circulation and CSV for anyone who wants the numbers in a spreadsheet — from one source, so the three cannot disagree.
Reports can also be sent directly rather than downloaded and re-attached by hand, and generated documents are stored rather than regenerated, so a report referenced in a ticket months later still shows what it showed at the time.
Controls for larger organizations and MSP environments.
- NewPer-organization, per-client, and per-module feature governance and toggles.
- NewAudit trail for reviewed changes, approvals, and generated reports.
- NewCompliance-ready evidence around model state, alert state, and operational decisions.
- ImprovedRole-aware access scoped by organization, client, and module.
The platform becomes a stronger system of record for how infrastructure is understood over time.
What changed under the hood
Access is scoped per tenant, and the boundary is enforced where data is read rather than where it is displayed. Hiding a control in the interface is not access control; a request for another tenant’s data has to fail at the query, and that is where the check sits.
Roles separate what a person can see from what they can change, with the highest-privilege actions — the ones that would let an administrator weaken the platform’s own protections — held above tenant administration rather than inside it.
Connects existing documentation sources with the IntraLogic model.
- NewIngestion of uploaded reference material — CSV, PDF, Visio and screenshots — extracted into the model for review.
- NewClarification prompts when documentation is incomplete, conflicting, or ambiguous.
- NewReviewed model publishing so teams approve the official environment view.
- ImprovedImproved cross-object logic across Sites, Physical, Roles, Storage, and Virtual.
Reduces the gap between written documentation and operational understanding.
What changed under the hood
Documentation stopped being something a person wrote about the environment and became something generated from it. The distinction matters: a written page is accurate on the day it is written and decays from then on, while a generated one reflects whatever the model currently holds.
This is the release where the platform’s central idea first appears — that the useful artefact is not a document but the model behind it, and that documents, diagrams and reports should all be views of that one thing rather than three separately maintained copies of it.
Establishes the core IntraLogic structure and the connected model.
- NewSites Intelligence and multi-location environment representation.
- NewPhysical infrastructure views for devices, racks, paths, and dependencies.
- NewCore Roles mapping for identity, DNS, DHCP, applications, and supporting services.
- NewStorage and Virtual modules with baseline simulation and state visualization.
Sets the core principle: move from raw visibility to real infrastructure understanding.
What changed under the hood
The foundation release established the domains the platform still works in — physical, storage, virtual, VDI, applications and roles, sites and resiliency — and, more importantly, the decision to hold them in one model rather than as separate modules that exchange data.
That choice is why cross-domain questions are answerable at all. A tool that models storage and a tool that models virtualisation can each be excellent and still be unable to say that this datastore sits on that pool on that array, so a controller failure reaches those applications. Building the domains into a single graph from the start is what made the simulation and blast-radius work of later releases possible.
Release notes support trust and operational control.
Customer Trust
Customers can review platform improvements and understand new operational capabilities.
Internal Control
Teams can track which version introduced each feature, rule change, or workflow improvement.
Governance
Release notes support change reviews, platform audits, and long-term operational accountability.