Trust model

InvarLock separates evidence creation, technical verification, portable recipient acceptance, and presentation into four transactions. The separation preserves the team's intended comparison when inputs and signing roles are controlled independently. The same organization or operator can maintain those roles using separately approved expectations and distinct evidence/verifier keys.

Security guidance

In plain language: A valid signature identifies a key; trust comes from independently deciding that the key, policy, artifacts, schedule, runtimes, and scoped result are the ones you intended to rely on.

Objective: Define what evidence-signer, technical-verifier, and envelope signatures establish, which anchors must remain independent, and the exact scope of a trusted receipt or portable acceptance envelope.

Assets or boundary: Canonical evidence, evidence-signer, verifier, and envelope-signing identities, technical and recipient policy, artifact, schedule, subject, and runtime anchors, authorized scorer code when selected, receipt and acceptance statements, and the authorization sources that are intentionally outside submitted evidence.

Use this page when: Assigning evidence signer, technical verifier, envelope signer, recipient, or receipt-verifier roles; designing trust-anchor distribution; or evaluating whether a signed result supports a proposed reliance decision.

The equations and runtime anchors below describe native pack-v1 evidence. Captured comparisons and bounded judge measurements have separate trust inputs; their boundaries are summarized after the anchor matrix.

Trust statement

Let $M$ be the canonical pack manifest, $\sigma_E$ its evidence signature, $\pi_V$ the independently supplied policy, $A_B$ and $A_S$ the expected artifact-identity digests, $d_{\mathcal S}$ the expected canonical schedule digest, $R_B$ and $R_S$ the expected runtime digests, and $K_E$ the expected evidence-signer fingerprint. Let $d_{\mathcal Q}$ be the independently approved normalized-request digest required when either side uses llama_cpp. Define the base verifier anchor set as:

For non-GGUF evidence, $A_V=A_V^0$. When either side uses llama_cpp, $A_V=(A_V^0,d_{\mathcal Q})$.

Let $V(E,A_V)$ be the replay result and $Q$ the signed receipt statement. The cryptographic checks establish:

and:

Acceptance additionally requires external authorization of $K_E$ and $K_V$, exact agreement with $A_V$, and this replay condition:

Cryptographic validity alone is therefore necessary but not sufficient. Portable recipient acceptance adds a second authorization decision: the recipient authenticates the DSSE envelope signer and the technical receipt verifier against separate current trust registries, binds the exact subject, and applies current freshness, contract-version, signer-status, and verdict policy. A valid outer signature cannot authorize the inner receipt signer.

Diagram

Trust anchors flow through separate evidence, verifier, and receipt domains with explicit rotation and revocation boundaries.

Roles and trust roots

The verifier must not derive an expected value from the evidence field that the value is intended to check. Copying the policy, artifact identities, schedule digest, runtime digests, evidence-signer fingerprint, or GGUF normalized- request digest from the submitted bundle makes the check circular.

Trust-anchor matrix

An anchor source must be protected from the evidence submitter for the threat it addresses. Merely storing the same value in two files does not create independence.

Captured, hosted and judge trust inputs

Captured comparison uses invarlock/trust-inputs-v2: independent complete-run pins, normalized-request pin, policy bytes, signer fingerprint and verifier identity/key. Its v3 receipt states captured_comparison scope and each metric's recorded or recomputed scoring assurance. These anchors do not substitute for native artifact, schedule and runtime anchors.

A captured hosted run uses a declared service_identity and artifact_digest: null. The complete-run pin covers the descriptor's configuration and observation window. It does not authenticate hidden weights, provider-internal execution or subsequent service behavior.

Bounded judge evidence uses its own recipient policy to pin the signer, intended subject, frozen runs, case set, plan, measurements, analysis policy and result. Native judge evidence additionally binds native_capture_sha256. Offline verification returns separate authentication, replay, verification, acceptance and decision fields. A local result can be unsigned; an optional judge receipt authenticates that result for handoff under its own receipt contract. verified: true does not imply accepted: true: advisory evidence cannot satisfy required recipient acceptance, even when its decision is pass. See judge measurements.

An externally assigned scalar rating may be evaluated as a captured recorded metric when policy explicitly approves its provenance. That verifies retained scores and their aggregation, not the original judgment or the bounded judge trial contract. Judge accuracy studies are complementary evidence selected by the decision owner, not a prerequisite for runtime verification.

Signed bytes are not truthful measurements

The Ed25519 evidence signature establishes that:

• the signing key corresponds to the fingerprint in the bundle;
• the signature covers the canonical manifest bytes; and
• the manifest binds the complete checksummed inventory.

It does not establish that the evidence signer is honest, that a model ran, or that a measurement is correct. An authorized but compromised evidence signer can fabricate a mutually consistent set of provider facts and sign it.

The verifier signature similarly establishes who signed the receipt and which manifest, anchors, and replayed verdict it covers. It does not make the source measurements true. It authenticates the named verifier's recorded result under the stated anchors and verifier implementation, including a failure result. Acceptance requires checking the verdict and applicable independent policy.

Trust in either statement therefore requires an external authorization binding between a real actor and the pinned public-key fingerprint.

InvarLock's fingerprint is:

RawEd25519 is the 32-byte public-key encoding. The fingerprint is not an X.509 certificate, decentralized identifier, or proof of possession. It is a compact key identifier that must be authorized elsewhere.

Digest identity is not execution attestation

A SHA-256 digest answers an identity question: the supplied bytes or canonical material match the digest. The verifier cross-checks independently expected artifact identities and schedule with the policy, observations, reports, runtime manifests, and runtime image digests bound into the evidence.

A runtime digest does not prove that the image executed the workload. The runtime manifest is evidence submitted by the evidence signer. Matching it against an external expected digest prevents the bundle from choosing a different declared image, but cannot detect an evidence signer that claims the expected digest without executing it. Use an independently controlled rerun or an external attestation system for that stronger claim.

Trust domains

Submitted evidence

Treat every file in the evidence directory as untrusted input until verification succeeds. The verifier checks canonical JSON, safe paths, bounded files, the exact inventory, checksums, signatures, versioned schemas, input identities, provider cross-bindings, schedule order, per-record scores, report arithmetic, the selected paired interval, optional count/width qualification, optional exact-match side-accuracy qualification, and the policy result.

A scorer binding inside the submitted request or evidence is also untrusted. It identifies requested code and configuration but cannot authorize either.

Independent anchors

The verifier's policy bytes, baseline and subject artifact-identity digests, canonical schedule digest, runtime digests, evidence-signer fingerprint, GGUF normalized-request digest when applicable, verifier identity, and verifier key are outside the submitted evidence. Their source, review, authorization, rotation, and revocation are operational controls. InvarLock records them; it does not operate a public-key infrastructure or policy distribution service.

For portable acceptance, the recipient additionally supplies current policy, separate envelope-signer and receipt-verifier registries, optional expected receipt trust-profile digest, and either expected subject bytes or an approved subject digest. These inputs must not be copied from the submitted envelope. Each registry permits only one record for an identity/fingerprint pair; duplicates invalidate the policy regardless of record order or status, and each authenticated signer must match exactly one record.

When a scorer extension is selected, the verifier also supplies an explicit ScorerExtensionRegistry from outside the evidence path. The independent policy pins the scorer ID, version, descriptor digest, and configuration digest. The registry must resolve that exact binding, and replay must produce the same canonical result twice. Scorer code is part of the verifier's trusted computing base: review and distribute it with the same discipline as verifier code. A deterministic extension scorer must not use a network, external model, externally assigned ratings, or LLM judge. InvarLock checks the authenticated scorer identity and deterministic replay; it does not sandbox extension code or prove those operational restrictions. The native judge scorer collects or imports bounded ratings under a separate evidence and recipient-policy contract. Only live collection requires the installed collector and provider credentials; verification replays retained measurements offline. Native judge evidence binds its runtime capture, while imported answers retain their supplied-source provenance. Judging does not execute through the deterministic scorer-extension trust boundary.

Authorization lifecycle

For each evidence signer, technical verifier, and envelope-signer identity, the deployment should maintain:

• fingerprint and role;
• owner and approving authority;
• issuance, activation, expiry, and revocation times;
• allowed evidence or policy scope;
• rotation predecessor/successor links; and
• compromise and re-verification procedure.

The evidence pack, receipt, and acceptance envelope do not query this lifecycle. A receipt verifier or recipient must check that the relevant keys were authorized for their distinct roles at the decision time.

Runtime and provider

For native model execution, runtime receipts bind an integration implementation, artifact identity, scoring observation, execution settings, device facts, and outer image digest. The host prepares the canonical schedule, then launches a separately digest-pinned Docker or Podman worker for each side. Each worker runs with network disabled, a read-only container root, reduced privileges, read-only job, artifact, and support mounts, and one isolated writable output directory. The host validates both closed worker outputs and signs the finalized bundle; the evidence-signing key remains host-side and is never mounted into either model worker.

Common image, device, and entrypoint options serve as defaults that per-side options may override. CPU workers may run together. Workers using the same or generic CUDA selection run sequentially, while two distinct explicit CUDA indexes may run in parallel. Strict execution also requires offline local material, remote code disabled, and authenticated checkpoint/tokenizer inputs. These controls reduce ambiguity and exposure; the container engine, host, kernel, accelerator, and host-side signing process remain trusted boundaries.

Schedule and policy selection

Exact pairing proves that both sides used the same submitted schedule. It does not prove that the schedule is representative or that the selected baseline, subject build, seed, policy, or run was chosen without looking at results. Review and precommit those choices outside the evidence transaction.

Receipt boundary

The signed receipt remains outside the immutable bundle so that multiple verifiers can evaluate identical evidence using independently sourced copies of the policy bound into that bundle and their own authorized identities and keys. It binds:

• the pack manifest digest;
• the independent policy digest;
• baseline and subject artifact-identity digests;
• the canonical schedule digest;
• baseline and subject runtime digests;
• the expected evidence-signer fingerprint;
• the normalized-request digest when either side uses llama_cpp;
• verifier identity and verifier fingerprint; and
• integrity, policy, and overall verdicts.

Archive the bundle and receipt together, but never insert a receipt into the already signed bundle.

Receipt verifier rule

A downstream receipt verifier should verify the receipt against independent expected verifier identity and fingerprint, then confirm that its statement binds the expected pack manifest and anchors. Trusting the public key embedded in the receipt without an external fingerprint check only proves self-consistency.

Portable acceptance boundary

Acceptance predicate v2 transports the signed receipt inside an in-toto Statement and DSSE envelope. The receipt signer is the technical verifier; the envelope signer is the party transporting the result. They may be the same identity and key, but recipient policy evaluates the roles independently. A countersigned relationship does not allow either registry to substitute for the other.

The recipient verifier:

• authenticates the DSSE signer against exactly one active envelope-signer trust record;
• authenticates the embedded receipt signer against exactly one active receipt-verifier trust record;
• optionally pins the receipt's independently maintained trust-profile digest;
• binds the statement to exact recipient-supplied subject bytes or digest;
• requires the outer predicate and inner receipt to agree on the technical verdict, artifacts, schedule, policy, contract version, and signer;
• evaluates envelope age from attestation_issued_at separately from evidence age derived only from the receipt-authenticated receipt_issued_at; and
• retains the exact supplied receipt bytes in receipt.raw_base64, with a digest over those decoded bytes and parsed-content equality.

The native v1/v2 receipt formats retained from v0.13 have no authenticated issuance time, including receipts created by the current implementation. Wrapping them cannot invent one: receipt_issued_at remains null, so they cannot satisfy a recipient policy that requires bounded evidence age. Creating a fresh envelope changes transport metadata only. This portable acceptance path supports native pack-v1 receipts; captured and judge receipts retain separate handoff contracts.

This boundary authenticates and policy-evaluates the portable projection; it does not replace full evidence replay with invarlock verify. The envelope is standards-shaped in-toto/DSSE transport, but interoperability with an external CUE, Open Policy Agent, or other policy engine requires a separately validated integration.

Non-goals

The trust model does not provide:

• execution attestation or proof of physical runtime state;
• key issuance, identity proofing, transparency logs, revocation, or secure key custody;
• representative sampling or population-level statistical assurance;
• correctness, safety, alignment, or provenance of the baseline itself;
• model-content safety, prompt-attack defense, or deployment authorization;
• external policy-engine authentication or policy-evaluation interoperability for the acceptance envelope; or
• host hardening, container-engine security, GPU isolation, or secret management.

See the assurance case, reproducibility limits, and Threat model. The portable recipient contract is specified in Acceptance attestations.

References

• RFC 8032: Edwards-Curve Digital Signature Algorithm, 2017.
• National Institute of Standards and Technology, Digital Signature Standard, 2023.
• National Institute of Standards and Technology, SP 800-57 Part 1 Revision 5: Recommendation for Key Management, 2020.
• in-toto project, Attestation Framework Specification 1.2, 2026. Its statement/predicate/envelope separation is useful context for distinguishing authenticated metadata from the truth of its predicate.