Evidence architecture
Faults travel. Trust does not.
The lab controls the disturbance, durable implementations recover, and a separate oracle decides what the evidence can support.
System map
One delivery. Separate authorities.
Delivery stays implementation-owned. Evidence crosses the trust boundary before any safety or liveness claim is accepted.
01 Durable sender
Reserves proofs, persists one immutable payload, and recovers the same delivery identity.
02 HTTP/Nostr faults
Drops, delays, duplicates, and reorders lab-controlled transport events.
03 Durable receiver
Persists intent and receipts across crashes without granting itself a pass.
- From durable sender
Exact payload
Preserves the immutable payload bytes and delivery identity used for every retry.
- From durable receiver
Mint recovery
Reconciles possible proof consumption against independent mint observations.
Independent oracle
Evaluates safety and liveness from authorities outside the implementation.
JSON/JUnit/HTML evidence
Unsupported claims remain explicitly not observable.
Separation of concerns
Recovery behavior is not release evidence.
A sender may converge and a receiver may avoid duplicate credit while the release gate still remains blocked. Behavior is observed per run; qualification additionally requires independent implementations, mints, authorities, and review.
Successful recovery
One tested pair can demonstrate correct behavior for one deterministic run.
- Same delivery converges
- Duplicate credit is prevented
- Receipt and mint state reconcile
Release qualification
A release claim needs broader evidence than a single implementation can produce.
- Independent implementation pairs
- Distinct mints and authorities
- Reviewed qualifying evidence
Use run evidence for feedback. Use the strict gate for release claims.
Inspect the strict release gate