Review a detected change before it reaches anyone else

A monitor that notices something has changed has done the easy half of the job. The hard half is deciding what the change means, and whether anyone should hear about it. Many setups skip that half: the moment a difference appears, it is posted to a team channel, written into a CRM field or handed to an agent as its next instruction. A change that has been detected is not yet a change that has been understood, and once it travels, it is very hard to call back.

How unreviewed changes cause damage

The problems are mundane, which is exactly why they slip through.

• Noise dressed up as news. A cookie banner, a rotating testimonial block or a “last updated” stamp registers as a difference. Forward a few of these and people learn to ignore the channel, including the one alert that mattered.
• Real differences, wrong reading. A pricing table moves to a separate page and the monitor reports that pricing was removed. A competitor renames an old feature and it is announced internally as a launch.
• Amplification. A finding forwarded to three channels and pasted into a weekly summary takes on a life of its own. The correction, if it ever comes, reaches fewer people than the original did.
• Action on a guess. A downstream agent updates an account record, drafts an email to a client or reopens a contract review because of a change nobody looked at. The detection was automatic; the consequence is real.

None of these needs a dramatic failure. They only need a pipeline in which detection and distribution are the same step.

Treat each run as an occurrence

The fix starts with how you record a run. Instead of a stream of alerts, keep each run as an occurrence: one record of what was checked, when it was checked, and every difference found against the last reviewed state. The occurrence is the unit of review. Nothing leaves it until someone has gone through its changes.

Inside an occurrence, review one change at a time and give each a disposition. A small, fixed set works well:

• Material: it matters for the question the monitor exists to answer, and it may travel.
• Not material: a genuine difference that does not affect the question.
• Noise: formatting, layout or a capture problem; consider excluding it next time.
• Unclear: needs a second look or another opinion before it goes anywhere.

Keep the dismissed changes as well as the material ones. The next reviewer should see that a similar difference was judged noise last week, and why. That history is what makes reviews quick after the first few.

Materiality is a judgment, so write it down

Whether a change is material depends entirely on why you are watching. A new paragraph on a supplier's terms page is material if it touches liability and irrelevant if it adds an office address. Leaving that call to each reviewer's mood produces inconsistent results; writing it down turns it into a rule people can apply and argue with.

For a hypothetical monitor on a regulator's guidance page, the rule might read: material means any change to the wording of an obligation, a deadline, a penalty or the definition of who is covered; not material means navigation, formatting, typo corrections and reordering without new text. When reviewers disagree about a case, the disagreement is useful: it usually means the definition needs one more sentence. How to settle that definition before the first run is the subject of set a baseline before you monitor.

A notification is not an action

It helps to keep three things apart. Detection is the monitor noticing a difference. Notification is telling a person that a reviewed change may need their attention. Action is changing something in the world: sending a message outside the team, updating a record, starting new work.

A good notification is informative and inert. It carries the occurrence, the before and after passages, the source reference and the reviewer's disposition, and it does nothing on its own. If the change should lead to work, that is a separate, deliberate step with its own scope, and anything that sends material outside the team should pause for a decision like any other outbound message. The seven consequential action classes describe where those pauses belong, and from a detected change to reviewed work follows the path from an accepted change into a work order.

This is how Pulse is set up in GoCux. It asks a recurring question over sources you pick, each run arrives as an occurrence that is reviewed change by change, and the notification setting is either off or email. A detected change never acts for you; turning it into work is a decision someone on the team makes.

What the reviewer needs on screen

Review is only quick if the evidence is already assembled. For each change, the reviewer should see:

1. The old passage and the new passage, quoted rather than paraphrased.
2. The source reference and the time it was retrieved.
3. The version of the monitor definition that flagged it, so the rule being applied is visible.
4. Earlier dispositions on similar changes from the same source.
5. A place to record the disposition with a one-line reason.

If the reviewer has to open the source in another tab and hunt for the difference, reviews get skipped. Everything they decide should also land on the record, which is what an agent audit trail is for.

A checklist before changes leave the review

• Detection and distribution are separate steps, with a person in between.
• Each run is kept as an occurrence, and every change in it gets a disposition.
• The materiality rule is written down and versioned, and reviewers can point to it.
• Notifications carry the before and after text and the source, and trigger nothing by themselves.
• Anything that leaves the team, or changes a record, goes through its own approval.
• Dismissed changes are kept with their reasons, so the next review starts informed.

For broader context on choosing what to watch, see web monitoring that tracks what matters and the guide to regulatory change monitoring.