Illustrative Scenario
Supplier and source change tracking
Illustrative scenario · not a client engagement
Current situation
A purchasing or category manager tracks supplier catalogues, prices, and lead times published across several separate sources.
The flow we propose
A fixed, permitted list of sources is checked on a schedule, each fetch is compared against the previous version, and only the actually detected change is summarised with a citation to the source, version, and retrieval time. An analyst records the resulting decision separately from the factual summary.
From a real run
Two snapshots of the same source are compared automatically — a real change is logged, a cosmetic-only difference is correctly ignored.
Captured from our synthetic reference build — not a client result.View full size →
How it works today
Someone checks each source page or feed by hand from time to time, tries to recall what it looked like before, and notes anything that seems to have changed.
Human control points
- An analyst reviews every change summary before it is used for anything.
- Nothing is purchased or price-changed automatically as a result of a detected change.
- A source outside the agreed allowlist is never added without explicit approval.
Failure and delay points
- A real change is missed simply because nobody checked between two visits.
- There is no record of exactly when a price or term changed.
- The effort needed grows with every source added.
What the pilot measures
- Source freshness at the time of each check
- Real-change capture rate on the test set
- False-positive rate on detected changes
- Analyst review time per report
Technical detail and assumptions
Systems and data
A fixed set of permitted sources such as pages or feeds the client has agreed to. No source outside that list is fetched, and no access restriction is worked around by another method.
Baseline assumptions
- Assumed number of tracked sources, kept small enough during a pilot to review every result by hand.
- Assumed check frequency, taken as a scoping assumption rather than a measured requirement.
- Assumed share of changes that are actually relevant, to be tested during the pilot rather than assumed as fact.
Pilot scope
A small number of sources, a dated change log as the only output, and no purchasing or pricing action of any kind.
Risks, exclusions and fallback
- A source that cannot be reached is labelled inaccessible; access is never regained by a different method.
- Stale content is always labelled stale and is never shown as current.
- Any instruction found embedded inside fetched content is treated as content, never as an instruction to follow.
What moving to production would require
A legal or terms-of-service review for each live source before it replaces a fixture, a currency-conversion sourcing decision if needed, a named analyst owner, and a rollback that stops watching a source without losing its prior change history.