Tsurai7 Invariant audit
Acceptance criteria verify designed paths; invariants must hold on paths nobody designed. The audit is a matrix — invariant × path — with evidence per cell.
Inputs
- The repo's invariant catalog (
INVARIANTS.mdor equivalent). If absent, derive candidates from the diff's blast surface — what costs money, what is PII, what is a published contract, what must be idempotent — propose the file, and audit against the candidates. - The diff's path inventory: happy path; retry/redelivery; timeout/timer; error/exception; concurrent or duplicate delivery; partial rollout (old config with new code, and the reverse).
Method
- For each invariant, walk each path and ask: can this path violate it?
- Fill the matrix. Every cell needs evidence — a code citation, a test, or check output. "Surely fine" is an empty cell.
- An unswept cell is a finding, not a footnote.
| Invariant | happy | retry | timer | error | concurrent | rollout |
|---|
Classic cells (each shipped past multi-model review once)
- Billed call re-executed by job redelivery after a failed completion ack.
- Retry of a non-idempotent start command → second billed instance.
- Metric counts successful parses, not attempts → reconciliation blind to exactly the error window you audit.
- PII escaping through an upstream error message wrapped into logged errors.
- Required config key plus a lagging config repo → total outage on rollout.
Provenance
Distilled from an internal retrospective of two production PRs (2026-08): the seven costliest review findings were invariant violations on non-designed paths, while the invariants themselves existed as happy-path acceptance criteria.