Skip to content

Runtime Gate Co-Activation Monitor

Runtime monitor — instantiates Conjunctive Path Assurance

Watches the live system for the moment too many gates on a route are simultaneously open, and raises the alarm before the last one closes.

The analysis before deployment is never complete, and the interlock only covers the routes someone anticipated. Runtime Gate Co-Activation Monitor is the operational backstop for the conjunction that slips past both: a live detector that continuously evaluates how many edges on a hazardous route are currently conducting and raises the alarm — or trips a safe state — when the count approaches completion, while one gate is still closing. Its defining trait is that it works at run time on the real system state, watching the coincidence develop rather than reasoning about whether it could, and it feeds its confirmed near-misses back as triggers to re-open the offline analysis. It assumes the map is incomplete and watches the territory.

Example

A security operations centre runs a correlation rule that fires on no single event but on a co-activation: within one short window, a valid-but-anomalous admin login and endpoint logging disabled on that host and an unusually large outbound transfer from it. Each alone is beneath notice and routinely benign; their simultaneous truth is the developing route to data exfiltration. The monitor raises a high-severity alert while the last gate — the transfer completing — is still in progress, buying the responders minutes to cut the session. It also logs the pattern as a reanalysis trigger: a combination the pre-deployment threat model rated impossible has now been seen live, so the control model is due for revision.

How it works

Instrument the state of each edge on the routes worth watching, define the co-activation condition — typically k of n gates open within a time window — and evaluate it continuously against the live stream, alarming or tripping on approach to completion. Confirmed near-coincidences are routed into a trigger that re-opens the offline path analysis. What distinguishes it from its siblings is the combination of real-time k-of-n detection with a time window and a feedback loop to reanalysis: it is the only mechanism that operates while the system runs and treats each live near-miss as evidence the model needs updating.

Tuning parameters

  • Detection threshold (k of n) — how many simultaneously-open gates trip the alarm. A lower k warns earlier but floods with false positives; a higher k warns later but surer.
  • Time window — how close in time the openings must fall to count as co-activation; a wider window catches slow-developing routes but admits more coincidental noise.
  • Alarm versus auto-trip — whether a detection notifies a human or directly forces a safe state; auto-trip is faster, but a false positive now disrupts live operations.
  • Suppression and correlation — how related signals are de-duplicated to fight alert fatigue; over-suppression can swallow the very alert that matters.
  • Reanalysis-trigger sensitivity — which near-misses are logged as signals that the offline model needs revisiting versus dismissed as noise.

When it helps, and when it misleads

Its strength is being the last-mile defence for the conjunction the analysis missed: it watches the real system and catches the developing coincidence in time to act, and it turns operational near-misses into feedback that improves the model no static analysis would have corrected on its own.

Its failure mode is the base-rate problem: genuine near-conjunctions are rare, so even an accurate detector produces mostly false alarms, and the resulting alert fatigue leads operators to tune it down — or ignore it — until the one real event scrolls past unheeded.[1] Set the threshold too high to quiet the noise and it warns only once the route is essentially complete, too late to matter. The classic misuse is exactly that quieting: tuning the monitor to silence until it no longer fires on the real event either. The discipline is to tune k and the window to the hazard's tempo, build suppression that de-duplicates without swallowing true positives, and treat every confirmed detection as a reanalysis trigger rather than a nuisance to mute.

How it implements the components

  • co_activation_monitor — it is the runtime detector of simultaneous gate openings on a route, evaluating the k-of-n condition live.
  • change_trigger_and_reanalysis_rule — a confirmed near-coincidence is logged as a trigger to revisit and re-run the offline path analysis, closing the loop from operation back to model.

It does not prevent the conjunction — that structural break is Independent Interlock or Guard — nor decide which routes and gate-sets to instrument, which comes from Minimal Cut-Set Enumeration.

Notes

Detection is not prevention. The monitor buys reaction time, but a fast conjunction can complete before any human responds — which is why it complements the Independent Interlock or Guard rather than replacing it. The usual pairing is structural: an interlock holds a gate shut against the routes you anticipated, and the monitor watches for the developing conjunction on the routes you did not.

References

[1] The base-rate problem means that when true events are rare, even a highly accurate detector yields mostly false alarms; the resulting alert fatigue is a documented driver of ignored alarms, which is why suppression and threshold tuning are the monitor's central discipline rather than an afterthought. ↩