Digital Twin Maturity Model: Fidelity Levels, ROI and a Practical Framework (2026)
Most organisations that say they have a digital twin have a dashboard. Some have a very good dashboard, fed by live telemetry and drawn over a 3D model, and it genuinely helps operators. But it does not predict, it does not run what-if scenarios, and nothing it says ever changes a setpoint without a person typing the number. Calling it a twin is not dishonest so much as imprecise, and the imprecision is expensive: budgets are justified against the promise of an autonomous system and then judged against the reality of a visualisation.
A digital twin maturity model fixes this by giving teams a shared ladder, so that scope, cost and expected return can be matched to the rung they are actually standing on. This post offers a six-level model, separates fidelity from maturity, shows how to price each step with a defensible ROI method, and maps the levels to ISO 23247 and ISO/IEC 30173.
What this covers: why maturity and fidelity are different axes, the six levels with entry and exit criteria, a scoring script, an ROI model with worked (illustrative) numbers, standards mapping, failure modes and a staged roadmap.
Context and Background
Maturity thinking in engineering is old. The Capability Maturity Model gave software teams a vocabulary for “ad hoc” versus “managed” versus “optimised” decades ago, and it succeeded because it made investment conversations concrete. Digital twins need the same thing, because the term now spans everything from a CAD file with a sensor feed to a self-tuning plant simulation. The definition most often cited in industry, from the Digital Twin Consortium, describes an integrated, data-driven virtual representation of real-world entities and processes with synchronised interaction at a specified frequency and fidelity. Notice that the definition itself embeds two variables, synchronisation frequency and fidelity, which is the first hint that a single “twin or not” label cannot work.
The academic literature drew an early line that is still useful. Kritzinger and colleagues, in a 2018 IFAC paper, distinguished a digital model (no automatic data flow), a digital shadow (automatic flow from the physical object to the digital one) and a digital twin (automatic flow in both directions). That taxonomy is about data direction only. It says nothing about how accurate the model is, how fast it runs, or whether anyone trusts its output, which is where most projects succeed or fail.
Two standards efforts matter for a practical framework. ISO 23247, the digital twin framework for manufacturing, was published as a four-part series: Part 1 gives the overview and general principles, Part 2 the reference architecture, Part 3 the digital representation of manufacturing elements, and Part 4 the information exchange. It deliberately does not prescribe data formats or protocols. ISO/IEC 30173:2023 supplies cross-domain concepts and terminology. For a deeper tour of how these fit with Digital Twin Consortium work, see our guide to digital twin standards: ISO 23247, ISO/IEC 30173 and the DTC.
The Digital Twin Consortium’s Capabilities Periodic Table takes a different route. It is a requirements-definition framework, described as architecture- and technology-agnostic, organised into six capability categories: data services, integration, intelligence, user experience, management and trustworthiness. Its user guide notes that organisations can define their own basic and advanced levels per capability and that a formal capability maturity model with a scoring index is proposed future work, not an existing artefact (Digital Twin Capabilities Periodic Table User Guide). That gap is exactly what practitioners fill with home-grown models. The model below is one such framework. It is the author’s synthesis, not a published standard, and it is meant to be adapted.
A Six-Level Digital Twin Maturity Model
Short answer: what are the digital twin maturity levels? The model used here has six: L0 static model, L1 digital shadow, L2 diagnostic twin, L3 predictive twin, L4 prescriptive twin and L5 autonomous twin. Each level adds one new capability, and each is defined by what the twin can do for a decision, not by how impressive its graphics are.
Figure 1: The six levels of the digital twin maturity model. Each step adds one decision capability and one new class of evidence the twin must supply.
The ladder in Figure 1 reads left to right. The lower rungs describe what the twin knows; the upper rungs describe what it is allowed to do. The crucial design choice is that every level is anchored to a decision, which gives the sponsor a way to ask “which decision does this level improve, and by how much?” Levels anchored to technologies (IoT, AI, cloud) invite buying technology for its own sake.
L0 and L1: the model and the shadow
L0, static model. Geometry, bills of materials, P&IDs, simulation files and documents exist, but nothing updates them automatically. Value is real but one-off: design review, clash detection, training. Entry criterion: a versioned model with an owner. Evidence of readiness for L1: a stable asset identifier scheme, because every later level depends on being able to say that sensor tag X belongs to asset Y.
L1, digital shadow. Data flows from the physical asset to the digital one automatically, typically through an IoT or SCADA pipeline into a time-series store, with the model used for context and visualisation. The twin can answer “what is happening now and what happened before”. The exit criterion is not data volume but data trust: documented latency, known gaps, calibrated sensors and a way to detect stale feeds. Many “twins” in production stop here, and that is a legitimate and valuable place to stop if the decisions it supports are descriptive.
L2 and L3: diagnostic and predictive
L2, diagnostic twin. The model is now behavioural enough to explain a deviation. It runs state estimation or residual analysis, comparing what the model expects to what the sensors report, and attributes the difference to a cause class. A pump shows low discharge pressure; the twin separates impeller wear from a closed downstream valve because the two produce different signatures. The new capability is root-cause attribution, and the new evidence is a labelled history of faults, even if small.
L3, predictive twin. The twin forecasts future state, such as remaining useful life, temperature trajectory or throughput under a coming load. It combines physics models, data-driven models or hybrids, and, importantly, it reports uncertainty. A forecast without an interval cannot be priced into a maintenance decision. This is where verification, validation and uncertainty quantification stops being an academic topic and becomes a gate: if the team cannot show the model was validated against held-out operating conditions, it should not be called L3.
L4 and L5: prescriptive and autonomous
L4, prescriptive twin. The twin evaluates alternatives. It can say “if you reduce feed rate by 6% and delay the next batch by two hours, the predicted yield is higher and the constraint violation risk drops”. It needs a fast enough model to run many scenarios, which is where reduced-order and surrogate models usually enter. A human still approves the action. The new evidence is a decision log showing that recommendations were followed, ignored or overridden, and what happened next.
L5, autonomous twin. The twin closes the loop: it writes setpoints or schedules to the physical system within a defined safety envelope, monitors the outcome and adapts. At the far end, several twins coordinate across an ecosystem, for example a supplier twin exchanging constraints with a factory twin. Few organisations operate here outside narrow, well-bounded loops such as HVAC optimisation or certain process control layers. The exit criterion for entering L5 is safety, not accuracy: demonstrable bounds, a tested fallback, and a clear accountability owner when the autonomous action is wrong.
Why the levels are not a mandatory staircase
A common misreading is that every twin should climb to L5. It should not. A building operator whose main decision is “which floors need cleaning today” may be fully served at L1. A turbine OEM selling availability guarantees may need L3 with rigorous uncertainty bounds and gain little from L5. Maturity is a property of a twin relative to a decision, so a single organisation will usually hold twins at several different levels at once, and that is healthy.
The second misreading is that levels are cumulative in effort. Moving from L1 to L2 is often cheaper than L2 to L3 by an order of magnitude, because L3 demands validation evidence, labelled run-to-failure data or a calibrated physics model, and a governance process for model updates. Plan budgets with that nonlinearity in mind.
Fidelity Is a Separate Axis from Maturity
Short answer: what is digital twin fidelity? Digital twin fidelity is how closely the virtual model reproduces the behaviour of the real asset for a stated purpose. It has several dimensions, geometric, physical, temporal and data, and a twin can be high on one and low on another. Fidelity should be specified per decision, not maximised.
Maturity tells you what a twin does. Fidelity tells you how well it does it. Treating them as one number is the root of a lot of waste: teams pour effort into photorealistic geometry (high geometric fidelity) for a twin whose only job is to forecast energy use, where the thermal and occupancy model (physical fidelity) is what matters.
Figure 2: Four digital twin fidelity dimensions feed a purpose-fit requirement, which then selects the maturity level worth building.
The four fidelity dimensions
Geometric fidelity is shape and spatial accuracy: level of detail of the CAD, point-cloud registration error, whether tolerances are modelled. It matters for clash detection, fit-up, line-of-sight and some CFD. In construction and infrastructure it is governed by information-delivery conventions such as those in ISO 19650, which we cover in our ISO 19650 guide to BIM and digital twins in construction.
Physical (behavioural) fidelity is how well the model predicts response: a lumped thermal model with three states versus a finite-element mesh with millions. Higher is not automatically better, since a heavier model may be slower than the process it mirrors and harder to calibrate. The right comparison is prediction error against a decision tolerance. If a maintenance planner can only act in 24-hour slots, a model accurate to within ten minutes is wasted precision.
Temporal fidelity covers synchronisation: sampling rate, end-to-end latency from sensor to model state, and model update cadence. A vibration-based bearing twin may need kilohertz acquisition at the edge but only hourly model updates in the cloud. Conflating these is a classic architecture mistake. State latency budgets explicitly: sensing, transport, ingestion, model update, and presentation or actuation.
Data fidelity is the quality of what feeds the twin: sensor accuracy and drift, coverage, labelling quality, missing-data rate, and provenance. ISO 23247 lists accuracy, security, data integrity and synchronisation among its high-level framework requirements for exactly this reason, as reported in the scope of Part 1. Poor data fidelity caps everything above it, however clever the model.
Fidelity needs a purpose-fit statement
For each decision the twin supports, write a one-paragraph fidelity statement: the decision, its tolerance, the required error bound on each fidelity dimension, and how it will be measured. Example: “Decision: schedule pump overhaul within a four-week window. Tolerance: remaining-life estimate within plus or minus 15% at the 90% interval. Data: vibration at 10 kHz at the edge, process variables at 1 Hz. Model update: daily.” That statement is testable, and it prevents the endless upgrade cycle where the twin is always “almost accurate enough”.
Mapping the Levels to ISO 23247 and ISO/IEC 30173
Standards do not define maturity levels, but they define the building blocks each level needs, which makes them a useful cross-check.
ISO 23247-2’s reference architecture is organised as functional entities grouped into domains. From memory of the standard’s structure, these are the observable manufacturing element (OME) domain, the data collection and device control domain, the core digital twin domain and the user domain; verify against the published text before relying on the exact names. L1 corresponds to populating the data collection and core domains in one direction. L2 and L3 deepen the analytics and modelling functions in the core domain. L4 adds the decision and user-interaction path, and L5 exercises the device-control path in the opposite direction, which is why L5 is the first level that needs the full bidirectional chain.
ISO 23247-3 addresses how manufacturing elements are digitally represented, covering the information attributes of personnel, equipment, material, process and facility. That matters at L0 and L1, where identity and attribute consistency determine whether later models can be trusted. ISO 23247-4 concerns information exchange, which is the interoperability concern behind L1 pipelines and L5 ecosystem links. The first part names the categories of manufacturing element the framework covers: personnel, equipment, material, process, facility, environment, product and supporting documents (ISO 23247-1:2021 summary).
Figure 3: How data and decisions flow between the physical asset, the twin core and the user as maturity rises, with the ISO 23247 style domain boundaries.
ISO/IEC 30173 contributes vocabulary, which is underrated. Most disagreements in digital twin programmes are semantic: one stakeholder’s “twin” is another’s “model”. Adopt the standard’s terms in your charter, and use the maturity level to qualify them (“an L2 diagnostic twin of line 3”). The sentence is longer, but nobody will be surprised later.
The DTC Capabilities Periodic Table gives a complementary checklist. For each level, ask which of its six categories need to be at basic versus advanced strength. L1 leans on data services and integration. L3 adds intelligence and trustworthiness. L5 demands management and trustworthiness at advanced levels, because someone must operate, secure and audit a system that acts on its own.
Scoring a Twin: A Working Script
A maturity model is only useful if two assessors reach roughly the same answer. The script below turns the framework into a repeatable scoring rubric. Each level has weighted evidence questions answered 0, 1 or 2 (absent, partial, demonstrated). A twin’s level is the highest level at which at least 80% of the evidence points are met, and every lower level must also pass; this “no skipping” rule stops a flashy L4 demo hiding a missing L1 data foundation. The rubric values are illustrative defaults, so tune them for your domain.
#!/usr/bin/env python3
"""Digital twin maturity scorer. Evidence 0=absent, 1=partial, 2=demonstrated."""
from dataclasses import dataclass
LEVELS = {
0: ("Static model", ["versioned_model", "asset_id_scheme", "named_owner"]),
1: ("Digital shadow", ["automated_ingest", "latency_documented",
"stale_data_detection", "sensor_calibration_log"]),
2: ("Diagnostic twin", ["state_estimation", "fault_signature_library",
"root_cause_attribution", "labelled_event_history"]),
3: ("Predictive twin", ["validated_vs_holdout", "uncertainty_reported",
"drift_monitoring", "model_versioning"]),
4: ("Prescriptive twin", ["scenario_engine_fast_enough", "decision_log",
"constraint_handling", "human_approval_flow"]),
5: ("Autonomous twin", ["write_back_path", "safety_envelope_tested",
"fallback_tested", "accountable_owner"]),
}
PASS_RATIO = 0.80
@dataclass
class Result:
level: int
name: str
ratios: dict
def score(evidence: dict) -> Result:
ratios, achieved = {}, -1
for lvl in sorted(LEVELS):
name, items = LEVELS[lvl]
got = sum(min(max(evidence.get(i, 0), 0), 2) for i in items)
ratios[lvl] = got / (2 * len(items))
if ratios[lvl] >= PASS_RATIO and achieved == lvl - 1:
achieved = lvl
name = LEVELS[achieved][0] if achieved >= 0 else "Below L0"
return Result(achieved, name, ratios)
if __name__ == "__main__":
pump_twin = {
"versioned_model": 2, "asset_id_scheme": 2, "named_owner": 2,
"automated_ingest": 2, "latency_documented": 2,
"stale_data_detection": 2, "sensor_calibration_log": 1,
"state_estimation": 2, "fault_signature_library": 2,
"root_cause_attribution": 1, "labelled_event_history": 2,
"validated_vs_holdout": 1, "uncertainty_reported": 0,
}
r = score(pump_twin)
print(f"Achieved L{r.level} ({r.name})")
for lvl, ratio in r.ratios.items():
print(f" L{lvl}: {ratio:.0%}")
Run on the sample evidence, the pump twin scores L2: L0 passes at 100%, L1 passes at 88% (seven of eight points), L2 passes at 88%, and L3 fails because uncertainty reporting is absent. The output is actionable in a way a bare number is not: the gap list for the next level is exactly the missing evidence items. Use it in workshops, have two assessors score independently, and treat disagreements as the interesting output.
Digital Twin ROI: Pricing Each Level Honestly
Short answer: how do you calculate digital twin ROI? Compute net present value per decision, not per platform: for each decision the twin improves, estimate the annual value of the improvement (avoided cost plus gained margin), multiply by a realisation factor that reflects adoption and model error, then subtract build, run and governance costs over the same horizon. Discount, and sum across decisions.
Digital twin ROI claims in vendor material tend to be large and unfalsifiable because they are quoted at the platform level, bundling many benefits and excluding most of the costs. A per-decision approach is more work and much more credible. It also has a useful side effect: it exposes which levels pay back and which are speculative.
Where value comes from at each level
L0 and L1 mostly deliver avoided search and coordination cost: engineers stop hunting for the latest drawing or the last known reading. The value is real but is proportional to the headcount and time currently wasted, which can be measured with a simple time study. L2 delivers faster diagnosis, so the metric is mean time to diagnose and, through it, downtime hours. L3 converts unplanned events into planned ones. The benefit is the difference in cost between a planned and an unplanned intervention, multiplied by the number of failures the forecast catches early enough to matter, and discounted by false alarms. L4 captures optimisation value: yield, energy, throughput or inventory improvements, usually single-digit percentages of a large base. L5 adds labour and latency savings but carries the highest risk cost.
The realisation factor is the part most business cases omit. A prediction that nobody acts on is worth zero, so multiply by the fraction of recommendations that are executed in time, and by one minus the model’s relevant error rate. In practice this factor is often between 0.3 and 0.7 in the first year; treat that range as a planning assumption to be replaced by measured data, not as a benchmark.
A worked example, with illustrative numbers
Take a fleet of 40 pumps in a process plant. Every figure below is illustrative, chosen to show the arithmetic, and is not drawn from a published case study. Assume an unplanned pump failure costs 60,000 in lost production, repair and expediting, while a planned overhaul of the same pump costs 18,000. Historically 8 unplanned failures occur per year. A predictive twin (L3) is expected to give sufficient warning for 55% of them, and a realisation factor of 0.6 accounts for late action and model error.
Annual benefit: 8 failures x 55% catchable x (60,000 – 18,000) x 0.6 = 8 x 0.55 x 42,000 x 0.6 = 110,880. Now costs. Suppose the L3 build (instrumentation completion, model development, validation, integration) is 220,000 in year one, with 70,000 per year to run: cloud and edge, model monitoring, a part-time data scientist and reliability engineer. Over a five-year horizon at a 10% discount rate, the net present value is the discounted benefits minus costs.
Discounted benefit annuity factor for five years at 10% is 3.791. Benefits: 110,880 x 3.791 = about 420,360. Run costs: 70,000 x 3.791 = 265,370. Build: 220,000 at year zero. NPV = 420,360 – 265,370 – 220,000 = about -65,000. Under these assumptions the project loses money. That result is a feature of an honest model, not a failure of it, and it shows how sensitive the case is to two things: the failure rate and the cost of running the twin.
Change one assumption and the picture shifts. If the fleet were 100 pumps with the same per-pump failure rate and incremental run cost scaled only to 110,000 a year, annual benefit becomes 277,200, and NPV rises to roughly 277,200 x 3.791 – 110,000 x 3.791 – 220,000 = 1,050,865 – 417,010 – 220,000 = 413,855. Scale economies in twin economics come from reusing one validated model across many assets, which is why the strongest ROI cases are fleet problems, not single-asset ones.
Figure 4: The per-decision ROI flow. Decision value is discounted by adoption and model error, then set against build, run and governance cost.
The costs people forget
Four cost lines are routinely missing from digital twin business cases. First, instrumentation gaps: the sensors you need are rarely the sensors installed. Second, validation: building evidence that the model is right, with held-out data and expert review, can equal the model development effort. Third, model upkeep: drift, asset modifications and process changes mean models degrade, so retraining and recalibration are recurring costs rather than one-time ones. Fourth, change management: operators must trust, understand and act on recommendations, and that takes training, interface work and time.
A practical rule of thumb used by many teams, and offered here as an opinion rather than a sourced figure, is to budget annual run cost at 25 to 40% of the build cost for levels L2 and above. Compare against your actuals after the first year and replace the heuristic.
Deeper Analysis: Running the ROI Model in Code
The arithmetic above is easy to get wrong in a spreadsheet and hard to audit. A small script makes assumptions explicit, supports sensitivity analysis and can be committed alongside the twin. The version below reproduces the worked example and then sweeps the two most uncertain inputs.
#!/usr/bin/env python3
"""Per-decision NPV for a predictive digital twin (illustrative inputs)."""
from itertools import product
def annuity(rate: float, years: int) -> float:
return (1 - (1 + rate) ** -years) / rate
def npv(failures_per_year, catch_rate, unplanned_cost, planned_cost,
realisation, build_cost, run_cost, rate=0.10, years=5):
annual_benefit = (failures_per_year * catch_rate
* (unplanned_cost - planned_cost) * realisation)
a = annuity(rate, years)
return annual_benefit * a - run_cost * a - build_cost, annual_benefit
if __name__ == "__main__":
base = dict(failures_per_year=8, catch_rate=0.55, unplanned_cost=60_000,
planned_cost=18_000, realisation=0.6,
build_cost=220_000, run_cost=70_000)
value, benefit = npv(**base)
print(f"Base case: annual benefit {benefit:,.0f}, NPV {value:,.0f}")
print("\nSensitivity of NPV to catch rate and realisation")
print("catch\\real " + " ".join(f"{r:>9.1f}" for r in (0.3, 0.5, 0.7, 0.9)))
for c in (0.3, 0.5, 0.7):
row = []
for r in (0.3, 0.5, 0.7, 0.9):
p = dict(base, catch_rate=c, realisation=r)
row.append(f"{npv(**p)[0]:>9,.0f}")
print(f"{c:>10.1f} " + " ".join(row))
# Break-even: smallest fleet multiplier for NPV >= 0, assuming
# failures scale with fleet but run cost grows at only 40% of fleet growth.
for m in (1, 1.5, 2, 2.5, 3):
p = dict(base, failures_per_year=base["failures_per_year"] * m,
run_cost=base["run_cost"] * (1 + 0.4 * (m - 1)))
print(f"fleet x{m}: NPV {npv(**p)[0]:>10,.0f}")
The base case prints an NPV of about -65,000, matching the manual calculation. The sensitivity table makes the lesson visible: at a catch rate of 0.3 almost nothing is profitable, while at 0.7 and a realisation factor of 0.7 the project is comfortably positive. The fleet loop shows the break-even turning positive somewhere between 1 and 1.5 times the original fleet under the stated run-cost scaling assumption. Replace every number with your own, and have the reliability team challenge the catch rate in particular, since it is the input least supported by evidence in the first year.
Staging the investment
Because value and uncertainty both rise with level, fund in stages with explicit gates. A gate should require evidence from the previous level, not a slide deck. For example, release L3 funding when the L2 twin has demonstrably cut mean time to diagnose on at least a defined number of incidents, and when a labelled event history exists with enough failures to validate a forecast. This turns the maturity ladder into a risk-reduction mechanism: each rung buys information about whether the next one is worth building.
Trade-offs, Gotchas, and What Goes Wrong
Maturity inflation. Once a maturity model exists, teams are tempted to score themselves generously because level numbers become a proxy for status. Counter this with evidence-based scoring, as in the script above, independent assessors and a rule that a level claim must be demonstrable in a live walk-through, not a slide.
Fidelity creep. Because fidelity has no natural ceiling, a twin can absorb unlimited budget chasing a perfect model. The purpose-fit statement is the defence. If a fidelity improvement does not change a decision or tighten a decision tolerance, it is not scheduled.
The pilot trap. Many programmes build an impressive L3 pilot on one carefully instrumented asset, then discover that scaling it needs a standard asset-identity scheme, a data contract per asset class and a model-governance process that did not exist. The pilot’s ROI was real, and the fleet’s ROI is negative until the foundations are built. Test scalability early by deploying the L1 pipeline to ten assets before building the L3 model for one.
Data-direction confusion at L5. The step from L4 to L5 changes the risk class entirely. A recommendation that is wrong costs a bad decision that a human may catch. A write-back that is wrong acts on the asset. Safety cases, change control, cybersecurity review and a rollback path are not optional extras. Apply them before any actuation, and keep the human-approval path available permanently as a degraded mode.
Model decay. Predictive models drift as assets age, are repaired or change operating regimes. Without drift monitoring and scheduled revalidation, an L3 twin silently becomes an L1 twin that happens to emit confident-looking numbers. This is worse than a plain dashboard, because users trust the forecast.
Semantic mismatch across vendors. A maturity model cannot paper over incompatible information models. If the shadow data, the simulation inputs and the asset registry disagree about what “asset 4711” is, no amount of AI will reconcile them. Invest in identity and units early.
Framework limits. This model is deliberately simple. It does not capture lifecycle phase (design twin versus operational twin), the twin’s scope (component, system, system of systems) or whether the twin is composable across vendors. Treat it as one lens, and combine it with the DTC capability categories for requirements and with ISO 23247 for architecture where manufacturing is in scope. It has also not been validated against a large empirical sample of organisations, and the pass threshold and the weights are judgement calls.
Practical Recommendations
Start by inventorying the twins you already have and scoring each one honestly with the rubric. Most organisations find a handful at L0 and L1, a few at L2 and almost none at L3 with real validation. That inventory is your baseline for every later conversation.
Next, pick decisions, not technologies. Select the three to five decisions with the largest annual value and the most measurable outcome, write a fidelity statement for each and compute the per-decision NPV using conservative realisation factors. Fund the cheapest rung that improves each decision. For most, that is L1 or L2.
Build foundations once. Asset identity, data contracts, a time-series store with documented latency, and a model registry are shared across all levels and decisions, and they are where reuse produces the scale economies that make fleet-level ROI positive. Align terminology with ISO/IEC 30173 and, for manufacturing, structure the architecture along ISO 23247 domains.
Gate every step up with evidence, and put model monitoring in the plan from the day the first predictive model ships. Finally, re-score twins every six months. A level is a perishable claim.
- Score every existing twin with an evidence rubric and publish the results internally.
- Write a one-paragraph fidelity statement per decision, with tolerances and measurement method.
- Compute per-decision NPV with a realisation factor and run a sensitivity table.
- Standardise asset identity and data contracts before scaling a pilot.
- Require validation and uncertainty evidence before any L3 label.
- Require a safety case, fallback and accountable owner before any L5 actuation.
- Re-score every six months and track drift metrics continuously.
Frequently Asked Questions
What is a digital twin maturity model?
A digital twin maturity model is a staged framework that classifies a twin by what it can do for decisions, from a static model through a data-fed shadow and diagnostic or predictive twin to prescriptive and autonomous operation. It gives organisations a shared vocabulary so that scope, cost and expected return can be matched to a realistic level. Several models exist, and none is a formal standard, so define your levels and evidence criteria explicitly.
How many digital twin maturity levels are there?
There is no universal number, because no standard fixes one. Published and proprietary models use anywhere from three to six or more levels. The model in this post uses six, L0 to L5, because each step adds one distinct decision capability: model, shadow, diagnosis, prediction, prescription and autonomy. What matters is that each level has testable entry criteria rather than the exact count.
What is the difference between a digital twin and a digital shadow?
In the widely cited taxonomy by Kritzinger and colleagues, a digital shadow receives data automatically from the physical object, but changes in the digital model do not automatically change the physical one. A digital twin has automatic data flow in both directions. In practice, many industrial projects labelled twins are shadows, and this post’s maturity levels add further distinctions based on diagnostic and predictive capability.
How do you measure digital twin ROI?
Measure it per decision. Estimate the annual value of each improved decision, multiply by a realisation factor covering adoption and model error, and subtract build, run, validation and governance costs over a stated horizon, discounted to present value. Include recurring model upkeep. Use sensitivity analysis on the least certain inputs, typically the fraction of events the twin actually catches early enough, and replace estimates with measured data after the first year.
Does a higher digital twin fidelity always give a better result?
No. Fidelity should match the decision. Geometric detail does not help an energy forecast, and a high-resolution physics model may run too slowly to support a scheduling decision. Specify required accuracy, latency and data quality for each decision, then build only to that tolerance. Extra fidelity beyond the tolerance adds cost and calibration burden without changing outcomes, and can make the twin harder to maintain.
How does ISO 23247 relate to digital twin maturity?
ISO 23247 does not define maturity levels. It defines a framework for digital twins in manufacturing, with parts covering principles, reference architecture, digital representation of manufacturing elements and information exchange. It is useful as a cross-check: each maturity level depends on specific architecture domains and data flows, and the standard’s requirements, such as accuracy, security, data integrity and synchronisation, map directly to the data-fidelity checks in the rubric.
Further Reading
- Digital twin standards: ISO 23247, ISO/IEC 30173 and the DTC for how the standards families relate.
- ISO 19650, BIM and digital twins in construction for geometric and information-management fidelity in the built environment.
- Digital twin verification, validation and uncertainty quantification for the evidence an L3 claim requires.
- Reduced-order and surrogate models for real-time digital twins for making L4 scenario analysis fast enough.
- Digital Twin Consortium Capabilities Periodic Table User Guide for the capability categories.
- ISO/IEC 30173:2023 on the ISO website for the terminology standard.
By Riju — about
