Input Quality Check¶
Protection protocol — instantiates Bottleneck Identification and Relief
Screens incoming work at the door of the constraint, admitting only complete, correct, and relevant items so scarce capacity is never spent on avoidable clarification or rework.
Input Quality Check protects the bottleneck by controlling the quality of what reaches it. It is a gate placed just upstream of the scarce stage that inspects each item against a readiness standard — complete, correct, in-scope — and admits it only if it passes, returning or repairing the rest before it can consume constraint capacity. Its distinguishing idea is that the most expensive way to spend a bottleneck's time is on work that never should have arrived: chasing a missing field, re-doing a botched handoff, or handling an item that didn't need the expert at all. By moving that filtering to a cheaper stage in front of the constraint, the check converts wasted constraint minutes back into productive ones — without adding any capacity at all.
Example¶
At a mortgage lender, underwriting is the constraint: a small pool of licensed underwriters, each file taking real judgment. Files arrive from loan officers, and a large share are incomplete — a missing pay stub, an unsigned disclosure, an income figure that doesn't reconcile. Today the underwriter discovers each defect mid-review, stops, emails back for the document, and sets the file aside, so a big fraction of scarce underwriting time is spent not underwriting but chasing paper.
An Input Quality Check adds a completeness gate at intake: a checklist (and some automated validation) that verifies every required document and cross-field consistency before a file is allowed into the underwriting queue. Deficient files bounce back to the loan officer with a specific list; only workable files reach the underwriters. The setup changes nothing about underwriting capacity, yet each underwriter now spends their hours on files that can actually be decided — and the intake gate quietly teaches loan officers which submissions keep getting returned, so the defect rate falls over time.
How it works¶
- Define an admission standard — the concrete, checkable conditions an item must meet to be worth the constraint's time (all fields present, inputs reconciled, request genuinely in-scope).
- Screen upstream, at a cheaper stage. The check lives before the bottleneck and is performed by something cheaper than it — automated validation, a triage clerk, a self-service pre-submit — because a constraint that inspects its own input has already spent the capacity you were trying to save.
- Return or repair on failure. Deficient work is bounced back with a specific reason, or completed at the gate, rather than passed through and discovered late.
- Feed the failure signal upstream so sources learn to submit clean work, shrinking the rejection load over time instead of holding it steady.
Tuning parameters¶
- Standard strictness — what counts as admissible. Too strict and the gate starves the constraint and over-processes good work; too loose and defects slip through to the expensive stage.
- Placement — how far upstream the gate sits. Earlier catches more before effort is invested, but a gate too far from the constraint may filter on stale or over-broad criteria.
- Who performs the check — automated rules vs. a triage role vs. self-service by the submitter. Cheaper checks scale but catch less; human checks catch nuance but cost more.
- Return vs. fix-in-place — bounce deficient work to its source, or complete it at the gate. Returning teaches the source; fixing keeps flow moving but absorbs the cost centrally.
- Feedback strength — whether rejections are logged and fed back to reduce future defects, or simply handled item by item.
When it helps, and when it misleads¶
Its strength is leverage without capacity: because an hour lost at the bottleneck is an hour lost for the whole system, an hour the constraint doesn't waste on avoidable clarification is pure throughput recovered.[n1] It is most valuable exactly when the constraint's work is judgment-heavy and its inputs are frequently messy.
It misleads when the gate merely relocates the queue: rejected work can pile up upstream, and unless system-level throughput actually improves, the constraint's tidier utilization is an illusion. A gate can also harden into bureaucracy or a blame-shifting ritual ("your submission was non-conforming") that adds friction without adding flow, and it can be run backwards — used to reject work to flatter a rejection metric rather than to protect the bottleneck. The discipline that guards against this is to measure whole-system output rather than constraint utilization alone, keep the check cheaper than the clarification it prevents, and route the failure signal back so the upstream defect rate falls.
How it implements the components¶
Input Quality Check fills the protect-by-quality side of the archetype:
preprocessing_or_triage_stage— it is an upstream stage that screens and prepares work before it reaches the bottleneck, keeping unready items out of the scarce queue.bottleneck_protection_rule— the admission standard is the rule that keeps the constraint from being consumed by incomplete, incorrect, or low-value work.
It protects by controlling input quality, not quantity — capping how much work is in flight is Work-in-Progress Limit, and keeping the constraint stocked with ready work is Bottleneck Buffer. It does not identify the constraint; that is Queue Analysis.
Related¶
- Instantiates: Bottleneck Identification and Relief — Input Quality Check guards the identified constraint's usable capacity.
- Consumes: Queue Analysis (or a Bottleneck Analysis Workshop) to establish which stage is the constraint worth guarding.
- Sibling mechanisms: Work-in-Progress Limit · Bottleneck Buffer · Queue Analysis · Bottleneck Priority Rule · Staffing Relief / Cross-Training · Theory of Constraints Cycle · Process Mining / Trace Analysis · Bottleneck Analysis Workshop · Capacity Expansion · Automation of Bottleneck Stage
Editorial Notes¶
Form Classification¶
Form family: Decision, Gate & Allocation
Rationale: Input Quality Check operates as a case-specific gate, selection, routing, prioritization, or resource disposition because it screens incoming work at the door of the constraint, admitting only complete, correct, and relevant items so scarce capacity is never spent on avoidable clarification or rework
Independent corroboration: The frozen evidence defines Input Quality Check as 'Screens incoming work at the door of the constraint, admitting only complete, correct, and relevant items so scarce capacity is never spent on avoidable clarification or rework', so its operative form is Decision, Gate & Allocation.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Operations Research
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Protecting the capacity of a binding constraint by screening work upstream is rooted in operations research and Theory of Constraints.
Related originating lineages:
- Organizational & Management Science — Workflow ownership and readiness-definition practice materially shape the organizational gate.
Review resolution: Both independent reviews place the primary lineage in operations_research. The queued differences (origin_mode_disagreement, encyclopedia_synthesis_disagreement) concern secondary metadata rather than primary provenance. The final retains organizational_management only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=cross_disciplinary_synthesis because the entry's present form deliberately composes methods from the documented lineages. domain_reach=multi_domain records application breadth separately from provenance.
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¶
The check must sit upstream of the constraint and cost less than the clarification it prevents. If the bottleneck performs its own input check, you have spent the very capacity you were trying to protect — the mechanism only pays off when the screening happens somewhere cheaper than the scarce stage.
[n1] A restatement of Goldratt's rule from The Goal — "an hour lost at the bottleneck is an hour lost for the entire system." Exploiting a constraint means never letting its irreplaceable time be spent on work that a cheaper stage could have caught, prepared, or filtered out. Used here as a real, named principle, not a quantitative claim. ↩