The evidence layer under your AI workflow
Change the model.Keep the evidence.
Ashaveri captures the evidence behind an AI run, keeps it when your provider changes, and hands you an export your reviewer can check with our service switched off.
Your model stays where it is.
- SIGNED AT THE SOURCE; the origin signature, preserved byte for byte
- VERIFIED OFFLINE; no account, no service call, no permission needed
- OPEN FORMAT; CDDL, vectors and verifier under Apache-2.0
- GAPS DISCLOSED; interruptions and unwitnessed spans stay visible
- HARDWARE OPTIONAL; one tier among four, never a precondition
- PORTABLE BY DESIGN; readable after the contract, and after us
What it is
Three things that outlive a provider
Most of what an AI workflow leaves behind is a log line and an invoice. Ashaveri keeps the part a reviewer can act on, in a form that does not depend on us.
Originals, not summaries
We keep the exact bytes that were signed, plus who produced them, when they were acquired, and which policy and verifier version judged them. A summary can be reworded later. An original can be re-checked later, and that is the difference.
One trail across providers
Your model can move host, region or vendor and the trail keeps running. Each provider keeps its own signature and we add ours beside it, so a change of vendor is a new source in the same history rather than a reset to zero.
A verdict you compute
The format, the parsing rules and the meaning of a verdict are public, in source and in binary. Your reviewer runs the check themselves, offline, and reaches an answer without an account with us or a call to a service we control.
Assurance tiers
Four levels. Named, not blended.
Every record we hold states which of these it reaches. A weaker tier is never quietly reported as a stronger one, and a check that cannot be completed answers unknown rather than passing.
- Observed
We saw it happen.
Proves: This collector recorded this event, from this source, at this time.
Stops at: Says nothing about the model, the answer, or who else saw the data.
- Provider-signed
The provider signed it.
Proves: The origin put its own signature over these exact bytes and we preserved them unchanged.
Stops at: We hold their statement. We do not turn it into ours.
- Hardware-appraised
The silicon vouches for it.
Proves: This ran in a measured confidential VM on a named platform, appraised against vendor roots.
Stops at: Not the correctness of the output, and a confidential GPU label is not a per-request attachment proof.
- Continuity-checked
The window is accounted for.
Proves: Enrollment, expected range, sequence and independent checkpoints line up, and every gap is visible.
Stops at: Cannot show what your provider never sent. An upstream omission stays outside the record.
Hardware is a choice.A customer working toward EU AI Act obligations does not need tier three to use tiers one, two or four, and verification never depends on a machine we control. Teams already running in confidential hardware get the same trail for the runs they already attest.
What you get
Proof you can hand to an auditor
Three artifacts, one chain of custody. None of them asks a reviewer to take our word for it.
The export
One signed bundle: the receipts, the originals they commit to, the attestation inputs, the policy and verifier versions, and both ends of the chain. It states inside itself which material was live, which was captured, and which was generated to test a rule.
The receipt
Each run is a COSE_Sign1 document in deterministic CBOR under Ed25519. It binds the request digest, the response digest, the measurement and the time into one structure, so changing any field breaks the signature rather than changing its meaning quietly.
The verifier
The format, the conformance vectors and the verifier are public under Apache-2.0. Your reviewer can check a record without our SDK, without an account and without a network call, which is what makes the answer theirs rather than ours.
Stated plainly
We publish the limits before a buyer finds them. A proof you are not allowed to interrogate is not a proof.
Offline cannot learn what happened later
A check runs against the roots and collateral retained with the record. It reports the verdict that was correct when the evidence was appraised, and it cannot know of a revocation issued after that moment. Current freshness is a separate, explicit question.
No claim about correctness
A receipt proves which code ran, over which bytes, at which time. It says nothing about whether the answer is right, whether the model was aligned, or whether the prompt template behind it was sensible.
A confidential GPU label is not an attachment proof
Device evidence proves a genuine confidential VM and a genuine device signature. The physical link between them is a boot-time statement on platforms that carry one, and it is never presented as a per-request proof.
Nothing can show what never arrived
Continuity is measured against what your source said it would send. An omission made upstream of intake is visible only if you hold an independent expectation of it, and we say so rather than implying completeness.
Retention and exit
Keep what matters. Erase what must go.
Scoped coverage
A source declares what it will send and from when. Sequence numbers, durable acknowledgement after persistence, and an expected range turn "we kept everything" into something a reader can test.
Checkpoints outside our service
Completed batches are witnessed into storage you control, and an interrupted run leaves a visible gap rather than a tidy history. A gap you disclosed is evidence. A gap nobody looked for is a finding.
Deletion that reaches the copies
An authorised erasure runs across the versions and copies in scope and reports what it could not complete. A valid legal hold blocks the deletion and says which one stopped it.
Retention sized to the duty
A period in time and a capacity in records are two different settings, and a count cap can silently defeat a duration. Each is set to the obligation you name, and an unmet window is reported as unmet.
The exit test
Ask the question procurement will ask: can you read this in three years, after the contract ends, with us unavailable?
An encrypted export whose keys you cannot use is not an exit. A delete marker on a versioned object is not erasure. A second bucket under the same administrator is not a recovery path. These are the tests the design is built against, and the ones it does not pass are written down beside it rather than left for you to discover.
Formats, keys and instructions stay yours, so history does not become unreadable when a provider or a vendor relationship changes.
Why now
The records you keep are becoming answerable.
A regulator, an enterprise reviewer or your own incident process eventually asks the same question in the same shape: what did this system do with our data, and can you show me. The answer is only as good as what you kept, in what form, and whether someone who does not work for you can read it.
Most AI evidence does not survive that moment. It lives in a provider's console, behind a dashboard that closes when the contract does, and it is reconstructed from logs that were never designed to be examined by a third party.
What the law does not prescribe. None of these articles requires signatures, hash chains, confidential hardware or checkpoints. Those are our design choices, made because the useful record is the one someone else can verify without asking permission, and that is the form which survives a review.
The boring fix is not a bigger log. It is a record that states its own provenance, keeps the originals it describes, and can be checked offline by the person who has to accept it.
EU AI Act
Transparency duties under Article 50 began applying on 2 August 2026. The higher-risk obligations in Chapter III reach Article 6(2) systems on 2 December 2027 and Article 6(1) systems on 2 August 2028. Which of them binds you depends on your role, the system, and when it was placed on the market.
Logs, documentation, retention
Article 12 concerns logging capability, Articles 19 and 26(6) name controlled logs kept for an appropriate period of at least six months unless other law provides otherwise, and Article 18 holds specified documentation for ten years. Three duties, three periods, one record class each.
GDPR, DORA and the Data Act
The same records sit under separate rules: lawful retention and erasure, what a financial-sector buyer asks for at procurement, and switching and exit obligations where they apply to the service. Each one turns a storage question into an evidence question.
Dates above are read from the Official Journal texts as of September 2026, including Regulation (EU) 2026/1744. They are a reading of the law, not legal advice, and they are not a claim that any obligation applies to you. Applicability is a per-system question for your own adviser.
Who it is for
Built for the people who have to answer for it
Six kinds of team carry this problem. If you recognise yourself in one of them, that is who we are building for.
You sell into enterprise reviews
A security questionnaire asks what your model did with customer data, and the honest answer is a log you no longer hold. Give the reviewer a signed record they can check themselves, without a call to you.
You deliver AI into an estate you do not own
You own neither the model nor the cloud, and you still carry the evidence question when the audit arrives. One trail across every provider you wire together, with the origin signature intact on each.
You review the system, you do not run it
You need to read an evidence trail without installing a service or trusting a vendor dashboard. The format and the verifier are public, so your conclusion rests on your own check and on what the record says it cannot show.
You issue the runs others must account for
Your customers want evidence with the response, and you would rather ship it than host a verification service. The receipt format and the rules a verdict must follow are open, so the proof is portable and yours to issue.
Procurement asks about exit and assistance
The questions are about recovery and continued access, not cryptography. Can you restore it, can you read it without the vendor, and what happens to the record when the contract ends. The evidence is designed to pass those tests.
You already run in TEEs
You have attestations and no way to show what last quarter produced. Keep the originals and the appraisal inputs so a verdict made today can be re-made later, and stay on the hardware you chose without being locked to it.
How it works
Five steps, and no step needs us online.
Your model keeps running where it runs today. The evidence trail is the part we take responsibility for, and the last step of it happens without us.
- 01
Capture at the source
Exact bytes, and who signed them
The collector takes the signed original as it left your provider, with the source identity, the acquisition time and the context a later check will need. Nothing is paraphrased on the way in.
- 02
Chain each record
Every entry names the one before it
Records are chained, and the store reports the window it actually held rather than the window it was asked to keep. A removal, a rollback or a lost suffix becomes something a reader can see.
- 03
Checkpoint outside us
Witnessed into storage you control
Completed batches are checkpointed on a schedule and acknowledged only once they are durable. An outage, a failed write or an unwitnessed interval is recorded, not smoothed over.
- 04
Export the window
One signed bundle, self-describing
The export carries the receipts, the originals, the attestation inputs, the policy and verifier versions and both ends of the chain, and it states which of that material was live, captured or generated to test a rule.
- 05
Verify without us
Offline, by whoever has to accept it
Your reviewer, your auditor or your incident lead runs the public verifier and re-computes the answer with no account and no call to us. Where a check cannot be completed, it reports that instead of passing.
Book an evidence review
Start with the question you cannot answer.
A questionnaire clause, an incident, an exit test, or a review that is coming. Tell us the request, the system behind it, and who has to accept the answer.