Self Checking Operation¶
Make the operation prove or test its own acceptability before its output can propagate.
The Diagnostic Story¶
Symptom: Invalid, inconsistent, or incorrect outputs leave their point of origin looking plausible and only reveal themselves downstream — in a reconciliation, a failed use, an audit, or a physical failure that is now expensive to trace back. Error detection depends on heroic manual review or on a downstream system that assumes the upstream was clean. Small slips — a transposed field, a transmission error, a calculation that returned an implausible value — compound into large failures because nothing at the source was checking.
Pivot: Insert an embedded validation layer into the operation itself, at the moment of production or commitment: encode the invariants, constraints, or redundant checks that should hold, and route the output through an explicit accept, reject, retry, correct, quarantine, or escalate path before it propagates.
Resolution: Invalid outputs are caught near their point of creation, so downstream systems receive cleaner inputs and operators get immediate feedback rather than delayed blame. Error-proofing is embedded in the workflow rather than dependent on memory or vigilance alone, and check status is visible rather than silently assumed. Audits shift from discovering routine preventable errors to improving the design of the checks themselves.
Reach for this when you hear…¶
[data engineering] “We found the bad account numbers in the reconciliation six weeks later — if the ingestion pipeline had a format check at the point of entry, we'd have caught it in thirty seconds.”
[surgical checklist] “The wrong-site incident happened because we trusted everyone to remember — the check has to be part of the procedure itself, not something you do if you have time.”
[manufacturing assembly] “That part can be installed backwards and it looks fine until the unit fails in the field — we need a fixture that makes the wrong orientation impossible.”
Mechanisms / Implementations¶
- constraint_gate_enforcement
- false_alarm_recalibration
- immediate_feedback_routing
- independent_recomputation
- invariant_checking
- physical_impossibility_design
- redundancy_based_error_detection
- safe_commit_hold
Related Abstractions¶
Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.
Built directly on (2)
- Error Proofing (Poka-Yoke): Error prevention.
- Validation: Confirming that an artifact actually solves the intended problem in its real operational context, as distinct from confirming it was merely built to specification.
Also references 14 related abstractions
- Algorithm: Step-by-step problem-solving procedure.
- Closure: Ensures operations remain within a set.
- Constraint: Limits possibilities to guide outcomes.
- Controllability: Ability to steer system.
- Data Integrity: Accuracy and consistency preserved.
- Fault Tolerance: Continue operating under failure.
- Feedback: Outputs influence inputs.
- Invariance: Properties unchanged under transformation.
- Observability: Infer internal state externally.
- Quality Control: Checking output against a specification before release and rejecting or reworking non-conforming items, binding process variation to defined tolerances through a measure-compare-act feedback gate.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Check-Digit Validation
Referential Integrity Self-Check
Checksum and Error-Correction Gate
Physical Poka-Yoke Self-Check
Pre-Commit Invariant Gate
Independent Recalculation Check