Every industrial software vendor now has an AI assistant in the demo. Ask it anything about your product. Why is this bracket titanium? What does this change order affect? Which units in the field are exposed to this defect? The assistant answers fluently, and the room is impressed, because the fluency is real. These models are extraordinarily capable of reasoning over the information they are given.
Then someone asks the question that matters. What information, exactly, will the assistant be given?
I have watched this conversation happen several times now, and it follows the same arc as the digital-thread conversations I wrote about in the previous article. The vendor describes the vision. The room nods. And later, in the smaller conversation without the vendor in the room, the engineers describe what the assistant would actually find if it went looking. The parts are managed. The BOMs are current. Beyond that, the same landscape as always: the interface contract in a document nobody indexes, the decision in a meeting minute nobody can find, the verification that validated a configuration that no longer exists, the judgment call that was never recorded anywhere at all.
The model is not the constraint. The substrate is.
What retrieval actually retrieves
The current answer to the substrate question is retrieval-augmented generation: index the organisation's documents, let the assistant search them, and ground its answers in what it finds. It is a reasonable pattern, and for some questions it works. But engineering documents have a property that makes them treacherous as a source of truth, which is that they drift from the reality they describe.
The interface specification describes revision C of the contract; the deployed units run revision E. The functional architecture diagram was accurate before the last two firmware loads. The design rationale memo records the decision but not the conditions that made it valid, several of which have since quietly stopped holding. A human engineer reading these documents applies a lifetime of calibration about which documents to trust, how stale each one is likely to be, and who to call to check. The assistant applies no such calibration. It retrieves the document, and the document is confidently wrong.
This is the uncomfortable part. An AI assistant answering from drifted documents is not a weaker version of the capability. It is a different and more dangerous thing, because it delivers stale engineering data with perfect fluency and none of the hesitation an experienced engineer would show. The failure mode of the human system was that finding the answer took three weeks. The failure mode of the assisted system is that the wrong answer arrives in three seconds.
Queries need objects
The fix is not better retrieval. The fix is giving the assistant something worth retrieving.
Consider what the impressive demo answers would actually require. Why is this bracket titanium: that is a decision object, with rationale, alternatives considered, and the conditions under which the decision holds. What does this change order affect: that is a traversal across interface contracts and system boundaries, which requires interfaces and systems to exist as objects with managed state. Which units in the field are exposed: that is a query against configuration history, the actually-existing state of every deployed unit, not the intended state in the release documentation. Can I trust the simulation on this margin: that is verification with lineage, plus the recorded judgment of the practitioner who assessed the marginal case last time.
Seven primitives, the same seven every time. System, interface, space, verification, configuration history, decision and rationale, judgment. Where these exist as first-class managed objects, the assistant's answer is a query with provenance: this decision, made on this date, under these conditions, two of which have since changed. Where they do not exist, the assistant's answer is an inference from document fragments, delivered in the same confident voice. The difference has a name. The first answer is defensible. The second is merely plausible. Engineering runs on defensible.
The industry has been here before. The digital thread promised end-to-end traceability against a data model that had no objects to hang traces on. The AI assistant now promises fluent answers against the same data model, which has no objects to ground answers in. The digital-thread stack was under-specified. The AI stack is under-substrated. And it will produce the same disappointment, on a faster cycle, because AI procurement moves faster than PLM procurement ever did.
The AI-in-engineering conversation currently splits into two camps. One camp says AI will transform engineering practice within five years. The other says it is overhyped and will disappoint. Both are arguing about the AI tools, and both are wrong for the same reason: the constraint is not the tools. An agent reasoning over a data model that carries interface as a document, verification as a report attachment, and judgment as an uncaptured heuristic is doing forensic reconstruction, not reasoning, and no amount of added sophistication at the reasoning layer changes that. The wall is not sophistication. The wall is the substrate.
Why federation is the AI-shaped answer
There is a second structural reason the assistant needs the federation architecture specifically, and not another consolidation programme.
The context an engineering assistant needs is never in one tool. The design intent is in the MBSE model, the released structure in PLM, the as-built state in MES, the service history in the maintenance system, the supplier interface in whatever the partner exchange process left behind. The consolidation answer to this, one platform to hold everything, has failed on its own terms for twenty years, for reasons that have nothing to do with AI and that I have described elsewhere. The federation answer leaves the tools in place, leaves authority where it belongs, and puts the seven primitives in a layer above them, each primitive referencing the systems of record underneath.
For a human organisation, this is a governance architecture. For an AI assistant, it is something more specific: it is the context layer. A federated primitive layer is, almost by accident of its design, exactly the shape a retrieval substrate should be. Bounded objects with owners, versions, validity conditions, and links into the underlying tools. An assistant grounded on that layer can answer across tool boundaries and cite its provenance object by object. An assistant grounded on any single tool answers from a fraction of the truth.
There is also the question of what happens after the assistant answers. AI-assisted engineering does not remove the human assessment; it multiplies the occasions for it. Whether the assistant's output on a marginal case should be trusted is a practitioner judgment, and an organisation that records those judgments as managed data, attributed, dated, referenceable, is building the calibration layer that makes assistance compound. This is what the judgment primitive is for, and the regulatory direction (the EU AI Act now in phased application, ISO/IEC 42001, the NIST AI framework) is converging on the same requirement from the compliance side: evidence, rationale, and accountability for AI-influenced outcomes, as managed records rather than as retrievable prose.
One consequence for the sponsor of the next programme
If you are about to fund AI-assisted engineering, a copilot pilot, an engineering-knowledge assistant, an AI layer positioned on top of the PLM estate, the diagnostic question is the same one I posed for the digital thread, because it is the same question. Does the data model underneath carry the seven primitives?
If it does, the assistant will be grounded in queryable engineering truth, and the capability will compound. If it does not, you are about to fund a very fluent interface to your organisation's undocumented assumptions. The pilot will demo well, because demos are built on curated data. The deployment will disappoint, because deployments run on the data you actually have.
This is also where the competitive gap of the next decade will open, and it will not open along the axis of who has the more capable AI tools. Tools commodify quickly; every serious industrial organisation will have access to something comparable within a year of any new capability landing. The gap will open along the axis of who has the substrate. The organisations that build it first will get assistants that answer with provenance. The organisations that buy the assistant first will get a faster route to the same wall.
One clarification, so the argument is not mistaken for opportunism. Federation is not worth building because AI arrived. The data model has been missing these primitives for two decades, and the cost has been paid every year in failed programmes, workaround effort, and disappointed digital-thread investments; the case stands on its own foundation. What AI changes is the urgency. It makes the substrate load-bearing for a class of engineering work that will be routine within the deployment horizon of the architecture itself, which turns federation from a decision worth making eventually into a decision worth making now.
One more thing
The argument here is a chapter of a larger one. I have spent the last three years writing that larger argument out at book length: it is called Beyond the BOM: A Federation Architecture for Complex Engineering Data, and it is on Amazon now. It specifies the seven primitives, the federation architecture that holds them, and the deployment path.
I will add one disclosure, because it is relevant to this article in particular. The book was written with a large language model as a writing partner, across many passes of drafting and revision. The architecture, the cases, and thirty years of accumulated scar tissue are mine; the prose was shaped with the model's help. I say this because it is the honest version of the argument above: I have seen at first hand what these models can do when they are grounded in a substrate someone actually maintains. The models are ready. The engineering data, in most organisations, is not. That gap is the work.