Artifact Identity Is Not Runtime Identity: A Note on Trustfall Lite's Evidence Class

Coslett, Anthony Ray

doi:10.5281/zenodo.20019127

Abstract

A model artifact can be verified on disk without establishing which model is computing at runtime. Trustfall Lite is an open-source command-line tool (Apache-2.0) that scans local Hugging Face and Ollama model caches, computes the SHA-256 of each artifact, and verifies the hash against a signed registry whose records are JWS-signed and verified against a published JWKS. Every artifact resolves to one of four statuses: verified, unknown_variant, not_enrolled, or pilot_available. The tool runs locally; model bytes are not transmitted, and file paths and filenames are not sent to the verification API. By default, artifact hashes may be queried against the Fall Risk API; --local-only verifies against a cached registry without network lookup. This note describes what artifact-level verification establishes, where it stops, and how it relates to the runtime structural identity measurement developed across the Fall Risk Research program. Artifact verification is necessary but not sufficient: the same SHA-256 can serve different runtimes, models can be loaded over the network without touching disk, and disk-time identity does not guarantee runtime identity. The boundary between these two evidence classes — file-level and runtime — is the subject of this note.

1. The Distinction

Two questions arise when a model is deployed:

Is the file on disk the file you think it is?
Is the running process computing what the file says it should?

These are different questions. They require different evidence. Neither answer implies the other. The admissibility doctrine [4] formalizes this separation: evidence from one identity layer cannot certify claims about another when the layers are operationally independent.

Trustfall Lite verifies what model artifact you have.
Trustfall Deep verifies which model is actually computing.

Artifact verification — what Lite does — answers question 1. It confirms that the bytes on disk match a signed enrollment record. It does not answer question 2: whether the model that is running in memory, serving inference, and producing outputs is structurally identical to what those bytes describe.

This gap is real in at least three operational settings:

Models loaded over the network and never written to disk.
Inference environments where disk-time and runtime can diverge (quantization, mixed precision, alternative kernels).
The same artifact hash serving different runtime configurations.

For those cases, runtime structural identity verification — measuring the model's activation geometry during ordinary forward computation — is the complementary evidence layer. That measurement is the subject of the broader research program [1, 2, 3]. This note concerns the artifact layer: what it establishes, what it does not, and how to use it.

2. Trustfall Lite

Trustfall Lite is an open-source artifact verification tool released under the Apache-2.0 license.

2.1. Installation

pipx install fallrisk-trustfall

The tool installs on Linux and macOS via pipx. Windows support is on the same release path. Source: github.com/fallrisk-ai/trustfall-lite.

2.2. What it does

Scans the local Hugging Face cache for model artifacts.
Scans Ollama models when present.
Computes the SHA-256 of each artifact.
Looks up the hash in the signed Fall Risk Registry.
Reports one of four statuses for each artifact.
Verifies registry record signatures against the published JWKS (RFC 7515).

2.3. What it does not

Measure the model at runtime. Lite verifies the artifact; runtime structural verification is a separate evidence class.
Verify what the model does — only what it is on disk.
Send file paths, filenames, or model names.
Send hashes when run with --local-only.
Assert that a model is safe, endorsed, or fit for any purpose.
Replace runtime structural identity verification.

2.4. Release snapshot

This note describes Trustfall Lite v0.3.2 (May 2026 release) against Fall Risk Registry v0.2.3.

Trustfall Lite package: fallrisk-trustfall
Registry version: v0.2.3
Registry records: 211
Evidence classes: 165 itpuf_structural_identity, 46 artifact_identity
Issuer kid: fallrisk-96cd5e6a01e1
Manifest digest: 0568fe38fc3fb4801b016450d23d2fce963f523204eb105db59fa4755ff13846
CI matrix: Python 3.10–3.13 across Ubuntu, macOS, and Windows at publication time

Enrolled model families include Llama, Gemma, Qwen, Mistral, Phi, and DeepSeek. The live registry may grow after publication. The claims in this note are scoped to the release snapshot above.

3. Commands

The May 2026 release exposes five commands.

Command	Purpose
`trustfall scan`	Scan default HF and Ollama locations. Report a status per artifact.
`trustfall verify <hash>`	Verify a single SHA-256 against the signed registry.
`trustfall registry`	Show registry status: manifest digest, issuer kid, snapshot date.
`trustfall version`	Print Lite version and registry version.
`trustfall diff <a> [b]`	Compare two scan-output JSONs. Report group, artifact, and status changes.

3.1. The diff command

trustfall diff compares two scan outputs and reports changes to groups, artifacts, and statuses. Two invocation forms are supported.

The explicit two-file form is recommended for CI and reproducibility:

trustfall scan --json > baseline.json
# ... time passes; models are added or removed ...
trustfall scan --json > current.json
trustfall diff baseline.json current.json

The implicit-current form runs a fresh default-scope scan in-process:

trustfall diff baseline.json

The implicit form is allowed only when the baseline was taken with default scope (no explicit paths). If the baseline used explicit scan paths, the diff exits 64 with instructions to provide an explicit current scan.

By default, the diff is printed and the command exits 0 regardless of what was found. Two opt-in flags are available for CI integration:

--exit-code — Exit 1 if any change is detected.
--exit-code-on-status-regression — Exit 2 only when a previously verified group regressed (verified → any non-verified status).

Additional flags shape output:

--json — Machine-readable JSON output.
--quiet — Suppress empty change-class sections in text output.

Exit codes follow this precedence:

Code	Meaning
0	No changes, or changes detected with no exit-code flag set
1	`--exit-code` set and one or more changes detected
2	`--exit-code-on-status-regression` set and a regression exists
64	File I/O error, malformed JSON, or implicit-current refused
65	Parseable JSON but not a Trustfall Lite scan output
66	Trustfall Lite scan from an incompatible major version

When both exit-code flags are set and a regression exists, exit code 2 wins (more specific).

4. Output Statuses

Every artifact in the local cache resolves to one of four statuses. The vocabulary is locked. Trustfall Lite does not editorialize beyond what each status says.

Status	Meaning
✓ `verified`	Artifact SHA-256 matches an enrolled record in the signed registry, and the record's JWS signature verifies under the published key (RFC 7515). The file on disk byte-matches the artifact hash committed by the registry record. This status does not assert that the model is safe, endorsed, or fit for any purpose — only that the bytes match a signed enrollment.
△ `unknown_variant`	A model with this name appears in the registry, but the bytes on disk do not match any signed enrollment. The variant could be a legitimate alternate build or a modified artifact.
? `not_enrolled`	Fall Risk has not enrolled this model. The registry holds no record against which to verify the artifact. Lite does not assert whether the file is good or bad — only that there is nothing to compare it to.
→ `pilot_available`	The model or artifact is on the pilot enrollment list. It has been queued for controlled enrollment review but has not yet been signed. After successful measurement or artifact-evidence generation, it may appear as `verified`.

5. Privacy

Scans run locally. File paths, filenames, and model names are not sent.

In default mode, Trustfall Lite sends artifact SHA-256 hashes to the verification API (api.attest.fallrisk.ai/v1/) for registry lookup. No file content, file path, filename, or model name is transmitted in any mode.

For environments that require no network contact:

trustfall registry --refresh        # fetch and cache the signed registry
trustfall scan --local-only          # scan against the cached registry; no hashes leave the machine

In local-only mode, Trustfall Lite reads from the locally cached registry. No hashes leave the machine.

6. Trust Chain

The registry is the authority. Trustfall Lite is a client. Every Lite verdict is a signed claim from the registry, not a Lite assertion. Registry records are signed with JWS (RFC 7515), verified against a public JWK Set (RFC 7517), and anchored by JWK thumbprint (RFC 7638). The public key is published on the registry page, the JWKS is at /.well-known/jwks.json, and the verification guide reproduces the trust chain step by step.

Local artifact
    │ SHA-256
    ▼
Trustfall Lite
    │ lookup against signed registry
    ▼
Signed registry record
    │ JWS verification (RFC 7515)
    ▼
Verdict
- - - - - - - - - - - - - - - - - -
  artifact verification stops here
- - - - - - - - - - - - - - - - - -
    │ runtime structural identity
    ▼
Trustfall Deep

Figure 1: Trust chain. Artifact verification produces a file-level verdict — a distinct evidence class from runtime structural identity. Trustfall Deep begins where Lite stops. Structural-evidence records can anchor runtime identity checks; artifact-identity records remain file-level evidence unless superseded by structural enrollment.

Lite asks. The registry answers. The signature is the proof.

7. The Verified Claim

A verified status means exactly one thing: the SHA-256 of the artifact on disk matches a signed enrollment record in the Fall Risk Registry, and that record's JWS signature verifies under the registry's published key.

It does not mean the model is safe. It does not mean the model is endorsed. It does not mean the model is free of vulnerabilities, biases, or undesirable behaviors. It does not mean the model will behave the same way at runtime as its weights describe on disk.

What it establishes is artifact correspondence: the file you have byte-matches the artifact hash committed by a Fall Risk signed enrollment record. What it does not establish — and what no artifact verification can establish — is runtime identity: whether the model that is computing inside the inference process is structurally identical to what the artifact encodes. That is a different evidence class, addressed by a different measurement, documented across the broader research program.

8. The Boundary

A signed artifact verdict is only as honest as the chain that produced it. Artifact verification establishes that the file on disk matches a known, signed enrollment. It does not establish that the model in memory is computing what that file describes. It does not establish that the file was loaded faithfully. It does not establish that the runtime environment preserves the mathematical properties the file encodes.

This is not a limitation of Trustfall Lite. It is a limitation of artifact verification as an evidence class. The admissibility doctrine developed in this research program [4] formalizes this boundary: evidence from one identity layer cannot certify claims about another when the layers are operationally independent. A valid artifact hash cannot prove that the model's internal structure is unchanged at runtime, for the same reason a valid TLS certificate cannot prove the binary behind the endpoint is unchanged.

Trustfall Lite closes one gap: is the file what you think it is? Trustfall Deep closes the next: is the model what the file says it should be? They are complementary evidence layers, not substitutes. Together, they span the distance from disk to inference.

9. Links

License: Apache-2.0

References

View 9 references ↓

[1] A. R. Coslett, "The δ-Gene: Inference-Time Physical Unclonable Functions from Architecture-Invariant Output Geometry," 2026. DOI: 10.5281/zenodo.18704275

[2] A. R. Coslett, "Template-Based Endpoint Verification via Logprob Order-Statistic Geometry," 2026. DOI: 10.5281/zenodo.18776711

[3] A. R. Coslett, "The Deformation Laws of Neural Identity," 2026. DOI: 10.5281/zenodo.19055966

[4] A. R. Coslett, "What Counts as Proof? Admissible Evidence for Neural Network Identity Claims," 2026. DOI: 10.5281/zenodo.19058540

[5] A. R. Coslett, "Measured Model Substitution Under Valid Agent Credentials," 2026. DOI: 10.5281/zenodo.19342848

[6] A. R. Coslett, "Safety-Alignment Removal as a Model-Identity Failure," 2026. DOI: 10.5281/zenodo.19383019

[7] M. Jones, J. Bradley, N. Sakimura, "JSON Web Signature (JWS)," RFC 7515, IETF, 2015.

[8] M. Jones, "JSON Web Key (JWK)," RFC 7517, IETF, 2015.

[9] M. Jones, N. Sakimura, "JSON Web Key (JWK) Thumbprint," RFC 7638, IETF, 2015.

Cite this paper

A. R. Coslett, "Artifact Identity Is Not Runtime Identity: A Note on Trustfall Lite's Evidence Class," Fall Risk AI, LLC, May 2026. DOI: 10.5281/zenodo.20019127

Click to select · Copy to clipboard

Acknowledgments

Portions of this research were developed in collaboration with AI systems that served as co-architects for experimental design, adversarial review, and manuscript preparation. All scientific claims, experimental designs, measurements, and editorial decisions remain the sole responsibility of the author.

Author's Disclosure

Anthony Ray Coslett is the founder of Fall Risk AI, LLC, which holds the provisional patents listed below. The structural identity measurement referenced in this note operates within the scope of that intellectual property. Trustfall Lite is released under the Apache-2.0 license. No external funding was received for this research.

Patent Disclosure

U.S. Provisional Patent Applications 63/982,893, 63/990,487, 63/996,680, and 64/003,244 are assigned to Fall Risk AI, LLC.