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

• constraint_gate_enforcement
• false_alarm_recalibration
• immediate_feedback_routing
• independent_recomputation
• invariant_checking
• physical_impossibility_design
• redundancy_based_error_detection
• safe_commit_hold

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.

▸ 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