Skip to content

Digital-Twin Hazard Rehearsal

Method — instantiates Conjunctive Path Assurance

Rehearses a specific dangerous conjunction — with its real timing — inside a high-fidelity simulation, so the end-to-end route can be exercised without exposing the live system.

Some conjunctions cannot be provoked on the real system — the whole point is that they are catastrophic — and some only bite when their conditions overlap in a particular window that a static model cannot feel. Digital-Twin Hazard Rehearsal meets both problems by driving the suspected conjunction inside a high-fidelity executable copy of the system and watching, in full dynamic detail, whether the hazard actually completes. Its defining move is timing: it does not just ask whether the conditions can co-occur, it sweeps their relative timing and overlap to find the exact envelope in which the route conducts — order-of-events and near-simultaneity effects that logic tables and solvers, which see only static combinations, cannot represent. It rehearses a few plausible catastrophes in depth rather than enumerating all of them.

Example

An autonomous-vehicle team suspects a conjunction: low sun blinding the forward camera, a pedestrian stepping off a median, a wet road extending braking distance, and the radar briefly discarding the pedestrian as clutter. No one will stage that on a public road. In the twin, they script exactly that scenario and — crucially — parameterise the timing: the glare arrives some fraction of a second before the pedestrian becomes visible, and they sweep that offset across a range while jittering sensor noise over hundreds of runs. The twin's instrumentation checks a single end-to-end question each run: did the vehicle stop before the conflict point? The result is a timing envelope — the band of relative delays in which the stack fails to brake in time — handed to the control team as the specific condition to design out.

How it works

Build or validate a twin faithful in the dynamics that matter (physics, sensor latency, control loops); script the joint-fault scenario; parameterise the relative timing and overlap of its conditions and sweep that parameter; run many stochastic repetitions to expose rare coincidences; and read the twin's instrumentation as the end-to-end oracle for whether the target state was reached. What distinguishes it from exhaustive testing is that it does not brute-force all combinations — it rehearses chosen high-consequence ones with full dynamic fidelity; and what distinguishes it from a solver is that it observes behaviour rather than proving a property, so it can model messy continuous dynamics at the price of never proving absence.

Tuning parameters

  • Fidelity versus cost — how faithful the twin is (physics, noise, latency, actuator dynamics). Higher fidelity earns more trust but costs build effort and compute; low fidelity risks a sim-to-real gap that invalidates the result.
  • Timing-sweep resolution — how finely the relative timing and overlap of the conditions is varied. Finer resolution finds narrow dangerous windows but multiplies the run count.
  • Scenario selection — which conjunctions to rehearse, since you cannot run them all. Good selection comes from a fault tree or cut-set list; bad selection rehearses the wrong catastrophe convincingly.
  • Stochastic repetition — how many noisy repeats per scenario. More repeats expose rare timing coincidences but cost compute.

When it helps, and when it misleads

Its strength is that it is the only mechanism here that exercises the dynamics and timing of a conjunction end-to-end and does so safely — surfacing order-dependent and overlap-dependent hazards that every static method misses. Its failure mode is that results are only as trustworthy as the twin's fidelity: the sim-to-real gap means a hazard absent in simulation may still exist in the world, and it can only rehearse scenarios someone thought to script, so it confirms and quantifies known conjunctions far better than it discovers unknown ones. The classic misuse is reading "it didn't reproduce in the twin" as "it's safe," or tuning the twin until the troublesome scenario passes. The discipline is to validate the twin against real telemetry or incident data, source scenarios from an independent hazard analysis, and treat a clean run as evidence bounded by fidelity, never as proof.[1]

How it implements the components

  • digital_twin_or_safety_sandbox — the twin is the safe executable environment in which the otherwise-catastrophic conjunction is provoked and observed.
  • temporal_overlap_model — its defining capability is parameterising and sweeping the relative timing and overlap of the conditions.
  • end_to_end_activation_oracle — the twin's instrumentation is the check that decides whether the full route actually conducted in each run.

It rehearses rather than enumerates or watches live: the exhaustive combinatorial_coverage_plan is Full-Factorial Joint-State Test's, sound proof over all states is Model Checking and Reachability Analysis's, and the live-system co_activation_monitor is the Runtime Gate Co-Activation Monitor's.

Notes

A twin used to find hazards, not merely to demonstrate a design, must be validated independently of the design team — otherwise it inherits the same blind spots the design has, and a clean rehearsal certifies the assumption rather than the system.

References

[1] The sim-to-real gap is the discrepancy between a simulation and the physical system it models; it is why a rehearsal that shows no hazard bounds confidence by the twin's fidelity rather than establishing safety outright, and why twins are validated against real-world data before their verdicts are trusted. ↩