When the monitor fires: turning a change into a scoped follow-up

A monitor's job is to notice. It tells you that a page, a filing, a price list or a policy has changed in a way that matters. What happens next is where most setups go wrong, in one of two directions. Either the alert lands in an inbox and nothing follows, or an automation fires straight off the change and does something nobody reviewed. There is a better middle path: review the change, and if it deserves work, open that work as its own scoped task, with its own plan and its own approval.

A change is a signal, not an instruction

It is tempting to wire a detected change directly to an action. The competitor changed their pricing page, so update the comparison sheet. The regulator published new guidance, so revise the checklist. The trouble is that a change rarely carries enough information to act on. Pages get redesigned without changing meaning. A partial update appears before the full one. A wording change looks material to a diff and turns out to be cosmetic to a reader. And the text on a monitored page is written by someone outside your company, which means it should never be able to steer what your agents do next.

So the monitor's work should end at a clear statement: this changed, here is the before and after, here is where and when it was seen. Deciding what that means is a separate step, done by a person.

Review the occurrence first

Each run of a monitor that finds something is an occurrence. Review it one change at a time, against the definition of “material” you agreed when the monitor was set up. If you never wrote that definition down, set a baseline before you monitor is the place to start. For each change there are only a few honest outcomes:

• Dismiss. Not material. If the same kind of change keeps getting dismissed, the definition needs revising, not more patience.
• Note. Material, but no work is needed now. Record it so the next reviewer has the context.
• Follow up. Material, and it needs work. Open a follow-up.

If the change will be shared with other people before any work happens, review the wording that travels with it. Review changes before they travel covers that step.

Write the follow-up as its own work order

The follow-up should not inherit the monitor's purpose. A monitor asks “did this change?” The follow-up asks a new question, such as “does this change affect us, and how?” That question deserves its own goal, its own scope and its own definition of done. For example:

Goal: decide whether the revised supplier terms change our renewal checklist.
Trigger: the reviewed occurrence, linked.
Scope: project Procurement; the current renewal checklist; the revised
       terms as imported, with their page reference and retrieval date.
Done when: every checklist item is marked affected or unaffected, each
       with the passage that supports the call; open questions are
       listed separately.
Bounds: no outbound messages; a short wall-time limit; read-only tools.

Writing acceptance criteria first keeps the follow-up from drifting into an open-ended investigation. The link back to the occurrence keeps the reason for the work attached to the work.

Give it a plan and its own source list

If the follow-up needs research, give it a plan: the question, the ordered steps, and the sources it may use. Do not reuse the monitor's source list by default. The monitor watched one page; working out what the change means may call for your own contracts, a regulator's full text or an internal policy, and may need to leave out sources the monitor happened to include. An empty source list should mean the plan may consult nothing, never that it may consult everything.

Approve the plan before it runs, and expect the run to stay inside it. If someone realises halfway through that the real question is different, that calls for a revised plan, not a quietly widened one. A changed question needs a new plan explains why.

Approval does not carry over

Approving a monitor approved the watching: which sources, how often, what counts as material, who hears about it. It did not approve anything a follow-up might go on to do. If the follow-up drafts a message to a supplier, exports files or schedules a recurring check, each of those steps should pause for its own decision, made by someone with authority over it, for that one attempt.

How GoCux connects the two

In GoCux, Pulse asks a recurring question over sources you pick. Its definition, covering cadence, timezone, what counts as a material change, and whether to notify by email or not at all, is approved as one exact version. Every run yields an occurrence that you work through change by change, and a detected change never takes any action for you. Follow-up work runs as a work order with a goal, a scope and acceptance criteria. A research plan must be approved before it runs, and running it cannot stretch it beyond what was approved. Consequential steps pause for a decision, and the result, its sources and the decisions stay together on the order's record.

A checklist for the hand-off

• The occurrence was reviewed against the agreed definition of material, one change at a time.
• The follow-up has its own goal, scope, acceptance criteria and bounds, and links back to the occurrence.
• Any research plan has a source list chosen for the new question, and was approved before it ran.
• Nothing the follow-up does outside the workspace leans on the monitor's approval.
• Changes that keep getting dismissed lead to a revised definition rather than a habit of ignoring them.
• Someone reading the record later can follow the chain from change to decision; what an agent audit trail should record lists what that takes.