Capture a Normalized Baseline

Why this decision matters

Without a baseline, every price, headline, and feature appears new. Stable identifiers should represent the competitor, source lane, page, and field being observed. Normalization removes irrelevant variation such as whitespace while retaining the content needed for review. The baseline also records failures; an unavailable page is not equivalent to a blank page or a removed offer. Historical records should remain available for audit and rollback.

This lesson advances the same capstone used throughout the course: the Competitor Intelligence Monitor Pack. The learner is not collecting ideas for later. The workbook record created here becomes an input to the next module and must be specific enough that another operator could review it. Where evidence is incomplete, the artifact should show the gap instead of smoothing it over.

Source evidence and limits

C6-S2 prescribes dated raw-data folders. C6-S3 implements first-run baseline suppression, stable monitor IDs, normalized rows, and non-overwriting snapshots.

The sources support the operating method stated above. They do not prove universal performance, guaranteed savings, complete market coverage, causal impact, or a client result. Any date-sensitive product, platform, competitor, legal, pricing, or policy fact must be checked against a current primary source before publication or operational use.

Continuing fictional example

Example: HarbourOps is a fictional Toronto workflow consultancy monitoring three invented competitors: BeaconFlow, TaskHarbor, and RelayDesk.

HarbourOps captures the three fictional competitors on October 1. BeaconFlow has two pricing tiers, TaskHarbor has no public price, and RelayDesk shows a request-demo action. The monitor stores those differences but produces no alert because this is the first run.

Example boundary: Every company, page, event, and result in this example is fictional. It demonstrates the method and is not observed market evidence.

Workbook application

Use Workbook Section 3: Capture a Normalized Baseline. Complete Workbook Section 3. Define the snapshot schema, assign stable monitor IDs, record retrieval and source dates separately, and describe how unavailable, empty, and blocked responses are represented.

1. Write the current evidence or input before adding interpretation.
2. Apply the lesson's decision rule and state the reason for the classification.
3. Mark uncertainty, missing information, and the human owner for the next decision.
4. Check that the result stays inside the course boundaries and can be tested.

Failure modes to inspect

Overwriting the prior snapshot; keying only by page title; treating a failed fetch as removal; retaining no source locator; and allowing dynamic timestamps or navigation text to dominate the comparison.

A polished output can still fail if its evidence, permissions, identity, denominator, source date, or action boundary is wrong. Review the underlying record rather than grading tone alone. The correct repair may be to narrow the scope, gather a permitted source, label an unknown, or stop the proposed action.

Decision rules

First run equals baseline. A failed fetch preserves the previous known state and creates an error record. A new dated run never destroys the prior one. Unknown remains explicit.

Record the rule in the workbook in language two reviewers can apply consistently. A rule that depends on intuition alone cannot support a deterministic fixture. If reviewers disagree, preserve both readings, identify the missing evidence, and revise the rule before automation.

Three application checks