guide
Why trust a receipt
corecruxctl verify-store --mode full --strict ok: true · 4 receipts · chain intact
Signatures bind to both the receipt id and the payload hash, so a receipt cannot be edited in place or transplanted elsewhere; ordering is carried by chained segment seals on the spine. You can run this exact experiment on your own machine: scripts/demo-receipt-tamper.sh in the Crux repo.
Why trust a receipt
Logs are assertions: whoever controls the logger controls the story. A CROWN receipt is built so that the story cannot be quietly rewritten.
Signed
Every state mutation the daemon performs is signed with Ed25519 under the acting passport. A receipt does not just say what happened; it is cryptographically bound to who did it.
Chained
Receipts live on a BLAKE3-sealed, append-only spine: every record is covered by a sealed segment hash, and each segment seal commits to the seal before it. Inserting, deleting, or editing history breaks verification visibly. There is no quiet edit.
Verifiable offline
You can check the whole chain with corecruxctl verify-store, or hand an export to someone else to verify with no network and no CueCrux account. The same export, verify, tamper-rejection flow is a release-blocking CI gate: a daemon build that cannot catch tampering does not ship.
Resolvable
Any receipt resolves back to a passport: who acted, at what trust tier, under which grants. Refusals are receipts too; a signed RefusalReceipt with a reason code proves that policy said no and why.
Why it matters
Receipts over vibes. When an agent misbehaves, you replay the signed trail instead of reconstructing intent from logs. When an auditor asks, you hand over evidence they can check themselves. When a bill arrives, every line traces to a receipt. The trust is in the mechanism, not in us.