What the referee guarantees

RCF's honesty rests on a division of labour: the tool referees structure, never adequacy. This page sets out precisely what each referee check proves, and what none of them can.

What validation proves

rcf define validate walks the whole tree and proves two things: every document matches its schema, and every reference resolves to a real document. It also checks the code bridge: a Code Node whose source path or symbol no longer exists in the working tree is reported the same way a broken reference between documents is. A tree that passes is structurally sound; nothing in it points at nothing.

What coverage proves

rcf audit coverage proves the test layer is real. 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 test-case row with a dead or missing pointer is reported as covered-unresolved, never as coverage: a stub or a stale pointer fails the gate exactly as a missing test does. This closes the oldest gap in the trade, the test that exists on paper only.

What the finalise gate proves

The lifecycle of a build item ends at verified, and only the finalise gate writes that word. It runs an independent verify against the deployed application, after merge, with its own authority to refuse. The everyday marking commands cannot reach verified at all; the ceiling for them is complete. So when the chain says a piece of work is verified, that claim traces to an actual post-merge check against a real runtime, not to anyone's assertion.

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 elicited the chain from a conversation with you and stops to walk you through it. Reviewing the tree is the craft of that moment.
• The review stage of every build cycle, once per work item. Before an item can move on, a fresh-context reviewer drives the running app against the item's acceptance criteria, a reviewer that uses the product rather than reads the code. The five-stage build cycle covers where that sits in the loop.

The division holds up because each side does what the other cannot: the tool makes the structural half of confidence mechanical, so the humans and the agent spend judgement only where judgement is needed.