If yesterday’s and today’s numbers match, did nothing happen? The actual snapshot comparator ignores some verification fields. I built a synthetic diff that avoids exaggerating price changes while preserving the work of checking again.
Read the work behind ignored fields
The source excludes fields such as checked date, reference and note from value comparison. That can avoid announcing a price change for every minor edit. But whether those changes may also disappear from operational history is another question: a fresh check can leave the number unchanged.
The independent version compares numeric values, verification metadata and unit representation separately. It preserves the latter even when price does not change. No actual notification is sent and the original comparator is untouched. This is a classification contract before deciding what to announce and what to retain.
Return three kinds of difference
Value fields compare normalized input and output numbers. Metadata fields compare checked date, reference and note. Representation fields retain changes to raw value-and-unit structures. Numeric difference makes the event value changed; other differences alone become verification or representation only.
An event can contain several kinds together. A price and checked-date update retains both; an equivalent unit expression leaves numeric fields empty. Even with a short event label, detail must remain available so a later reviewer can explain the classification.
Name a date-only update accurately
Changing only the synthetic checked date leaves value fields empty and records checked under metadata. Changing output creates a numeric change. Re-expressing point-zero-zero-two per thousand as two per million is representation only. Testing all three keeps the boundary concrete.
Editing a date does not itself prove another source review occurred. The function preserves supplied differences, while the reviewer’s actual action and original material need their own evidence. Synthetic dates are not presented as a live service’s freshness claim.
Represent repeated verification without noise
A stable value can accumulate review records. Keeping only price-change events makes continued checking indistinguishable from neglect. Announcing a new price every time does the opposite, exaggerating actual change. One event kind should not serve both purposes.
The module returns an array without storing a history database. Notification policy, retention and review intervals need a real service’s decisions. No scheduler or provider fetch was added, so this task does not claim to operate continuous verification.
Keep additions and removals as distinct events
An identity present on one side becomes added or removed, not a changed existing value. Both snapshots reject duplicates first. The next article focuses on that prerequisite, which prevents repeated keys from disappearing before comparison.
Only synthetic provider and model identities appear. A missing row in an actual feed would also need review before being described as discontinued service. Removed means absent from the compared inventory; it does not establish a business termination decision.
Make no-change results explainable
Twelve tests cover date refresh, representation changes, numeric updates, additions, removals and preserved inputs. Identical snapshots return no changes, while metadata differences are no longer discarded. The public module retains actual source and extraction results.
I want a maker to explain an event by pointing to a particular number and field. Separating review work from changed facts makes information calmer and more precise. Inventory, schedule and condition comparators can use the same method: define which difference constitutes which event before designing its badge.