Start with the decision someone must make
“Monitor this URL” names a location but leaves the useful work undefined. A monitoring brief names the subject, the change that matters, the capture conditions and the person who will review the evidence.
This editable template turns those decisions into a record an engineer, auditor or client can check before monitoring starts. It works as a planning document for OnChange or another monitoring process. It is not an import format or a promise that every field maps to an automated feature.
A completed example
The following brief is fictional. Its values come from the public Fieldnotes examples, so the scope can be inspected without a customer account.
Scroll horizontally to see all columns.
| Brief field | Worked value |
|---|---|
| Question | Did the Team offer change in a way that needs commercial review? |
| Subject | Team plan, five seats, USD, monthly billing, taxes excluded |
| Evidence source | Public plan page and its named Team region |
| Capture state | Same locale and account state; 1440 × 900 and 390 × 844 CSS pixels |
| Include | Name, amount, currency, period, seats and adjacent purchase terms |
| Exclude | Workshop and documentation announcements that do not change the offer |
| Expected match count | One Team region in the captured state |
| Missing or ambiguous target | Record unavailable evidence and investigate; do not substitute zero |
| Material example | $29 per month becomes $39 per month for the same included seats |
| Quiet example | Announcement changes while the complete Team region stays equal |
| Review owner | Assign a named person before activation |
| Response target | Agree an operational target with that owner; none is claimed here |
| Review trigger | Recheck the brief after a redesign, selector failure or change of offer |
The stable-region experiment supplies the paired observations for this example. The selector experiment explains why one matching price is insufficient without subject identity.
Separate capture rules from alert decisions
Capture rules determine what evidence you collect. Alert decisions determine which observed changes need attention. Preserve that distinction in the brief: narrowing the source may remove a signal altogether, while a notification rule can keep an observation in history without interrupting someone.
Write a concrete example for each decision. “Only important changes” is hard to implement or review. “Notify the pricing owner when amount, period, currency, quantity or availability changes” can be tested against authored examples. State who handles an observation that cannot be classified confidently.
Do not remove context simply to make a comparison quiet. A number without its billing period can hide a material change, as the same-price example demonstrates.
Name the conditions that can change the answer
The same URL can show different content by locale, region, account, consent state, viewport or interaction. Record the conditions relevant to your question and keep the comparison consistent. If you cannot control a condition, preserve that limitation with the result.
An interaction belongs in the brief when it is necessary to reveal the subject. The mobile-menu example needs an opened menu. A form-error comparison needs an invalid submission. Recording a narrow viewport without the required state would leave the intended check incomplete.
If the monitoring mechanism cannot reach a required state, name a separate test or manual review that can. This template does not imply that OnChange's scheduled screenshot capture automatically clicks menus or submits forms.
Decide how uncertainty reaches a person
Missing targets, ambiguous matches, blocked pages and incomplete captures are evidence-quality outcomes. Give them a review path. A blank extraction should not be treated as a confirmed unchanged page, and a failed check should not silently become the next successful baseline.
For an API, name the consumer contract as well as the field. Missing, null and empty values can require different explanations even when the eventual handling decision is the same.
Try three acceptance examples before activation
- Expected material change: change the subject in a known way and confirm the chosen evidence preserves it.
- Expected quiet change: change content outside the stated decision and confirm the intended handling is understood.
- Unavailable evidence: remove or block the subject and confirm the result is recorded as unavailable or ambiguous, with an owner.
Use controlled fixtures or a safe preview for these checks. Record what actually happened, the environment and the next action. A brief is ready when the owner understands the boundaries and can explain what the monitor will miss as well as what it should detect.
Download the editable files
The blank Markdown brief includes fields for scope, evidence, ownership and acceptance checks. The CSV version is convenient for a spreadsheet. The worked brief preserves the fictional example above.
Keep a revision date with the brief and revisit it when the subject, page template or response responsibility changes. For a wider operational process, use the alert-routing playbook. For evidence used in a release decision, use the release evidence pack.