An AI log is not proof
Here is what we built to try to make it verifiable.
Last April, I wrote a fairly simple sentence:
"You don't have proof. You have beliefs."
At the time, I was mostly talking about a fundamental problem.
Artificial intelligence gives us more and more answers, recommendations, and soon decisions. But once these systems start to take part in legal, financial, industrial, or strategic processes, one question always ends up surfacing:
How do you prove, weeks or months later, what actually happened?
Prove what can actually be proven.
Since then, we have tried to turn that question into an engineering problem.
And we discovered something important:
a record can be cryptographically verifiable… and contain false information.
This is not a failure of our protocol.
It is probably one of the most useful results of our work.
In our tests, we deliberately introduced a source containing semantically false information.
The record could therefore be classified:
VERIFIED
Even though its initial content was false.
That may seem paradoxical.
It isn't.
An integrity proof answers one question:
"Is this really what was recorded at that moment?"
It does not answer:
"Was what was recorded true?"
Confusing the two lets you make spectacular promises.
Distinguishing them lets you build auditable systems.
We chose the second path.
Take a system that records 10,000 decisions.
That looks solid.
But now suppose the operator silently deletes the 300 most embarrassing decisions before handing the record to the auditor.
The remaining 9,700 decisions can still be perfectly signed.
Every record presented is authentic.
And yet the population presented is incomplete.
That is the problem we were really interested in.
So a proof must not only let you ask:
"Has this record been modified?"
It must also let you ask:
"Can a decision that had been admitted silently disappear from the history presented later?"
We devoted most of our work to that second question.
We deliberately chose a narrow property.
When an operation crosses a declared boundary of our system and that admission is acknowledged by our witness mechanism, it must then remain accounted for.
But it must not simply disappear.
For a population to be classified VERIFIED, every acknowledged admission must be reconcilable with an explicit terminal state.
In other words:
an admission known to the witness must continue to exist in the history presented as complete.
We call this population continuity after admission.
This article presents the main takeaways from our work. The protocol, the threat model, the hostile scenarios, the experimental results, and the limitations are documented in our full technical note.
Protocol / publication reference: f7cfe7ede525d5ba1b01f8f44ea8b2b54fe759eb Implementation hardened after PR #30: 13524a13bfaa1d312c84fa7dcc588ede742b6388
A large part of the problem comes from the order of operations.
A conventional architecture can work like this:
But what happens if the system goes down between step 1 and step 3?
The action may have taken place.
The record knows nothing about it.
So we reversed the logic on the boundaries we protect.
First, the intent or admission is recorded. Only then can execution begin.
If the system goes down after that admission, we keep an unresolved operation.
That is less comfortable than a perfectly clean history.
But it is much more honest.
To us, an INCOMPLETE state is preferable to a false impression of certainty.
We then ran into another problem.
If KOREV controls the log and the key that signs it, KOREV could in theory rebuild a shorter history and sign that new history.
The signature would be correct.
The chain could be consistent.
But the history would have changed.
So we added a witness with its own state and its own key.
Its role is not to know the business content of the decisions.
It keeps a reference to the state of the history it has already acknowledged.
When a new step is presented to it, that step must extend the previous state exactly.
We then no longer ask only:
"Is this history consistent?"
We can ask:
"Does this history really extend the one that had already been acknowledged?"
The distinction is fundamental.
In our current experiments, the witness is separated by process and by key, but remains under the same administration.
So we do not yet claim to have demonstrated full operational independence.
That is a next step.
Our verifier uses three states.
The bytes, the inventory, the history, and the witness's current state reconcile, and no required operation remains open.
A necessary piece of information is missing, or an admission remains in an unresolved state.
A cryptographic or structural inconsistency is detected: signature, scope, sequence, hash, freshness, or inventory.
A fourth state is deliberately missing:
"true"
Also missing:
"compliant"
Cryptography must not be used to turn a technical property into a legal or business conclusion that it does not demonstrate.
We did not just want to write the protocol.
We wanted to try to make it fail.
Our v2 targeted study now includes 67 tests, 43 of which were added around durable capture and the witness.
Among other things, we tested:
We recorded two experimental batches of 10 and 100 recommendations, with 11 predetermined scenarios per batch.
That is 22 recorded observations, whose observed classifications match the expected results defined before execution.
This is not a production benchmark.
It is not proof that every possible attack is covered.
It is something more useful:
a precise property tested against precise attempts to make it fail.
There was a much more mundane problem left.
And probably just as dangerous.
Files.
In KOREV Evidence, a user can start from a conversation, add documents, then create a Secure Record.
At first glance, this looks like an interface topic.
In reality, it is part of the chain of proof.
Imagine that we perfectly protect a record after its admission, but that the bytes of a file could be replaced just before that admission.
The log would be flawless.
The wrong attachment would be perfectly protected.
We would have secured the wrong thing.
So we specifically audited the boundary:
Conversation → Record
The audit produced nine initial findings. The fix and the hostile review then surfaced further defects.
Among other things, we added:
The lesson is important:
The quality of the proof starts before cryptography, at the moment the system decides what has actually been admitted.
We also strengthened our CI gates.
When the publication work was frozen, our four main workflows completed successfully:
During the Conversation → Record hardening that followed, the reported validations include in particular:
And we also keep in our report the failures of the optional suites that remain to be addressed.
Because a green workflow must never be used to suggest that the whole product is perfect.
Our capture applies to declared, instrumented boundaries.
Today, this covers in particular certain agent admissions, model calls, streams, embeddings, tools, outputs visible in the UI, HTTP bytes, and file transitions to Records.
That does not mean we see everything.
These limits are part of the system.
Not an appendix we would rather hide.
We are obviously not the only ones working on this question.
The software supply chain has already developed advanced provenance and transparency mechanisms, with projects such as Sigstore/Rekor or SLSA.
And the arrival of AI agents now extends this question to the models, tools, APIs, and actions carried out on behalf of users or organizations.
Infrastructure players such as Traefik, for example, are working on a gateway-centered approach, where model, MCP, and API calls are observed along the communication path.
Our current work focuses on a different boundary: what is admitted by the runtime and the application, how that admission remains accounted for, and how it reconciles with what happened next.
The two problems are not identical.
And we have not run any benchmark that would allow these architectures to be ranked.
What interests us more is that the industry is finally starting to ask a better question:
no longer just
"What is my agent doing?"
but:
"What will I actually be able to demonstrate about what it did?"
Today, we can defend a limited property:
When an admission crosses a declared KOREV boundary that is instrumented and acknowledged by the configured witness, it must then remain accounted for and be reconciled before the population can be classified VERIFIED.
We cannot say that:
And that is precisely why we publish these limits alongside the results.
Our development repository remains private.
But verifiable does not have to mean open source.
So we are preparing a controlled reproduction pack that includes in particular:
The goal is simple:
to let someone who has no reason to believe us try to demonstrate that our property does not hold.
Because ultimately, that is probably the best definition of technical proof:
something you can try to refute.
In April, I wrote that we too often confuse an answer with proof.
A few months on, our position has evolved slightly.
We no longer try to say:
"KOREV produces proof."
We try to be able to say exactly:
here is the property we claim, here is the boundary within which it holds, here is how we tried to break it, here are the results, and here is what it does not demonstrate.
It is less spectacular.
But as AI agents gain access to our data, our systems, and our business processes, it will probably be far more useful.
Because in a complex system, trust is not a feature.
It is the consequence of what you are able to verify.
See how multi-model consensus produces verifiable, auditable decisions.