Reality defined, software enabled: the ordering that makes a twin checkable

The Digital Twin Consortium's Manufacturing Working Group, which we co-chair, spent this week's session on how models made by different vendors can be made to work together across a company's factories. It is a real problem, and the technical half of it has good answers today. The question we raised underneath it is one of ordering: which comes first, the model, or the reality and the outcome the model exists to serve. What follows is our own argument from that session, not a position of the group.

The order decides what the result is measured against. A programme that begins with the model produces a reference that lives inside the software. When someone asks whether it works, the answer available is that the software behaves as modelled, which is a statement about the model. A programme that begins with the outcome the organisation is trying to reach, and with the plant as it currently stands, keeps the reference outside the software. The same question then has an answer that can be checked on the floor.

Reality defined, software enabled. Reality sets what is true, the intended outcome sets what matters, and software is what makes acting on both practical at the speed the business needs. Models are how that gets done, and they are worth the money when the thing they serve was named before they were built. This is the same ordering the published method runs on: outcome, decision, insight, information, and data last.

A design that has not absorbed the current state is a wish list. An existing plant carries years of accumulated adaptation that appears on no drawing. It shows up as the pallet route that avoids a column, the station moved a metre and never redrawn, and the fixture that only fits one way round. Generative design and AI assistance will propose excellent things measured against world best practice. Whether this building can host the proposal, using components this site is able to buy, is a separate question. It becomes answerable when the current state sits in the model as an anchor rather than as an assumption.

Nobody can grade a decision they were not present for. An engagement that ends at design handover produces no observation of the thing it designed. Year one is when the layout meets the actual mix, year two is when the mix changes, and year three is when the model either still matches the plant or quietly stopped matching it. Whether the model is still open in year three is a question of running cost and of who is left holding it, as much as of how good it was on the day it was delivered. An organisation that has both the current state and a continuous presence can say whether something worked. Without those two, the honest answer is that nobody knows.

The ordering bites hardest across many sites. Manufacturers of a certain size rarely run one plant. Ten or twenty is common, several of them acquired rather than built, each with its own systems and its own reporting habits. Connecting those systems technically is largely a solved problem today. Agreeing what a term means across all of them — that a stoppage, a batch or a shift is the same thing in every plant — is harder, and this is what people in the field call semantic interoperability. Agreeing what may cross a border, and who is permitted to decide, is harder still, and it is a legal question before it is a technical one. Zoom out one further level and the same three questions arrive again across the supply chain, where knowing where a component comes from and where it goes has become a security requirement rather than a logistics preference.

Models are worth what they cost. The argument is about what they are anchored to, and about who is still present when the answer meets the plant.

The method behind this ordering is published and citable with a DOI, and it is readable in full as SMILE. The phased version of it, showing what each phase does, what it hands over and which gate closes it, is on project phases.