Control Digital-Twin Changes in Inspection Workflows
A digital twin changes as assets, data and software change. Preserve the relationship between each released result and the version that produced it, and review whether a change alters the uses the owner can reasonably support.
For: Asset information owners, digital-twin project teams and inspection data managers
Define the system state that a result depends on
A result displayed by an inspection digital twin can depend on the asset model, the identity mapping, source records, processing rules, software and user configuration. If any of those change, a later display may differ even when the asset has not changed. Begin by identifying the components that determine the output relevant to the intended use.
Create a baseline reference for a released state. It should allow the organization to identify the relevant versions and evidence without copying every file into a single document. The baseline is a controlled description, not a claim that the system will never change. Its purpose is to make later changes understandable and reviewable.
Use configuration management proportionately
NASA describes configuration management as controlling and tracking changes to a baseline so that the product's configuration remains visible. Its systems-engineering guidance has a specific organizational context, but the principle is useful for digital-twin governance. [1]
Apply enough control to support the actual consequence of the system's use. A training visualization and a model informing an engineering decision may need different review arrangements. Do not copy a large aerospace process into a small project without considering whether it is usable. Equally, a simple interface does not justify informal changes when its output is used for consequential decisions.
Distinguish normal updates from changed behavior
A system may be designed to receive new inspection records or sensor values through an established process. Those expected updates are different from changing how identifiers are matched, how values are interpreted or how results are calculated. Define the boundary in the system's operating and change arrangements.
The distinction must be specific to the use case. A new record within a supported range may follow the normal update process, while a new asset class or unfamiliar data format may require impact review. Do not assume that every update is harmless because the import succeeds. The important question is whether the new information remains within the conditions the system was reviewed to handle.
Give each change a clear reason
A change request should describe the problem or opportunity, the affected component and the desired result. Examples include correcting an asset relationship, supporting a newly approved source format or resolving a display ambiguity. Avoid vague requests such as improve accuracy when the team has not identified what is wrong or how improvement will be evaluated.
Record who proposed the change and which users or decisions are affected. A request from a single user may reveal a wider issue, but it may also reflect a local preference that conflicts with another workflow. The reason helps reviewers choose appropriate evidence and prevents development effort from drifting away from the system's intended purpose.
Review the effect on data meaning
Some changes alter presentation while others alter meaning. Renaming a field, changing a unit, adjusting a time convention or redefining a status can affect how users interpret records. Have the relevant data owner and inspection specialist review those changes even when the software implementation appears small.
Preserve the original information where required and document any transformation. A corrected unit label may expose that historical values were interpreted incorrectly, while a new status name may create uncertainty about older reports. Do not repair the visible interface without considering the records and decisions that already relied on the previous meaning.
Assess identity and geometry changes carefully
A revised asset hierarchy, replacement component or updated model geometry can change where inspection evidence appears. Review whether the existing mappings remain valid and whether historical records should stay linked to an earlier configuration. A current asset view and a historical examination record may legitimately refer to different states.
Use explicit relationships for replacement, renaming or assembly changes. Avoid silently moving old evidence onto a new component merely because it occupies the same model location. The responsible asset and technical reviewers should determine the correct association. The software team can implement that decision, but it should not invent asset continuity from visual similarity alone.
Revisit credibility when intended use changes
NIST's manufacturing digital-twin research treats credibility assessment as a lifecycle activity tied to intended purpose. [2] A model reviewed for locating inspection records is not automatically supported for predicting remaining life or recommending maintenance intervals. A change in use can be more significant than a change in code.
Require the sponsor to state the proposed new decision and the evidence needed to support it. Identify additional data, uncertainty analysis and qualified review as appropriate. Keep unsupported functions clearly separated from released uses. A demonstration of a possible capability should not become an operational feature merely because users can see it on the same screen.
Map the affected dependencies
List the interfaces, reports, exports and downstream systems that use the changed information. A mapping update may affect a dashboard, a maintenance-system link and an archived export. Reviewers need to see those relationships before deciding which checks are sufficient. Otherwise the main screen can look correct while a downstream consumer receives inconsistent identifiers.
Ask the owners of connected systems to identify their assumptions. Some may rely on a stable field name, a particular status value or a specific time format. Record required coordination and release timing. A local change is not fully planned until the team understands whether another organization or system must change with it.
Build an evidence plan before implementation
For each material change, define what will be checked and who will assess the result. Include representative normal cases, relevant edge cases and previously problematic examples. The specific technical criteria belong to the qualified reviewers and governing project arrangements; this guide does not supply engineering acceptance limits.
Separate software behavior checks from checks of data meaning and intended use. A calculation may run without error while using the wrong asset association. A display may preserve every field while making an important limitation hard to see. The evidence plan should address the actual failure concerns rather than simply counting automated tests.
Worked example: a location mapping correction
In a fictional digital-twin pilot, two historical location labels are found to have been mapped to the same model object. The team proposes a corrected mapping. It would be easy to update the current view and consider the problem solved, but earlier exported views may have been used in planning discussions.
The change review identifies the affected records and outputs, confirms the corrected relationships with the asset owner and determines which recipients need updated information. New outputs receive the revised mapping version, while earlier outputs retain their original version reference and an appropriate correction record. The example demonstrates traceability; it does not establish a technical disposition for any real asset.
Keep development and released states distinguishable
Develop and test changes in an appropriate controlled environment. Users should be able to distinguish a trial state from the version released for the agreed purpose. A development feature can be useful for exploration, but its presence should not imply that its results have completed the required review.
Use clear version and status information in outputs where it matters. If screenshots or exports leave the application, include enough context to identify whether they came from a draft or released state. Otherwise a visually convincing trial result may circulate long after the team has abandoned or corrected the underlying approach.
Preserve the history of generated results
An output should retain the relationship to the data and model state that produced it. If the organization recomputes a result after a change, identify the new output separately and explain why it differs. Do not relabel the old output with the latest version merely to make the archive appear consistent.
Decide whether historical results require annotation, withdrawal from active use or further technical review. That decision depends on the impact and the organization's obligations. Preserve the basis for the decision and the communication to affected users. A version history that records only software release dates may be insufficient to explain the meaning of historical inspection displays.
Define who can approve release
Release authority should reflect the affected responsibilities. A developer can confirm implementation, an IT owner can assess deployment arrangements and a qualified technical reviewer can assess the relevant inspection use. The sponsor or designated owner decides whether the required evidence supports release under the project's governance.
Avoid one ambiguous approval box that conceals these different judgments. A small project may combine roles, but it should still identify what each approval means. Record any limitations or conditions attached to release. Approval for a bounded pilot dataset is not approval for every asset class that a future user may attempt to import.
Plan recovery before changing the active system
Identify how the prior approved state can be recovered if the change causes unexpected problems. The recovery plan may involve software, configuration, mappings and data, so restoring an application file alone may be insufficient. Have the responsible system owners determine and test the appropriate arrangement.
Define the conditions that would trigger recovery and who can authorize it. Consider what happens to new records received after the release. A rollback that removes those records without reconciliation can create a different problem. The plan should preserve evidence of the interrupted period and identify how affected outputs will be reviewed.
Communicate changes in terms users can act on
Tell users what changed, which workflows are affected and what they need to do differently. Include limitations that remain. A release note listing internal software details may be accurate but unhelpful to an inspection planner trying to understand whether an earlier export is still suitable for a meeting.
Target the communication to affected roles and retain evidence of the route used. If a change corrects misleading information, identify the earlier outputs or period concerned rather than announcing a generic improvement. Users need enough context to revisit their own decisions through the appropriate process without having to infer the consequence from a version number.
Verify the released state after deployment
Check that the active system matches the reviewed baseline and that the intended interfaces are operating as expected. Confirm representative identifiers, outputs and status information in the actual released environment. This is a release verification activity, not permission to skip the earlier evidence plan.
Record unexpected differences and assign them through the change or incident process. If the release environment behaves differently from the test environment, investigate before assuming that the approved conclusion still applies. The appropriate response may be correction, restricted use or recovery to the prior state, depending on the issue and authorized decision.
Handle urgent corrections without losing control
An urgent issue may require a shorter decision path, but the organization still needs to know what changed, why and under whose authority. Define that path before a problem occurs. Preserve the minimum evidence needed to understand the temporary action and schedule any further review that the urgent circumstances prevented.
Do not let a temporary workaround become permanent through neglect. Give it an owner, a review date and a stated limitation. If the workaround changes what users may rely on, communicate that change explicitly. Urgency can justify prompt coordination; it does not establish the technical validity of an unreviewed result.
Use the worksheet to review a real change
Choose one proposed change and complete the worksheet with the relevant owners. Identify the current baseline, intended use and likely impact before discussing implementation effort. Then agree the evidence plan, release authority and recovery arrangements. Unanswered fields should become assigned actions rather than optimistic assumptions.
Use a small worked example during the meeting, such as locating an affected historical report before and after the proposed mapping change. Ask whether a future reviewer could reconstruct both states. The worksheet is a coordination record and should connect to the organization's actual change process rather than becoming a parallel approval system with uncertain authority.
Track supplier-controlled changes too
A hosted service or external software component may change outside the owner's development schedule. Agree how the supplier communicates relevant updates and what evidence is available before they affect the inspection workflow. Identify which changes the owner can defer and which require a coordinated response under the service arrangement.
When notice is limited, use the agreed post-change checks and escalation route. Keep the supplier version or service release reference with the system baseline where available. A statement that the vendor updated something is too vague to explain a later difference in output. The owner still needs enough information to assess whether the released use remains supported.
Review the change process as the twin grows
As more assets, interfaces and users are added, revisit the configuration items and review responsibilities. A lightweight arrangement suitable for a demonstration may no longer cover a system that supports several operational teams. Growth should prompt a review of governance as well as computing capacity.
NDT Connect provides learning material and service discovery, not an automatic digital-twin approval service. Establish the actual change controls with the system owner and qualified specialists. The practical objective is to keep each released use connected to its evidence, make changes understandable and preserve the ability to explain what a result meant at the time it was produced.
Frequently Asked Questions
Does every new measurement require a full model revalidation?
Not necessarily. Define normal updates and material changes for the specific system, then use qualified impact review to decide what checks are needed.
Can an old result be relabeled with the newest model version?
No. Preserve the original result's version relationship. A recomputed result is a new output that should be identified separately.
Does passing software tests establish fitness for an inspection decision?
No. Software checks are one part of the evidence. The intended use, data meaning and technical limitations also need appropriate review.
References & Standards Cited
- NASA Systems Engineering Handbook, 6.5 Configuration Management; accessed October 31, 2026. View source ↗
- NIST, Credibility Consideration for Digital Twins in Manufacturing, 2022; accessed October 31, 2026. View source ↗
Related on NDT Connect
Join NDT Connect — free
The free marketplace for the NDT industry — connect inspectors and the companies that need them.
Free to join · Compare provider qualifications and confirm availability directly · Browse providers
By NDT Connect Editorial · Updated
Source-based editorial guidance. Read our editorial policy and disclosures.