Rejection or Quarantine Queue¶
A fail-closed handling process — instantiates Data-Control Boundary Inertization
Routes content that fails the boundary's checks to a held, logged disposition path — never silently dropped nor forced through — where it can be reviewed, released, or purged.
Every other mechanism at the boundary decides what to admit; this one is the fail branch — the safe destination and disposition policy for the content that was not admitted. Its defining idea is fail-closed handling: content that fails validation is neither silently discarded (which hides attacks and quietly loses legitimate data) nor forced through (which admits the very risk the check caught); it is held inert in an isolated queue, logged, and adjudicated on a policy — reviewed and released, transformed and retried, or purged on a retention clock. It owns the disposition verdict for failed content, which is a different decision from the parse-time validity check that sent the content here.
Example¶
An email security gateway scans inbound mail. A message arrives with a macro-laden attachment and headers that fail sender authentication. Delivering it is risky; deleting it is also wrong, because it might be a legitimate invoice. So the gateway routes it to a quarantine queue: the message is held in isolated storage where it cannot act, the recipient and an administrator get a notice, and a disposition policy takes over — hold for ≈30 days, allow an authorized admin release, auto-purge afterward — with every arrival, release, and expiry logged. A reviewer later inspects it and either releases it (an audited handoff back into delivery) or lets it expire. The failed item is safely parked and adjudicated, so the system never has to choose between the two bad defaults of "pass it" and "drop it."
How it works¶
- Fail-closed by default: anything the admit-path controls reject lands here, not in the live flow.
- Held inert: quarantined items sit in storage isolated from the trusted pipeline, unable to execute or render while they wait.
- Disposition policy: a verdict for failed content decides reject / hold-for-review / transform-and-retry / purge, and on what clock.
- Audited release: every arrival, release, and purge is recorded, and returning an item to the live flow requires an explicit, authorized action.
Tuning parameters¶
- Reject-versus-quarantine threshold — hard-reject outright versus hold for review. Quarantine preserves recoverable false positives at the cost of storage and a review burden; hard reject is cheaper but discards legitimate items with the bad ones.
- Retention clock — how long held items live before auto-purge. Longer aids recovery and forensics; shorter limits how long possibly-malicious content is stored.
- Release authority — who may release, and whether release needs a second review or is self-service. Stricter release resists "just release it" social engineering; looser reduces friction.
- Notification policy — whether, and what, senders and recipients are told. Notice aids legitimate recovery but can also confirm to a sender that their item was caught.
- Isolation strength — how firmly quarantined items are kept from executing or rendering while held; they must be inert in the store, not merely flagged.
When it helps, and when it misleads¶
Its strength is that it turns the failure branch into a designed outcome rather than an afterthought: content is denied by default and held safely, an instance of fail-safe defaults,[n1] and false positives are preserved for recovery instead of vanishing. Its failure modes are organizational as much as technical — a quarantine nobody reviews becomes a black hole that silently loses legitimate items, or a pressure valve that trains staff to release without scrutiny, and held malicious content is still dangerous if the store is not truly isolated. The classic misuse is using "quarantine" as a euphemism for a silent drop, or making release so frictionless that the queue is theater. The discipline that keeps it honest is to pair the queue with a real review SLA and audited, authorized release, and to keep held items inert in storage.
How it implements the components¶
rejection_or_quarantine_path— it is the safe destination for content that fails the boundary's checks: isolated, logged, recoverable, and never in the live flow.post_parse_policy_verdict— it applies the disposition verdict to failed content (reject / hold / transform-retry / purge, and on what clock), distinct from the upstream validity decision.
It does not make the parse-time validity check or hold the grammar it is checked against (allowlisted_grammar_or_schema) — that is the Allowlisted Parser or Schema Validator, whose reject verdict this queue consumes; nor does it label content's provenance (provenance_and_taint_record), which is Taint Tracking or Provenance Labeling.
Related¶
- Instantiates: Data-Control Boundary Inertization — provides the archetype's safe, fail-closed exit for anything the boundary refuses to admit.
- Consumes: Allowlisted Parser or Schema Validator and the other admit-path controls supply the reject verdict this queue acts on.
- Sibling mechanisms: Taint Tracking or Provenance Labeling · Parameterized Interpreter Call · Structured Command Construction · Template or Markup Sandbox · Contextual Output Encoding · Allowlisted Parser or Schema Validator · Capability-Scoped Tool Invocation · Content Security Policy or Execution Policy · Injection Payload Regression Tests · Least-Privilege Execution Context
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Rejection Or Quarantine Queue operates by moves rejected items through fail-closed isolation, queued review, and an explicit final disposition. That concrete deployed or enacted form is Protocol, Workflow & Routine under the frozen taxonomy.
Nearest alternative: Control, Automation & Runtime — Although Control, Automation & Runtime can support this mechanism, the frozen evidence makes its operative form the act that moves rejected items through fail-closed isolation, queued review, and an explicit final disposition; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Logged quarantine and review queues are characteristic of software security, moderation, and data-processing systems.
Related originating lineages:
- Library & Information Science — Archival and records-disposition practice independently developed held-status routing and documented release or purge.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement, origin mode disagreement adopts reviewer_a's evidence: Logged quarantine and review queues are characteristic of software security, moderation, and data-processing systems. The selected record uses alternates=library_information_science, origin_mode=convergent, and domain_reach=multi_domain; the other review proposed alternates=engineering_design, origin_mode=single_lineage, and domain_reach=multi_domain. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
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¶
Quarantine is not a synonym for drop. Its value depends on an owner: a review SLA, a purge policy, and audited release. Without that human or process backstop, a quarantine queue degrades into either a silent loss of legitimate content or a rubber stamp — both of which defeat the reason it exists.
[n1] Saltzer and Schroeder's principle of fail-safe defaults — base decisions on permission rather than exclusion, so the default action under failure or uncertainty is to deny and withhold. A quarantine queue realizes that deny-and-hold default at the boundary rather than defaulting to pass or to silent delete. ↩