The twin is a core building block. It answers from live state (neighbours, addresses, routing tables, policy, NAT, hit counters), not just from intended configuration, and it is the piece that lets the pipeline say, before the approval card, which flows a change would break, which it would newly allow, and who is affected.
01Two halves: a graph twin and an emulation lab
The graph twin (for example in Neo4j)
- Collected, read-only: the automation platform runs read commands on a schedule and on demand; parsers turn the output into devices, ports, VLANs, addresses, routes, neighbours, firewall rules, NAT and load-balancer objects.
- Enriched from the source of truth: roles, sites, criticality, owners, zones, naming aliases. The twin holds no source-of-truth credential; the collector exports what it needs.
- Policy models per platform: a firewall evaluated in its own order (ingress, un-NAT, to-the-box, route lookup, access rules, NAT), interface ACLs on switches and routers, routing from the installed tables.
- Path tracing hop by hop across switches, routers, firewalls, load balancers and wireless, with the deciding rule and its hit counter as evidence.
The emulation lab (Cisco CML, GNS3, EVE-NG, containerlab)
- Real device images, built by the pipeline for the slice of the network a change touches, from the source of truth and the twin's topology.
- The change's playbook runs there first, with its own verification, before production.
- Its own vault paths and identities; it can never reach production credentials.
- The graph twin answers "what would happen"; the lab shows "does the playbook actually do it on this software".
02What-if, interactively
The twin applies a scenario to a copy of its inputs and traces every regression flow before and after. Pick a scenario on this toy network:
| Golden flow | Expected | Before | After | Change |
|---|---|---|---|---|
| users-app-443 | reaches | reaches · dc-sw r10 | unreachable | would break |
| app-db-5432 | reaches | reaches · dc-sw r20 | reaches · dc-sw r20 app → dc-sw → db | unchanged |
| voice-app-5060 | reaches | reaches · dc-sw r30 | unreachable | would break |
| guest-app-443 | denied | denied · dc-sw r40 | unreachable | would break |
| users-internet-443 | reaches | reaches · fw f10 | reaches · fw f10 users → dist-1 → core-a → fw → internet | unchanged |
| guest-internet-443 | reaches | reaches · fw f20 | reaches · fw f20 guest → dist-1 → core-a → fw → internet | unchanged |
| guest-db-5432 | denied | denied · dc-sw r40 | unreachable | would break |
A toy network, invented for this page and computed in your browser. dc-sw is single-homed to core-b on purpose: "core-b down" shows a single point of failure the redundant core hides.
03What it answers
| Question | How |
|---|---|
| What breaks if this fails? | Device, link, port, VLAN or site failure over the graph; single points of failure and redundancy reports. |
| What breaks if I make this change? | Mutations (device or interface down, ACL line added or removed, route added or removed, configuration lines added, removed or replaced) on a copy, then every regression flow traced before and after. |
| What does this change newly allow? | The same diff in the other direction: flows denied before and allowed after. |
| What breaks if I replace this box? | The current device's model against the proposed replacement's policy, over the regression flows. |
| Who is affected, and how much does it matter? | Owners, criticality and service tiers from the source of truth, attached to every affected flow. |
| Is the twin itself right? | Cross-check the twin's verdict at a firewall against the device's own packet simulation on a schedule; golden flows decided against configuration backups in CI. |
04Regression flows
- Golden flows: flows with a known answer, the rule that decides it, and the path they must take. They live in Git; a change that alters one on purpose updates the file in the same merge request, so intent is reviewed with the change.
- A generated matrix: one host in every known subnet to every other, on a handful of ports, to catch what nobody wrote down.
- Observed flows: the top flows per zone pair from flow telemetry, so the test covers what people actually use.
- A flow reaches only if it is allowed and delivered where it was going; a flow that is allowed but routed somewhere else is broken.
05In the change pipeline
The twin and the lab sit between the merge request and the approval card. A break not marked as intended fails the pipeline; otherwise the blast radius goes on the card:
What, why, targets, the playbook, how to verify, how to roll back. The agent never touches a device.
Standard change
No affected flows, an approved playbook: the record-only path, approved by the change owner.
Normal change
Affected flows on non-critical services: CAB approval with the blast radius attached.
Major change
Breaks a critical service, opens a new path from outside, or touches the edge: rehearsed in the emulation lab first, in a change window.
06Keeping the twin safe and fresh
- Read-only to agents: every query runs in a read transaction; arbitrary queries refuse writes, bulk loads and administrative procedures (graph databases often have no read-only users, so this is enforced in code).
- What-if never touches the live model: mutations apply to a copy.
- Fresh enough: collected nightly and on demand, re-collected after every change; snapshots kept so a what-if can run against a named baseline.
- Tested: parser fixtures, the golden flows and the policy engines run in CI on every change to the twin.
The agents use the twin through a read-only tool server (Integrations): Heimdall for audits and drift, Mimir for blast radius during an incident.