Three representative scenarios — embedded
The three most evidentially significant scenarios. S26 demonstrates the full dual-notify refund flow. S27 proves registry-offline resilience — the merchant processes a refund independently when the registry is unreachable. S28 verifies hash chain integrity end-to-end.
Evidence download
The archive below contains all S24–S28 server-side screenshots, the refund flow MP4, and all T01–T08 consumer-side MP4 recordings and final-state screenshots. 24 files, 3.2 MB. SHA-256 checksum provided for integrity verification.
Full scenario manifest
Complete list of all recorded scenarios with pass/fail status and what each verifies.
Server-side — S24 through S28
| ID | What it verifies | Status | Evidence |
|---|---|---|---|
| S24 | Paid path generates card — full checkout-to-delivery flow with ABT-C origin. Webhook received, envelope decrypted in memory, card generated and delivered, sentinel PII preserved. | PASS | Screenshot |
| S25 | Paid path idempotent — duplicate webhook does not generate or deliver a duplicate card. Idempotency key enforced. | PASS | Screenshot |
| S26 | Refund dual-notify full flow — consumer Ed25519 signature verified at merchant, Stripe refund processed, merchant signs completion, completion_witnessed inserted at registry with hash chain. | PASS | Screenshot |
| S27 | Registry-offline resilience — merchant processes refund successfully when registry endpoint is unreachable. Confirms registry is witness-mode, not a routing gatekeeper. | PASS | Screenshot |
| S28 | Registry hash chain integrity — request_witnessed → completion_witnessed linkage verified. prev_event_hash correctly chains. SHA-256 chain traversal confirms no tampering. | PASS | Screenshot |
Consumer-side — T01 through T08
| ID | What it verifies | Status | Evidence |
|---|---|---|---|
| T01 | Canonical payload byte-identical — the payload bytes the consumer signs are byte-for-bit identical to what the merchant and registry receive. No serialization drift. | PASS | MP4 |
| T02 | Signature verifies at merchant — the merchant endpoint verifies the consumer's Ed25519 signature against the canonical payload. Invalid signatures rejected. | PASS | MP4 |
| T03 | Signature verifies at registry — the registry endpoint independently verifies the consumer's Ed25519 signature before inserting the witness record. | PASS | MP4 |
| T04 | Full dual-notify happy path — consumer fires merchant and registry in parallel via Promise.allSettled. Both succeed. Merchant returns signed completion. Registry records request_witnessed. | PASS | MP4 |
| T05 | Registry offline simulated — registry endpoint unreachable. Merchant refund completes. Promise.allSettled ensures registry failure never blocks the merchant call. | PASS | MP4 |
| T06 | Retry succeeds — registry-pending witnesses are retried by the background loop. A witness that failed on first attempt is successfully recorded on retry. | PASS | MP4 |
| T07 | Merchant signature invalid — rejected. When the consumer receives a completion payload with an invalid merchant Ed25519 signature, it is not persisted to the local refund record. | PASS | MP4 |
| T08 | Abandonment after 7 days — registry-pending witnesses older than 7 days are marked abandoned and removed from the retry queue. Background loop does not retry indefinitely. | PASS | MP4 |
How to verify the archive
Download the ZIP and confirm the SHA-256 matches the published checksum before reviewing the contents.
# macOS shasum -a 256 abt-c-evidence-may-8-2026.zip # Linux sha256sum abt-c-evidence-may-8-2026.zip # Expected: # d771448417978bb96ddb5f8aa5be1cbceac932e1bfedc04f384d1f7c090ab081