WISE.EST SYSTEMS

Wise.Est / Lab / AI Receipts

Research / In development

What should exist
after an AI acts?

AI systems produce outputs and take actions while leaving users with weak, fragmented, provider-dependent records of what occurred. Wise.Est is exploring whether an AI interaction can leave behind a portable, inspectable receipt instead.

Working demonstration

Change one field. Watch the seal fail.

The receipt below was sealed when this page loaded. The four highlighted fields are editable. Alter any character and the digest moves, the signature stops matching those bytes, and the verification state changes. Restore it and the state comes back.

Receipt wr_7f3a91c4e0d25b68 Sealing
Request
Receipt ID wr_7f3a91c4e0d25b68
System / model assistant/opus-5
What happened
Tools invoked read_document, compare_records, write_record
Actions read_document(invoice-2026-08.pdf)
compare_records(invoice-2026-08, po-4471)
write_record(reconciliation-2026-08)
Evidence
Sources invoice-2026-08.pdf · sha256 2fdee94ab2e3c448
po-4471.pdf · sha256 9c11ba7740e6d3f2
Result
Verification scope external events, inputs, tools, actions, evidence and output. Not internal reasoning.
Digest sha-256 computing…
Signature signing… key…

Preparing the record.

What is real here. The canonical form is deterministic, the digest is a real SHA-256 over those exact bytes, the signature is a real ECDSA P-256 signature, and verification is a real check against the current bytes. What is not. The signing key is generated in your browser when the page loads. It proves the mechanism, not an identity. A deployed system signs with a persistent key and is checked by a verifier you did not have to trust.

Receipt structure

The fields under investigation.

This set is not final. It is the current working answer to what a record would have to contain before an outsider could say anything useful about what happened.

Receipt ID
Stable handle for this interaction
Timestamp
When the interaction was sealed, by the sealing party’s clock
System / model
What answered, at what version
Input
What entered the system
Tools invoked
What capabilities were available and used
Actions
What the system did outside itself
Evidence / sources
What the answer was built from, by fingerprint
Output
What was returned
Policy / authorization
What it was permitted to do, and who permitted it
Digest
SHA-256 over the canonical bytes of everything above
Signature
Signature over those same bytes
Verification status
The result of re-checking, computed by the reader
The boundary

A receipt records events, not thoughts.

Observable and auditable
  • What entered the system
  • Which tools were called, and with what
  • What changed outside the system
  • Which sources were used, by fingerprint
  • What was returned, and under what authorization
Not captured, and not claimed
  • The model’s internal reasoning
  • Why it chose one answer over another
  • Whether the output is correct
  • Anything happening inside a provider you cannot inspect

A receipt that claimed to capture private chain-of-thought would be claiming something it cannot check. The useful boundary is the one drawn at external events, because those are the things a second party can independently confirm.

Status
Stage
Research / in development
Frozen
No. The field set and the canonical form are both still moving.
External review
None. Nobody outside Wise.Est has examined this.
Related work
W.I.N — the same idea applied to files, already shipped
Next question
Which fields survive contact with a real deployment, and who is willing to be the independent verifier?
Contact

Pull on this
with me.

If you run AI systems where somebody eventually asks what happened, I want to know which of these fields you would actually need.

Start a conversation Next: Learning Systems