How verification actually works
Most rules registries say “human-verified” and hope you don't ask what that means. We'd rather show you the instrument. This page describes what status: "verified" mechanically requires, what runs every day, what gets sampled by independent practitioners, and what the operator actually does — which is not “a human read every statute.”
The current honest state
Right now the registry holds 679 rules, 261 verified, and 679 carrying quote anchors or an anchoring exemption. All seed rules start at needs-reverification by policy and stay there until the pipeline below has run against the cited sources. Per-domain anchor coverage and measured error rates are published on /coverage and machine-readable at GET /api/audit-stats — including the gaps.
What “verified” requires — a hard gate, not a vibe
A rule cannot claim verified without evidence. The schema itself rejects a verified rule that lacks either:
- Quote anchors —
quoteAnchors[]: the exact sentence(s) of the government source the rule derives from, with URL, pin cite, and capture date. Government sources only: statutes, regulations, agency publications. - An anchoring exemption —
anchorExempt.reason, for the rare rule synthesized from multiple provisions. Exempt rules don't get a pass: they receive always-on blind re-derivation instead.
This is enforced in the zod schema, so CI's registry validation and the runtime registry load both reject an unanchored “verified” rule. It cannot ship. Anchors captured from offline fixtures (sourceMode: "fixture") can never promote a rule to verified.
Layer 1 — quote anchoring + daily source watch
Because each verified rule pins the exact source text, the daily watch job can re-fetch every anchored source and compare. Unchanged text ⇒ the anchor holds. Changed or unreachable text ⇒ the rule is flagged and queued for re-verification — before a consumer can be wrong about it. Hashing alone can't catch slow codification, so every rule also carries a volatility class with a backstop re-verification interval:
| A | Fast-moving (agency amounts, annually adjusted figures) — every 30 days. |
| B | Agency-adjusted procedures — every 90 days. |
| C | Stable statutory ground — every 180 days. |
| D | Legislative-session-driven (state deadlines that move by statute) — re-verified after the cited state's session adjourns, when codification lag makes hash-watching blind. |
Layer 2 — blind re-derivation
Every rule carries a questionTemplate: the rule restated as a neutral question answerable from the source alone (“What is the deadline to file an answer to a civil complaint in Oregon circuit court?”). The pipeline hands a model the source text and the question — never the stored rule — and compares the blind answer to what the registry claims. Agreement is recorded on the rule (blindAgreement); disagreement opens an escalation and flips the rule to needs-reverification until a named operator resolves it against the primary source. Rules with severityDefault: critical (deadlines, money, forfeiture) are re-derived cross-model — a second model from a different vendor — so one model's blind spot can't silently confirm itself.
Layer 3 — sampled practitioner audits, with published error rates
Quarterly, a seeded-random 5% sample per domain goes to contracted practitioners who check each rule against the law they practice. Verdicts land on the rule (auditHistory[]); incorrect or unclear rules are flagged, escalated, and corrected. The resulting per-domain measured error rates are published — on /coverage and at GET /api/audit-stats — whether they flatter us or not. A domain that breaches its error threshold gets a full pipeline re-run, not a shrug.
The errata program
The people most likely to catch a wrong rule are the people using it in practice. Anyone can file a report at POST /api/v1/errata; Community-tier partners (legal aid, nonprofits) get a formal SLA — 48 hours for critical reports, 7 days standard — and public credit. Confirmed errors are corrected, changelogged, and published permanently on the public errata changelog. A registry that publishes its corrections is the registry you can trust.
The golden-set harness
How do we know the pipeline itself works? A golden set of rules with deliberately seeded errors (wrong deadlines, wrong amounts, stale citations) is run against every pipeline version. A new version (model change, prompt change, comparison-logic change) cannot be promoted until its golden run meets the detection and false-positive thresholds. The current pipeline version is vc-2.0.0, and every verification it performs is stamped with it.
What the operator actually does
No human read every statute, and we won't pretend otherwise. The operator governs the system: signs off on pipeline runs, resolves blind-derivation disagreements and escalations against primary sources, triages errata within the SLA, commissions the quarterly audits, and gates pipeline-version promotions on golden-set results. verifiedBy on a rule records the pipeline version and the operator's sign-off on that run — that is the claim, exactly, and no more. The machine does the reading at scale; the human is accountable for the machine.
Everything above is inspectable: rules live in git, the schema gate is in CI, stats are at GET /api/audit-stats, and corrections are public at /errata. Pandect is informational, not legal advice — every payload says so, and carries its citations.