Anyone can demo the happy path. The interesting question is what a system does when someone alters a document, forges an approval, withholds a quorum, or lies about an anchor. So the proving ground declares the outcome of each attack in advance — and then proves the system behaves exactly as declared. Where we were wrong, the row would say so.
A single fixed seed drives the entire stack through the real modules — not mock-ups of them: membership, a service agreement co-signed by two parties, delivery, an invoice, a dispute, the routing of that dispute to the right tier, a resolution reached by several signers, an anchored root, and finally verification performed offline.
Because the seed is fixed, the run is deterministic. You can reproduce it, and so can anyone who doubts it.
Around that golden path sits the scenario matrix: twenty attacks, each with an outcome written down before the run, each row proven against its own declaration.
Both are downloadable. The verifier re-runs live when you click: valid for the intact package, invalid for the twin, with a named reason. A tool that cannot tell the two apart is not a verifier, it is a decoration.
You are not required to run it here, either. Take both packages, check out the verifier clean, and run it yourself — which is the only version of this claim that should ever convince you.
Membership to anchored root to offline verification, driven end to end through the real modules.
Altered documents, forged approvals, missing quorum, a lying anchor, a failed key store, statutory holds, duplicates.
Download both packages. Watch one verify and the other fail with a reason. Then do it yourself, offline.
Four scenarios walk the lifecycle; thirteen are attacks; the rest exercise idempotency and release. Every row states its expected result up front, and the run proves the system matches it. A failure is explicit and machine-readable — silent fallback, pretending all is well, is forbidden by design.
| Code | Scenario | Declared outcome |
|---|---|---|
| NSBX-01 | Complete flow, no dispute | Passes · VALID |
| NSBX-02 | Flow with complaint and valid resolution | Passes · VALID |
| NSBX-03 | Third-party release with valid approval | Allowed · logged |
| NSBX-04 | Mutual retirement, conditions met | Erased · proof survives |
| NSBX-05 | Document changed after signing | Refused · nothing stored |
| NSBX-06 | Evidence hash rewritten | Verification fails |
| NSBX-07 | Missing counterparty signature | Refused |
| NSBX-08 | Well-formed but cryptographically invalid approval | Refused |
| NSBX-09 | Unsupported suite or contract version | Refused · fail-closed |
| NSBX-10 | Unknown member attempts a governed action | Refused · audited |
| NSBX-11 | Suspended member attempts a future action | Refused · audited |
| NSBX-12 | Unapproved third party requests release | Refused · audited |
| NSBX-13 | Resolution without the required quorum | Does not exist |
| NSBX-14 | Unilateral retirement attempt | Refused · needs two |
| NSBX-15 | Retirement under statutory hold | Refused · never in-app |
| NSBX-16 | Audit-history tampering | Detected |
| NSBX-17 | Key service unavailable mid-operation | Fail-closed · no insecure path |
| NSBX-18 | Write accepted but finality unconfirmed | Not reported as success |
| NSBX-19 | Reviewer unavailable / timeout | Bounded failure · logged |
| NSBX-20 | Duplicate / replayed submission | Idempotent · no double effect |
Infrastructure that oversells itself is worse than none, because people rely on it for things it was never built to do. So, plainly:
Twenty attacks, twenty declarations, and an evidence package you can carry off and check on your own machine without asking us anything.