Invariant Guarding¶
Identify conditions that must always remain true and guard operations so those invariants are preserved.
The Diagnostic Story¶
Symptom: The system keeps reaching states that everyone agrees should have been impossible. Integrity, safety, or eligibility problems surface only after downstream work has already proceeded, making cleanup expensive. Different actors disagree about which exceptions are allowed because the must-preserve property was never made explicit. Automation or delegation has amplified what was once a small rule weakness into widespread state corruption.
Pivot: Declare the invariants explicitly, identify every transition that could violate them, and add guard conditions with defined violation responses. Maintain those guards as the system changes rather than treating them as one-time additions.
Resolution: The system keeps changing to act and adapt, but properties necessary for safety, integrity, or legitimacy hold across those changes. Violations are caught before commitment rather than discovered after the fact, and the cost of compensating fixes shrinks because preventable violations stop occurring.
Reach for this when you hear…¶
[database engineering] “The constraint should live in the schema, not in application code that someone will forget to call -- if the invariant can be violated at all, it will be.”
[medical device] “We found a sequence of valid-looking commands that could put the device into an unsafe mode -- each step passed its own check, but nobody was verifying the combined state.”
[financial compliance] “A transaction can look legitimate in isolation and still blow a regulatory limit when you account for the position it lands on -- the guard has to see the whole picture.”
When This Archetype Applies¶
Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.
Diagnostic problem
A system changes over time, but some properties must remain stable for safety, integrity, identity, authority, or viability.
What this problem means
The structural problem is that change threatens a property the system depends on. Individual actors, operations, or automated steps may each seem reasonable, but their effects can combine into a state that violates safety, integrity, authority, identity, or legitimacy.
Invariant failures often appear as impossible states: records that should not exist, orders that should not have been released, exceptions that should not have been approved, or configurations that should not have been reachable. These are signs that the invariant may be known culturally but not guarded structurally.
Show the applicability expression
Applicability expression3 distinct conditions
groundedpartly groundedopen
3 conditions, all required.
3Required in every casenumbered 1–3
These hold no matter which pattern applies.
Operation-preserved property · grounded
A named necessary property must remain unchanged under every permitted operation on a shared state.
The source archetype describes the situation as follows: Multiple operations can alter a shared state, record, resource, or commitment. The property at risk is necessary rather than merely desirable. The normalized requirement above isolates the load-bearing portion used in this condition set.
Locally valid global violation · grounded · any one of 6
A transition can pass local checks while violating a wider safety, integrity, authority, or identity property.
The source archetype describes the situation as follows: A transition may appear locally valid while breaking a wider safety, integrity, authority, or identity condition. The normalized requirement above isolates the load-bearing portion used in this condition set.
Bypassable informal invariant · open
Exceptions, delegation, concurrency, or automation can bypass informal invariant judgment.
The source archetype describes the situation as follows: The system has exceptions, delegation, concurrency, or automation that can bypass informal judgment. The normalized requirement above isolates the load-bearing portion used in this condition set.
Other requirements and context (1)
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.
Supporting contextViolations are costly to detect or reverse after the state is committed.
Coverage
2 of 3 conditions grounded · 1 open.
Mechanisms / Implementations¶
- Database Constraint: Encodes a record invariant — uniqueness, referential integrity, a balance rule — directly in the data schema so the store itself rejects any write that would break it.
- Safety Interlock: Makes a hazardous action physically impossible unless every enabling safety condition is true, holding the system in a safe default state until they are.
- Invariant Test Suite: Expresses declared properties as executable assertions and exercises common, rare, and regression cases offline, so a change that would break the invariant fails before it ships.
- Contract Check: Attaches preconditions, postconditions, and state assumptions to a boundary and evaluates them at runtime, so a transition is refused the moment it would break the contract.
- Policy Guardrail: Routes, refuses, or demands evidence for decisions that might violate a rule, right, or separation-of-duties requirement, with scoped exceptions and a named owner.
- Integrity Monitor: Watches live state for violations, near misses, and bypasses and records them, surfacing invariant breaks that slipped past the guards so they can be governed.
- Rollback Transaction: When a change fails its invariant check partway through, returns the system to a known-good state instead of leaving a partial or invalid result committed.
- Two-Person Rule: Requires two authorized people to independently confirm a high-risk transition before it proceeds, so no single actor can break the invariant alone.
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 (4)
- Boundedness: Values remain within limits.
- Closure: Ensures operations remain within a set.
- Data Integrity: Accuracy and consistency preserved.
- Invariance: Properties unchanged under transformation.
Also references 8 related abstractions
- Accountability: Responsibility for actions.
- Boundary: Defines system limits.
- Constraint: Limits possibilities to guide outcomes.
- Fail-Safe: Default to safe state on failure.
- Fault Tolerance: Continue operating under failure.
- Function (Mapping): Relates inputs to outputs.
- Set and Membership: Groups and categorizes elements.
- Transaction: All-or-nothing operations.
Variants¶
Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.
Runtime Invariant Guarding · implementation variant · recognized
Guard invariants while a system is operating, so invalid transitions are blocked, repaired, or rolled back before they become committed state.
Policy Invariant Guarding · governance variant · recognized
Guard institutional or policy conditions that must remain true across decisions, exceptions, delegation, and implementation drift.
Safety Interlock Guarding · risk or failure variant · recognized
Guard life, health, or damage-prevention invariants by preventing hazardous transitions when required safety conditions are absent.
Data Integrity Invariant Guarding · domain variant · likely subtype
Guard record, ledger, schema, or provenance properties that must remain true as information is created, transformed, or reconciled.
Editorial Notes¶
Problem Classification¶
Classification: Correctness, Conformance & Formal Validity Failure → State Transition & Transaction Integrity
Problem kernel: state changes can violate protected invariants
Rationale: Required safety, identity, authority, and viability properties are not checked and preserved across every legal transition.
Independent corroboration: The earliest necessary condition in the frozen evidence is: A system changes over time, but some properties must remain stable for safety, integrity, identity, authority, or viability. That is a state transition and transaction integrity problem because State changes admit illegal successors, broken invariants, partial completion, order effects, ambiguous absence, or inconsistent observations across concurrent participants.
Review outcome: Independent reviewer agreement; high confidence.