Corpus scope: closed by rule, sampled by rule

157 documents are committed to this repository as content-addressed snapshots. The set comprises 152 Federal Register documents — 132 attributed by the CFR index to the five in-scope 31 CFR parts, and 20 retained from a citation-following pass — and the five part texts. Extraction has been run over 25 of them: the five part texts and every committed Federal Register document published in 2026. This site presents that sample.

Both boundaries are executable rules in reglens/corpus.py, not hand-picked lists: one decides what the corpus contains, the other decides what the model reads. Both are checked — tests/test_corpus.py asserts the published claim set is exactly what the sampling rule selects.

Inference runs entirely on one laptop. The remaining documents are ingested and committed; python -m reglens.extract --all extracts them. Text read: 1,368,017 of 7,175,669 characters. The five CFR part texts are read in full; Federal Register documents are capped at 80,000 characters, and any shortfall is recorded per document and shown beside it.

See it work: one accepted claim, one rejected claim

The totals above are computed from extractions such as these two.

Loading example…

What this demonstrates

How the pipeline works

  1. Snapshot. Public sources fetched once and stored content-addressed (SHA-256); everything downstream is reproducible from the snapshots.
  2. Extract. A local model at temperature 0, JSON-schema constrained.
  3. Verify. The provenance gate keeps a claim only if its quote is an exact substring of the source; failures are rejected and counted.
  4. Store & evaluate. SQLite/Parquet artifacts; metrics reported with confidence intervals and provisional labels.
  5. Publish. A pre-computed static export: every page renders without a live service, and the one optional live call — draft narrative generation — falls back to the committed drafts.

About this demonstration

RegLens-31 is an independent working mockup of one publicly documented Treasury AI use case: OGC-01, the “Regulatory Reform Tool” listed by the Office of the General Counsel in the U.S. Department of the Treasury’s public AI Use Case Inventory. Built from public primary sources only, it demonstrates what each of OGC-01’s stated outputs can look like when every claim must survive a verbatim, fail-closed provenance check.

It is a mockup, not the OGC-01 system: it has no connection to it, uses no Treasury-internal information, and is not affiliated with, endorsed by, or representing the U.S. Department of the Treasury (31 U.S.C. § 333). Where the inventory describes OGC-01 in deregulatory terms, this demonstration implements deliberately neutral analogs — it makes no recommendations, nominates no rules for change, and draws no legal conclusions.

Loading the inventory record…

Stated outputs and what this site demonstrates

Each output and stated purpose the inventory records for OGC-01, and the on-page module demonstrating its neutral equivalent:

“generates draft proposed and final rules”
Draft rule skeletons — Proposed and final-rule skeletons for every in-scope part, with a parameterized drafting interface (part, rule type, optional policy objective) and optional live narrative generation. Structure is deterministic Document Drafting Handbook form behind a fail-closed conformance gate: the model writes only labeled narrative fields, and any set-out regulatory text must verify verbatim against the source or the draft is rejected. Open: Draft rule skeletons
“reviews statutes for potential deregulatory actions” / “identify statutes that are not statutorily required …”
Statutory authority citations — Every rulemaking authority the ingested CFR parts cite, resolved against a pinned U.S. Code release and classified mandatory / discretionary / silent / unresolved from verbatim-verified verb spans. The classification describes the statutory text; no candidate list and no recommendation is produced. Open: Statutory authority citations
“… that are inconsistent with Looper Bright [sic]”
Grounding markers — Two-sided retrieval of literal textual markers in published rule preambles — deference-reliance markers and grounding-strength markers, presented with equal weight. Marker counts describe the published text; nothing is ranked, predicted, or concluded. Open: Grounding markers

Read the data as an API

Everything on this site is also published as static JSON under /api/v1/, described by an OpenAPI 3.1 document. It is read-only, needs no key, and is generated at build time from the same artifacts these pages render — so it cannot disagree with them.

The full description, including the currency and metrics endpoints, is at /api/v1/openapi.json.

Methodology & governance documents

The repository carries the full written record behind this demonstration: