Billing Invariants Proven: Property Tests, Proof-Anchor Gate & Registry v2.18
Why This Matters
SpeyBooks’ billing state machine and webhook ordering rules have been mechanically enforced at the database since migrations 099 and 100, but under this platform’s honesty rules an invariant is not “delivered” until an executable proof verifies it on every release. This release ships those proofs: 63 new property-test cases covering every legal and illegal subscription transition and every ordering, staleness, and envelope behaviour the webhook handler promises. It also closes a deeper gap the work uncovered: the pipeline verified that proof files existed, but nothing verified they passed. A new deploy gate now runs the entire proof suite on every release, and on its very first prerequisite run it found an older proof that had quietly stopped working. That proof was rebuilt the same night. Two releases ago the transition ledger caught its first bug; this release makes sure the things that catch bugs are themselves being checked.
The Two Proofs
-
State machine behavioural equality (AX-BIL-004) The platform keeps two descriptions of the subscription state machine: the database enforcement that arbitrates every write, and a typed table in the application used for compile-time checking and honest logging. Two descriptions of one machine is exactly one too many unless their agreement is executable. The new test attempts every possible transition, legal and illegal, including the edge regions (a subscription record must be born without a status; a status can never be erased at runtime; a cancelled subscription can only be exited with a new, distinct subscription identity) and asserts that both descriptions reach the same verdict in all 52 cases. Neither side is the hand-written expectation: the property is their equality, so a future edit that lets them drift fails before it ships.
-
Ordering, staleness and envelope (AX-BIL-003) Stripe does not guarantee webhook delivery order. The second test drives the real handler code against the real records: out-of-order events are discarded with a receipt and never applied, an event identical to recorded state records as a no-op and changes nothing, same-moment ties defer to the state machine, and the corrected envelope reading from 5.49.0 is pinned in both directions (the field’s new location wins; the old location still honoured for replays of older-shaped events). The resolution hardening from the same release is proven too: a subscription reference pointing at an organisation owned by a different customer is never used. A replay loader rounds it out: any captured real-world event payload can be dropped into the fixture set, and the suite asserts that replaying it twice converges instead of double-applying.
The Gate That Runs the Proofs
- A new deploy phase executes the full test suite on every release The pipeline already verified that every delivered invariant cited a proof file that existed. Existence is not execution: preparing this release, the payment scale-identity proof (AX-MON-001, the guard against the pence-to-pounds corruption class) was found to have been silently broken by unrelated service refactoring, with every deploy since passing all gates because no gate ran the tests. The proof was rebuilt against the service as it actually works today, its property assertion unchanged, and the new gate makes the whole class structurally impossible: 76 proof cases now execute in about one second on every deploy, positioned so a failing proof halts the release before the running service is ever touched.
Operational Impact
- AX-BIL-003 and AX-BIL-004 move from planned to delivered in the axiom registry (v2.18); the platform now carries 45 mechanically verified Class M invariants, confirmed by the registry coverage gate
- Every proof in the suite executes on every deploy; a proof that exists but does not pass can no longer reach production
- A failing proof halts the pipeline before the service restart, so the live service always predates any failure
- The dormant AX-MON-001 proof is live again with its original property intact, and its decay is documented in the registry rather than erased
Kernel Closure Statements
Axiom: AX-BIL-004 - Subscription Morphism
Status: CLOSED as of SpeyBooks v5.50.0
Enforcement layers verified:
Database layer - transition arbitration on every status write
(migration 100; installation self-tested)
Tests layer - behavioural-equality property test, 52 cases,
all six contract regions
CI verification:
Registry coverage gate - PASS (45 delivered Class M)
Proof-anchor execution gate - PASS (every deploy)
Residual risk:
None within the subscription state machine. Per amendment A11,
"subscription state" includes the pending-cancellation flag and the
billing period end, which ride the same event family.
Next dependent axiom:
AX-BIL-005 - Single Writer (operational; CI check owed)
Axiom: AX-BIL-003 - Ordering Non-Regression
Status: CLOSED as of SpeyBooks v5.50.0
Enforcement layers verified:
Database layer - event identity unique by construction; ordering
substrate indexed (migration 099)
Runtime layer - strictly-older events discarded with a receipt;
equal timestamps defer to the state machine
Tests layer - ordering/staleness/envelope property test
driven through the real handler
CI verification:
Registry coverage gate - PASS (45 delivered Class M)
Proof-anchor execution gate - PASS (every deploy)
Residual risk:
None within webhook ordering. One staleness verdict gates the whole
mirror write; receipts are history, not state.
Next dependent axiom:
AX-BIL-006 - Mirror Reconciliation (operational; daily job owed)
Files Changed
Backend:
- Test suite: two new billing property-test files plus a shared database test harness (the suite’s first tests that exercise the live enforcement layer; everything runs in a rolled-back transaction and nothing persists)
- Payment scale-identity proof rebuilt against the current service
- Webhook handler: one function exported as a test proof surface; no behaviour change
- Deploy pipeline: new proof-anchor execution phase
- Axiom registry: v2.18
Frontend / Portal:
- None.
Known Issues
- The pending-cancellation banner copy review for post-trial mid-cycle cancellations (carried from 5.49.0) remains open ahead of 3 September.
With the billing state machine and its ordering rules now proven on every release, the remaining road to the first live charge is configuration and copy, not kernel work.