What changes when there are ten thousand product pages

A new document may describe a different object

Define two configurations of the fictional К-42. Document A describes shipment A with ten items. Document B describes a new shipment B with eight. Offers from both shipments may remain on sale. Offer B's page was based on A: the number in the specifications was changed to eight, while the description and image were left untouched. The complete item lists are not specified in this example; a count alone cannot reconstruct them.

The information is not contradictory while it refers to different sets. Document B's date does not authorise replacing ten with eight in every К-42 record. First determine which trade item each offer sells and connect it with the appropriate materials.

A family code, model designation, set configuration and seller offer serve different purposes. A matching name helps find candidates for comparison but does not establish identity. If the warehouse mixes shipments and cannot identify the set supplied with an order, editing alone cannot justify a precise promise of eight or ten items.

The task then goes to the owner of the data or fulfilment process. The text needs a confirmed object. Marking the question “unknown” keeps the problem visible, but does not permit publication if the offer requirements cannot be met without an answer.

From set data to dependent passages

For set B, “eight items” is linked to document B and its scope. Dependencies connect the record to specifications, descriptions, image captions, translations and other representations using these contents. This creates a review queue instead of a search for every occurrence of the digit eight in the catalogue.

Some dependencies are indirect. A calculated average price per item uses both the count and the offer price. A comparison promising two more items requires the alternative and both set versions to be checked. A search for the literal “10” alone may miss such an inference.

W3C PROV-DM describes derivation and revision relationships between data. A catalogue can use these concepts to retain provenance. “After a change, find and reconsider dependent publications” is our applied policy, not a guarantee provided by the standard.

A graph is useful only to the extent that its links are complete and correct. If text within an image is not registered as dependent, following the stored links will miss it. Manually comparing real pages with the registry, including old images and manual additions, helps reveal that gap. An error consistent across all channels remains an error: the shared source still needs checking.

What to preserve with every revision

An update date alone does not explain what happened. Reconstructing the decision requires the source document and its scope, extracted information, product-page questions, channel requirements, the text revision and check result. Record the reason separately: error correction, a new set, a changed platform rule or a new audience task.

The processing method also needs a version: which rules extracted the values, produced inferences and made decisions? If an instruction update makes the evaluator reject valid calculations, the history distinguishes a data change from a change in the check.

Repeatability means being able to reconstruct the inputs and assess the decision's evidence. It does not always mean obtaining byte-for-byte identical text when a model is run again. Preserve the actual revision for audit, and the configuration and control cases for repeated testing.

Public text should not acquire internal identifiers merely for process convenience. Those can be stored in a publication registry. Buyers need clear information about the selected product; the system needs a link between the page and a specific checked state.

Different reasons for stopping require different actions

A catalogue inevitably contains pages with ready data, documents of uncertain applicability and identified text errors at the same time. “Generate again” does not suit every state. Separate queues by the next action and assign responsibility for each decision.

Replacing a “10” label with “8” does not correct a photograph of a different set. If B's image or item list is missing, the visual part remains unresolved.

Every transition requires a basis. A “checked” status without a version and result does not establish what was examined. A document dispute goes to someone who can verify provenance and applicability; language improvement remains an editorial task.

Some work may be automatic and some manual. The important point is that a human decision survives the next run. If an editor excludes an unsupported promise, a new generation must receive that decision with its evidence, scope and data version. When applicable evidence becomes available, reconsider the decision rather than turning it into a permanent prohibition.

An update ends where the content is displayed

Set B may have a website, marketplace export, instructions and images. Sending a new version to one channel does not establish its appearance in the others. Data receipt, processing, caching and variant switching form separate checkpoints.

Publication order matters too. An old job that finishes after a new one can restore an outdated description. The system therefore needs a way to tie a result to the product's current state and prevent an obsolete job from overwriting an approved revision. Repeated submission of the same result must have defined behaviour.

For release, preserve the checked version, its destinations and evidence of actual receipt. If something fails, the ability to roll back to a previous technical version does not make that version's content current again. If it describes a different set, an appropriate solution for the data and offer is needed.

Individual channels have their own mechanisms. For example, Merchant Center automatic updates use page data for selected price, sale-price, availability and condition attributes. Google explicitly says this does not replace regular product-data updates. It should not be mistaken for universal updating of descriptions and set contents.

After delivery, check the identifier and scope. Finding the new phrase on the page is insufficient if another selected variant still has the old contents nearby. Check field consistency in the state the buyer can actually access.

A count of completed texts does not describe the catalogue's state

Every row can be processed while important questions remain unanswered. Track source-data readiness, required answers, blocking violations and delivery of current versions separately. Each metric needs a defined denominator: products, variants, claims or publications.

The queue's composition matters too. If difficult cases are moved to manual review, a high automatic-check success rate concerns only the remainder. Deferred cases and abstentions must stay in the report, or the unfinished work will be hidden.

Sample checks cover rejected and accepted results. Look for missed errors among accepted results and false alarms among rejected ones. Examine categories, languages, new shipments and rare conditions separately when they may change task difficulty.

The test set evolves as well. A discovered old К-42 image becomes a case for checking links. A lost condition becomes a pair for regression testing. After the process changes, compare results on retained and independent cases, not only on the example that was fixed.

Useful operational metrics include the age of unresolved questions, the time from a new document to a consistent update and recurrence of a corrected error. Interpret them in context: a fast release with unsupported contents does not accomplish an accurate update.

How to evaluate the system on a concrete task

To evaluate the service, give it a bounded dossier and several linked К-42 representations. Ask it to identify document B's scope, find dependent passages, retain A's separate data and show the evidence for the proposed revision. Then check what happened to the image, translation and resubmission of the old job.

This makes capabilities observable. It shows where the system extracts a fact, where it makes an inference, which cases it sends for clarification and which version it treats as complete. One successful paragraph reveals only a small part of that work.

System requirements must be verifiable in the results: a link between claim and source, change history, an understandable finding, preservation of required conditions and checks of the delivered state. Measure time and cost on a defined workload and task mix. There is no basis for promising universal savings without that comparison.

For the fictional К-42, a successful run has exact conditions: offer A retains ten items; B describes eight according to its own document; B's image is verified separately; and a late job for the old revision does not overwrite the approved publication. Check each result within the relevant offer and channel.