InvarLock 0.14.0: Evaluator-Neutral Evidence and Recipient-Controlled Acceptance

Evaluator-neutral qualification, portable acceptance, and a permanent v0.13 verification covenant

Highlights

• A common JSON, CLI, and Python qualification boundary now retains evidence from open-source or proprietary evaluators.
• The maintained matrix covers 19 upstream profiles. Seventeen have deterministic per-record authoritative imports over the retained 102-record evaluation; two remain observation-only.
• A canonical in-toto Statement in a DSSE envelope carries the signed technical result to a recipient that controls its own trust, freshness, contract, and exact-artifact policy.
• Existing v0.13 receipts retain their original bytes and verification semantics while gaining a portable path into current recipient policy.

InvarLock 0.13 defined one closed evaluation transaction: authenticate the baseline, subject, data, runtime, policy, metric, schedule, and evidence destination; evaluate or import both sides; sign the evidence; independently verify it; and report from the same canonical result.

Version 0.14 extends that transaction in two directions. On the input side, it defines how evidence from many evaluators can cross one authority boundary. On the output side, it defines how a verified technical result can cross into a recipient's current acceptance process. Verdict authority remains grounded in independently replayable evidence throughout the flow.

One qualification boundary across evaluators

The core exposes one evaluator-neutral qualification boundary through four closed contracts. Runners maintained in the examples tree execute pinned upstream tools and normalize their output for the same JSON, CLI, and Python surfaces.

Authority follows the completeness of the retained evidence. When an adapter supplies the deterministic per-record surface required by the runtime-import boundary, InvarLock independently recomputes the results and can use them in the paired verdict.

The v0.14 matrix keeps three claims separate:

The 17 authoritative profiles replay one pinned Qwen3-0.6B exact-match evaluation containing 102 records: 52 exact matches and 50 mismatches. The demonstrated scope is exact-match compatibility for this retained evaluation.

The matrix also retains two useful observation surfaces. MLflow contributes aggregate-only output, while Garak currently has unsupported replay semantics. Both remain visible as observations, while verdict computation stays reserved for replayable per-record evidence.

A technical result and a recipient decision

Technical verification asks whether the authenticated evidence still satisfies the contract under which it was produced. Recipient acceptance asks whether that verified result is acceptable now for an exact artifact under the recipient's current policy.

Version 0.14 makes the handoff between those decisions portable:

1. An 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 that receipt, including the exact supplied receipt bytes, in an in-toto Statement carried by a DSSE envelope.
5. The artifact recipient authenticates the envelope, binds it to the artifact bytes, and applies current policy.

The envelope signer and technical receipt verifier have separate recipient-controlled trust registries. This preserves both trust decisions: who verified the technical evidence and who transported that result to the recipient.

Freshness is separated in the same way. Envelope age comes from the attestation timestamp, while evidence age comes from the timestamp authenticated by the receipt. Each layer therefore retains its own history when a recipient applies current age limits.

Policy engines consume an authenticated projection

The release includes standalone OPA/Rego and CUE interoperability fixtures. A local verifier first authenticates the canonical envelope, the embedded receipt, both signatures, signer identities, subject binding, and agreement between the signed verdict projections. OPA or CUE then evaluates the resulting invarlock/acceptance-policy-input-v1 projection.

The division of responsibility is explicit. The local verifier handles canonicalization, Ed25519 signatures, receipt authentication, and subject binding. Rego and CUE apply current recipient policy to the authenticated projection. invarlock verify remains the full semantic replay path for the complete evidence pack.

The committed fixture set covers an accepted case plus policy rejection, subject tampering, an untrusted signer, stale evidence, and an unsupported contract. Together, these fixtures exercise the successful handoff and the fail-closed outcomes for trust, freshness, subject identity, and contract support.

Permanent verification, current acceptance

Version 0.14 also makes the v0.13 compatibility promise explicit:

• v0.13 evidence and receipts remain permanently verifiable under their original parsing, binding, replay, and decision semantics;
• their original format identifiers and exact receipt bytes are preserved rather than relabeled as v0.14 evidence; and
• recipient acceptance remains a current decision.

The last point is essential. Current policy can produce a different acceptance outcome when signer status, evidence freshness, contract support, or the supplied artifact has changed. The historical technical result remains intact while the recipient applies today's requirements.

Version 0.13 therefore remains the technical foundation. Version 0.14 carries its signed result into a portable acceptance handoff while preserving its original meaning.

Limitations

• The 17 authoritative imports cover exact match over one retained 102-record Qwen3-0.6B evaluation; other tasks, metrics, models, and judges require their own retained evidence.
• Qualification, authoritative import, and end-to-end release assurance are separate levels. LM Evaluation Harness is the current end-to-end demonstrated profile.
• Aggregate-only and unsupported-replay inputs stay in the observation layer, separate from verdict computation.
• The acceptance predicate covers the authenticated technical handoff. Recipients retain wider deployment policy, and invarlock verify retains full evidence replay.

Sources

• InvarLock v0.14.0
• v0.14.0 changelog
• Evaluator qualification
• Acceptance attestations
• Policy-engine interoperability
• Compatibility covenant
• Golden acceptance-handoff package