Authorisation Receipt, format v1 (final)

Status: final, version 1 (xybern-authorisation-receipt/v1). Example: spec/xybern-formats-v1/vectors/receipt.json.

A receipt is the standalone record of one decision: the action, the authorisation, the lineage, and the Vault certificate that lets anyone verify it offline. Since Phase 9 it is two-sided: authorisation.execution carries the tool's attestation and two_sided says whether one exists.

Key	Meaning
format, workspace_id, issued_at, receipt_id (rcpt_ + decision id), decision_id	Identity
action	action_type, summary, content_excerpt, content_sha256, metadata, occurred_at, agent, chain
authorisation.outcome	authorised, refused, escalated, authorised after review, authorised after dual control, authorised with obligations (, all met)
authorisation.decision, decision_path, rules_triggered, verdict, reasoning, escalation, latency_ms	The decision
authorisation.charter	The Charter version pinned
authorisation.lineage, lineage_text	See lineage-v1
authorisation.warrant, collective_limits, obligations, flow, execution, two_sided	The warrant proof, shared counters, obligations with who satisfied them, information-flow labels with provenance, the execution attestation
vault_entry_id, proof, proof_available	The Vault certificate: entry, chain hashes, ECDSA signature, public keys, hashing recipe

Verify with tools/xybern-verify/verify.py <proof_bundle.json> or the SDK's offline verifier; the proof block is what makes the receipt checkable without Xybern.