Docs Product
Receipts & proof packs
Every decision KIFF makes leaves a receipt: a signed record of what was authorized, on what basis, before the action ran. A proof pack is the exportable bundle of that evidence for one control over a window. This page is precise about what a receipt proves — and, just as important, what it does not.
What this does
When KIFF decides on a proposed action, it records one receipt capturing the decision: the action, the entity and its state at that moment, the outcome, and the policy that was checked. The receipt is signed and tamper-evident, so the record of the decision can’t be quietly altered after the fact.
What a receipt proves
A decision receipt proves pre-execution authorization: that, at a
specific moment, this action on this entity was evaluated against the
recorded state and your declared policy, and a specific decision —
allowed, blocked, approval_required, or invalid — was reached
before the action ran. It is verifiable and tamper-evident.
In plain terms: the receipt is proof of what was authorized and on what basis, made at the gate.
What a receipt does not prove
This boundary matters, and overstating it would be dishonest:
- A receipt does not prove the action executed. KIFF is the decision
boundary, not the runner — your system executes
allowedactions, and what happened downstream is outside the receipt. - A receipt does not prove the outcome of the action (that the money actually moved, that the email was delivered).
- A receipt does not assert reviewer attribution beyond what the product records; approval-to-control linkage is limited today (see What’s real today).
So a receipt answers “was this authorized, before it ran, against what state and policy?” — not “what did the system do after?” Those are different questions, and conflating them is exactly the trap honest evidence avoids.
Why “before” is the whole point
Most systems log what happened after the fact, in a store the acting system controls. That’s an account, not proof — the actor wrote it, and it can be edited. A decision receipt is different on all three counts: it’s made before the action, by the decision boundary rather than the actor, in a tamper-evident form. That’s what makes it hold up when someone later asks you to show what was authorized.
Proof packs
A proof pack is the exportable form of this evidence for one Protected Control over a time window. The on-screen Govern view and the exported proof pack are built from the same evidence object, so what you see and what you hand someone else cannot diverge.
A proof pack covers what the evidence object can truthfully show for the window: the control’s identity, the decisions by outcome, the signed receipts and their verifiability, and the posture (shadow vs enforce). It carries an honesty disclaimer about scope — a sampled “all verified” never reads as a complete-window guarantee.
Verifiability and tamper-evidence
Receipts are signed, which is what makes them tamper-evident: a change to the recorded decision breaks the signature. Receipts can optionally be anchored to an external trail for independent verifiability; the production form of that anchoring is not shipped, so the honest claim today is signed, tamper-evident, verifiable — not more. See What’s real today for the exact line.
A receipt detail from a clean demo tenant — the decision it records and its signature status (Signed.).
The proof-pack export for one control — the signed decisions and receipts in scope, led by the honesty disclaimer about what it does and does not assert.