Self Checking Operation¶
Make the operation prove or test its own acceptability before its output can propagate.
Gap-Fill Rationale¶
This draft fills direct pilot coverage for the accepted primes error_proofing_poka_yoke and validation, both currently marked as zero-any coverage targets. Accepted neighbors cover relation constraints, data integrity, correspondence validation, and audits, but none makes embedded operation-level self-validation the central intervention.
Essence¶
A self-checking operation makes its own result prove, test, or expose whether it is acceptable before the result can propagate. It turns validation from a delayed inspection step into a built-in gate, signal, or route inside the operation.
Compression statement¶
Self-Checking Operation embeds a validation rule, redundant signal, invariant test, consistency check, or independent recalculation into the operation itself. Instead of relying only on later inspection, the operation produces evidence about whether its result is internally valid and routes pass, fail, retry, correction, or quarantine immediately.
Canonical formula: operation + embedded validity criterion + redundant/invariant evidence + immediate routing rule -> bounded error propagation
When This Archetype Applies¶
Complete catalog groundingAt least one sufficient condition set is fully represented by existing primes or domain-specific abstractions.
Diagnostic problem
An operation can produce an invalid, inconsistent, corrupted, mistyped, incomplete, or unsafe result that looks usable enough to continue. If validity is checked only later, the error spreads through downstream systems, decisions, records, or physical processes. The system needs the operation itself to generate validity evidence at the point of production or commitment.
What this problem means
An operation can emit an invalid result that looks usable enough to continue. Once accepted, the error spreads through downstream records, decisions, transmissions, or physical processes. Later audit may find the error, but the cost of repair has multiplied.
Applicability expression4 distinct conditions
groundedpartly groundedopen
4 conditions, all required.
4Required in every casenumbered 1–4
These hold no matter which pattern applies.
Pre-review output use · grounded
Outputs are copied, transmitted, committed, installed, shipped, or used before external review is likely.
This is a load-bearing situation condition in the diagnostic expression. The condition is: Outputs are copied, transmitted, committed, installed, shipped, or used before external review is likely. If it does not hold, this particular condition set is incomplete.
primeSelf Checking— A system detects errors in its own output by computing the answer through partially-independent paths and comparing.
Small errors, large failures · grounded
Small input, transfer, calculation, or sequencing errors can create large downstream failures.
Once accepted, the error spreads through downstream records, decisions, transmissions, or physical processes. The narrower requirement in this condition set is: Small input, transfer, calculation, or sequencing errors can create large downstream failures.
primeSelf Checking— A system detects errors in its own output by computing the answer through partially-independent paths and comparing.
Automatically checkable invariants · grounded
There are known invariants, relations, constraints, redundant encodings, or expected balances that can be checked automatically.
This is a load-bearing situation condition in the diagnostic expression. The condition is: There are known invariants, relations, constraints, redundant encodings, or expected balances that can be checked automatically. If it does not hold, this particular condition set is incomplete.
primeSelf Checking— A system detects errors in its own output by computing the answer through partially-independent paths and comparing.
False pass costs more · grounded
The cost of a false pass is higher than the cost of checking before release.
This is a load-bearing situation condition in the diagnostic expression. The condition is: The cost of a false pass is higher than the cost of checking before release. If it does not hold, this particular condition set is incomplete.
primeSelf Checking— A system detects errors in its own output by computing the answer through partially-independent paths and comparing.
Other requirements and context (3)
Why these sit outside the expression
Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.
Solution feasibility — it describes whether the intervention can work, not whether the diagnostic problem exists.
Supporting contextHuman operators are rushed, fatigued, distracted, or working across repetitive steps where slips are predictable.
Supporting contextA downstream process assumes that upstream outputs are valid and has weak recovery capacity.
Solution feasibilityThe operation can branch into accept, reject, retry, correct, or quarantine states without destroying usability.
Coverage
4 of 4 conditions grounded.
When to Use This Archetype¶
Use it when a known class of error can be detected at the point of entry, transformation, transmission, assembly, calculation, or commitment. It is especially useful for identifiers, databases, packets, ledgers, forms, manufacturing fixtures, medical devices, deployment pipelines, and data workflows.
Structural Problem¶
An operation can emit an invalid result that looks usable enough to continue. Once accepted, the error spreads through downstream records, decisions, transmissions, or physical processes. Later audit may find the error, but the cost of repair has multiplied.
Intervention Logic¶
Define the operation boundary, identify the failure mode, encode a checkable criterion or redundant signal, run the check inside the operation, and route pass, fail, retry, correction, quarantine, or escalation immediately. Expose check status and use failure logs to recalibrate the rule.
Key Components¶
Key components include the operation boundary definition, failure mode inventory, checkable validity criterion, redundant or independent signal, embedded check executor, accept/reject/retry route, check status exposure, override and exception control, and failure feedback channel.
Common Mechanisms¶
Common mechanisms include invariant checking, redundancy-based error detection, constraint gate enforcement, independent recomputation, immediate feedback routing, physical impossibility design, safe commit hold, and false alarm recalibration.
8 documented mechanisms across 4 implementation forms.
The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.
Assessment, Review & Assurance · 1 mechanism
- Independent Recomputation — Re-derives the same result by a deliberately different method and compares the two derivations, so a mistake in either path shows up as a disagreement.
Control, Automation & Runtime · 5 mechanisms
- Constraint Gate Enforcement — Stations an admissibility rule at the operation's boundary so an output that violates a declared constraint is rejected before it can enter or commit.
- False-Alarm Recalibration — Feeds the log of false alarms and misses back into the check itself, retuning its criterion and thresholds so the gate stays trustworthy as the operation changes.
- Invariant Checking — Makes an operation test its own result against a property that must always hold, so an internally inconsistent output flags itself before it can propagate.
- Redundancy-Based Error Detection — Attaches an independently-derived second encoding to an output and compares the two, so corruption reveals itself as a mismatch — and, when the code is rich enough, can be corrected in place.
- Safe-Commit Hold — Holds an operation's output in a non-propagating pending state until it is cleared or approved, so nothing downstream can consume it until it is known good.
Interface, Display & Cue · 1 mechanism
- Immediate Feedback Routing — Surfaces the check's verdict to the operator at the instant of the slip and routes them straight to the fix, so errors are corrected while the context is still fresh.
Structure, Architecture & Configuration · 1 mechanism
- Physical Impossibility Design — Shapes the hardware so the wrong action simply cannot be performed — the part won't seat, the plug won't fit — making a whole class of slip physically impossible.
Parameter / Tuning Dimensions¶
Tune check strictness, false-positive tolerance, false-negative tolerance, latency budget, override authority, automatic-correction scope, escalation threshold, retry limits, user feedback style, and logging depth. High-risk workflows justify stronger gates; low-risk workflows may need lighter checks.
Invariants to Preserve¶
The check must evaluate the same output downstream systems will use. Acceptance criteria must remain explicit. Check status must be visible. Overrides must be logged and bounded. Failure routes must prevent propagation rather than merely record it.
Target Outcomes¶
The target outcome is bounded error propagation: invalid outputs are caught near creation, operators receive immediate feedback, downstream systems see fewer corrupt states, and validation becomes normal operation rather than exceptional cleanup.
Tradeoffs¶
Self-checking reduces failures but adds complexity and maintenance burden. Strict gates can reject valid edge cases; lenient checks can miss important errors. Automatic correction can improve speed but hide uncertainty. Passed checks can create false confidence if their scope is not clear.
Failure Modes¶
Common failures include false assurance from narrow checks, brittle rejection of edge cases, silent auto-correction, common-cause check failure, normalized bypasses, latency bottlenecks, and check drift after system change. Mitigations include scope exposure, governed overrides, independent redundancy, bypass monitoring, tiered checking, and version-linked rule review.
Neighbor Distinctions¶
relation_constraint_enforcement blocks invalid relations and can be a mechanism inside this archetype, but self-checking is broader. data_integrity_preservation protects data across a lifecycle; self-checking operates at the production or commit boundary. correspondence_validation checks continuity across versions or domains; self-checking checks immediate output acceptability. completeness_audit finds missing coverage; self-checking prevents invalid operational output from propagating.
Cross-Domain Examples¶
A barcode check digit catches scanning mistakes. A database foreign key prevents invalid references. A packet checksum detects corruption during transmission. A manufacturing fixture blocks wrong orientation. A ledger refuses to post unbalanced entries. A deployment pipeline blocks release when invariant tests fail.
Non-Examples¶
An annual audit is not this archetype because it is delayed and external. A warning sign without an embedded check is not this archetype. Asking people to be careful is not self-checking. A later sampling review is not the same as an operation that validates before commit.
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
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → Insufficient Conformance & Assurance Evidence
Problem kernel: invalid outputs lack validity evidence at production time
Rationale: Earliest causal condition: An operation can produce an invalid, inconsistent, corrupted, mistyped, incomplete, or unsafe result that looks usable enough to continue. If validity is checked only later, the error spreads through downstream systems, decisions, records, or physical processes. The system needs the operation itself to generate validity evidence at the point of production or commitment.
Independent corroboration: The earliest necessary condition in the frozen evidence is: An operation can produce an invalid, inconsistent, corrupted, mistyped, incomplete, or unsafe result that looks usable enough to continue. That is a conformance assurance and certification problem because Outputs, controls, and whole-system claims are accepted without adequate evidence that enacted behavior meets requirements, tolerances, endpoint criteria, and valid evaluation conditions.
Review outcome: Independent reviewer agreement; high confidence.