Contents
Before committing to a digital-twin project, define what the proposed representation should help people understand or decide. Agree the relationship between the model, the available observations and the real operating process. Readiness depends on that specific use and the evidence required to support it.
State the purpose in operational terms
Identify the user, the question and the action that may follow. Distinguish reviewing current conditions from exploring a hypothetical scenario or recommending a change. Each purpose requires a different account of what the model represents and how its output will be checked.
Define success for the first use without relying on the label attached to the project. Explain why the proposed model is needed and what a simpler reporting or analysis approach would leave unanswered. Keep the initial scope small enough to evaluate meaningfully.
Make the model boundary explicit
Record which assets, processes and relationships are represented and which are omitted. Describe the assumptions, parameters and operating conditions that affect interpretation. Have the relevant domain specialists review those choices before the interface makes the result appear authoritative.
Separate observed values from calculated or assumed values. Decide how users will recognise the difference. If a scenario changes an assumption, retain that context with its result so a hypothetical output cannot be mistaken for a current measurement.
Check whether the required data exists
Inventory the sources, identifiers, units and timestamps needed by the model. Verify access through approved interfaces and inspect representative data quality. Record missing context and historical gaps rather than treating planned collection as though it already exists.
Agree how stale, incomplete or inconsistent observations affect the model's use. Define what the application should show when a required input is unavailable. Include the work needed to maintain mappings as equipment and processes change.
Define validation for the intended use
Ask the domain owner to specify the comparison method and acceptable limits for the proposed decision. Choose representative conditions and record those not assessed. Keep the evidence tied to the model version, input data and assumptions used.
Review discrepancies rather than hiding them in an aggregate result. Determine whether they arise from data, assumptions or implementation. A convincing visualisation is not a substitute for evidence that the model is suitable for the decision being proposed.
Test interpretation and responsibility
Observe whether intended users can explain the output and its limitations. Include normal, incomplete and disputed cases in the review. Define when the result should lead to further investigation and who is authorised to make an operational decision.
Keep changes to equipment or operating procedures subject to the responsible engineering and site process. The software should make its advisory or analytical role clear. Record escalation and support arrangements so uncertainty has an owner rather than being passed silently to the user.
Plan for the model to change
Assign ownership for data quality, model updates and re-evaluation. Identify events that require review, such as equipment changes, revised assumptions or a new intended use. Preserve versions and decision records so earlier results remain explainable.
Use a bounded pilot to establish whether the proposed approach meets its purpose. Review the maintenance effort as well as the initial result before expanding. A readiness decision should state what is supported now, what remains uncertain and who is responsible for the next step.
A digital-twin readiness exercise for an advisory scenario
A fictional operations team wants to compare scheduling scenarios for one production line. First state the decision: estimate whether a changed schedule may increase waiting time under specified assumptions. Separate observed cycle durations from assumed demand and calculated queue behaviour. A three-dimensional view of the line does not establish that the model supports this decision.
The domain owner defines validation: compare the model with representative held-out operating periods, including startup and interruptions, using tolerances suitable for this advisory use. Record equipment, input quality, model version and conditions not assessed. If the available history lacks interruptions, disclose the gap and commission evidence rather than labelling the model validated for them.
Test missing observations, an equipment change and a scenario outside the supported range. The interface should show limitations and prevent an assumed scenario from appearing as current measured state. NIST’s manufacturing digital-twin programme includes validation and trust concerns; its existence does not validate this model. Keep operational changes under the responsible site process and revisit readiness whenever the intended decision or represented equipment changes.
How this relates to Veda Software’s work
Encounter is adjacent evidence of specialist information delivered through a user workflow. It supplies no digital-twin model, manufacturing validation or evidence for the fictional scheduling scenario.