Methodology
Every artifact sold on ContextFile ships with a signed verification report: what was claimed, which passage supports each claim, and how strongly. This page defines how that report is made, what it guarantees, and what it does not.
The pipeline
Every generation runs the same stages, and the report records the outcome of each.
| Stage | What happens |
|---|---|
| retrieve | lock the evidence corpus: content-addressed, licenses checked |
| generate | write claim-anchored prose against the locked corpus only |
| decompose | break the draft into atomic, checkable claims |
| verify | score each claim from 0 to 1 for entailment by its cited passage |
| bind | rewrite, cut, or send to human review anything under the floor |
| humanize | optional voice pass; every touched claim is verified again; always disclosed |
| report | sign it, content-address it, publish it with the artifact |
Claim decomposition
A finished draft is broken into atomic claims, each a single checkable statement bound to a passage in the locked corpus. "Nansen sailed in September 1893 with provisions for five years" becomes two claims. Opinion and invented voice carry no claim; only statements of fact enter verification. You cannot verify an essay, but you can verify it one sentence at a time.
Entailment scoring
Each claim gets a score from 0 to 1 for whether its cited passage supports it, not whether the passage mentions the topic.
- 1.0 means the passage states the claim outright.
- 0.0 means the passage contradicts the claim or says nothing that supports it.
- Hedged, speculative and topic-adjacent statements score low by design.
A separate model scores, never the one that wrote the prose, so the writer does not grade its own work. Every report pins the judge model, the judge prompt version, and the SHA-256 of the prompt text. A claim's state follows its score: verified at or above the floor, in_review just below it (a person decides), cut otherwise.
The floor: what it guarantees, and what it does not
A listing's floor is a fraction of claims. A floor of 0.95 means at least 95 percent of the edition's claims are verified against their sources, checked again at purchase time for the format basket the buyer chose. The platform default floor is TBD: it is chosen against the golden set, not guessed.
| What | Status |
|---|---|
| Each delivered edition met its floor when checked, or the buyer was refunded automatically | guaranteed |
| The full source ledger and a signed, content-addressed report you can check yourself | guaranteed |
| Errata propagate to every sold edition when a source is corrected | guaranteed |
| That the sources themselves are right; archives get corrected | not guaranteed |
| Opinions, voice, or anything that is not a bound claim | not guaranteed |
The guarantee is faithfulness to evidence, plus a public correction when evidence changes.
Checking a score yourself
Reports are content-addressed (the digest is a hash of the body) and signed. Anyone can recompute the digest and verify the signature against the published key, with no account. The free re-verify endpoint (reverify_claim, REST POST /v1/reverify) re-runs one claim against the real judge. It answers unavailable until the live judge is provisioned, and this page says so until then.
Escrow makes the floor binding
Every purchase is escrowed. The delivered edition's report is checked against the listed floor, and funds release only on a pass. A miss refunds the buyer in full with no dispute, and the failure is written to the seller's trust graph.
The trust graph
Reputation is computed, never typed in. Each verification outcome, cleared escrow, failed floor, refund and erratum writes an edge to an append-only graph, and a score is computed from that history with recent events weighted more, so it has to be kept up rather than banked.
Judge versions
The live judge prompt is never published: a published judge is an open target for claims phrased to fool it. Each version is published in full, against the hash reports already carry, the day its successor ships. Because every report pins that hash, a blind spot found in one version defines an exact cohort of reports, which recall operations re-verify and the transparency digest reports. A buyer's agent can refuse reports scored under an older judge (min_judge_version) or under one with an open recall (reject_open_judge_errata).
The judge, by version
| Version | Status | Prompt hash | Text |
|---|---|---|---|
v0-dev | live | sha256:1e64388843ffb61194ac8007b4992da06d5edd7ac2671ec35b1e82d8c2a9d04d | withheld until it retires |
Retired-prompt archive
No judge version has retired yet. v0-dev is the first; its full text publishes here, against the hash above, the day its successor ships.
The golden set today
The harness that gates every pipeline change runs today on a fixture of 2 locked sources (packages/core/src/golden.ts). It must produce a signed report whose digest and signature verify and whose every claim is bound to a source. The full golden set is built from real works before the eval gate is armed; until then this page says so rather than quoting a pass rate.
Version 2, updated 2026-10-11.