I have been in enough digital-thread conversations over the last decade to notice a pattern.
The vendor describes the vision. End-to-end traceability. Requirements to design to verification to production to service to end of life. Every artefact linked to every other artefact. A single query returns the current state of any part, its history, its context, and everything it depends on.
People in the room listen. They nod politely. Later, in a smaller conversation without the vendor in the room, they describe what it would actually require for that vision to be realised. The parts are managed. The BOMs are current. The change orders exist. Beyond that, everything falls apart. The interface contract between two subsystems lives in a document nobody indexes. The decision that shaped the architecture is in a meeting minute nobody knows how to find. The verification model that validated the interface was run against a configuration that no longer exists. The judgment call the chief engineer made about the acceptable EMC margin was not recorded.
Then the vendor says the digital thread will connect all of these. And people in the room rarely correct the vendor, because arguing with the vendor is not why they are there. But privately, everyone in the room knows the substrate does not exist, has not existed for the entire time the industry has been talking about digital thread, and is not going to exist just because a new PLM release has better linking mechanics.
That is the pattern. Digital thread as marketed is a traceability layer promised against a data model that has no first-class objects to hang traces on.
What the digital thread aspiration actually requires
The aspiration is right. An engineering organisation should be able to trace a service failure back to the interface contract that governed the boundary, to the verification that validated the interface at the version in production, to the decision that constrained the interface at design time, to the judgment call that accepted the marginal case. That trace is real engineering work, and organisations that can do it will outperform organisations that cannot.
But the trace is a query, and a query needs objects to hang on. Right now, the objects the trace would need to reach are not first-class in any PLM data model I have worked with.
Interface is not an object. It is a document, or a table of properties on a part, or an attribute overlay in a specific tool. It has no lifecycle of its own that is decoupled from the parts on either side. It has no change-control mechanic distinct from the change control of the underlying parts. It has no versioned link back to the verifications that validated it against a specific interface revision.
Space is not an object. In AEC it is (a room in a building is a first-class object with area, ventilation targets, acoustic requirements). In manufacturing PLM it is not. The nacelle around an aircraft engine has thermal envelope requirements that survive part changes, but those requirements sit on parts, and they die every time the parts are replaced.
Judgment is not an object at all. Every experienced engineer has judgment. Nothing in the data model captures it as engineering data, attributes it to the practitioner who rendered it, dates it, or lets subsequent engineering work reference it. When the engineer retires, the judgment leaves with them. Nothing about the digital thread as marketed will change that.
Decision and rationale, configuration history, verification with lineage, system as a bounded object, the story repeats primitive by primitive. Each is missing. Each is what a real digital thread would need. Each is what the vendor's traceability layer, however sophisticated, cannot manufacture on its own.
The digital-thread stack is not wrong; it is under-specified. It connects what the underlying data model has. What it cannot do is generate primitives the underlying data model does not have.
Why this pattern has held for a decade
The story digital-thread programmes tell about themselves has evolved. In 2014 it was about breaking down silos. In 2018 it was about connecting islands of automation. In 2022 it was about the model-based enterprise. In 2024 it was about AI-ready engineering data. The vocabulary changes. The underlying claim does not. Every version promises the same end state, end-to-end traceability across the product lifecycle, and every version fails at the same point, which is the moment the trace needs an object the data model does not carry.
This is not a vendor conspiracy. Vendors are selling what the market wants to buy, and the market wants to buy end-to-end traceability because the underlying need is real. The problem is that the vendor version treats the solution as adequate and the linking mechanics as the missing piece. The reality is the opposite: the linking mechanics are actually quite good in most modern PLM stacks. The missing artefacts are the real problem. Better linking does not fix a problem if you do not have anything to link to.
For twenty years, long enough for two generations of PLM leadership to cycle through, long enough for three or four major vendor consolidations, long enough for the term "digital thread" to be replaced twice and revived once, the same gap has kept the promise from arriving. Not because the industry is failing to try. Because the missing pieces are architectural, not operational, and operational effort cannot install architectural pieces.
What the substrate would look like
Here is the shape of the argument, in one paragraph, that I have spent the last several years working out.
Engineering data needs at least these seven primitives it does not currently have. System (a bounded managed object with scope and lifecycle, not just a BOM hierarchy). Interface (a contract with its own version, owner, and change-control mechanic). Space (a functional region with requirements independent of the parts that realise it). Verification (evidence with lineage that updates when the configuration it validates changes). Configuration history (actually-existing state, not just intended state). Decision and rationale (the choices that shaped the architecture, with the reasoning, the alternatives considered, and the trigger conditions that would reopen the question). Judgment (formal practitioner assessment as managed engineering data, with the practitioner's standing as data too). Together these seven primitives are what the digital-thread trace needs to reach. Federation is the pattern by which they can sit above the existing (PLM, PDM, ERP, MES, MBSE, etc.) tools engineering organisations already run, rather than replacing any of them.
This is what I mean when I say the digital thread problem is not actually a digital thread problem. It is a primitives problem. And the reason it has been unsolvable for twenty years is that nobody was talking about the primitives, because the vocabulary of digital thread does not include them.
One consequence for the sponsor of the next programme
If you are about to sponsor the next digital-thread investment, a new PLM migration positioned as a digital thread project, a new integration platform sold as digital-thread infrastructure, a new consulting engagement scoped as digital-thread strategy, the diagnostic question is whether your current data model carries the seven primitives.
If it does not, the digital-thread traceability you are about to fund will hit the same wall the last one did. Not because the tool is wrong, not because the integration is broken, not because the change management could have been better. Because the primitives required do not exist, and the primitives are what the tool is trying to trace.
The organisations that build the data model first, the seven primitives as first-class managed objects, federated across the tools already in place, will find that digital-thread traceability emerges as a query pattern rather than as another integration project. The organisations that do not build the data model will keep buying digital-thread software, keep seeing the same failure modes, and keep on wishing that the next vendor will get it right.