Version 0.1, draft, published 2026-08-11. Thirteen entity types, three conformance levels, and the coverage rules that decide whether a twin is an asset or a liability.

The model is the easy part

A digital twin is sold on the strength of the question it answers: what happens if we replace Oracle, move to Azure, lose this vendor. Every one of those answers is a function of two things nobody asks about — how complete the model is, and how old it is. A twin covering 60% of the estate, refreshed quarterly, will answer a dependency question with total confidence and be wrong in the 40% it cannot see. The model is the easy part. Knowing what the model does not know is the product.

The thirteen entity types

How each type is usually wrong

Not hypothetical failure modes. These are the ones that make a twin answer confidently and incorrectly, and each is a question to put to your own model before you trust an answer from it.

• People. Modelled from the HR system, which knows reporting lines and not who actually holds the knowledge. The person who can restore the payroll database is rarely the person the org chart points to.
• Systems. Non-production is omitted, then a change is simulated as safe because the twin cannot see the six environments it also touches.
• Applications. Criticality is self-declared by the owning team, so everything is tier one. Criticality is only meaningful when it is scarce.
• Infrastructure. Decommissioned equipment stays in the model for years because nothing tells the twin it is gone. Absence of an update is not evidence of no change.
• Data. Residency is recorded as contracted rather than as enforced, and the two differ more often than anyone expects.
• Cloud. Spend is modelled from the invoice rather than from tagging, so it cannot be attributed to an application and therefore cannot be simulated against a change.
• Projects. The twin models the estate as it is and the project portfolio as it is planned, then simulates a change against a state that will not exist by the time the change happens.
• Customers. Missing entirely, which is why an outage simulation returns a technical impact and no contractual one.
• Vendors. Modelled per contract rather than per capability, hiding the fact that four contracts all rest on one supplier.
• Contracts. Notice periods are absent, so an exit simulation returns a timeline that ignores the clause that actually sets it.
• Costs. Only run cost is modelled. Change cost, exit cost and the cost of the people who operate it are the ones that decide most scenarios.
• Risks. Recorded as a register rather than as a relationship, so the twin cannot tell you which risks a proposed change creates or clears.
• Policies. Modelled as documents rather than as constraints, so a simulation can propose something the organisation is not permitted to do and report it as viable.

Conformance

Three levels, because the word "twin" is applied to all three and only the last one can simulate anything.

Coverage and freshness

The rule that decides whether a twin is an asset or a liability.

1. Every entity carries as_of and source. An entity with neither is excluded from simulation rather than assumed current.
2. Coverage is declared per entity type as a proportion of what EXISTS, not of what was imported. If what exists is unknown for a type, coverage for that type is unknown, and saying so is the correct answer.
3. A simulation states the oldest as_of among the entities it used. One stale entity in a dependency chain sets the age of the answer.
4. Below a stated coverage threshold for any entity type the scenario touches, the twin declines to simulate and says which type is thin. Declining is a feature; the alternative is a confident answer computed over a hole.
5. Freshness is measured from the source system's change, not from the import job. An import that ran this morning against a feed that stopped updating in March is fresh by every signal that matters to a monitoring tool and stale by the only one that matters here.

What a simulation may put in front of a decision-maker

Must include:

• A range, not a point. The spread is the information.
• The assumptions that drive the spread, named, so a reader can challenge the one they know is wrong.
• Coverage and oldest as_of for the entities used.
• What would have to be true for the recommendation to be wrong.

Must not include:

• A confidence percentage, unless it is derived from outcomes the twin has actually observed and scored. Absent outcome history there is no basis for one, and it lands in the position of maximum influence on the page.
• A saving presented as achieved rather than as modelled.
• A recommendation on a scenario the coverage rules said should be declined.

Scenarios a conformant twin refuses

• Workforce reduction targeting identified individuals. The model knows roles, not people, and a twin used this way launders a decision through an interface that cannot be questioned.
• Anything where the twin's own coverage of the affected entity type is unknown.
• Safety-critical or life-safety systems, where a modelled consequence is not an acceptable substitute for an engineering assessment.
• A regulatory position. A policy modelled as a constraint is a simplification of a legal text, and the simplification is exactly where the exposure lives.

How a twin is claimed without being earned

Three ways a twin is claimed without being earned. Counting entities rather than relationships, because an inventory is not a model and the relationships are the expensive part. Reporting coverage as a percentage of what was imported rather than of what exists, which makes an incomplete twin look complete. And answering a simulation with a single number rather than a range, because a range invites the question of what drives the spread.

Questions to ask

1. What is your coverage per entity type, as a proportion of what exists rather than of what you imported?
2. How do you know what exists for the types where coverage is high?
3. What is the oldest as_of in a typical simulation, and is it measured from the source change or from your import?
4. Show me a scenario your twin declined to simulate. If it has never declined one, what is the coverage threshold for?
5. Do you model relationships or only entities, and how is dependency strength established rather than assumed?
6. Where does a confidence figure in your output come from, and how many scored outcomes is it based on?
7. Which of the thirteen entity types do you not model at all?

Status

Version 0.1, draft, and the same caveat as every specification in this family: one organisation publishing a specification is a proposal. It becomes a standard when someone models an estate against it and tells us which entity type we got wrong.