Decision Receipt Standard
DRAFT v0.1 · not an official standardEvery time a system decides something that matters about a person, it should hand back a receipt. This page defines what the receipt contains, so any company can issue one and any person can check it.
Why this exists
Decisions now happen in milliseconds. The explanation, if one comes, arrives later, shorter, and from nobody in particular. The speed gap is already here. The accountability gap is the one nobody has put a name on.
A receipt closes it at the only moment it can be closed: when the decision is made.
Scope
Any decision, automated or automation-assisted, that has a material effect on a person. That means money, work, housing, health, access to a service, or the ability to speak or be heard. Out of scope: recommendations, ranking of content, and decisions with no effect on the person.
The five fields
What was decided
- The subject (what the decision was about) and the outcome from a fixed list:
approved,declined,restricted,ended,changed. - A decided_at timestamp and, where relevant, the amount or scope.
Why it was decided
- At least one specific reason, in a plain sentence, that the person could check against their own facts.
- Whether it was automated and whether a human reviewed it. Both are required booleans.
- "After careful consideration" and "for security reasons" are not reasons.
Who answers for it
- A named person and their role. A team or department name does not count.
- A working contact, not a no-reply address.
- A reply_within_days commitment, 10 business days or fewer.
How to undo it
- Whether undo is available. If yes: how and a deadline of at least 30 days. If no: a stated reason.
- What happens to the decision while it is under review (effect).
- "You may reapply" is not undo. It is starting over.
Whether it follows you
- Whether the decision or its data is retained, and for how many days.
- Whether it is used_for_other_decisions about the person. Both are required booleans.
Rules
- Issue at decision time, in the same channel as the decision. Not later, not on request.
- Plain sentences. A person who has never heard of the system must be able to read it.
- Machine-readable too. The same receipt exists as JSON, so the person can store it and other tools can check it.
- Human-speed reply. Questions to the named person get an answer in 10 business days or fewer.
- No stays no. If the person declines something, the receipt records it and the system does not ask again in a new form.
Example (JSON)
{
"receipt_version": "0.1",
"decided_at": "2026-10-03T09:14:00Z",
"what": { "subject": "personal loan application", "outcome": "declined" },
"why": {
"reasons": ["Your monthly debt payments are 52% of your stated income; our limit is 45%."],
"automated": true,
"human_reviewed": false
},
"who_answers": {
"name": "Jordan Lee",
"role": "Credit Review Lead",
"contact": "mailto:review@bank.example",
"reply_within_days": 10
},
"undo": {
"available": true,
"how": "Reply to the named contact with updated income or debt figures.",
"deadline": "2026-11-12",
"effect": "Decision is paused while it is reviewed."
},
"carry_over": { "retained": true, "retention_days": 90, "used_for_other_decisions": false }
}
Check a receipt
Paste a receipt as JSON. This checks it against the draft. ✗ is a MUST that failed. ! is a SHOULD you can fix. Everything runs in your browser.
Open questions
- Who verifies that a receipt is true? A receipt can be well formed and still say nothing useful.
- Where do receipts live so a person can find them again? An inbox is not a record.
- What counts as "material"? The scope line is a starting point, not a boundary.
- How should this interact with existing rights to explanation and review, which differ by country?
This is a proposal from Chiibitsu Labs. It is a sketch to argue with, not a legal or technical standard. Say it well is the human-scale version: practise the same five things in your own messages. Check a message you received shows the gap on real ones.