Deterministic comparison answers exactly which normalized fields changed. Semantic analysis asks whether the movement has meaning in context. A reliable monitoring system needs both in sequence: deterministic evidence for auditability, semantic interpretation for triage, and human review for material decisions.

What this guide covers

  • the strengths and failure modes of exact and semantic comparison;
  • a layered change-detection architecture;
  • rules for choosing the right technique by field;
  • an evaluation set for real monitoring noise.

Define the two jobs

A deterministic diff applies explicit rules to comparable inputs. Given the same inputs and rules, it returns the same result. Examples include string equality after normalization, numeric field comparison, set membership, or a structured JSON patch.

Semantic analysis interprets meaning across wording, structure, and context. It can recognize that “up to ten seats” and “maximum team size: 10” may express the same boundary, or that a rewritten headline changes the audience while retaining few exact tokens.

The techniques are complements. A semantic model should not be the only record of a price changing from one value to another. An exact HTML diff should not decide whether reordered navigation represents a new strategy.

Build the evidence layers

1. Retrieval state
2. Comparable capture
3. Content normalization
4. Structured extraction
5. Deterministic field diff
6. Semantic classification
7. Materiality and review
8. Decision routing

HTTP Semantics, RFC 9110 defines protocol concepts such as representations, validators, status codes, and conditional requests. These help establish retrieval state; they do not establish that two rendered pages are commercially comparable. Login state, locale, experiments, client rendering, and blocked content need their own checks.

Choose the technique by data type

FieldPrimary comparisonSemantic role
Numeric price or allowanceparsed exact comparisonexplain affected workload
Plan membershipnormalized set diffgroup related entitlement movement
Availability stateexplicit enum transitiondetect ambiguous launch language
Positioning claimversioned extracted textclassify audience/problem/promise shift
Changelog entrystable event identity and metadataclassify launch, maintenance, deprecation
Status incidentcomponent/time/state fieldssummarize pattern with boundaries

Make the structured schema narrow enough to maintain. Do not extract hundreds of unstable fields merely because a model can produce them.

Normalize before diffing

Remove or isolate fields that change without decision value: timestamps, rotating testimonials, tracking parameters, navigation order, build IDs, cookie text, and repeated layout content. Preserve the raw evidence separately.

Normalization is a controlled transformation and needs a version. W3C PROV-O describes how entities, activities, agents, and derivations can be represented. The practical implication is straightforward: keep enough provenance to know which capture and transformation produced a field.

Use semantic analysis after the exact record exists

Give the model:

  • source type and decision context;
  • exact changed fields;
  • short before and after excerpts;
  • capture-health and comparability notes;
  • approved taxonomy and output schema;
  • instruction to return “not established.”

Ask it to classify, group, identify alternative explanations, and draft the review question. Do not ask it to recreate missing evidence.

Route ambiguous cases safely

Use terminal states:

  • material change confirmed;
  • real change, not material;
  • semantic movement, corroboration needed;
  • no normalized movement;
  • incomparable capture;
  • retrieval or extraction fault;
  • reviewer pending.

A low-confidence semantic change should not be promoted by dramatic language. A high-confidence exact change may still be irrelevant.

Build a test set from failures

| Case | Expected exact result | Expected semantic state | Material? | Failure protected |
|---|---|---|---|---|
| billing toggle changed | incomparable | evidence fault | no | false price alert |
| price field 20 -> 25 | exact movement | pricing | depends | missed numeric change |
| headline rewritten | text movement | positioning / no material | depends | noise or missed repositioning |
| first healthy capture | baseline | no change | no | fabricated event |
| content block vanished | structural loss | capture fault | no | false deprecation |
| feature moved tiers | set movement | packaging | yes | feature-only interpretation |

Measure precision, recall on reviewed material cases, citation fit, extraction stability, and reviewer correction rate. NIST's AI Risk Management Framework supplies a useful govern-map-measure-manage loop for that evaluation.

Use Evidence Compare to inspect public comparisons, the company directory and market map for context, and the monitoring guide for ownership. The AI monitoring architecture defines the claim-level evidence contract. Google's people-first guidance is the final publication check.

Sources and further reading

Method note

Deterministic does not mean correct when extraction or comparability is wrong; semantic does not mean material when language changes. Preserve the raw record and validate both layers.