Exception Review Workflow¶

Exception-handling process — instantiates Tolerance Band Management

Routes borderline and out-of-band cases to an accountable reviewer for a governed accept/repair/reject decision, and flags when repeat exceptions mean the band itself is wrong.

An Exception Review Workflow is the controlled path a case takes when it falls outside the band or lands ambiguously on its edge. Its whole reason to exist is that no band survives contact with reality perfectly: there will be items that are technically out of tolerance but harmless, and edge cases the rule never anticipated. This mechanism keeps those from being waved through by whoever is closest or silently dropped — it names who may grant a waiver, on what basis, and it counts the waivers so that a band being exceptioned every week gets escalated rather than quietly eroded. It is the disposition-and-governance mechanism, not the measurement or the limit.

Example¶

An infrastructure team runs a standard change process: routine deployments inside a defined blast-radius and maintenance window go through automatically. One request doesn't fit — it touches a shared database during business hours, outside the normal window. Rather than let the engineer decide alone (silent acceptance) or bounce it outright (rigid rejection), the Exception Review Workflow routes it to a change-advisory reviewer with the authority to accept it under conditions, require a rollback plan, or defer it. The decision, its rationale, and the conditions are logged against a named owner. Three months later the log shows the same "out-of-window database change" exception granted eleven times — the workflow's review trigger fires, and instead of approving a twelfth one-off, the team revisits the change policy itself, because a rule that needs waiving every fortnight is describing the process wrong.

How it works¶

Its distinguishing move is that it operates on the cases the band can't cleanly classify, and it does two things a limit cannot. First, disposition: an accountable reviewer — not the item's owner — decides accept-as-is, accept-with-repair, reclassify, isolate, or reject, and records why. Second, memory: it accumulates exceptions so that frequency becomes evidence. A single justified waiver is fine; a pattern of them is a signal that the band, the process, or the fit requirement needs to change. That second job is what separates a genuine review workflow from an ad-hoc approval — it converts individual mercy into a trigger to fix the rule.

Tuning parameters¶

Escalation threshold — how far out of band, or how ambiguous, a case must be before it routes to review rather than passing or failing automatically. Lower catches more but floods reviewers.
Reviewer authority level — who can dispose of what; a tiered board reserves high-consequence waivers for senior sign-off.
Disposition menu — the allowed outcomes (accept, repair, reclassify, isolate, reject); a richer menu handles more cases but invites inconsistency.
Review-trigger sensitivity — how many repeat exceptions, over what window, force the band itself back onto the table. Too high and tolerance creep sets in; too low and every fluke reopens the spec.
Audit trail depth — how much rationale each waiver must carry, trading reviewer effort against later defensibility.

When it helps, and when it misleads¶

Its strength is that it prevents the two failure modes a bare band produces: rigid rejection of harmless deviations and informal tolerance creep, where exceptions are granted off the books until the real band is nothing like the written one. By pinning each waiver to an owner and a reason, and by watching the frequency, it keeps the band both humane and honest. Its own failure mode is becoming a rubber stamp — a workflow that approves everything routed to it is just slow silent acceptance. The classic misuse is running it backwards: granting the waiver first and back-filling a justification, so the review documents a decision already made instead of testing it. The guard is the review trigger — waivers are counted, and a band that keeps needing them is fixed, not perpetually excused.^[1]

How it implements the components¶

exception_disposition_rule — its core: the governed procedure for accepting, repairing, reclassifying, isolating, or rejecting an out-of-band or borderline case.
tolerance_ownership — it assigns the accountable reviewer and records the decision against them, so no waiver is anonymous.
tolerance_review_trigger — it counts exceptions and, past a threshold, forces the band, process, or fit requirement back into review.

It does NOT set the band or nominal (that's Engineering Tolerance Specification), measure conformance, or run the routine correction on in-band-but-failing items (that's Quality Control Limit); it acts only on the cases those mechanisms flag as exceptional.

Instantiates: Tolerance Band Management — this process governs the edge cases that keep a static band from drifting or breaking under real-world variety.
Consumes: Quality Control Limit and Acceptance Sampling Plan — it acts on the out-of-band cases those mechanisms detect.
Sibling mechanisms: Policy Discretion Bounds · Engineering Tolerance Specification · Acceptance Sampling Plan · Quality Control Limit · Calibration Procedure · Go/No-Go Gauge · Statistical Process Control Chart · Clinical Reference Range · Grading Rubric · Service-Level Tolerance · Usability Tolerance Test

Notes¶

It pairs closely with Policy Discretion Bounds but is not the same mechanism: Policy Discretion Bounds defines the envelope of acceptable judgment up front; this workflow processes a specific case that lands outside it. One sets the rule; the other adjudicates the exception and watches whether the rule still holds.

References¶

[1] In manufacturing quality systems, a Material Review Board is the standing body that dispositions nonconforming material (use-as-is, rework, repair, scrap, return). It is the canonical instance of this mechanism — an accountable review with a bounded disposition menu — and its logs are exactly the exception record that should feed a band revision. ↩