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 levels an implementation can reach

Not every implementation does the same job, and conformance is honest about that.

Provetrail’s conformance model has four levels, L1-L4 (defined in CONFORMANCE.md, which is authoritative). In prose we sometimes group them under a three-word shorthand, and that shorthand maps onto the levels exactly one way: integrity = L1-L3 (the record is canonical, signed, and provable) and governance + ground truth = L4 (what the record’s events establish about admission and outcomes).

A verifier can be conformant at the integrity levels without touching L4. The governance and ground-truth events are ones 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.

Flynn’s reference verifier passes the published suite at L1-L4 as scoped at this version. L4 at this version means exactly two things: admission completeness (gov.*) and outcome binding (shallow.no_ground_truth); gate-result consistency and containment-downgrade detection are explicitly deferred and are not part of conformance at this version. The three reference clients (Rust, Python, npm) implement the integrity tiers (L1-L3).

Other approaches in this space reach the integrity levels, a signed and tamper-evident record, which is genuinely useful. Producing L4 records 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 levels 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.