What “verified” means, check by check
When a rule here says status: "verified", four checks stand behind it, and you can inspect each one below: what the schema demands, what runs every day, what practitioners sample each quarter and what the operator signs. It does not mean a person read every statute, and we won't claim it does.
The Registry Today
Right now the registry holds 687 rules, 334 verified, and 660 carrying quote anchors or an anchoring exemption. Every seed rule starts at needs-reverification by policy and stays there until the pipeline below has run against its cited sources. Anchor coverage and measured error rates for each domain are on /coverage and at GET /api/audit-stats, gaps included.
Every Standard Shown
Signatures here span more than one standard. The pipeline has been revised since the first rules were signed, and a rule keeps the version that signed it until it is signed again; the current version is vc-2.9.0. Every rule falls into one of three buckets by that version stamp. No rule sits in two, and together they add up to the 687 rules in the registry:
vc-2.9.0 | Signed under the current pipeline standard: 8. |
| pre-vc-2.9.0 | Signed under an earlier standard and not yet signed again: 571. They serve with their real status, and the standard that signed them travels with them. |
| unsigned | No pipeline signature at all, so their warrant is their last human verification: 108. |
Reachability is counted on its own. When the daily check cannot fetch or read a rule's source, that rule is unreachable (11 of 687), and it keeps whatever standard it already had. Escalations, the live queue of rules waiting for operator review, also sit outside the buckets. They are published at GET /api/audit-stats, and the operator queue (docs/operator-queue.md) lists each one with its evidence and the exact dry-run command that checks it again. Publishing a count never signs a rule as verified; re-verification is its own pipeline run, authorized by a person. The counts on this page, at GET /api/audit-stats and in docs/verification-standards.md all come from one registry scan, and a test fails if they ever disagree.
Evidence Required
A rule cannot claim verified without evidence. The schema itself rejects a verified rule that lacks either of these:
- Quote anchors in
quoteAnchors[]: the exact sentence or sentences of the government source the rule comes from, with URL, pin cite and capture date. Government sources only, meaning statutes, regulations and agency publications. - An anchoring exemption in
anchorExempt.reason, for the rare rule built from several provisions at once. Exempt rules get no free pass: blind re-derivation runs on them every time instead.
The zod schema enforces this, so both CI's registry check and the runtime registry load reject an unanchored “verified” rule. It cannot ship. Anchors captured from offline fixtures (sourceMode: "fixture") can never promote a rule to verified.
Anchored and Watched
Each verified rule pins the exact source text, so a daily job can fetch every anchored source again and compare. If the text is unchanged, the anchor holds. If it changed or cannot be reached, the rule is flagged and queued for re-verification before anyone downstream relies on the old version. A changed page is easy to catch; a new law still waiting to be codified is not, so every rule also carries a volatility class with a backstop re-verification interval:
| A | Fast-moving, like agency amounts and figures adjusted every year: every 30 days. |
| B | Procedures an agency adjusts: every 90 days. |
| C | Settled statute: every 180 days. |
| D | Moves with the legislature, like state deadlines set by statute: re-verified when the cited state's new session laws take effect, because a check run at adjournment would still read the old text. |
Derived Again, Blind
Every rule carries a questionTemplate, the rule restated as a neutral question the source alone can answer (“What is the deadline to file an answer to a civil complaint in Oregon circuit court?”). The pipeline gives a model the source text and that question, and never the stored rule, then compares its answer with the registry. Agreement is recorded on the rule as blindAgreement. Disagreement opens an escalation and sets the rule to needs-reverification until a named operator settles it against the primary source. Rules marked severityDefault: critical (deadlines, money, forfeiture) are derived again cross-model, by a second model from a different vendor, so one model's blind spot can't confirm itself.
Sampled by Practitioners
Each quarter, a seeded random sample of 5% of every domain goes to contracted practitioners, who check each rule against the law they practice. Their verdicts land on the rule in auditHistory[], and a rule they find incorrect or unclear is flagged, escalated and corrected. The measured error rate for each domain is published on /coverage and at GET /api/audit-stats, whether it flatters us or not, and a domain with no audit yet says “not yet audited”. A domain over its error threshold gets a full pipeline re-run.
Errors Published
The people most likely to catch a wrong rule are the people using it on real cases. Anyone can file a report at POST /api/v1/errata. Community-tier partners in legal aid and nonprofits get a formal SLA, 48 hours for critical reports and 7 days for standard ones, and public credit. A confirmed error is corrected, entered in the changelog and published for good on the public errata changelog.
Tested Before Promotion
The pipeline gets tested too. A golden set of rules with deliberately planted errors (wrong deadlines, wrong amounts, stale citations) runs against every pipeline version. A new version, whether the change is a model, a prompt or the comparison logic, cannot be promoted until its golden run meets the detection and false-positive thresholds. The current version is vc-2.9.0, and every verification it performs carries that stamp.
Signed by the Operator
No person read every statute, and we won't pretend one did. The operator governs the system: signs off on pipeline runs, settles blind-derivation disagreements and escalations against primary sources, triages errata within the SLA, commissions the quarterly audits and holds back any pipeline version whose golden run falls short. verifiedBy on a rule records the pipeline version and the operator's sign-off on that run. That is the whole claim. The machine does the reading at scale, and a person answers for the machine.
Check any of it yourself. The rules live in git, the schema gate runs in CI, the stats are at GET /api/audit-stats and every correction is public at /errata. Pandect is informational, not legal advice; every payload says so and carries its citations.