Breach Checklist¶
Monitoring checklist — instantiates Event-Script Structuring
A ready-to-hand list of the must-see events, forbidden combinations, and timing markers that flag — live, in the moment — when a familiar encounter has left its script.
A Breach Checklist is the thin, real-time instrument that turns an event script's expected unfolding into a handful of concrete watch-items, so that a departure from the script trips an alarm while the encounter is still happening. Its defining move is liveness: it is consulted during the event, not after it, and it asks only one kind of question — has the script been broken yet? — never why, and never what to do about it. Where the full script describes everything that should happen, the checklist distills only the signals whose absence, impossibility, or mistiming means this is no longer the situation we thought it was.
Example¶
An emergency dispatcher answers a call reported as first-party chest pain. Alongside the medical protocol, a breach checklist runs in the background: must-see — caller confirms the patient is conscious and breathing; must-see within the first half-minute — a callback number captured; forbidden combination — first-person symptom report paired with the caller saying they cannot see the patient; timing flag — no ambient sounds consistent with the described scene. Two minutes in, the caller mentions the patient is a neighbor down the hall they haven't laid eyes on. The forbidden-combination item fires: detailed first-hand symptoms and no line of sight cannot both be true. The script "first-party medical emergency" is flagged as breached, and the dispatcher switches to a welfare-check script and dispatches police alongside EMS. The value is entirely in the timing — the mismatch surfaced in seconds, while the call was still open, rather than when a crew arrived to a door nobody could open.
How it works¶
The checklist is distilled from the script's expected event sequence, but it keeps only the load-bearing checkpoints — the events whose failure actually changes what you should do. Items come in three shapes: presence checks (a required event must appear by a given point), impossibility checks (a combination the script forbids), and order/timing checks (an event out of its window or out of sequence). Each item is written against the script's branch-and-exception model, so a known optional path does not raise a false alarm — the checklist distinguishes a legitimate branch from a true breach. Every item resolves cleanly to fired / not-fired; interpretation and remedy are deliberately out of scope.
Tuning parameters¶
- Sensitivity vs. alarm fatigue — how many items and how tight their thresholds. Tighter catches more real breaches but floods the operator with false positives until the flag is ignored.
- Checkpoint density — how often along the sequence you check. Dense checking catches breaches early; sparse checking keeps attention on the encounter itself.
- Branch tolerance — how many known exception paths you pre-authorize before an anomaly counts as a breach. Wide tolerance suppresses noise but lets genuine drift pass as "probably just a variant."
- Escalation coupling — whether a fired item merely flags for the operator or auto-triggers a handoff. Tight coupling is fast but removes human judgment from the loop.
When it helps, and when it misleads¶
Its strength is that it makes anomalies noticeable at the only time you can still act on them — inside the live encounter. It is the standing guard against normalization of deviance, the slow process by which repeated small departures, absent any bad outcome, come to feel like the new normal.[n1]
Its central failure mode is that a checklist only ever catches the breaches it was written to expect: a genuinely novel failure that no item names sails straight through, and a list grown too long breeds tick-box complacency where a green sheet is mistaken for a safe situation. The classic misuse is treating "no items fired" as positive evidence that all is well rather than mere absence of a known alarm. The discipline that keeps it honest is to keep the list short, to review both the items that fired and the surprises that slipped past, and to route those surprises to revision rather than quietly widening branch tolerance until nothing trips at all.
How it implements the components¶
breach_detector— the fired-item logic is the detector; the checklist is a breach detector rendered small enough to run under time pressure.expected_event_sequence— it references the script's sequence, but only the checkpoints whose failure is decision-relevant.branch_and_exception_model— it encodes the known branches so that authorized deviations do not false-alarm, separating a legal variant from a real breach.
It does not interpret why a breach happened or choose the fix — the causal_link_map belongs to its nearest twin, Expectation-Violation Review, which reconstructs a breach after the fact, and the script_update_rule belongs to Script-Revision Workshop; the checklist only raises the flag in the moment.
Related¶
- Instantiates: Event-Script Structuring — supplies the live breach-detection instrument the pattern relies on.
- Consumes: Script-Card Template — the canonical step order the checkpoints are distilled from.
- Sibling mechanisms: Case-Intake Script · Counter-Script Review · Expectation-Violation Review · Interface-Flow Script · Role-Play Rehearsal · Scenario Walkthrough · Script-Card Template · Script-Revision Workshop · Service-Blueprint Script
Editorial Notes¶
Form Classification¶
Form family: Monitoring, Sensing & Alerting
Rationale: A ready-to-hand list of the must-see events, forbidden combinations, and timing markers that flag — live, in the moment — when a familiar encounter has left its script, making its operative form repeated observation of actual state that emits measurements, status, or alerts.
Independent corroboration: The frozen evidence defines Breach Checklist as 'A ready-to-hand list of the must-see events, forbidden combinations, and timing markers that flag — live, in the moment — when a familiar encounter has left its script', so its operative form is Monitoring, Sensing & Alerting.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Cognitive Science
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Detecting when an encounter departs from a familiar event script draws directly on cognitive-science accounts of scripts and schema violation.
Related originating lineages:
- Criminology & Forensic Studies — Forensic practice contributes reconstruction of entry path, affected assets, and evidentiary trace.
- Psychology — Prospective-memory and checklist research explains why an external prompt prevents omission under stress.
- Security Studies & Intelligence Analysis — Incident-response practice contributes containment, evidence preservation, escalation, and notification prompts.
Review resolution: Cognitive science is the agreed primary lineage because the checklist externalizes prospective memory at the moment a rule or boundary is breached. Psychology, security incident practice, and forensic reconstruction materially shape its prompts; the reusable diagnostic form is an Encyclopedia synthesis with multi-domain reach.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Normalization of deviance — sociologist Diane Vaughan's term, developed in her study of the Challenger launch decision, for the process by which repeated small departures from a standard, when they produce no immediate harm, are gradually redefined as acceptable practice. ↩