Interlock Integration
Hardware interlocks are the last line of defense and act independently of software; orchestration integrates with them but never replaces them.
Defense in depth
The Kronos control philosophy layers protection: predictive orchestration (L4) aims to avoid faults, and hard-wired interlocks (below L1) catch what prediction misses. Interlocks are physical or firmware safety circuits that act in real time, with no dependence on the event plane, the twin, or the copilot. Orchestration integrates with them, observes their state, and defers to them, but never sits in their protective path.
Independence is the point
If the entire software stack, including L4, froze, the interlocks would still trip a breeder quench energy-dump or a burner magnet safe-state on their own. This is why the fast quench and over-current protection are hardware, not orchestration; the quench-abort workflow coordinates the rest of the machine but the reflex is hard-wired.
Software-to-interlock contract
- Orchestration reads interlock status as high-priority events but cannot disable an interlock.
- Every command respects interlock preconditions; a command that would violate one is rejected upstream at the rules stage.
- An interlock trip is a P0 event that preempts all procedures and forces a safe-state saga.
| Layer | Acts on | Can be disabled by software |
|---|---|---|
| hardware interlock | real-time reflex | no |
| rules engine | every command | no (audited change only) |
| envelope checker | every command | no (audited change only) |
| twin/copilot | proposals only | n/a (cannot actuate) |
Why orchestration still matters
Interlocks protect the machine but at a cost: a trip usually means an aborted shot or shutdown. Predictive orchestration exists to keep the machine inside limits so interlocks rarely fire, improving availability without weakening the last-line guarantee. Interlock trips are journalled to the lineage bus and analyzed via replay to improve the predictive layer.