Trustfall Lite — Fall Risk AI

Most people do not know what models are sitting on their machines.

Trustfall Lite tells you what is verified, what is an unknown variant, and what is not enrolled. It runs locally. It checks against the signed Fall Risk Registry. It does not phone home with your filenames.

Install

pipx install fallrisk-trustfall

Free. Open source. Apache-2.0.

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

What it does, and what it does not do

Does

Scans your Hugging Face cache for model artifacts.
Scans your 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 signatures against the published JWKS.
Optionally writes a local CSV/JSONL inventory of the scan result (--export).

Does not

Measure the model at runtime.
Verify what the model does, only what it is on disk.
Send file paths or filenames.
Send hashes when run with --local-only. By default, hashes are sent to the verification API for lookup.
Say a model is safe, good, or endorsed.
Replace runtime structural identity verification — that is Trustfall Deep.

Install

v0.4.0 · live on PyPI

Install with pipx:

pipx install fallrisk-trustfall
trustfall scan

The first scan walks your Hugging Face cache and Ollama store, hashes every artifact, and returns one of four statuses for each. For a worked example of a real first scan, read the Founder Scan.

Source: github.com/fallrisk-ai/trustfall-lite. License: Apache-2.0.

Trustfall Lite is licensed under Apache-2.0. It installs on Linux, macOS, and Windows via pipx and is continuously tested across Python 3.10–3.13 on each platform.

Commands

Trustfall Lite v0.4.0 exposes five commands. The shape is stable; minor releases extend it without breaking existing flags.

Command	Purpose
trustfall scan	Scan default Hugging Face and Ollama locations when present. Reports 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 <baseline.json> [current.json]	Compare two scan-output JSONs and report group, artifact, and status changes.

Local-only mode · no network

Every command above accepts --local-only, which verifies against a downloaded copy of registry.json and never contacts the verification API for hash lookup. Hashes do not leave the machine. This is a first-class mode of operation, not a fallback — the Trustfall Lite trust model is designed so the verification API is optional.

trustfall registry --refresh                         # one-time, fetches signed registry
trustfall scan --local-only
trustfall verify <hash> --local-only
trustfall diff baseline.json current.json --local-only

Inventory export

As of v0.4.0, trustfall scan accepts --export PATH, which writes a flat CSV or JSONL inventory of the scan result. The format is chosen from the file extension.

trustfall scan --export inv.csv      # flat CSV inventory (local file only)
trustfall scan --export inv.jsonl    # JSONL instead (chosen from the extension)
trustfall scan --export inv.csv --export-include-paths   # opt in to filesystem path columns

Inventory export · what it does and does not do

The export writer performs no upload, opens no network connection, and starts no daemon — it consumes the already-computed scan result. It does not change the scan's lookup mode: a default scan may still query the verification API with artifact hashes; --local-only does no per-scan network lookup. --export does not make a scan offline.

The default export contains no filesystem paths — the path columns are absent, not empty. Paths are written only when you explicitly pass --export-include-paths. That flag is separate from the network-side --include-paths; one governs local export file contents, the other governs path hints sent to the registry API. Neither implies the other.

The full export schema is documented in docs/INVENTORY_EXPORT.md.

Diffing a baseline against the current cache

To compare a current scan against a prior one — for example, to detect new or removed model artifacts since you last looked — capture a baseline, then diff against it later:

trustfall scan --json > baseline.json
# ... time passes, you install or remove some models ...
trustfall diff baseline.json                       # implicit current scan
trustfall diff baseline.json current.json          # explicit comparison

CI integration

By default, trustfall diff prints the diff and exits 0 regardless of what changed. Two opt-in flags change the exit-code behaviour: --exit-code exits 1 on any change; --exit-code-on-status-regression exits 2 only when a previously verified artifact is no longer verified.

Output statuses

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

✓ verified artifact is known and signed

What this means: the artifact's SHA-256 matches an enrolled record in the signed registry, and the record's signature verifies under the published key.

What to do next: nothing. The file on disk is the file the registry records.

⚠ unknown_variant plausible match, not enrolled at this hash

What this means: a model with this name appears in the registry, but the bytes on your disk do not match any signed enrollment for that model. The variant could be a legitimate alternate build, or the artifact could have been modified.

What to do next: compare the hash to the publisher's stated checksums. If you need a signed answer for this specific artifact, contact integrations@fallrisk.ai.

? not_enrolled no record in the signed registry

What this means: Fall Risk has not enrolled this model. The registry holds no record against which to verify the artifact. Lite does not assert anything about whether the file is good or bad — only that there is nothing to compare it to.

What to do next: if you want this model enrolled and signed, contact integrations@fallrisk.ai.

→ pilot_available candidate for enrollment

What this means: the model is on the pilot enrollment list. It is not signed yet, but it is queued for measurement under contract and will appear in the signed registry on completion.

What to do next: if this model matters for your stack, request pilot prioritization at integrations@fallrisk.ai.

See a real scan

I ran Trustfall Lite against my own local Hugging Face and Ollama caches. The result is exactly what the tool is built to show: what is known, what is unknown, and what needs deeper verification.

Read the Founder Scan →

Privacy

Scans run locally. File paths and filenames are not sent.

By default, Trustfall Lite sends artifact SHA-256 hashes to the verification API for lookup. Hashes are redacted from access logs at the web tier. The application tier records aggregate counters only. Endpoint reference and request shapes are in the API documentation.

If you prefer no network at all, run Trustfall Lite with --local-only against a downloaded copy of registry.json. In local-only mode no hashes leave the machine.

The --export writer is a local file write: it adds no upload, network, or daemon activity of its own. It does not change how the scan that produced the data behaves. The default export contains no filesystem paths; paths appear only with the explicit --export-include-paths opt-in, which is a separate control from the network-side --include-paths.

Why this matters now

Recent tokenizer-tampering research has shown that changing tokenizer artifacts can alter model output without changing the model weights. Trustfall Lite does not inspect tokenizer contents or issue safety verdicts. Instead, it answers a narrower supply-chain question: do the local artifact bytes match a signed Fall Risk registry record? In v0.4.0, the inventory export includes tokenizer_surface_coverage so teams can see whether the tokenizer-relevant surface is covered by the signed artifact identity material.

Registry relationship

The registry is the authority. Trustfall Lite is a client.

Every Lite verdict is a signed claim from the registry, not a Lite assertion. You can verify each verdict yourself: 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.

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

Deep relationship

Lite tells you the file is the file you think it is. Deep tells you the running process is computing what the file says it should.

Artifact verification — what Lite does — is necessary but not sufficient when:

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

For those cases, Trustfall Deep performs the structural measurement under contract. Deep is an enrollment-based service: integrations@fallrisk.ai.

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

A signed artifact verdict is only as honest as the chain that produced it. This page belongs to that chain.

Trust chain

Local artifact

↓ SHA-256

Trustfall Lite

↓ lookup against the signed registry

Signed registry record

↓ JWKS verification

Verdict

Trustfall Deep

↓ runtime structural identity, anchored to the same registry

Artifact verification stops at the file. Runtime structural identity begins with Trustfall Deep, anchored to the same signed records the registry publishes.

What it does, and what it does not do

Install

Commands

Inventory export

Diffing a baseline against the current cache

Output statuses

See a real scan

Privacy

Why this matters now

Registry relationship

Deep relationship

Links