Skip to Content
ConceptsChanges between scans

Changes between scans

A regulatory landscape is not a still image — it moves. The most valuable thing Regulatory Snapshot does on your second and subsequent scans is tell you what has changed since you last looked. This page explains what “changed” means precisely, how the detection works at a conceptual level, and where you read the result in both the product and the API.

The model

When you run a scan for a configuration that has been scanned before, the engine compares today’s snapshot to the most recent comparable previous snapshot and labels every item:

LabelWhat it means
NewToday’s snapshot has this item; the previous snapshot did not.
UpdatedBoth snapshots have this item, but something material moved — status, expected date, impact, or summary content.
UnchangedBoth snapshots have the same item with no material movement.
BackfillToday’s snapshot caught an item that should have been in the previous one but was missed. Surfaced with a “missed last time” affordance rather than as truly new.
RemovedThe previous snapshot had this item; today’s does not — often because it has aged out of horizon, been withdrawn, or been superseded.

This per-item labelling, plus scan-wide counts and a short narrative of what moved, makes up the change overlay on the snapshot.

What counts as “comparable”

The overlay only runs when there is a comparable previous snapshot to compare against. Specifically: the previous snapshot needs to share the same set of jurisdictions, the same set of areas (including custom areas), and the same horizon. If you tweak any of those — add a jurisdiction, swap one custom area for another, push the horizon from 12 to 18 months — Regulatory Snapshot still picks the most recent prior snapshot to compare against but flags the comparison as approximate. Small tweaks are still useful; complete reconfigurations are not.

For brand-new configurations the change overlay is absent on the first run. Your second run is the first one with a delta.

Where it shows up

In the product

The dashboard surfaces changes in two places:

  1. Heatmap change markers — a small green dot, amber triangle, or red triangle in the corner of a cell, indicating new, updated, or removed items in that area-and-jurisdiction since the last comparable scan. Hover for a count, click for the detail panel filtered to those items.
  2. The “What’s Changed” panel — a card below the heatmap with scan-wide counts (X new · Y updated · Z removed), the most material changes called out, and a short prose summary of what moved this period.

Detail panel cards also carry a chip indicating change status, and clicking an “Updated” chip shows you which specific fields changed.

For the full walkthrough, see What’s changed since last scan.

In the API

The change overlay is a sub-resource on the snapshot:

GET /v1/snapshots/{id}/drift

The API resource is named drift. The user-facing product language across the rest of Regulatory Snapshot is “changes”. You may see the term drift in API field names — that is the developer concept and has been kept stable across API versions for backwards compatibility. They refer to the same thing.

The response is either the structured overlay or { "available": false } if no comparable previous snapshot exists. See the snapshots API reference for the full shape and the errors page for related codes.

Material vs paraphrase change

One subtlety worth knowing: not every “Updated” label is substantive. Snapshot runs the research fresh on each scan, which means an item’s summary may be rephrased slightly between runs even when nothing about the regulation has actually moved. Status, expected date, impact, and likelihood are the load-bearing fields — when those change, something has materially moved. When only the summary wording changes, treat it as effectively unchanged.

In the app, clicking into an “Updated” chip on the detail panel shows you which specific fields differed. In the API, the drift overlay carries field-level deltas so your integration can decide which differences are worth surfacing.

A weekly loop

The pattern most teams settle on:

  • Week 1 — first scan. No changes view. Read the full briefing top to bottom.
  • Week 2 — re-run the same configuration. The changes panel reads, say, 4 new · 6 updated · 1 removed. You read only the deltas.
  • Week 3 onward — five or ten minutes per scan to absorb what moved. The recurring loop is the point.

That is the case for setting up a scheduled scan (in the app, via Settings → Scheduled Scans; in the API, on your own cadence). The first scan is the expensive read; the recurring scans are the easy ones.

What comes next

Scans and snapshots