Skip to content

Surprise-to-Action Bridge

Response-routing protocol — instantiates Predictive Residual Processing

The wiring that guarantees a validated surprise doesn't just light up a dashboard — it lands on a specific desk with a defined next move.

A residual loop can flag surprise perfectly and still fail, if the surprise goes nowhere. Surprise-to-Action Bridge is the protocol that connects a confirmed, worth-acting-on residual to a concrete decision, investigation, or learning action — with a fast bypass for the safety-critical cases that can't wait. It is purely about closure: turning "something surprising is real" into "someone is now doing X." It does not detect the surprise or judge it in hindsight; its entire reason to exist is to defeat the well-known failure where an alert everyone saw is owned by no one. Every validated surprise must exit the bridge attached to an owner and a next step.

Example

An SRE team's monitoring validates an anomaly in checkout error-rate — it's confirmed real, not a deploy blip or a monitoring glitch. The bridge takes over: it classifies severity, pages the owning on-call, attaches the relevant runbook, and opens an incident channel. Because the anomaly touches the payments path, it also invokes the safety-critical bypass — escalating straight to a senior responder instead of waiting in the normal triage queue. The residual that was merely "interesting" ten seconds ago is now a named incident with an accountable owner and a first action underway. The bridge's value is precisely that defined path from surprise to hands-on-keyboard.

How it works

  • Receive a validated surprise — one that upstream detection has already confirmed is worth acting on.
  • Classify criticality — routine, urgent, or safety-critical.
  • For safety-critical, invoke the bypass — route straight to immediate response, skipping normal queuing.
  • Otherwise fire the trigger — expand the surprise into full context and a defined action: assign an owner, open a case, attach the playbook.
  • Confirm handoff — the surprise isn't "handled" until acknowledgement and ownership are recorded.

Tuning parameters

  • Criticality classes and the bypass rule — what counts as safety-critical and earns the fast path; the highest-stakes dial.
  • Routing targets — who owns which class of surprise; a bridge to the wrong desk is as bad as no bridge.
  • Trigger richness — how much context and expanded detail travels with the alert, so the owner can act without re-investigating.
  • Acknowledgement / closure SLA — the time within which a surprise must be owned.
  • Duplicate suppression — collapsing repeats so one event isn't twenty pages.

When it helps, and when it misleads

Its strength is closing the loop — preventing the well-flagged surprise that everyone saw and no one acted on.

Its failure modes are about volume and scope. Too many triggers breed alarm fatigue and normalized deviance — the page everyone has learned to ignore — and a mis-scoped bypass either over-escalates routine noise or lets a genuinely critical case wait in line.[1] The classic misuse is wiring everything to "notify a channel" — no owner, no next step — and calling it handled. The discipline: every trigger names an owner and a defined action, the bypass is reserved for the genuinely safety-critical, and time-to-acknowledge is tracked so silent drop-offs surface.

How it implements the components

  • safety_critical_bypass_rule — it owns the fast path that routes safety- or mission-critical surprises straight to response, skipping normal handling.
  • decompression_trigger — a validated surprise fires the trigger that expands it from a terse flag into full context and a defined action.

It does not decide which residuals count as surprising in the first place (that's Event-Triggered Residual Reporting and Confidence Threshold Table), serve the full raw signal on demand when the prediction is untrustworthy (that's Raw-Signal Fallback Switch), or adjudicate the error afterward (that's Prediction Error Review).

Notes

Distinguish it from Raw-Signal Fallback Switch: the fallback switch serves the full raw signal when the prediction has become untrustworthy; this bridge routes a validated surprise to action. Different triggers, different outputs — one restores the data path, the other mobilizes a response.

References

[1] Normalization of deviance (Diane Vaughan's term for how repeated unpunished warnings come to be treated as normal) and alarm fatigue are the standard failure modes when too much is escalated; reserving fast paths for genuinely critical cases and tracking acknowledgement are the recognized guards. ↩