Self Checking Operation

Make the operation prove or test its own acceptability before its output can propagate.

Solution archetype #

947

Problem family

Correctness, Conformance & Formal Validity Failure

Problem subfamily

Insufficient Conformance & Assurance Evidence

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.”

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.

Show the applicability expression

Applicability expression4 distinct conditions

Pre-review output useandSmall errors, large failuresandAutomatically checkable invariantsandFalse pass costs more

Algebraic1∧2∧3∧4

groundedpartly groundedopen

4 conditions, all required.

4Required in every casenumbered 1–4

These hold no matter which pattern applies.

1

Pre-review output use · grounded

Outputs are copied, transmitted, committed, installed, shipped, or used before external review is likely. more

and — also required

2

Small errors, large failures · grounded

Small input, transfer, calculation, or sequencing errors can create large downstream failures. more

and — also required

3

Automatically checkable invariants · grounded

There are known invariants, relations, constraints, redundant encodings, or expected balances that can be checked automatically. more

and — also required

4

False pass costs more · grounded

The cost of a false pass is higher than the cost of checking before release. more

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.

Read the methodology · Download the trigger-logic data

Mechanisms / Implementations

• 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.
• 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.
• 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.
• 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.
• 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.
• 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.

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.

▸ Show 4 more

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.