InvarLock 0.14.0: Evaluator Evidence In, Recipient Policy Out

The evaluator may produce the records. It does not get to decide what the recipient trusts.

Teams rarely use one evaluation tool forever. A research group may run LM Evaluation Harness, a security team may use Garak, and a production group may depend on a private evaluator. The review problem is the same: which records must be saved so another person can check the result, and who decides whether to accept it?

InvarLock 0.14 extends the v0.13 comparison at both ends. Before verification, evaluator imports must provide a common set of records and identities. After verification, the receiving organization applies its own trust rules and requirements through recipient acceptance.

At a glance — v0.14 release snapshot

• Import supported evaluator records into a common format for independent replay.
• Preserve aggregate or unsupported output as observation-only context.
• Carry the exact signed receipt to the recipient in a Dead Simple Signing Envelope (DSSE).
• Apply recipient-owned policy without rewriting the historical result.

One evidence boundary for many evaluators

Knowing which evaluator produced a score is not enough. A reviewer also needs the complete ordered records from which another verifier can recalculate it.

Consider an export containing a model name and accuracy: 0.71. The number may be correct and signed. Without its records and schedule, however, a verifier cannot confirm that every sample appears once, both sides use the same order, or the governing contract permits that record shape.

Version 0.14 defines four closed JSON, CLI, and Python contracts at the evaluator-neutral qualification boundary. Maintained runners execute pinned upstream entry points, then normalize their output into those common contracts.

At release time, the v0.14 matrix described three progressively deeper demonstrations:

The 17 authoritative rows replay one pinned Qwen3-0.6B exact-match evaluation: 102 ordered records, 52 matches, and 50 mismatches. That retained run demonstrates exact-match import compatibility for those profiles. It is not a general ranking of evaluators.

The matrix also retains two outputs as context. MLflow is aggregate-only, so another verifier cannot reconstruct its records. Garak uses replay semantics that the v0.14 contract does not support. Both remain authenticated observations outside the paired verdict.

Historical note: Version 0.14 described evaluator evidence as cumulative “levels.” Version 0.15 replaces that framing with three independent axes: adapter support, replay authority, and signed-journey maturity. See An Evaluator Can Be Supported Without Being Decision-Ready for the newer model.

Why replay authority follows records

Before allowing imported records to determine the result, ask four questions:

• Were all expected samples present exactly once?
• Did the evaluator score the baseline and subject in the same order?
• Can the metric be recomputed without trusting the aggregate?
• Does the governing contract allow that record shape to determine policy?

That is why v0.14 does not equate “adapter maintained” with “decision-ready.” Authority comes from the retained evidence and its contract, not from the popularity or commercial status of the evaluator.

A verified result is still not recipient acceptance

Version 0.13 gave the technical verifier independent replay authority. Version 0.14 adds a separate question: is that authenticated result acceptable now for the exact artifact this recipient is considering?

For example, a receipt can verify artifact A while a deployment job fetches artifact B. The historical comparison remains valid, but the recipient must reject the handoff because the supplied subject no longer matches the receipt.

The distinction matters because technical verification and recipient acceptance operate on different clocks and trust stores. A result can remain historically valid while a current recipient rejects it because the evidence is stale, a signer is no longer trusted, the contract is unsupported, or the supplied artifact does not match the approved subject.

The portable handoff works in five steps:

1. The evaluation operator identifies the exact baseline and subject artifacts.
2. Per-record results are recomputed and published in a signed evidence pack.
3. An independent technical verifier replays the pack and signs a receipt.
4. An envelope signer places the exact receipt bytes in an in-toto Statement—an explicit software-supply-chain claim—then carries that statement in a Dead Simple Signing Envelope (DSSE).
5. The recipient authenticates the envelope, binds it to the artifact bytes, and applies current policy.

Diagram

A DSSE envelope carries an exact signed receipt to a recipient that separately authenticates both signatures, binds the subject, and applies current policy.

From signed receipt to recipient policy

Authenticate

Check the outer envelope signature and the inner technical receipt against separate trust registries.

Bind the subject

Match the supplied artifact to the exact subject named in the authenticated receipt.

Apply current policy

OPA/Rego or CUE receives authenticated fields. Evidence age and envelope age remain separate.

Full evidence replay remains the job of invarlock verify. Acceptance is not deployment approval.

The outer envelope signer authenticates transport and statement bytes. The inner receipt verifier authenticates the technical result and evidence identity. Trust in one never substitutes for trust in the other.

Freshness remains separate too. Envelope age comes from the attestation timestamp. Evidence age comes from the timestamp authenticated by the technical receipt. Re-signing an old result for transport does not make the evidence young again.

Policy engines receive an authenticated projection

The retained fixtures reject a handoff when its artifact, signer, freshness, contract, or technical verdict is wrong. They also retain one accepted handoff, so reviewers can see each boundary close for a specific reason.

The release includes these policy-engine fixtures for Open Policy Agent's Rego language and for CUE configuration rules. Authentication comes first. Policy evaluation comes second.

A local verifier checks the signed handoff and exact subject. It then emits an authenticated projection: a small verified set of fields that Rego or CUE can evaluate safely.

The receipt-envelope reference shows the nested statement and exact receipt fields.

Historical verification, current acceptance

Version 0.14 makes a long-term compatibility promise explicit. Existing v0.13 evidence and receipts remain verifiable under their original rules: how files are read, linked, recalculated, and judged against policy. Their format identifiers and receipt bytes are preserved rather than relabelled as v0.14 evidence.

Recipient acceptance is intentionally different. It is a current decision. A recipient can apply today's signer registry, freshness window, supported-contract set, and exact-artifact policy to an older technical result without altering what that historical result meant.

This gives the two layers a useful independence:

• Verification asks: what did the authenticated evidence establish under its original contract?
• Acceptance asks: does our organization accept that exact result for this exact subject now?

The compatibility covenant defines the permanent verification side of that relationship.

What changed from 0.13

Choose the example that matches your handoff

Use the retained evaluator records to inspect import and replay, and the acceptance fixtures to inspect subject binding and current recipient rules. Their exact-match corpus and named integration do not establish every evaluator feature. Recipient acceptance covers this technical handoff; deployment authorization remains with the receiving organization. The tagged sources below preserve the v0.14 contracts and outcomes.