FILE 03 · METHOD Deterministic. Sealed. Reproducible. Refusable.
Four steps.
None of them optional.
A verification is a chain of checks anyone with the receipt can rerun and get the same answer. If a step in the chain can’t be automated, we say so. If a verdict would require judgment, a human signs for it — not a model.
Finding.
Every engagement starts with a list of things to check — either the standard checklist (Instant Repo Audit) or a bespoke list agreed with the client in the engagement letter. Each item is written as a falsifiable proposition: a sentence that could be true or false, with the check that would tell them apart.
“The build is reproducible” is a finding. “The codebase feels solid” is not.
Deterministic check.
Every finding gets translated into a script. That script must run to completion, unattended, in a locked environment (a Nix derivation or a pinned Docker image), and produce a fixed-shape output. The script is part of the deliverable.
If a check needs a human eye — reading legalese, judging whether a comment matches behavior — we mark it MANUAL in the receipt and a named reviewer initials it. We never fake determinism.
| Check type | Ships as | Reviewer |
|---|---|---|
| Static / structural | python / bash | automated |
| Reproducible build | Nix / Dockerfile | automated |
| Runtime / behavior | harness/ repo | automated + human |
| License / provenance | SBOM + notes | named engineer |
| Legal / representational | MANUAL | principal, initialed |
Sealed receipt.
Every engagement produces one report and one JSON receipt. The report is what humans read; the receipt is what machines re-check. The receipt is hashed with SHA-256, and the hash is signed with an ASSAY key rotated annually. Every receipt lists the key ID it was signed with.
- Report (PDF)
- Cover · verdict · findings ledger · reviewer signatures · reproducer instructions.
- Receipt (JSON)
- Every finding: id, proposition, check_ref, verdict, evidence hash, reviewer.
- Harness (git repo)
- Everything needed to rerun. Locked deps. Deterministic build. No network at run time.
- Signature
- ed25519 · key ID on cover page · public key published alongside the first sealed client receipt
You re-run it.
The last line of every report is a single command. Run it. You get back a hash. If it matches the one on the cover page, the receipt is intact. If it doesn’t, something changed — the environment, the artifact, or the receipt itself — and you should tell us.
REAL — the re-run block from ASSAY-001 (TypeSafe Jev, September 2026). Public repo; every raw response and both scorers included.
Re-running the scoring needs nothing from us. Re-running the model needs the vendor’s key and produces a new run, not this one — that distinction is on the report’s cover. The method itself is open source: assay-kit — pre-registration, freeze-by-hash, corpus pinning, positive controls, numbered amendments. Run it on yourself and the result is stamped SELF-ASSAYED. When we run it on you, blind, re-scored on a different model and signed, it is ASSAY-VERIFIED. The kit cannot emit the second one.
§04Why no model in the verdict path.
Language models are useful helpers. They read code fast, they draft findings well, they catch things people miss on the third pass. They are also non-deterministic, opaque, and, at time of writing, occasionally confident about things that are not true. That is a bad combination for a receipt.
So we use models the way we use interns: they read, they draft, they suggest, they never sign. Every verdict in an ASSAY receipt was produced by a deterministic check or by a named human being. The line between what the model touched and what the verdict says is drawn on the cover page.
§05When we refuse.
- R.01 The claim is not falsifiable as stated.
- R.02 The check requires access we do not have and cannot verify from artifacts.
- R.03 The check would require us to break the law or an existing NDA.
- R.04 The client requires us to omit a finding from the receipt.
- R.05 The result is a coin flip: check produces different verdicts on repeat runs.
- R.06 We disagree, internally, and neither position is deterministic.
Refusal is not failure. It is the correct output of a verification practice when verification is not possible. We expect the refusal rate to be high, and we would rather it stayed that way.
You probably have a check in mind.