Containment on Alarm¶
Procedure — instantiates Fail-Safe Default
A procedure or automation that quarantines, isolates, blocks, or closes off a hazard when an alarm occurs — walling off the affected part while the rest keeps running.
Containment on Alarm is the response that, on receiving an alarm, moves a suspect part of a system into a predefined isolated holding state — quarantined, sealed off, blocked from propagating — rather than stopping the whole operation. Its defining idea is locality: the hazard is presumed containable, so the right default is to wall off the affected element and let the unaffected remainder continue, buying time to investigate without either spreading the harm or halting everything. It is the opposite reflex to a global shutdown: keep the ship afloat by sealing one flooded compartment, keep the pipeline flowing by diverting the bad records into quarantine. Because the affected part is held rather than destroyed, containment inherently owns the shape of that isolated state, its legibility, and the discipline for releasing it — while the sensing that raised the alarm, and the decision of what counts as an alarm, come from elsewhere.
Example¶
A data platform ingests millions of records a day that feed automated pricing decisions downstream. A validation monitor raises an alarm: a batch from one upstream source has begun arriving with malformed timestamps that would corrupt any calculation using them. Containment on Alarm does not stop the pipeline — the other sources are fine and pricing must keep running. Instead, on that alarm, the affected records are diverted into a quarantine store: a holding area that blocks them from reaching the pricing engine while leaving the rest of the flow untouched. The quarantined batch is flagged in the operations dashboard with its size and source, so no one mistakes "held" for "processed." Nothing corrupt reaches a decision; nothing good is stopped. Later, once the upstream timestamp bug is fixed and the held records are corrected or discarded, a defined release procedure lets the cleaned data re-enter the flow. The hazard was walled off, not shut down — and only the bad slice ever felt it.
How it works¶
- React to an alarm, don't hunt for one. The trigger is an alarm raised by a monitor; containment's job begins the moment the alarm arrives.
- Divert the affected part into a holding state. Route the suspect flow, records, compartment, or host into a predefined quarantine that blocks propagation.
- Preserve the remainder. Leave unaffected parts running; the whole point is local isolation, not global halt.
- Make the quarantine legible and releasable. Flag what is held and why, and define the procedure for inspecting, cleaning, and releasing (or discarding) it.
Tuning parameters¶
- Blast radius of containment — how much gets isolated per alarm. Isolating widely is safer but sacrifices more availability; isolating narrowly preserves throughput but risks missing hazard that has already spread.
- Reversibility of the hold — whether quarantined items can be cleaned and released or only discarded. Reversible holds recover value; irreversible ones are simpler but lossy.
- Auto-release vs. gated release — whether items leave quarantine automatically once conditions clear or require review. Gated release prevents re-admitting the hazard; auto-release keeps things moving.
- Quarantine capacity and aging — how much can be held and for how long. Ample capacity avoids overflow; aging rules stop the quarantine from silently growing forever.
When it helps, and when it misleads¶
Its strength is proportionality: when a hazard is genuinely local, containment preserves availability while still stopping the harm — you neither ignore the bad batch nor throw away the whole day's throughput. It is the archetype's answer to "does this really require stopping everything?"
Its failure mode is the silent black hole: a quarantine that fills unattended, so the "held" items are never reviewed, the upstream cause is never fixed, and containment quietly becomes data loss — the exact pathology a dead-letter queue develops when nobody reads it.[n1] The classic misuse is treating containment as the resolution rather than a pause: the alarm stops firing, everyone relaxes, and the hazard sits walled off but unaddressed while the real problem festers. The guarding discipline is to make the quarantine loudly legible, alert on its growth, and pair every containment with a review-and-release policy so isolation is a holding pattern, not a grave.
How it implements the components¶
Containment on Alarm fills the local-isolation-and-hold slice of the archetype — the parts a quarantine procedure owns:
hazardous_failure_mode— it is built around one specific danger: a hazard that propagates (a corrupt batch, a spreading breach, a flooding compartment) if not walled off.safe_default_state— the quarantine/isolated holding state is the safe state it enters and maintains for the affected part, distinctively local rather than a whole-system stop.status_indicator— it flags what is held and why, so isolated items are never mistaken for processed ones.recovery_policy— its inspect-clean-release procedure is the disciplined path for returning held items (or discarding them) without re-admitting the hazard.
It does NOT implement failure_detector or shutdown_or_isolation_rule — Containment on Alarm does not sense the anomaly or decide the transition logic; it reacts to an already-raised alarm and holds an isolated state. Sensing plus the halt-transition rule belong to its twin Automatic Shutdown, which stops the whole operation rather than isolating one flow.
Related¶
- Instantiates: Fail-Safe Default — Containment on Alarm supplies the local-isolation safe state that walls off a hazard while the rest continues.
- Consumes: Automatic Shutdown — the monitoring logic that senses the anomaly and raises the alarm containment reacts to.
- Sibling mechanisms: Emergency Stop · Dead-Man Switch · Trip Switch or Circuit Trip · Automatic Shutdown · Fail-Closed or Fail-Open Design · Safe Mode · Watchdog Timer
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: A procedure or automation that quarantines, isolates, blocks, or closes off a hazard when an alarm occurs — walling off the affected part while the rest keeps running, making its operative form a live operational control that automatically routes, enforces, adapts, or responds during execution.
Independent corroboration: The frozen evidence defines Containment on Alarm as 'A procedure or automation that quarantines, isolates, blocks, or closes off a hazard when an alarm occurs — walling off the affected part while the rest keeps running', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Process-safety engineering cohered automatic isolation of a suspect compartment or flow on alarm while unaffected operations continue.
Related originating lineages:
- Computer Science & Software Engineering — Data and service operations independently developed quarantine queues and host isolation on alerts.
- Disaster Management & Risk Reduction — Emergency containment practice contributes cordons and controlled holding states with gated release.
Review resolution: Alarm-triggered local isolation cohered independently in safety engineering, digital quarantine, and emergency containment; the unified cross-domain formulation is synthesized.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; medium confidence.
Notes¶
[n1] A dead-letter queue is the standard software instance of containment: messages that fail processing are diverted into a side queue rather than blocking or crashing the pipeline. Its notorious weakness is also containment's central risk — an unmonitored dead-letter queue silently accumulates failures no one ever revisits, turning a safety hold into quiet data loss. ↩