# Evidence-only signed receipts

This format supports inspection of a signed statement. It is not an action
request, grant, activation certificate, renewal, recovery command, or migration.

The closed outer JSON object has exactly:

```json
{"format":"EZA-EVIDENCE-RECEIPT/1","algorithm":"Ed25519","payload_hex":"...","signature_hex":"..."}
```

The signature is exactly 64 bytes, encoded as 128 lowercase hex characters.
The payload contains 1–65536 exact bytes encoded as lowercase hex. The outer
document is bounded at 140000 bytes. Parsing rejects duplicate keys, invalid
UTF-8, nonfinite numbers and unsupported fields. The signature input is
`UTF8("EZA-001/evidence-receipt/v1") || 0x00 || payload_bytes`.

The closed payload has `kind` equal to `EZA-EVIDENCE-CLAIM`, a 64-lowercase-hex
`release_manifest_sha256`, an identifier `authority_domain`, and `result`.
`result` is one complete transport response whose inner record claims the same
release digest. It contains no grant issuance, authority changes, callbacks,
paths, URLs or commands. A prepared result with a live handle is not a receipt.

The verifier receives an independently trusted 32-byte Ed25519 evidence public
key and the expected historical release digest as separate inputs. No key inside
a receipt is trusted. It verifies the signature, exact payload shape, release
binding and the exact context-free result-consistency rules in RESULTS.md, then returns:

```json
{"status":"VERIFIED_EVIDENCE_ONLY","authority_granted":false,"claim":{}}
```

`claim` contains the validated signed statement. It does not prove current
authority, current state, a fresh clock, or the truth of unobserved events.
An invalid signature, wrong key, different expected release or invalid shape
fails verification. Verification has no execution or recovery side effect and
does not contact a network service. A signed statement naming `EXECUTE` remains
evidence; it is never fed into the action API as permission.

The tests generate disposable Ed25519 evidence keys to verify this behavior.
Those keys are not the owner's publication key and are not credentials for any
real resource. The implementation uses the maintained `cryptography` Ed25519
API rather than custom signature mathematics. The tested dependency version is
recorded with the results. See the [official API documentation](https://cryptography.io/en/latest/hazmat/primitives/asymmetric/ed25519/).

Publication signing is a separate owner-controlled workflow. A receipt signature
and a release signature have different purposes; neither creates operational
authority. Do not use a test key as the official release identity.

The declared internal-consistency checks are mandatory even when a signature is valid.
RESULTS.md section 2 supplies the complete checklist, including non-null success
claims, one through eight distinct lineage references, and actor/delegate equality. REJECT and
ESCALATE must have equal primary and blocking reason codes. FAIL_SAFELY keeps
its objective-level reason and the registered underlying cause. NOT_EXECUTED
must have a null returned result. Only a successful preparation may return a
live handle; that response is not a completed action receipt. A real successful
read may return a string, and a valid denied action may still be signed as
historical evidence. These rules cannot establish the truth of unobserved
facts, but they prevent the verifier from labeling contradictions as a valid
complete outcome.