Digital twins, scenarios, and deterministic simulation.

Aurora is the digital-twin and simulation specialist. It is a capability rather than another assistant, and it keeps no memory of its own: a turn starts from the authorized project’s Atlas context, identifies the simulation evidence that is missing, and returns eligible normalized findings to that project’s memory.

Twin and run behavior

A twin is a bounded declarative document (eventium.aurora.twin.v1): stocks and flows driven by named parameters, 3D entities bound to stocks for the spatial view, and named scenarios.
Every parameter names its source — the opaque id of the Atlas evidence that grounds it, or assumption. Assumptions are reported back as missing simulation evidence rather than quietly standing in for it.
The engine is deterministic: fixed-step integration and seeded Monte Carlo. It runs no user-supplied code.
Findings written to Atlas are recomputed on the server from the model. Client-supplied text is never stored as a finding.
twin.v2 adds a route graph — an origin, bays, junctions and vehicles — for discrete-event runs. A run is the twin, the scenario, the seed and the ordered operations, so any branch is recomputed from scratch and is identical to its parent up to the first new operation.

Aurora simulates; it does not actuate. An operation changes one declared operable property of the simulation at a simulation time — a bay’s open, a vehicle’s active or, within its declared range, its speed. There is no path from here to physical equipment.

Operations

The operations this product exposes today. The full contract, with schemas, is in the REST API reference.

POST /api/aurora/turns — Run a turn against a twin.
POST /api/aurora/runs — Start a discrete-event run from a twin and scenario.
POST /api/aurora/runs/operations — Branch a run by applying declared operations.
POST /api/aurora/findings — Return eligible normalized findings to project Atlas memory.

Open Aurora →