Collector plus Validator: capture the running system, then compare that twin to the architecture model.
IOModel Digital Twin is the product that keeps the architecture model honest against production. It is Collector + Validator working as one loop: capture what actually runs, then compare it to what you designed.
What it answers
| Question | Who answers |
|---|---|
| What is deployed right now? | Collector |
| Does that still match the model? | Validator |
| Where did design and production diverge? | Digital Twin, in Studio, the IDE, or CI |
The Compiler is a different question: is the model internally consistent? Digital Twin never replaces that check. It asks whether the consistent model still describes reality.
How the loop works
Collect
Python collectors run in CI on build or deploy. They inspect services, dependencies and configuration and assemble a digital twin.
Push
The twin is sent to IOModel through the API and stored next to the architecture model.
Compare
The Validator walks both graphs: modeled services versus observed ones, modeled links versus observed dependencies, modeled config versus what is running.
Review
Drift shows up in
What the twin is
The digital twin is a snapshot of the real system. It is not the architecture model. Keeping both is the point: you can see the claim and the evidence in the same product.
Typical drift:
- A service exists in the model but not in the twin (or the other way around)
- A dependency is modeled and missing in production — or appeared in production without a model link
- Configuration diverged from what the model records
Where it runs
| Surface | Role |
|---|---|
| CI | Collector captures; Validator can fail the pipeline |
| Studio | Review drift on the live diagram |
| IDE Extension | See the same diagnostics while editing next to code |
Pro plan
Digital Twin (Collector and Validator) is part of the IOModel Pro plan. See Plans.
Go deeper
Last updated on