How to monitor regulatory changes on government websites (and why exact diff beats the AI tier)

The guidance page changed on a Tuesday. "within 30 days" became "within 14 days." No press release, no email. Nothing in anyone's inbox. Somebody found it in October, pasted a screenshot into a Slack thread, and asked whether that had always said 14.

The obvious fix makes it worse in a specific way. You buy a change monitor with AI relevance filtering, point it at the page, and now a model decides which edits are worth your attention. On a regulator's page, relevance is the judgment you were not allowed to delegate. A word you were not watching for is still a word that changed the obligation.

Registers are the easy case. Here's why, and here's the setup.

What counts as a register

Define it by behaviour, not by domain. A register is a page whose text is the thing itself, not a description of the thing. It's quiet by design, edited deliberately, and versioned somewhere upstream.

Pages that behave this way:

• a specific eCFR part or section, not the title landing page
• a Federal Register public inspection listing
• a national data protection authority's guidance page
• a financial regulator's handbook instrument page
• a sanctions or designated-entity list
• a procurement or tender register
• a vendor's DPA or subprocessor list, which is the private-sector version of the same page

The test is simple: if you'd read every change, it's a register. If you'd read one change in twenty, it's a newsroom, and this post's advice is wrong for it.

Sources: "Privacy Policies Across the Ages: Content and Readability of Privacy Policies 1996–2021" (Wagner) and "We Value Your Privacy … Now Take Some Cookies: Measuring the GDPR's Impact on Web Privacy" (Degeling et al.).

That shape is the whole argument. A page that sits still for months and then moves sharply around a deadline is a page where you want a stenographer, not a critic.

The register already publishes its change history. It just won't push it to you

This is the part almost nobody writing about government monitoring mentions: the sources are built to be read precisely.

The eCFR returns three separate date fields per title (latest_amended_on, latest_issue_date and up_to_date_as_of) and has a reader-aid page explaining why the distinction matters. It also exposes a title versions endpoint. The Federal Register's REST API covers every document published since 1994. govinfo will hand you lists of new and updated content in a collection. Regulations.gov gives you 1,000 requests an hour on a standard key and a 429 when you burn through it — a rate limit written by people who expect you to poll.

GOV.UK goes further and classifies its own edits: the publishing API separates major from minor updates, and only a major update produces a public change note in the "See all updates" history.

Which is the gap, stated by the government itself. A minor edit produces no change note. A minor edit still changes the words.

They log it. They don't tell you. And building against those APIs has its own cost: GOV.UK's reuse policy says plainly that the content API is unsupported and may change without notice. A monitor on the human page is often the more durable thing, as long as you check it at a sane frequency.

Why exact diff wins on a regulatory page

Mechanism first. Exact diff fetches the page, normalises the text, and compares it byte-for-byte against the last snapshot. No model call, no prompt, no interpretation. If a character moved, you get a unified diff: the standard - old line, + new line format, the same one you read in a code review.

Four reasons that's the right instrument here.

Every change is signal. A prompt is a filter, and filters are for pages where most edits are noise. On a register the base rate flips. The edits are rare, and each one was made on purpose by someone whose job is to make edits on purpose.

The change is a word. "may" becomes "must." "30 days" becomes "14 days." A single entity gets added to a list. Summaries paraphrase. Diffs quote.

It's deterministic. Same input, same answer, every run. There's no confidence score for anyone to argue about eight months later.

Deletions count. A withdrawn guidance note or a struck clause is a diff line with a minus in front of it. It is not "a change to the page region," and it is not something a relevance filter reliably decides you wanted.

What the alert actually looks like

The alert carries the diff, not a description of the diff:

- Notification must be made to the Authority within 30 days of the change.
+ Notification must be made to the Authority within 14 days of the change.

Plus one sentence, a timestamp, and a link to the monitor timeline. The bar we hold ourselves to is that you can forward that into a ticket or paste it into a vendor-risk record and nobody has to reopen the page to check what it used to say. A diff is a verbatim quotation of both versions with a date on it. That's an artifact. A summary is a retelling.

Why the semantic tier is the wrong instrument here

Nothing wrong with our own AI tier. It's a mismatch on this class of page, and it fails in three predictable ways.

It answers your question, and only your question. The semantic tier reads the fresh page against the last snapshot plus your prompt and decides whether the change you described happened. Anything outside the prompt is correctly, silently discarded. On a register, outside the prompt is where the surprise lives.

Its evidence is a summary, before/after excerpts, and a confidence score. Good for triage. Weak as a record. Nobody files an 84%.

And it costs a model call on every run, for a page that changes four times a year.

On a register, judgment is the bug. If you want the longer version of that argument across all three tiers, we wrote a full explainer on choosing a check tier.

Where exact diff struggles (read this before you set it up)

The recommendation is only worth anything if we name the cases where it falls over.

"Last updated 14:02" stamps and hit counters. These change on every load. Diff will fire daily and you'll stop reading it inside a week. Fix: use the visual picker to select the body of the section rather than the whole page, or move that one monitor up a tier.

Paginated listings and result counts. "Showing 1–20 of 3,412" is a change every Tuesday. Watch the record, not the index. Or watch the index with the semantic tier and a prompt about new entries.

Registers that render client-side. Some publishing systems ship an empty shell and fill it with JavaScript. Test it in ten seconds: view the raw page source in your browser, not the inspector, and search for a sentence you can see on screen. If it isn't there, exact diff is comparing two identical empty shells forever and you need the browser agent tier, which launches real Chromium and waits for the page to settle. We went deeper on that failure mode in monitoring pages that don't exist until JavaScript runs them.

Cookie and consent interstitials. Same answer: agent tier, which dismisses them before it reads.

PDF-only publication. This is the honest one. We read the page, not the document behind the link. A new PDF appearing in a list shows up as a diff line; the clause inside that PDF does not. If your entire workflow is agencies that publish nothing but PDFs, buy a tool built to fetch and diff documents instead. Wachete gets recommended for this often, and fairly. Check their site for current capabilities and pricing.

When to use the AI tier anyway, and when to buy something else

Not every government page is a register, and not every regulatory problem is a monitoring problem.

• Agency newsroom, or one page that mixes rulemaking with press releases and event listings → semantic tier, with a prompt about the specific instrument or docket you care about.
• One page, forty jurisdictions' worth of relevance to filter → semantic tier, and be honest that you may be outgrowing a monitor.
• Obligation mapping, impact assessment, control linkage, attestation workflow, audit evidence packs → buy a regulatory change management platform. Regology, Vixio and MetricStream exist for this and do it properly. Regology's own framing is that good RCM should surface changes 6–18 months ahead where you can get them, against implementation windows that are sometimes 30–90 days. Vixio notes that manual tracking usually breaks once you're covering two or more jurisdictions. We alert. We don't run your program.

There's also a live claim on the other side of this. 4CRisk published figures putting AI horizon scanning at 20–30× faster than manual review. Plausible for the wide, unbounded scan across thousands of sources. It's a different job from watching one section of one part and quoting the delta. (Figures as published; check their site for current numbers.)

If your current tool is a pixel or element diff that classifies importance after the fact, our Visualping alternative page lays out the difference in starting philosophy.

How to monitor regulatory changes on government websites, in five steps

1. Pick the deepest stable URL. The section, the part, the specific instrument page. Not the title landing page and not a search result URL with a session parameter in it.

2. Check how it renders. Raw source test above. Text present → exact diff. Empty shell → browser agent.

3. Set the tier to diff. It's a dropdown, not a migration. If the page turns out to be noisier than it looked, change it next week; nothing else about the monitor moves.

4. Set the interval to the window, not to your anxiety. Comment periods and objection windows are counted in days, so a daily check is right for almost every register. Checking a quiet legal page every two minutes buys you nothing and gets you rate-limited.

5. Route it where the record lives. Email for the people who act on it. A signed webhook (X-Modsignal-Signature: t=<unix>,v1= HMAC-SHA256 of t.body) into your GRC intake if you want the change event to land in the system of record automatically. The per-team RSS feed if you want a passive log someone reviews quarterly. Every channel carries the same evidence.

One monitor per page

Don't stack six regulators into one monitor to save on your plan limit. Each monitor has its own timeline, and that timeline is the audit trail for that page. A merged timeline is a worse record and a harder thing to hand to a reviewer.

What to do when it fires

Diff it. Read the actual - and + lines. Two versions, verbatim, side by side.

Date it. The timeline has the check time and the snapshot it was compared against. That's your "we knew on the 14th."

File it, or object. Most of the time the answer is "no impact, logged." Write that down anyway. Auditors love a documented non-event.

The timeline is the source of truth. Slack, email and webhooks are copies of it.

From one page to a register program

Three CFR sections checked daily costs nothing: the free plan gives you 3 monitors, daily checks, exact diff and semantic, two team members, no card. That's a genuinely adequate answer for one person watching a handful of pages, and we'd rather say so than pretend you need a subscription.

When it grows: Pro is $25/mo for 25 monitors at 15-minute checks, Scale is $49/mo for 100 monitors at 5 minutes. You pay for reach, not per alert. Checks are never metered, which matters most on exactly this kind of page. Sixty register pages checked every day for a year is a lot of checks and almost no alerts, and you shouldn't be billed for the quiet.

A register that fires four times a year and says nothing the rest of the time is a monitor working correctly.

Start with one page, the deepest URL you have, exact diff, daily. Then see how long it stays silent.