Signed vs proven: what a runtime record can and can't prove

A signature proves that a specific key emitted a specific set of bytes, and that nobody changed them afterward. It does not prove the work behind those bytes was real. If the same component that does the work also writes and signs the record of the work, a valid signature only tells you that the emitter asserts something happened. Whether it happened is a separate question, and it is the one a customer or an auditor is asking.

This is the difference between an attestation and a proof. “Verifiable” gets used for both.

The specification is a draft (0.1.0-draft). Everything below describes what it and the reference runtime do at that version.

What “signed” gets you

A signed record gives you two guarantees:

• Authenticity. The record was emitted by the holder of a particular key, which you can check against a published identity.
• Integrity. The record has not been altered since it was signed. Commit the events to a Merkle tree and sign its root, and an edit to any earlier event breaks verification of the whole record.

Both of those ship in Provetrail today and can be checked client-side against a signed Merkle root. They are where the guarantees start.

The gap is that a signature says nothing about the content’s truth. A wrapper that signs “I summarized the document” signs that string whether or not it summarized anything. The cryptography is sound; what it secures is who made the claim.

What Provetrail adds beyond signed

The reason to have the governed runtime write the record is that the runtime can commit to facts the agent could not fabricate. Two of those go beyond integrity:

• Governance. Every side-effecting action is admitted against a policy before it runs, and the admission decision is written into the record. Because the runtime that mediates the action is what writes the line, “no action ran without authorization” becomes a property a verifier can check.
• Ground truth. A claimed success is bound to a committed check. A record that says “done” with nothing behind it is rejected. The claim carries a hash of what was observed, so an authorized party can re-run the check without trusting the verifier.

Both are checked at the governance level (L4) of the conformance suite, by a verifier such as flynn spine verify. The npm package and the browser demo stop at integrity.

These are the properties that separate “here is a log I signed” from “here is a record a runtime enforced.” They hold because the thing that wrote the record is the thing that refused the bad path. In the reference implementation, Flynn, the invariants are enforced at the point an action is dispatched, and the same dispatcher writes the record. An unmodified runtime therefore records only paths it allowed.

The ceiling, stated plainly

Checked at every level, a Provetrail record proves that the record is intact, authentic, governed, and bound to evidence. It does not, on its own, prove two things:

1. That the emitting runtime was not itself modified. If someone tampers with the binary that produces and signs records, it can emit a record that is internally consistent and correctly signed but describes work that never happened the way it says. A signature over the output cannot catch a compromised producer of that output.
2. That nothing was omitted. A record proves that the events it contains happened as described. It does not by itself prove that no other events happened and were left out.

Closing those two gaps is a different class of problem than signing. We are working on both:

• A proven emitter. Binding the record to a measurement of the exact, reviewed build that produced it, so a verifier can confirm the record came from that build. Hardware attestation is one route to this, and it requires the run to happen inside an enclave.
• Omission-resistance. Structural commitments that make a dropped or withheld event detectable.

We are not claiming either today. When one ships, we intend to say so with the same specificity, and to add a conformance vector you can run to check it.

Why we publish the ceiling

Two reasons. First, in our view, a buyer who cannot yet tell “signed” from “enforced” from “proven-emitter” will be sold the cheapest of the three as if it were the dearest. Naming the ceiling keeps the words attached to what they mean.

Second, the ceiling is exactly what a skeptic will quote, so it is better quoted from us, with the reasoning next to it.

If you want the guarantees in mechanical detail, see how third-party verification works. For the definition and where this sits among neighbouring standards, see what is verifiable execution provenance.