An autotwin is a digital twin that builds itself. Rather than being modelled by hand, it assembles from the systems of record you already run, keeps itself in step with reality through event feeds, measures its own fidelity, and carries agents that can reason on it and act within guardrails.

How is an autotwin different from a normal digital twin?

A conventional twin is a project: someone models it, and someone has to keep it current. That maintenance burden is why most twins are abandoned within a year. An autotwin treats assembly, synchronisation and fidelity checking as automated functions of the system itself, so the twin stays useful without a standing team to nurse it.

What are the three layers of an autotwin?

The network layer models the supply chain, including sub-tier suppliers, sites and routes. The asset layer models the plant, lines and equipment that convert supply into product. The agentic layer runs agents that watch both, reason about what is coming, and act within defined guardrails.

How do you know a twin can be trusted?

By measuring fidelity continuously. An autotwin reconciles its own predictions against what actually happened, reports where it is accurate and where it is not, and degrades loudly rather than silently. A twin that cannot state its own error is not a decision tool.

Autotwins | Digital Twins That Build Themselves and Act

Executive summary

Digital twins have a credibility problem, and it is not a technical one. The modelling works. What fails is the upkeep. A twin is commissioned as a project, modelled by a small team who understand the plant, and handed over. Then a line is reconfigured, a supplier is switched, a route changes, and nobody updates the model, because updating the model is nobody's day job. Within a year the twin is quietly wrong, and being quietly wrong is worse than not existing, because people are still making decisions with it.

An autotwin inverts the build. Instead of a model that people maintain, it is a model that maintains itself: assembled from the systems of record you already run, kept in step by the events those systems already emit, and continuously scored against what actually happened. On top of that live model sit agents that can watch, reason and act inside defined limits. This paper sets out the three layers, how fidelity is proven rather than assumed, and how to get to something useful in a quarter rather than a programme.

Why conventional twins stall

The pattern repeats across manufacturing, logistics and utilities. The twin is treated as a deliverable rather than a capability, and every failure follows from that.

It is modelled by hand, so it is only as current as the last person who had time to update it
It is built for one question, usually a layout or capacity decision, then has no purpose once that decision is made
It sits beside the operation rather than inside it, so nothing breaks when it goes stale
Nobody can say how accurate it is, so when it disagrees with a supervisor, the supervisor wins and the twin is ignored
It models the plant but not the supply that feeds it, so it cannot see the disruption that is actually coming

The last point matters more than it looks. Most operational surprises do not originate inside the four walls. They arrive from a supplier, a port, a component or a route. A twin that stops at the factory gate is modelling the part of the problem you can already see.

A twin that someone has to maintain will not be maintained. Automate the assembly, or accept the decay. WAJD Group

The three layers of an autotwin

An autotwin is not one model. It is three layers that share a spine, each useful alone, and considerably more useful stacked. Most organisations should build them in this order.

Layer one: the network twin

This is the twin of everything that feeds you: suppliers, the suppliers behind them, sites, components, routes, ports, lead times and the commercial terms that govern them. It assembles from purchasing and ERP records, goods receipt history, logistics and customs data, quality records and supplier disclosures. The value is not the picture. The value is that the picture is complete enough to answer questions you cannot answer today.

Which finished products stop if this one sub-tier site goes down, and how much revenue is that a week
Where do two suppliers we count as independent converge on one factory, one region or one raw material
What does our real lead time distribution look like, as opposed to the lead time in the master data
If this route closes, what is the next best route, at what cost, and how long to switch

Nobody answers those from a spreadsheet in the hour a disruption gives you. A live network twin answers them before the disruption, which is when the answer is still worth something. Our companion paper on n-tier supplier concentration goes into how the sub-tier map is actually discovered.

Layer two: the asset twin

This is the twin of conversion: the lines, cells, equipment and process steps that turn supply into product. It assembles from the control layer and the manufacturing execution system, historian data, maintenance records and quality results. It models throughput, constraint, changeover, condition and the behaviour of a process as it drifts.

Built conventionally, this is the expensive layer, because it is the one people try to model physically from first principles. Built as an autotwin, most of the model is learned from operating history and reconciled against it, with physical modelling reserved for the few places where behaviour genuinely needs to be derived rather than observed. That distinction is what turns an eighteen month simulation programme into a quarter.

Where the true constraint sits today, which is rarely where the capacity study said it would
What a change to sequence, batch size or changeover actually does to output, before committing to it
Which equipment is degrading, and what that costs if it fails in the middle of the schedule
How quality drift tracks with process conditions, and where the process is running closer to the edge than anyone realises

Layer three: the agentic twin

The first two layers make an operation legible. The third makes it responsive. Agents sit on the live twin, watch for the conditions that matter, reason about the options using the twin as their sandbox, and act inside limits you set. The twin is what makes this safe: an agent can rehearse a decision against the model before it touches the real operation, and you can see the reasoning it used.

The discipline here is the same one that governs any autonomy we deliver. Every agent has a defined scope, a stated confidence, a reversibility class and an audit trail. Actions that are cheap and reversible, such as reordering a schedule or raising a purchase for a buffer part, can be taken and reported. Actions that are expensive or hard to unwind are proposed with the evidence attached, and a human decides. There is more on this in our paper on agentic AI in operations.

Propose or act, decided per action class, never as a blanket setting
Every action traceable to the signal, the reasoning and the twin state that produced it
Confidence stated and thresholds enforced, so low confidence escalates rather than guesses
A stop that works, tested, and owned by operations rather than by the vendor

What actually makes it automatic

The prefix is doing real work. Three functions have to be automated, and if any one of them is left as a manual task, the twin decays back into a diagram.

Self assembling. The topology is derived from systems of record, not drawn. A new supplier, part or line appears in the twin because it appeared in the transactions, not because someone remembered to add it.
Self synchronising. State follows events. Goods receipts, work orders, downtime records and quality results update the twin as they happen, so its idea of the present matches the operation's.
Self checking. The twin holds itself to account by comparing what it predicted against what happened, publishing the error, and flagging where it can no longer be trusted.

Fidelity is the whole argument

Everything rests on whether people believe the twin, and belief has to be earned with numbers rather than asked for. An autotwin should be able to state, at any moment, how well it matches reality and where it does not. When a line is modified and the twin's predictions for that line start drifting, that drift should raise a flag on its own, long before someone notices in a meeting.

The practical rule is that a twin must degrade loudly. It is entirely acceptable for a twin to say it has low confidence in one area. It is not acceptable for it to present a confident number that quietly stopped being true three weeks ago.

A twin that cannot state its own error is a decoration. Fidelity, measured and published, is what makes it a decision tool. WAJD Group

Where the value lands

The returns come from decisions taken earlier and with better information, which shows up in a handful of specific places.

Disruptions absorbed rather than escalated, because the exposure was mapped before the event
Scenarios tested against a model instead of argued in a meeting, so the debate is about evidence
Capital decisions on capacity, dual sourcing and buffer stock sized against real behaviour rather than assumptions
Resilience testing that is genuinely severe but plausible, because the twin can run the scenario properly, as covered in our paper on resilience testing
Institutional memory that survives people leaving, which in most operations is the quiet risk nobody prices

How to start

Start narrow and prove fidelity early. The failure mode to avoid is a twelve month modelling exercise that produces its first useful answer after the sponsor has moved on.

Pick one decision that is expensive and currently made on judgement, and build the smallest twin that informs it
Assemble from systems of record only, and treat anything that needs manual entry as a defect in the design
Publish fidelity from week one, even when it is poor, because the credibility comes from the honesty
Add the agentic layer only after the twin has been right for long enough that people argue with reality rather than with the model
Keep the operational technology boundary intact, so data flows out safely and control stays where it belongs

Common pitfalls

Modelling the plant and ignoring the supply network, then being surprised by supply
Buying a twin platform before knowing which decision it is meant to improve
Letting the twin depend on a manual data step, which is where every abandoned twin began
Giving agents authority before the twin has demonstrated fidelity
Treating fidelity as a launch metric rather than a permanent, published one

How WAJD Group helps

We build autotwins and run them as a managed service: the assembly pipelines, the synchronisation, the fidelity scoring, and the agent layer with its guardrails, improved as the operation changes and measured against SLAs. We start with the decision, not the platform, and we expect to show a defensible fidelity number before anyone is asked to trust it. See the adjacent thinking on supplier concentration, continuous third-party risk and engineering manufacturing resilience.