Invariant Propagation Test¶
Test or assessment — instantiates Inductive Validity Extension
Runs repeated transitions or simulated steps and checks whether the stated invariant remains true after each transition.
Invariant Propagation Test takes a single running sequence and interrogates one thing at every step: does the invariant still hold after this transition? Rather than reasoning about an infinite domain or generating a scattershot of independent cases, it drives one process through many actual transitions — real or simulated — and asserts the invariant at each boundary between steps. Its defining move is positional: the check sits between consecutive states of a single execution, so when it fires it names not just that the property broke but the exact transition that broke it. It is less interested in whether a claim is universally true than in where along the chain it first stops being true.
Example¶
A data pipeline ingests raw sales records and passes them through eight transformation stages — dedup, currency-normalize, join to accounts, aggregate, and so on — before a revenue dashboard reads the result. The team's invariant is stated once: total recognized revenue must equal the sum of source line-item amounts, minus explicitly logged adjustments. Trusting the dashboard because the raw import was correct is exactly the unsupported extension the archetype warns against; eight transformations sit between import and display.
So the Invariant Propagation Test asserts the revenue-reconciliation invariant as a checkpoint after every stage. Running a day's data through, seven stages preserve the total to the cent — and the aggregation stage drops it by 0.4%. The test localizes the break immediately: a rounding step in aggregation silently truncated fractional cents. The failure is not "the dashboard is wrong" but "the invariant died at the aggregation transition," which points a single engineer at a single stage. The fix restores propagation, and the checkpoint stays wired in so any future regression at any stage trips at the exact step it occurs.
How it works¶
- Fix one invariant, expressed as a runtime assertion. The property is checkable mechanically on any intermediate state — an equality, a bound, a schema, a conservation law.
- Instrument every transition boundary. Place a checkpoint after each step of the same sequence, so the invariant is re-evaluated on the actual state the previous step produced.
- Drive the sequence and watch for the first break. Run the process (or a faithful simulation) and let the checkpoints fire; the earliest failing checkpoint localizes the fault to one transition.
- Report position, not just verdict. Output is "held through step 7, failed at step 8," which is diagnostic in a way a pass/fail on the final output is not.
Tuning parameters¶
- Checkpoint density — after every transition, or only at a few critical boundaries. Denser checks localize faults precisely but add runtime overhead and assertion-maintenance cost.
- Real vs. simulated steps — drive the live process or a modeled surrogate. Live runs are faithful but slow and may lack rare states; simulation covers more but inherits the model's blind spots.
- Invariant strictness — exact equality versus a tolerance band. Too strict trips on benign floating-point noise; too loose lets real drift slip under the threshold.
- Sequence length — how many transitions to run before declaring propagation established. Short runs miss slow accumulating drift; long runs cost time.
When it helps, and when it misleads¶
Its strength is localization: because each check is pinned between two adjacent states of one execution, a failure indicts a specific transition rather than the whole system, which is what makes it a staple of data pipelines, control loops, and safety procedures. It formalizes the same instinct as design by contract[n1] — a running assertion that must hold at defined points — applied across a sequence rather than at a single interface.
Its failure mode is that it only ever checks the invariant you wrote, on the sequence you happened to run. A day of well-behaved data can preserve an invariant that a rare input class would violate, so a clean run certifies propagation for that trace and no more. It is also vulnerable to invariant drift — the property preserved numerically while its real meaning shifts — which a literal equality check will happily wave through. The guarding discipline is to treat a green run as evidence for the exercised path only, and to pair the test with case generation that reaches states this particular sequence never visited.
How it implements the components¶
invariant_definition— requires the property stated as a mechanically checkable assertion, which the test evaluates verbatim at each boundary.step_transition_rule— the transitions of the running sequence are the steps the checkpoints straddle; the test knows where one step ends and the next begins.monitoring_checkpoint— its signature contribution: a fired assertion sitting after each transition, localizing any break to the step that caused it.
It does not generate the population of cases it runs against, and it does not size how much evidence is enough — extension_domain, validity_evidence_threshold, and counterexample_check belong to Property-Based Testing, its nearest twin. The dividing line: this test walks one sequence and checks the invariant after each transition; Property-Based Testing fabricates many independent cases across an input class and hunts for any that violate the property.
Related¶
- Instantiates: Inductive Validity Extension — realizes the "check the invariant after every transition" step for a single running sequence.
- Sibling mechanisms: Property-Based Testing · Recursive Process Validation · Staged Rollout Validation · Counterexample Search · Induction Proof · Recursive Decomposition Check · Scalable Policy Rule Audit · Training Progression Validation
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Invariant Propagation Test operates as a bounded trial, probe, simulation, or rehearsal that generates evidence from performance because it runs repeated transitions or simulated steps and checks whether the stated invariant remains true after each transition
Independent corroboration: The frozen evidence defines Invariant Propagation Test as 'Runs repeated transitions or simulated steps and checks whether the stated invariant remains true after each transition', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Testing assertions after each simulated transition is rooted in program verification, state-machine testing, and Design by Contract.
Related originating lineages:
- Mathematics — Proof by induction and invariant preservation materially supply the stepwise validity principle.
Review resolution: Both independent reviews place the primary lineage in computer_science. The queued differences (domain_reach_disagreement) concern secondary metadata rather than primary provenance. The final retains mathematics only where a reviewer supplied a formative-lineage rationale; this does not convert downstream applicability into origin. origin_mode=convergent because the reviewers document independently established or materially co-developing traditions. domain_reach=multi_domain records application breadth separately from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Bertrand Meyer's Design by Contract, in which preconditions, postconditions, and invariants are stated as assertions that must hold at defined program points. An Invariant Propagation Test applies the same discipline across a sequence of transitions instead of at a single call boundary. ↩