Help Center / The what-changed feed
The what-changed feed
When a breach-notification law moves, the "What changed" feed shows you the change and flags exactly which of your open incidents that change affects — so you know precisely which live incidents need their obligations recomputed.
Where it lives
The feed sits at the top of the Incidents tab (the incident list view), under a heading "What changed (law dataset …)".
Versioned dataset & the changelog
The jurisdiction data is versioned (for example 2026.3). Each new version carries a changelog of plain-English entries describing what moved — for example the 2026.3 entries cover California SB 446, Oklahoma SB 626, the proposed CIRCIA labeling, the proposed HIPAA 72-hour item, and the confirmation that SEC Item 1.05 is in force. Each changelog entry also records what it affects: specific states, framework flags, or frameworks.
When you compute (or recompute) an incident's facts, Klaxon stamps the incident with the dataset version it was computed against. That stamp is how the feed knows whether an incident has "seen" a given change yet.
Reading the feed
- The top of the panel lists the latest changelog entries in plain English — what changed in the current dataset version.
- Below that, Klaxon checks each open incident (anything not Closed) against the changes.
- If any open incidents are affected, a red banner says "N open incidents affected by a law update — recompute their obligations," followed by a table of those incidents. Each row shows the incident title, the dataset version it was last computed against versus the current version, and why it's affected (e.g. "affected residents in CA," "incident carries the phi flag").
- If open incidents exist but none are affected, the feed says so: "No open incident is affected by a pending law update."
- Click an affected incident's row to open it.
How "affected" is decided
An incident is flagged by a change only when the change actually touches that incident's facts, and only when the incident was last computed against an older dataset version than the change. A change can match in three ways:
| The change touches… | An incident is affected when… |
|---|---|
| A specific state | The incident has affected residents (count > 0) in that state. Example: a CA change flags any incident with CA residents. |
| A regulated-data flag | The incident carries that flag. Example: a change to the proposed HIPAA item flags any incident with the PHI flag. |
| A framework | The incident triggers that framework (via its flag). Example: a CIRCIA change flags any CIRCIA-covered incident. |
So a change to Oklahoma law won't bother an incident that has no Oklahoma residents, and an EU-only incident won't be flagged by a U.S.-state change. You only see what's relevant to you.
Recomputing an affected incident
- Open the affected incident from the feed.
- Review the facts, then click Update facts & recompute.
- Recomputing re-runs the engine against the current dataset version and re-stamps the incident with that version, so the obligation set reflects the new law and the incident drops off the affected list.
Closed incidents are never flagged — the feed only nags about live incidents you can still act on.
It's local and deterministic
The whole feed is computed in your browser from the dataset that shipped with the app and the incidents in your local storage. No network call is made to produce it, and the same inputs always produce the same result.