# KRINEIA Receipt Schema Changelog

The normative prose is `RECEIPT_SCHEMA.md`; the current strict write schema is `krineia_receipt.schema.json`. Historical verification behavior is preserved in `tools/verify_chain.py`.

## v0.1 (2026-04-27) — initial envelope

Six fields: `id`, `time`, `state`, `drift`, `prev_hash`, and `hash`.

- No explicit schema version or signature.
- Hash input is canonical JSON over the five fields excluding `hash`.
- Trust-root separation is deployment-asserted through a separate observer process.
- This canonicalization remains frozen; valid historical v0.1 chains remain verifiable.

## v2.0.0 (2026-05-15) — deprecated historical runtime envelope

Ten fields added explicit version, session and actor identities, and `signature_envelope`. The runtime writer and verifier actually:

1. Canonicalized all top-level fields except `signature_envelope` and `hash`.
2. Hashed that unsigned body.
3. Optionally signed the resulting hash with HMAC-SHA256 or Ed25519.

Contemporaneous schema prose instead said the receipt hash covered the signature envelope. That was not implementable as written without a two-stage construction and did not match the code. Schema `2.0.0` is therefore deprecated and verification-only. Its historical algorithm remains in the verifier so existing evidence is not silently invalidated; new writers MUST NOT emit it.

## v2.1.0 (proposed 2026-08-30) — strict signed envelope

The ten-field shape remains, with these normative changes:

- Every field is mandatory and unknown top-level or signature-envelope fields are rejected.
- `session_id` is an opaque non-empty identifier rather than incorrectly requiring UUID syntax.
- Ed25519 is the only admitted signing algorithm; signatures are raw 64-byte values encoded as lowercase hexadecimal.
- Canonical JSON is explicitly defined, including UTF-8, Unicode, whitespace, duplicate-key, and non-finite-number rules.
- The Ed25519 signature covers every top-level field except `hash`; inside `signature_envelope`, it covers `key_id`, `signer_identity`, and `algorithm` while excluding only `signature`.
- The receipt hash is computed after signing and covers every top-level field except `hash`, including the complete signature envelope.
- Missing verification keys, signer-identity registry bindings, or
  cryptographic support are fatal for v2.1.
- The reference daemon fails rather than emitting unsigned or HMAC-signed v2.1 receipts.

This construction binds signature metadata and signature bytes without circularity. It does not replace Invariant 5's operational requirement that the signer be structurally independent of the observed actor.

## Compatibility and admission

- v0.1: original bytes and hash rule unchanged; structural inspection now
  requires an explicit legacy policy and is reported as unauthenticated.
- v2.0.0: supported for read-only verification with a deprecation warning.
- v2.1.0: the only version admitted for new writes after ratification.
- Other explicit versions: rejected until a future constitutional amendment defines them.

Chain policy is monotonic: v0.1 or v2.0 after the first v2.1 receipt is a
fatal downgrade. Assurance callers must also compare the presented chain with
an independently trusted expected head and receipt count; internal linkage
alone cannot detect removal of a valid tail.

Admission of v2.1 requires ADR-002, the proposed constitutional amendment, a receipt generated by an external observer, and approval by Reuben Bowlby. Until those gates complete, the proposal is not operative governance law.