Decide what normal looks like before the first alert

Most monitors are switched on with a vague instruction to report changes. The first run then produces either a flood of differences or nothing at all, and nobody can say whether that is correct. What is missing is a starting point: a reviewed record of what the sources said when monitoring began, and an agreed sentence about which differences deserve a person's time. Without both, the first alert compares against something nobody checked, judged by a rule nobody wrote.

A change needs something to change from

Every alert is a comparison between two states. If the earlier state was never looked at, the comparison inherits whatever went wrong when it was captured. A page that loaded half its content, a document that was cut off, a login wall that returned a stub instead of the real text: each becomes the reference, and the next normal capture shows up as a dramatic change.

The opposite failure is just as common. A monitor with no reviewed starting point treats everything on its first pass as new, so the team receives a long list of “changes” that are really just the current state. People skim it, conclude the monitor is noisy, and stop reading before the alerts start to mean anything.

What goes into a baseline

A baseline is more than a snapshot. It is a snapshot someone has checked, with the parts that matter pulled out. For each source in scope it should hold:

• The source reference and retrieval time, so anyone can see exactly what was captured and when.
• The captured content, with known noise set aside: navigation, rotating banners, view counters, timestamps that change on every visit.
• The facts you actually care about, extracted with the passage that supports each one. For a hypothetical supplier terms page, that might be the payment term, the termination notice period and the liability clause.
• A note of who reviewed it and anything odd they noticed, such as a section that failed to load or a document that looks like a draft.

The extracted facts are the important part. Later, a change to the payment term is easy to recognize because you know what the payment term was, and you know which passage said so. Supporting each value with its passage is the same discipline described in citations that hold up.

Write the materiality rule before the first alert

The second half of the starting point is a definition of material change, written before anything fires. If you write it afterwards, it tends to be shaped by whatever the first alerts happened to contain. A short template is enough:

• Question: Have the published onboarding terms of our suppliers changed in a way that affects existing contracts?
• Sources: the terms page and the data-processing annex of each supplier on the approved list.
• Material: any change to payment terms, termination notice, liability or data-handling clauses, and any new section.
• Not material: formatting, navigation, contact details, typo fixes, reordering without new text.
• Cadence: weekly, on Monday morning, in the Istanbul timezone.
• Notification: email to the procurement lead; nothing else happens automatically.

This reads a lot like the acceptance criteria for a work order, and for the same reason: it says in advance what counts, so the result can be judged against something fixed. Write acceptance criteria before the agent starts makes the general case, and deciding which sources may answer covers how to choose the source list.

Version the definition instead of editing it

The rule will change. Reviewers will find a category of noise you did not anticipate, or a kind of change you forgot to call material. The temptation is to edit the definition in place. Resist it. If the rule changes silently, past alerts become hard to interpret: was this difference flagged under the old rule or the new one, and would it be flagged today?

Treat each definition as a version. A new cadence, a wider source list or a different materiality sentence produces a new version that someone approves, and every run records which version it ran under. Old versions stay readable. In GoCux, a Pulse definition, meaning its cadence, timezone, notion of material change and notification choice of none or email, is approved as one exact version, and each run is reviewed against it. The monitor quickstart walks through setting one up.

Re-baseline on purpose

A baseline is not permanent, but it should only move deliberately. Good reasons to set a new one:

• A material change has been reviewed and accepted, so the new state becomes the reference for what comes next.
• A source has been restructured, for example a site redesign that moves the same text to new pages.
• The question itself has changed, which usually means a new definition version as well.

Record each re-baseline as an event with its reason. A baseline that drifts on its own, quietly absorbing every change, makes the monitor blind to slow shifts that never trip a single alert.

Before you switch it on

• The sources are listed, each with a reference, and someone has looked at the first capture.
• Known noise is identified and excluded from comparison.
• The facts that matter are extracted, each with its supporting passage.
• The materiality rule is written down, with examples of both material and not material changes.
• Cadence, timezone and notification are set, and the whole definition is approved as a version.
• Everyone knows what happens when a change is accepted: who reviews it and when the baseline moves.

Once alerts start arriving, the next step is reviewing them properly before they spread; review a detected change before it travels picks up from there.