
What an Enterprise Twin Is (and Why It Isn't an Org Chart)
An Enterprise Twin is a living, scored model of how your organization actually works — its systems, processes, and people — kept current from real change data. Unlike an org chart, it shows where work flows, where the single points of failure are, and where AI would actually pay off.
- Leon GinsburgFounder & CEO
In this article
An Enterprise Twin is a living, scored model of how your organization actually works — its systems, processes, and people, and the connections between them — kept current from real change data. Unlike an org chart, it doesn't show who reports to whom. It shows where work really flows, where your single points of failure are, and where AI would actually pay off.
What is an Enterprise Twin?
A digital twin, in engineering, is a live model of a physical thing — a jet engine, a factory line — that mirrors the real object closely enough to reason about it. An Enterprise Twin applies the same idea to an organization. It is a typed graph: the systems you run, the processes that move work through them, and the people who operate both, connected by the real dependencies between them. It is built from your actual systems, not from a slide someone drew, and it carries scores that let you compare one part of the organization to another.
The point of building it is not to have a prettier diagram. It is to be able to ask questions of your organization the way you'd query a database — where does this process actually bottleneck, who is the one person holding it together, what would break if we changed this system — and get answers grounded in how work really flows, rather than how someone believes it does.
How is it different from an org chart?
An org chart answers exactly one question: who reports to whom. That's useful for HR and almost nobody else, because reporting lines are not where work happens. The person everyone actually depends on is rarely the person at the top of the box, and the process that quietly runs the business often crosses six departments the chart draws as separate.
| Dimension | Org chart | Enterprise Twin |
|---|---|---|
| Shows | Reporting lines | How work actually flows |
| Built from | HR's intent | Your real systems and processes |
| Updates | When someone remembers | From a live change stream |
| Answers | Who's my manager? | Where's the risk, and where does AI pay off? |
The difference isn't cosmetic. An org chart is a statement of structure; a twin is a model of behavior. You can run questions against behavior.
What does the twin actually model?
Three layers, and the edges between them, which are where most of the insight lives:
Systems. The applications and data stores that run the business, and how they connect — the same systems a governed AI platform already integrates with.
Processes. The flows of work that cross those systems: how a claim, an order, or a hire actually moves, including the informal steps no policy document mentions.
People. Who operates and depends on each system and process — modeled as roles and relationships, not as personal profiles.
Because it's a typed graph, every node and edge has a kind, which is what makes it queryable. "Show me every process that depends on a single person and touches a system we're about to retire" is a graph query, not a workshop.
Where are your single points of failure?
This is the question the twin answers that nothing else can. In graph terms, the people and systems that hold an organization together are the ones with high betweenness centrality — the nodes that sit on the most paths between other nodes. Remove one and a disproportionate number of processes lose their connection.
That's a precise, measurable definition of key-person risk, and it routinely surprises leadership. The critical dependency is often not the senior name on the chart but a long-tenured operator three levels down who is the only bridge between two systems nobody else understands. The twin makes that person visible before they take the knowledge with them, which is the whole point of finding them.
Key-person risk is usually discovered the expensive way — when the person leaves. Measured as centrality on a live model, it becomes something you can see coming and plan around.
Scoring AI-readiness 0–100
"Where should we use AI?" is normally answered by a vendor survey and a gut feeling. The twin answers it with a score. Each process gets an AI-readiness rating on a 0–100 scale, built from the factors that actually determine whether automation will work there — how structured the data is, how repeatable the decision is, how well-documented the process is, and how much it depends on tacit judgment that resists automation.
The value isn't the number in isolation; it's that the numbers are comparable. A readiness score lets you rank a hundred candidate processes against each other on a defensible basis, so the first thing you automate is genuinely the thing most likely to pay off — not the thing whose sponsor argued loudest.
(The factors a readiness score combines — structured data, repeatability, tacit dependence, and others — are weighted per organization.)
The opportunity map: from model to backlog
Once processes are scored and dependencies are mapped, the twin can produce an opportunity map — a ranked view of where automation would deliver the most value against the least risk. That map is not a strategy deck; it's the input to a build backlog. The processes that score high on readiness and high on impact become the first candidates, and each one arrives with its context already attached: which systems it touches, who depends on it, and what would have to be true for a change to be safe.
This is where the twin connects to the rest of a governed AI platform. The opportunity it surfaces is the spec the agent-building side of the platform then builds and gates — so "where's the value" and "let's build it, safely" are two ends of the same pipeline rather than two disconnected projects.
How it stays current: a twin that updates itself
A model of an organization that's accurate the day you build it and wrong a month later is worse than useless, because people will trust it while it drifts. The twin avoids that by projecting from a live change stream rather than a periodic export. As systems change — a new integration, a retired application, a shifted process — the model re-projects, so the risk map and the readiness scores reflect the organization as it is now, not as it was during last year's consulting engagement.
That "living" property is what separates an Enterprise Twin from the digital-transformation slideware it superficially resembles. A slide is a snapshot someone has to redraw. A twin is a query you can run again tomorrow and trust the answer.
Frequently asked questions
See your organization as a model you can query. Walk through how the Enterprise Twin maps your systems, processes, and people, measures key-person risk, and scores where AI would actually pay off — kept current from live change data. Book a walkthrough.