The Reality Twin is the why. This post is the how.
Ten darknoc-twin-* sims, all Forge apps, all running independently. The interesting part isn't any one sim — it's how they're wired into each other.
Three roles
Every sim plays one of three roles in the cascade:
- Provider — emits signals upstream consumers depend on.
- Consumer — reads providers, makes decisions, emits a higher-altitude signal.
- Hub — reads multiple upstream sims (providers and consumers), and is where the broadest cross-domain decisions happen.
The map
- Providers:
coverage-twin,demand-sim,telemetry-sim. - Consumer:
incident-simconsumes the three providers. - Hub:
security-breach-simconsumes all five upstream sims (the three providers, the consumer, pluscrm-sim). - TMF path:
growth-launch-simconsumescrm-simvia TMF v5.0 signals. - Push channel:
security-breach-sim → incident-simviaincident-feed. The hub doesn't just pull — it pushes back when containment requires a new incident to be raised.
Why bidirectional sync matters
The sims split-view. A change in the network-flow side of growth-launch-sim shows up immediately in the compartmental-model side. A demand spike in demand-sim shows up immediately in incident-sim's event timeline.
Without that sync, the sims are demos. With it, they're a working concept fabric — the loop runs end to end in the lab and you can actually see the loop closing.
What the cascade enables
- Cross-sim scenarios. A scenario like "launch day" exercises
growth-launch-sim,crm-sim, anddemand-simin the same DOIL run. - Agent training that matches reality. Autoresearch can tune an agent against a signal cascade that mirrors how the real network behaves.
- Conviction. When you see the hub catch a breach that the consumer flagged that the provider detected — three sims, one loop — you stop arguing about whether the architecture works.
Next read: Synthetic flows — how a scenario is authored against the cascade.