Find out whether the catalogue changed before asking people to review it again
A daily export can be a new file without containing new product information. If a comparison treats every new file as a complete set of changed items, reviewers may repeatedly inspect material that nobody altered.
This fictional cost investigation concerns the work generated by a catalogue synchronisation, rather than provider charges or a promised labour saving. It asks which review tasks are justified by the approved source and which are artefacts of the comparison rule.
Follow the source into the review queue
Export E-1 contains 50 product records. Each has a stable reference, approved description, dimension, document reference and publication state. It also includes an exported_at value describing when the file was produced.
The next day, E-2 contains the same 50 product records with identical product facts and publication states. Only the export timestamp changes. The current comparison includes that timestamp in every row's fingerprint, so all 50 rows are marked changed and each creates a review task.
The reviewer opens several tasks and sees no difference in the displayed product information. That is evidence to investigate the comparison, not a reason to instruct staff to approve the batch without looking.
Define what a review is supposed to mean
The product owner supplies the meaningful comparison contract. A review is required when the approved description, dimension, document reference or publication state changes, or when an item is added or removed under the agreed source rules. The stable reference identifies the item being compared.
The file's production timestamp is useful provenance. It does not, by itself, change any of those product facts. It remains recorded with the export but is excluded from the product-change fingerprint.
| Field or event | Treatment in this fixture |
|---|---|
| Stable product reference | Match the source identity |
| Approved description or dimension | Compare; difference requires review |
| Document reference | Compare; a changed association requires review |
| Publication state | Compare; retirement requires its agreed review |
| Added or removed source identity | Handle explicitly under the source contract |
| Export production timestamp | Retain as provenance; do not treat as a product change |
This is a specific contract, not an instruction to remove every date from every comparison. A validity date could be a meaningful product fact in another catalogue. Its treatment would require the owner's decision.
Make the correction discriminate
The team repeats E-2 against the accepted E-1 baseline in an isolated review fixture. The corrected comparison produces zero product-change tasks because all meaningful fields match. The export record still shows the new production time, so the receiving team can establish which file was examined.
A third export, E-3, changes product P-17's approved dimension from 80 to 85 in the source's agreed unit. Its document reference and publication state remain the same. The comparison now produces one review task for P-17, showing the previous and new dimension. The other 49 records do not receive tasks solely because E-3 has another timestamp.
The task remains a review request. The synchronisation does not automatically approve the changed dimension or make a technical suitability claim. The product owner still decides whether the source change is ready for publication.
Preserve the change that is easy to overlook
A separate E-4 fixture keeps the dimensions unchanged but marks P-22 retired. The publication-state comparison produces the required retirement review. Excluding the transport timestamp has not excluded status changes or turned the process into a numbers-only comparison.
The team also checks a new identity P-51 and a source omission. Those follow their explicitly agreed paths instead of being silently treated as unchanged. The comparison does not infer that an omitted row is safe to delete unless the source contract establishes that meaning.
An unchanged re-run of the same accepted export creates no new product-change tasks. The import record still records the attempt, so provenance and review work remain separate.
Choose the scope from the observed cause
The selected improvement is a bounded comparison and review-queue change, with the meaningful fields and controls documented. The business does not commission a larger dashboard merely to make 50 false tasks easier to process.
The evidence explains a source of recurring work. It does not establish how many staff hours the business will save in ordinary operation. A useful follow-up would inspect actual task volumes and the time reviewers spend under comparable conditions, accounting for real product changes.
The cost to include in the proposal is maintaining the comparison contract as the catalogue evolves. A new meaningful field needs an explicit decision and a test; it should not be ignored simply because it was absent from the first fingerprint.
For a system connection, bring two exports believed to be equivalent and one with a deliberate business change. Ask the implementation to distinguish them. That can expose the work hidden behind the apparently harmless promise to “refresh the catalogue every day.”