What the referee guarantees

RCF's referee checks structure. It cannot determine whether the documents adequately describe the intended product. This page names what each check does prove and where judgement is still required.

What validation proves

rcf define validate walks the whole tree and proves two things: every document matches its schema, and every strong reference in it points at a real document. It also checks the bridge to code, so a source file the chain says exists but no longer does is reported the same way a broken document reference is. A tree that passes is structurally sound; nothing in it points at nothing. Whether it describes the right product is not a mechanical property, and validation does not claim it is.

What coverage proves

rcf audit coverage reports the shape of the test layer. A requirement counts as covered only when every acceptance criterion under it has a test case whose pointer resolves to an actual, named test. A stub or a dead pointer fails the gate exactly the way a missing test does. There is an explicit opt-out for the times you want the summary without the refusal, and no other quiet way past the check.

What eval coverage proves

rcf audit eval coverage proves the same shape on the non-deterministic half of the chain. An acceptance criterion your agent marked non-deterministic at define time counts as covered only when a live evaluation names it and its most recent run has a result. Missing, superseded or stuck-pending evaluations refuse the gate. Deterministic ACs are untouched by any of this, and a chain that carries none of them passes trivially.

The two audits are peers, not layered. They cover the two halves of the same contract, and a project's own CI is expected to run both.

What the finalise gate proves

A build item's lifecycle ends at verified, and the finalise gate is the only path to that word. The everyday build-status commands cannot reach it; their ceiling is complete. The runtime check behind it happens at the Test stage: a verifier hand, separate from the builder, runs rcf verify run --hand verifier against the preview or version host serving the reviewed head, a local server serving it, or the packed package, and commits the report on the pull-request branch. Finalise ingests that report on the same branch, before the merge, with --ci-run <ref> naming the CI run that passed on the head the report names. It refuses a report that is not committed at HEAD or differs from its committed bytes, one outside the project root or read through a symbolic link, one whose head HEAD does not contain, a loopback report that does not name its engine, its port and a served sha equal to its head, one whose verifier is also a builder (checked on a merged or fast-forwarded head too), and one that is too old. The verified write is committed on the branch and the merge carries it, so a chain that says verified traces to an independent runtime check of a head the merge contains, by construction.

The gate reads the verify report and refuses on a settled list of unresolved states: a mock-only or blocked-by-declaration AC, a missing or below-threshold evaluation for a non-deterministic AC, and a set of runtime-check failures the report can flag. Each refusal has a named opt-out that turns the refusal into a recorded acknowledgement on the ship manifest, so a deliberate degraded ship reads as a written decision rather than a silent skip.

A blueprint can ship a Playwright probe pack of its own: small runtime checks anchored to specific acceptance criteria that a browser-verify run reads and folds into the report the finalise gate reads. What a pack proves is bounded by what it actually probes; the rest sits outside the gate. Each blueprint's README lists the mechanism-reach gaps in its pack, and that authoring rule is being brought into line across the shelf.

What none of them prove

Whether the chain captures what you actually want built. Whether an acceptance criterion states the right behaviour. Whether a test asserts the outcome that matters: a renamed test is caught, but a gutted test that kept its name is not. The referee is mechanical, and adequacy is not a mechanical property.

That judgement is deliberately two-party, and it has two named homes:

• The docs-review gate, once, before the first build. Your agent has walked you through the chain it elicited from you, and Reviewing the tree is the craft of that moment.
• Fresh-context reviews across the build cycle. Every FBS item ends with a diff-and-tests review before it can move on, and every few items, and always at cycle end, a fresh-context reviewer drives the running app against the accumulated acceptance criteria, using the product rather than reading the code. The five-stage build cycle covers where each of those sits in the loop.

The tool checks structure mechanically. You and your agent decide whether the requirements, checks and tests describe the intended behaviour.