# 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.