The feedback loop

A shipped change is a question, not an answer — did the thing it was for happen? This page is the pattern for letting production answer: detection stays deterministic and stays in your monitoring stack; a breach briefs a headless session that runs veri:evidence-intake; the evidence lands on the graph linked to the bets it bears on; and judging what it means stays yours. Veri ships no watcher. The pattern is a page, not a platform.

1. The loop, end to end

Detect — deterministic, yours. An error-rate threshold, a latency budget, a nightly metrics export, a support-ticket spike: whatever your monitoring stack already does. No model is involved in noticing. Veri adds nothing here on purpose — thresholds and alert routing belong in the tools built for them, and a detector that lives in your stack keeps firing when Veri is closed.

Brief — a headless session at the door. The alert's payload becomes the brief for an agent session connected to your project's MCP server. The session's job is the veri:evidence-intake gate: file what was observed, faithfully, linked to what it bears on — and nothing else.

claude -p 'Run veri:evidence-intake on this alert.

checkout-error-rate breached its 2% threshold at 04:10 UTC —
6.1% over 30 minutes, 214 requests affected. Dashboard:
<link to the graph>. The last change on that path shipped
under WO-131.

File it as a source against whatever it bears on. Do not judge
the bet — leave that for my morning.'

Wire that command to your alerting webhook, a scheduled job, or run it by hand — the gate is the same either way. The session classifies the material (kind: metric, user-feedback, or investigation), searches for what it plausibly bears on, and files one source with provenance: where, when, who.

File — the edges are the point. From a source, tests / supports / refutes point at the requirement whose bet the evidence answers, and outcome-of points at the work order that shipped the change. Direction is enforced at issue tier — a backwards edge is a no-op that leaves the bet untested forever, which is why the gate runs veri check after filing and reports the advisory count before and after: the untested-bet advisory clearing is the proof the edges landed the right way round. Interpretation stays out of the document — "so we should retire it" is a reading, and it stays in the conversation so someone who disagrees can re-read the evidence.

Travel — the record briefs the next session. A correct edge pays out immediately: the source rides into the requirement's context package, the work order's section gains a "what shipped here reported back" line, and get_receipts closes the work order's history with its outcome evidence. The next agent briefed on that area reads what reality already said before adding to it.

Judge — yours, through veri:did-it-work. When the evidence is in, the learning gate keeps three questions apart — did we build what we said, do the constraints still hold, what did the declared metric do against its declared target — and names one of four verdicts: supported, refuted, inconclusive, unmeasured. Inconclusive files too; "measured, and the instrument cannot discriminate" is a real answer. What the verdict means for the requirement — revise, retire, harden, re-bet — is your act and only yours.

2. What Veri deliberately does not do

Veri never watches anything, schedules anything, or calls the network — there is no bands file, no poller, no webhook receiver, and none is planned. Core, the MCP server, and veri check spawn no subprocesses, which is also why Veri never executes a work order's verify: command: the record can require that a run be evidenced, but the running is always done by a session or CI, never by the record-keeper. And evidence never promotes: a source's arrival changes no requirement's status, kind, or declared outcome. Reality reports; you judge. The gate that files and the gate that judges are deliberately different gates.

3. The verification pattern on the way in

The same division — Veri holds the contract, the harness does the running — governs verification before anything ships:

The work order declares its proof. An optional verify: line carries the one command that must exit 0 — npm test -w that-package, a smoke script, a curl check. Planning asks for it when the work is cut; the context package renders it to every session that picks the work up.
The session runs it; the receipt quotes it. The implement gate runs the declared command before writing the receipt and states the outcome in the receipt's sentence. The dispatcher's kickoff prompt gives headless sessions the same instruction. A done work order that declares a command and whose receipts nowhere evidence the run is surfaced by the verify-unevidenced advisory — the machine flags the gap; it does not fill it.
Hooks are harness configuration, not Veri features. Your agent harness can enforce what a page can only recommend: a pre-edit hook that blocks changes to test files during a fix task, deny rules on protected paths, a gate that demands a green run before commit. Configure those where your agent runs (for Claude Code, hooks in settings.json); Veri's record then holds what it is good at — the declared contract and the evidenced run.

Where next: the workflow guide for rule 9 — how hypotheses declare the outcome that settles them — or the dispatcher that runs the same headless pattern on the way out.