The Property Prover
Prove the invariant across the input space — not just the twelve cases someone imagined.
The incident
The pricing function had twelve unit tests, all green, all reviewed. The thirteenth shape of input arrived in production: a discount stacked with a proration on a leap-day boundary, producing a negative total the code happily charged as a credit. No one had imagined that combination — which was exactly the problem. The tests checked the cases someone thought of. The bug lived in the cases no one did.
Why the obvious approach fails
Example-based tests encode the author's imagination, and bugs — by definition — live outside it. For simple code that's fine; for algorithmic code with combinatorial inputs (pricing, proration, scheduling, merging, parsing), the interesting failures sit in interactions no one enumerates by hand. Property-based testing changes the question from 'does it work for these inputs' to 'what must always be true' — totals are never negative, a merge never loses data, parse-then-serialize round-trips — and then generates thousands of adversarial inputs hunting for a counterexample. When it finds one, it shrinks it to the minimal failing case, which is usually a bug report better than a human writes.
The standard
- Critical algorithmic code (money math, merging, scheduling, parsing) declares its invariants explicitly — and tests them as properties, not just examples.
- Property tests run generated input campaigns in CI, with failures shrunk to minimal counterexamples automatically.
- Every discovered counterexample is preserved as a permanent regression case — the bug that happened once cannot happen quietly twice.
- Domain generators model real input shapes (currencies, time zones, boundary dates), so the campaign explores the space that production actually sends.
- Example tests remain for readability and specification; properties carry the correctness load.
How Cortex validates it
At plan time
Missions touching critical algorithms state the invariants in the validation contract itself — the properties are the definition of done.
At validation
assert: invariants.tested_as == properties (generated campaign)assert: total >= 0 across input_space (example invariant)assert: past_counterexamples.in_regression_suite == 100%Assertion syntax is illustrative.
At review
the approver sees the campaign summary: inputs generated, invariants held, and any counterexamples found during development — with their fixes — on the record.