Plugin receipts
What you'll find here
The craik.plugin_receipt contract — what plugin actions and outputs
record, common outcomes, and how the receipt keeps descriptor
identity separate from runtime authority.
Grants explain why; receipts explain what.
Capability grants show why an action was allowed. The receipt records what happened. Both must be redacted.
Runtime writers should create plugin receipts through Craik's receipt factory rather than constructing writable receipts directly. The factory redacts result summaries and metadata before persistence, and local stores attach an integrity HMAC that is verified whenever plugin receipts are read back.
Linked records
craik.plugin_receipt links a plugin action to:
Task and actor
Plugin descriptor
And optional probation record.
Capability grants
Trust boundary
Redacted result summary
Evidence and handoff records
Outcomes
passedfaileddeniedEvery outcome links evidence and handoff.
Successful, failed, and denied plugin receipts all require evidence and handoff links so reviewers can reconstruct the action boundary without reading raw plugin output.
The optional probation link is shown in the operator receipt view when present. Receipts may omit the probation id for already-promoted plugins, but an empty probation id is rejected. Result metadata must not contradict the receipt redaction flag.