A durable competitor-monitoring stack is a chain of small, inspectable components: source registry, compliant retrieval, immutable capture, health checks, normalization, structured extraction, deterministic diff, bounded semantic analysis, human review, decision routing, and outcome measurement. Start with the decision workflow and add components only when a real failure requires them.
What this guide covers
- the minimal architecture and data contracts;
- where deterministic and AI components belong;
- source health, provenance, and review states;
- a staged implementation plan.
Begin with the operating contract
Before choosing tools, define:
- three to five companies and the reasons they matter;
- one decision class, such as plan and allowance movement;
- source URLs and fields;
- collection cadence and access rules;
- reviewer and decision owner;
- materiality threshold;
- retention and publication boundary.
This contract prevents a general web-crawling project from replacing the business problem.
Layer 1: source registry and retrieval
The source record needs requested URL, source type, company, decision field, cadence, locale or state, last health, and owner. Retrieval should record status, final URL, headers, observed time, and errors.
RFC 9110 defines HTTP semantics such as representations, status codes, and validators. RFC 9309 defines the Robots Exclusion Protocol. Respect access controls, published directives, terms, rate limits, and applicable law. A retry strategy is not permission to bypass a block.
Layer 2: immutable capture and health
Store the raw response or approved representation separately from derived fields. Give it a stable identifier and content hash. Record:
- observed timestamp;
- final URL and response state;
- capture method and version;
- locale, currency, billing, or authentication state;
- size and extraction diagnostics;
- previous comparable capture;
- block, challenge, or rendering indicators.
The first healthy observation is a baseline. A failed capture is an operational event, not a competitive event.
Layer 3: normalization and extraction
Normalize only what the decision requires. For pricing, fields may include plan, value metric, price, period, allowance, entitlement, and entry motion. For positioning, use audience, category, problem, promise, proof, and frame.
Version normalization and extraction rules. Keep null, absent, and unknown distinct. Never fill a missing value with a model guess.
Layer 4: deterministic comparison
Compare structured fields exactly and create an event candidate containing before, after, field path, and capture IDs. Suppress known non-material fields. Group related changes within one observation.
{
"sourceId": "...",
"beforeCapture": "...",
"afterCapture": "...",
"changedFields": [
{"path": "plans.pro.allowance", "before": 500, "after": 750}
],
"comparability": "healthy"
}Layer 5: bounded semantic analysis
Give the model only the event candidate, relevant excerpts, source context, and approved taxonomy. Ask for classification, materiality hypothesis, alternative explanation, and unknowns. Require claim-to-evidence pointers and permit “not established.”
The model does not decide that a source is comparable or that a material decision should be made.
Layer 6: review and decision routing
Reviewer states should include confirmed, correlated, not material, false positive, evidence fault, and pending. Every rejection has a reason code. Confirmed material movements create a decision record with owner, due date, response, and outcome.
W3C PROV-O offers a general language for provenance among entities, activities, and agents. Your schema can be simpler, but it should reconstruct which source and transformation produced a conclusion and who reviewed it.
Layer 7: operations and evaluation
Track capture success, comparability, material precision, missed known events, review delay, reviewer corrections, stale fields, decision closure, and source cost. OpenTelemetry's signals can inform the system-observability layer; market observations and operational telemetry should remain distinct.
Use a labeled regression set containing page noise, locale changes, source faults, baselines, exact commercial changes, ambiguous rewrites, and reversals.
Stage the implementation
| Stage | Scope | Exit test |
|---|---|---|
| 1. Manual evidence | five sources, weekly capture and review | decisions and fields are stable |
| 2. Reliable capture | registry, immutable versions, health states | failures no longer become signals |
| 3. Structured diff | one source type and schema | reviewed precision is acceptable |
| 4. Semantic triage | bounded model output | citation and correction tests pass |
| 5. Decision loop | owner, due date, outcome | useful decisions close consistently |
| 6. Expansion | additional sources and markets | each addition has a capacity owner |
Use the EXVIV company directory, market map, and Evidence Compare to inspect a public implementation boundary. The monitoring guide defines the operating loop; the AI evidence architecture defines the model contract.
Related EXVIV research
- Monitor competitors with AI without hallucinations
- Deterministic diff versus semantic analysis
- How to score competitive signals
Sources and further reading
Method note
This reference architecture is technology-neutral. Collection methods and retention must be reviewed against the actual sites, data, contracts, risk, and jurisdiction in scope.