What makes an implementation Provetrail-conformant?

An implementation is Provetrail-conformant if it accepts every valid record in the published vector suite and rejects every malformed or tampered one. Conformance is defined by the vectors, not by who wrote the code, and not by us. Any runtime, in any language, can be conformant. That is the point of publishing the vectors: it turns “trust our verifier” into “run yours against the same records and see that they agree.”

Conformance is defined by vectors, not vendors

A standard is only real if two independent implementations agree on the same inputs. Provetrail publishes conformance vectors for exactly this: a set of valid records a conforming implementation must accept, and a set of malformed or tampered ones it must reject.

That makes conformance a property you can measure rather than a badge someone grants. If a verifier passes the suite, it is conformant. If it fails, it is not, and the specific vector it failed on tells you where. No committee, no self-certification, no taking anyone’s word for it.

What the suite checks

The must-reject cases are where a standard earns its keep, because they pin down the failure behaviour that a vague spec would leave to interpretation. A conforming implementation must reject at least:

• A broken chain: an event altered after the fact, so the recomputed Merkle root no longer matches the signed root.
• A bad signature: a record signed by the wrong key, or not validly signed at all.
• A non-monotonic sequence: events that claim an ordering the sequence numbers contradict.
• A fold mismatch: a final state that is not the deterministic result of folding the event stream.
• A byte/logical disagreement: carried bytes that do not match the logical content they claim to encode.

The must-accept cases confirm the inverse: valid records verify cleanly. An implementation that rejects a valid record is as non-conformant as one that accepts a tampered one.

The tiers an implementation can reach

Not every implementation does the same job, and conformance is honest about that. There are distinct tiers:

• Integrity. Signatures and the Merkle chain verify. This is what a thin, read-only verifier in any language does, and it is enough to confirm a record is authentic and untampered.
• Governance. Each side-effecting action carries the authorization decision that admitted it, so “nothing ran without authorization” is checkable.
• Ground truth. A claimed success is bound to committed evidence, so an unbacked “done” is rejected.

A verifier can be conformant at the integrity tier without touching the other two. The governance and ground-truth tiers describe records that a governed runtime enforced and emitted; a verifier reads them, but only a runtime can produce them. That distinction is covered in signed versus proven.

The reference implementation today

Every standard needs running code, not just a document. The reference implementation of Provetrail is Flynn, an open agent runtime. It emits records as it executes and verifies them per tier with flynn spine verify.

As of this writing, Flynn is the only complete implementation we are aware of that passes the full conformance suite across all three tiers. Other approaches in this space reach the integrity tier, a signed and tamper-evident record, which is genuinely useful. Passing the governance and ground-truth tiers requires a runtime that enforces those invariants at the point it dispatches an action, which is a different kind of system than a wrapper or a logger. We would rather state that as a checkable fact than as a claim: run the vectors and see which tiers an implementation clears.

The full Flynn write-up lives on Flynn’s own site.

Implement your own

A conformant third-party verifier is not a threat to the standard; it is the standard working as intended. The verification path is deliberately thin: rehash the carried bytes, check the signature on the signed root, and confirm the chain. A verifier does not re-serialize anything, so it cannot drift from the producer. The mechanics are walked through in how third-party verification works, and you can see a verifier run client-side on the home page.

If you build one, run it against the published vectors. If it agrees with the reference implementation on every case, it is conformant, and your users no longer have to trust either of us.

For the definition of the category, see what is verifiable execution provenance.

Last updated: 12 July 2026.