Everything a compliance, engineering, or risk team asks before a first call. ← Back to home
For regulated decision functions, the right starting point is the decorator (@plainreal.consequential) on the functions that make regulated decisions. This produces the strongest evidence, designed to meet OCC examiner, NYDFS, and litigation discovery standards.
Auto-instrument is the right starting point if EU AI Act Article 12 or GDPR Article 22 record-keeping is your near-term driver. It records every LLM call made through the instrumented client, without code changes.
We recommend running both in production. A coexistence guard ensures exactly one record per call, never two.
Yes. Same record schema, same Ed25519 signing, same S3 Object Lock COMPLIANCE mode WORM, same RFC 3161 timestamp, same standalone plainreal verify CLI. The capture_layer field tells the auditor which forensic claim applies. The verify CLI validates records.
SDK integration in a clean development environment: 30 minutes. Enterprise production integration: 1-4 hours. Enterprise security review of the ABSA interceptor: 3-6 weeks, reduced by the OWASP mapping. Total onboarding to first production artifact: 4-8 weeks.
A valid signature is a narrow claim, and the narrowness is the point. It proves the bytes are the bytes that were signed, and that nothing has changed since. Five things it does not prove:
Not that the decision was correct. A verified record of a bad decision is still a verified record of a bad decision. Evidence of what happened is not a judgement about whether it should have.
Not that the record is complete. A signature covers what is present. It cannot show you what a producer chose never to record in the first place.
Not write-once custody. The declared retention_class is signed, and the substrate derives the Object Lock period from it. Confirming a specific object is genuinely under that lock requires access to the storage account.
Not when it happened. That is the RFC 3161 timestamp's job, and the signature covers content rather than time. Published sample records carry no timestamp token.
Not human non-repudiation. A record showing that a person approved something proves the system recorded that approval tamper-evidently. It does not prove that person personally signed anything. Authentication happens upstream, outside our trust boundary.
There has also been no third-party security audit. When there is one, we will name who did it.
In production, TIER-A means HSM-signed inside FIPS 140-2 Level 3 hardware, WORM-committed, and RFC 3161 timestamped. Design partner phase uses software signing with the same Ed25519 algorithm. Designed as the primary evidence grade for SOC2 auditors and OCC examiners.
TIER-B: Customer-hosted attestation with a declared 60-second uncertainty window. Corroborating evidence. The distinction is explicit in the evidence_tier field of every artifact.
Yes. The OWASP Agentic AI Top 10 mapping is published open source on GitHub. Every control claim is tied to a specific named field in the record schema, also published. Your security team can review the mapping against the schema and verify every claim independently.
The mapping distinguishes between Prevention and Recording. Naming what each mode actually does is more honest than claiming prevention for everything.
EU AI Act Article 12 requires automatic event logging for high-risk AI systems; it does not, in its own words, mandate cryptographic integrity. But a log that could have been altered after the fact carries little evidentiary weight with a regulator, a court, or an auditor. That gap between logging and evidence is the point. The Annex III obligations are deferred to 2 December 2027, so this is rarely about a single EU deadline. A discovery request, a SOC 2 audit, or an OCC exam tests whether you can prove a decision much sooner. A PlainReal record is built for that bar: tamper-evident and independently verifiable, so it holds up when someone challenges it.
Yes. OCC Bulletin 2026-13 (April 2026) revised interagency model risk management guidance but explicitly excluded generative and agentic AI from scope, on the basis that these technologies are "novel and rapidly evolving." The same agencies have signaled a forthcoming RFI specifically addressing AI-driven model risk. Meanwhile the OCC's Spring 2026 Semiannual Risk Perspective named agentic AI as a supervisory priority.
Banks face a gap: their agents fall outside the formal framework but inside the active supervisory focus. The real question is whether your governance program produces evidence that survives an examiner asking "what controlled that decision?" under a framework still being written. Mutable logs cannot. A PlainReal record produces a signed, WORM-committed artifact for each consequential agent action.
CloudTrail records that an API call happened. It does not record why the AI decided what it decided, what policy was in force, or what input the model received. It can also be altered, by your own team or by your cloud vendor. An OCC examiner or opposing counsel will ask one question: can you prove these logs were not touched after the fact? With CloudTrail, you cannot. With PlainReal, the answer is yes, because each artifact is signed, WORM-committed, and timestamped by a neutral party.
The evidence exists whether you capture it or not. The regulator will find the bad decisions regardless. What PlainReal gives you is proof that you found the problem internally, before the examiner arrived, and proof of exactly when you knew.
Mutable logs do not protect you. They mean the examiner finds the problem and you cannot establish your own timeline. Tamper-evident evidence is what lets you show a good-faith compliance program rather than a gap you cannot account for.
A PlainReal record is written to your S3 bucket in your AWS account. The signing operation receives the hash of your data, not the data itself. PlainReal has no write access to your bucket after provisioning. The deployment_mode field records which arrangement produced a given record, so a reader can see it rather than infer it.
Your artifacts live in your S3 bucket under your Object Lock policy. PlainReal has no write access post-provisioning. Every artifact stays in your possession, in your bucket, under your retention policy.
The standalone verify CLI will be open source. Your auditor verifies authenticity using only your bucket access and the published public key. We are establishing escrow custody of source code and keys for the cessation scenario.
Past artifacts remain independently verifiable even if PlainReal ceases operations. New artifacts require PlainReal signing. Most customers continue with PlainReal not because they have to, but because the signing infrastructure, schema currency as regulations evolve, operational tooling, and the auditor reference base are what make the evidence audit-grade.
Four things.
The signing service. Every new record requires Ed25519 signing, with HSM backing in production. Without this, your agents cannot produce new audit-grade evidence.
Schema currency as regulations evolve. EU AI Act enforcement clarifications, OCC bulletin updates, new state laws, FinCEN rulemaking. We keep your evidence schema current. The OCC Bulletin update from 2025-26 to 2026-13 and the addition of Annex IV and SOC 2 CC8.1 are recent examples of work the schema captures so you don't have to track it.
Operational tooling. Fleet-wide monitoring, anomaly detection across deployments, compliance reporting, and integration with downstream audit systems that the standalone CLI does not provide.
The auditor reference base. As the customer base grows, schema acceptance by CPA firms grows, and that recognition transfers to you. This is the long-duration moat of the company, and you benefit from it by continuing with PlainReal.
OpenTelemetry spans are mutable, infrastructure-dependent observability records designed for debugging. They can be deleted, modified, or selectively exported. An OCC examiner or opposing counsel can challenge their integrity.
Production artifacts are signed inside a FIPS 140-2 Level 3 HSM. Design partner phase uses software signing with the same Ed25519 algorithm. Both are written to S3 Object Lock COMPLIANCE mode and timestamped by a neutral RFC 3161 TSA. One is for debugging. The other holds up when a regulator or opposing counsel challenges it. Not the same thing.
The sealing operation runs in the background, so it never blocks your agent. The record identifier returns immediately; the WORM commit and trusted timestamp complete asynchronously. Each artifact records its own sealing-time metadata for forensic transparency.
Because you would be signing your own evidence. An OCC examiner or opposing counsel will ask: who holds the signing key? If the answer is the same company that made the decision, or the same cloud that hosted it, the independence argument fails.
PlainReal holds the signing key. The timestamp comes from a neutral third-party TSA. Your S3 bucket holds the artifact. No single party controls all three. That separation is what makes the record credible to a regulator who was not in the room when the decision was made.