Resiliency Verification and Drills

Proving the resiliency stack works by injecting faults in simulation and demanding a safe outcome every time - before hardware exists.

Claims must be tested

A resiliency design is only as good as its evidence. Fault-injection testing deliberately triggers each enumerated failure mode - in the digital twin pre-FOAK, on hardware later - and checks that the stack detects it, responds correctly, and reaches a safe or degraded state within the required time. A mode that has never been drilled is an unproven claim, not a capability.

The drill matrix

Every FMEA entry maps to at least one drill. The drill specifies the injected fault, the expected detection latency, the required response, and the acceptance criterion. Coverage is measured as the fraction of FMEA modes with a passing drill; the goal is complete coverage of high-RPN modes.

def run_drill(twin, inject, expect):
    twin.reset(); twin.inject(inject)
    result = twin.run_until_settled()
    return {
      'detected_ms': result.detect_latency_ms <= expect.max_detect_ms,
      'response':    result.action == expect.action,
      'safe':        result.final_state in expect.safe_states,
    }

Honest verification pre-FOAK

Because Hyperion and the burner are design-and-simulation studies before FOAK ~2030, all drills today run against the twin with modelled physics. We report drill results as simulation coverage, distinguishing modes validated against real component-test data from those resting on models alone - and the burner plug-regime drills carry the 166-830x extrapolation caveat explicitly. As hardware arrives, the same drill suite migrates to commissioning tests, and results from each unit feed the fleet and every postmortem.