A record is one AI decision, sealed the moment it was made and tamper-evident ever since: the policy that governed it, what the model was given, what it decided. Whoever is asking can check it without you and without us.
AI agents now approve loans, flag fraud and deny prior authorizations. Regulators, auditors and opposing counsel are all entitled to ask why.
Your AI agent approved 9,300 loan applications last quarter. Now prove how each one was decided. You have logs and audit trails. They sit inside your own systems, vouched for by you. Not enough. What you cannot prove, you concede.
Five demands. Here is what each one costs you.
policy_version_hashinput_hashNone of that is fixed by them. Cloud audit logs, AI monitoring, policy engines and your SIEM govern the runtime. They record what ran. None of them commits what the model was given, before it ran.
A communications archive is the strongest version of this objection. It holds the record outside your systems, which genuinely answers custody. It still records what passed through it, and checking it means asking whoever holds it.
Which is the question worth asking of anything that calls itself sealed: what does someone need in order to check it? Here, the file and a published key. Nothing else, and nobody to ask.
Why CloudTrail and OpenTelemetry fall short →One record for each decision that matters. The one below is real and this summary is generated from it, so it cannot say anything the record does not. Change the outcome and watch the proof fail.
A verified record of a bad decision is still a verified record of a bad decision.
A signature covers what is present, not what was never written.
Only the declared retention class is signed; confirming the lock needs the storage account.
This one was solely automated, and the signature is ours, not a human’s.
Everything above rests on one thing: the bytes have not changed since they were signed. The verifier checks that in your browser, on a site whose framing we do not control. No account, no upload, nothing leaves the page.
This is the page you hand over with the record. Whoever you hand it to opens a link and gets an answer, without installing anything and without a call to you.
Open source at github.com/plainreal/verify. Every release is signed, and the signature names the exact page you were served, so the checker itself can be checked. How that works →
The rest of your stack is reproducible by design: same inputs, same code, same result. An AI model is not. One exception is worth naming: where an agent writes code once and that code is then frozen, running it again gives the same answer. What cannot be re-run is the decision that produced the code. Same prompt, same settings, and the answer can come back different, because the provider updated the model behind the same version string or the sampling varied.
So you cannot re-derive what the agent decided six months ago. Whatever you did not capture as it happened, to the exact input the model saw, is gone. And what you did capture is only as good as your ability to show it has not changed. The discovery order arrives long after the decision, which is why capture has to be live.
The record of a consequential AI decision is scattered across the systems that produced it. Your company deployed the agent. A vendor supplied it. A provider served the model. Some chains are longer, some shorter.
One decision is pinned in every party it reached: d-4f21, the one an examiner asked about. Where a component has changed since, its row shows what it was running then. Six parties hold a copy. None of them is a witness.
solid outline: inside your company dashed: a party you do not control
Eighteen months on, that combination no longer exists. The two public models are the sharp case: v2026-05 and v2026-03 never move while the model behind the string can be replaced.
It holds the sealed record and gains nothing from the decision going one way or the other. The check runs without us and without you, open source and in your own browser.
The in-house case is the worst one, not the best. Build the whole stack yourself and you hold the evidence about your own conduct. Every record you produce is a record you could have written.
Better logging, immutable storage and governance tooling are all worth doing. None of them closes this.
What is missing is not completeness.
It is independence.
The format is public and the verifier is public. Stop paying us and every record you already hold still verifies, with no cooperation from us. What you pay for is the sealing itself, because tomorrow's decisions cannot be sealed after the fact. That is how you know the independence claim is real rather than marketing.
Five things happen when a record is sealed, and the finished record carries all five. Turn a layer to see what it holds. Every value shown is read out of the sample record, not typed in.
The order is the guarantee: the time anchor is only requested once the lock has been read back. And no two of these layers are held by the same party. PlainReal signs, your storage keeps it under a lock its own operator cannot lift, and an outside authority timestamps. That is what makes it an architecture rather than a promise.
Both produce the same record, verified by the same CLI. Start with auto-instrument for immediate coverage, then promote your regulated paths to the decorator.
Wrap a regulated function. The input is sealed before it runs. For OCC, NYDFS, and litigation evidence.
how the decorator captures → plainreal run Auto-instrumentZero code changes. Captures every LLM call at the client boundary. For EU AI Act Article 12 and GDPR record-keeping.
how auto-instrument captures →Whoever asks, the question is much the same: what did the agent decide, on what, and can you show it has not changed since. One record answers that once.
Tap one to see what it actually says.
19 years building infrastructure that proves data integrity at the OS level, the storage stack, and federal compliance: HP, VMware, Cloudera, FedRAMP GovCloud, FIPS 140-3. PlainReal asks the same question about AI decisions.
Full background ↗An evidence company that overstates the need is the last one you should trust with evidence. If any of these fit you, you do not need us yet.
No law or regulation currently compels cryptographic decision evidence, and we will not pretend otherwise. What we build for is the challenge itself: the discovery request, the adverse-action suit, the examiner asking a question you cannot answer. That exists today, regardless of what any law requires.
deployment_mode field records which arrangement produced a given record, so a reader can see it rather than infer it.Live today and early. We are taking on two design partners: you define what your auditor would accept, and we build to it.
Engineers, look before we talk. a real record, deployment modes, or verify one yourself. SDK integration takes about 30 minutes. contact@plainreal.com
90-day pilot · 50% upfront · scope set together. One conversation to see if it fits.
Or book directly: 30-min call ↗