Receipts
Receipts are evidence objects.
Most systems produce logs, events, statuses, and screenshots. Mindplane produces receipts.
A receipt is an evidence object for automated work: what was claimed, what was observed, what was decided, what changed, and what can be proven later. Not another log format. A reusable evidence object, where each type captures a specific kind of operational truth.
Why there are types, and why there are not many
A new receipt type is only justified when it captures a new kind of truth. We are deliberate about not letting them sprawl, because the value is in a small set of primitives that can be read, joined, and reused across tools, not a bespoke schema for every feature.
Receipts are not valuable because they sit in storage. They are valuable because readers can turn them into answers. A reader asks a repeated operational question, finds the evidence objects that answer it, and returns something a system or a human can act on.
What a receipt proves
Input fingerprint
Shows which inputs produced the decision. The same inputs, re-run later, produce the same answer.
Observed evidence
Links the decision to evidence, not just intent. What was measured, not what was assumed.
Verdict
Records what the deterministic system decided, and on what basis. The conclusion is not separate from the reasoning.
Hash chain
Makes later edits detectable. Receipts are tamper-evident: an alteration cannot pass silently, because the chain breaks.
Live today
shippedRun receipt
proves whether a run matched what was declared. Records the declared path, the observed path, and the difference between them.« The agent said it ran five steps. Which were actually observed? »
Decision receipt
proves what Mindplane concluded and why. Records the policy and evidence available at the time, the verdict, and whether enforcement was applied or only observed.« Would Mindplane have blocked this automation if enforcement were on? »
Building now
in progressReconciliation receipt
proves whether a claimed piece of work still matches reality. Records the claimed state, the observed state, the evidence checked, and the verdict.« This ticket says the work is needed. Is that still true? »
Commit receipt
proves what changed before code left the machine. Records the diff, risky paths, ticket references, and the local decision.« What did this commit change, and what checks ran before it left the laptop? »
Provenance receipt
partial proves where an event came from and how much trust was placed in it. Today it records the trust grade a signal claimed; verifying that grade at the source is work in progress, not a finished guarantee.« Did this automation act on a signal we actually trusted? »
Relay receipt
partial records what was relayed, to which target, and whether it landed. The stronger relay receipt, linking that message back to the evidence object that supported it, is building.« What did we tell the customer, and what supported it? »
On the roadmap
aheadValidation receipt
proves whether the expected outcome was observed after an action.« The action ran. Did reality change the way we expected? »
Break-glass receipt
proves emergency action was explicit, attributed, time-bounded, and reviewable.« Who used emergency access, why, and what review followed? »
Where this is going: incident receipts
Incident work is slowed by the same first questions, every time: what happened, is this new, have we seen it before, what changed recently, is there a known fix, has it shipped, has it been validated, who needs to know.
Incident receipts are designed to preserve that meaning without becoming another investigation. The aim is not more incident data. Teams already drown in that. The aim is to remove the repeated rediscovery of context, so the first ten investigation steps stop being steps at all.
A remedial agent should not begin by guessing what happened. It should begin from the receipts that already prove what is known. The agent that starts from evidence instead of starting from scratch is the difference between automating the work and automating the rediscovery of it.
This is direction, not a shipped feature. We are honest about that line everywhere on this site, and we hold it here too.
Need a receipt we have not modelled?
If your team has a recurring operational question that takes ten steps to answer, that is usually a receipt waiting to be defined. We would rather model the evidence object that removes those steps than sell you another dashboard.
For custom receipt types, validation patterns, or ingestion questions: receipts@mindplane.ai
