The Digital Twin Maturity Model

The Twin Identity Crisis

Ask five people in manufacturing IT what "digital twin" means and you will get five answers. A vendor with a 3D visualization of a warehouse calls it a digital twin. A BI team with a Tableau dashboard hooked up to an IoT feed calls it a digital twin. A research lab running computational fluid dynamics on a jet engine calls it a digital twin.

They are all technically correct, which is part of the problem. When the same label covers a static bar chart and an autonomous decision engine, the term stops being useful for planning. Organizations end up overestimating their maturity ("we already have a twin") or underestimating the investment required ("we just need a real-time dashboard").

A maturity model helps cut through the ambiguity. It gives you coordinates: where you are, what each level requires, and what you get at each stage. Here is a framework we find useful.

Level 1: Descriptive -- The Expensive Screenshot

At Level 1, your "digital twin" is a reporting layer with better aesthetics. You have aggregated data from your ERP, MES, SCADA, and maybe a handful of IoT sensors into a dashboard. It shows current state: production throughput, inventory levels, machine status. It updates periodically, sometimes in near-real-time.

Functionally, this is a data warehouse with a friendlier UI. The twin describes what happened and what is currently true. It cannot tell you why. It cannot tell you what will happen next. And nobody checks it at 2am when the production line goes down -- they call the floor supervisor who has been running that line for fifteen years.

Most organizations that claim to have a digital twin are here. The dashboards look great in executive presentations. They inform exactly zero operational decisions that were not already being made by experienced humans with spreadsheets. The value is real -- consolidating data sources into a single view is genuinely useful -- but calling it a "twin" is generous.

Level 2: Diagnostic -- Now You Know Why It Broke

Level 2 adds root-cause analysis. The twin does not just show you that Line 3 is producing at 72% efficiency instead of the target 88%. It correlates that drop with a pattern: the tooling change at 6am, the temperature spike in Zone B at 7:15am, the material lot switch at 8am. It surfaces hypotheses about what is going wrong and why.

This sounds like a natural progression, but the engineering leap is significant. Diagnostic capability requires a semantic layer -- some formal understanding of how different data sources relate to each other. You cannot correlate sensor readings with maintenance logs unless the system knows that Sensor-47 is mounted on Machine-12, which was last serviced under Work Order WO-2024-3891, which replaced the spindle bearing that is now showing elevated vibration. That chain of relationships is domain knowledge, and most systems do not have it.

The Level 2 Wall

This is where most organizations stall, and the reason is not technical -- it is organizational. Building diagnostic capability means modeling your domain formally. It means getting operations, engineering, and IT to agree on what entities exist, how they relate, and what "normal" looks like. That is a political problem disguised as a technical one.

The organizations that break through the Level 2 wall are the ones that invest in domain modeling before they invest in analytics tooling. Everyone else buys a correlation engine, points it at uncurated data, and wonders why the root-cause suggestions are nonsense.

Level 3: Predictive -- Seeing Around Corners

A Level 3 twin uses historical patterns, simulation models, and machine learning to forecast future states. When will this machine fail? When will inventory drop below safety stock? Which supplier is likely to miss next Tuesday's delivery window based on their current shipping patterns?

Prediction is also where ontology starts becoming really important. Statistical models are great at finding correlations in data -- so good that they will find correlations between the cafeteria menu and production yield if you let them. A formal domain model constrains the search space, telling the algorithm which relationships are physically or logically possible. Without that, predictive models tend to produce impressive-looking outputs that do not hold up operationally.

A well-grounded Level 3 twin is genuinely powerful. Predictive maintenance -- replacing components before they fail based on degradation models -- is one of the more proven applications. Demand forecasting that accounts for supply chain constraints can help mitigate the bullwhip effect that traditional MRP runs are prone to. Companies like Siemens and Bosch have invested heavily here, and the results are real when the underlying domain model is sound.

Level 4: Prescriptive -- The Twin That Has Opinions

Level 4 crosses a psychological barrier. The twin does not just predict that Machine 7 will fail in 72 hours. It says: "Here are three options. Option A: replace the bearing during tonight's changeover, with a known parts-and-labor cost, zero additional downtime. Option B: run at reduced speed until the scheduled maintenance window on Friday, with some probability of mid-run failure and the associated emergency repair cost. Option C: reroute production to Machine 9, which has capacity but requires a 45-minute reconfiguration."

The prescriptive twin evaluates trade-offs against business objectives. To do this, it needs to understand not just what is happening and what will happen, but what should happen. That means encoding goals, constraints, policies, and priorities -- exactly what an enterprise ontology provides. Minimize cost? Minimize downtime? Maximize on-time delivery? These are not parameters you tune. They are business rules you formalize.

Very few organizations operate at Level 4 today. The ones that do tend to have two things: a deep domain model and a culture that trusts system-generated recommendations. The second is harder to build than the first.

Level 5: Autonomous -- The Twin That Acts

The autonomous twin closes the loop. It does not recommend actions; it takes them -- within predefined guardrails. It reorders materials when stock projections cross a threshold. It reroutes production when a machine degrades. It adjusts pricing when demand signals shift. Humans supervise. They intervene for edge cases and policy changes. But the operational steady state runs without them.

Level 5 is aspirational for most enterprises, but it is not science fiction. FANUC's lights-out factories have been running CNC machines unattended for over a decade. Autonomous mobile robots from companies like Locus Robotics and 6 River Systems manage warehouse fulfillment with minimal human intervention. Algorithmic trading systems have operated autonomously for years. The pattern is consistent: where you have a formal, executable model of the domain and well-defined guardrails, autonomy works.

The gap between Level 4 and Level 5 is not technology. It is trust, liability, and organizational readiness. The autonomous twin requires an ontology so rigorous and comprehensive that you are willing to let it make decisions on your behalf. That is a high bar. It should be.

Where You Actually Are (Be Honest)

The vast majority of organizations claiming to have a digital twin are at Level 1. A smaller group has reached Level 2 for specific, well-instrumented processes. Meaningful Level 3 work is rarer still. Level 4 and 5 are uncommon enough that the companies doing it -- FANUC, some Siemens reference sites, a handful of semiconductor fabs -- tend to be well known for it.

There is nothing wrong with being at Level 1 -- consolidating data sources into a single view is genuinely valuable. The important thing is being clear-eyed about what it takes to move up. Each level requires significantly more domain modeling, data quality, and organizational commitment than the one before it.

The Common Thread: Domain Modeling

Looking across these levels, the pattern is clear: the bottleneck is almost never compute or tooling. It is domain modeling. Each level requires a richer, more formal model of your operations -- what entities exist, how they relate, what constraints govern them, what objectives matter. Getting that model right is slow, unglamorous work that involves operations, engineering, and IT actually agreeing on how the business works.

P3 is our attempt to make each level transition more tractable by providing a reusable semantic foundation. But regardless of what tools you use, the domain modeling is the real work. If your organization has not agreed on what entities exist and how they relate, no amount of tooling will move you from Level 1 to Level 3. The modeling comes first. The technology enables it, but does not replace it.