The current report is not necessarily the report for an earlier purchase

Start from the order, not the download page

The natural shortcut is to open the product page and attach whatever report is linked there today. That answers a different question. The current public file describes the batch the store is offering now; the customer is asking about the item they received. Treat the request as a retrieval task against the order, and record the order reference, the product identifier as printed on the order line, and the date of purchase before touching the evidence library.

Also record what the customer actually asked for. Some want the document that was public when they bought; others want the report for the physical lot in their hands; a few are really raising a dispute about the current listing. The first two are retrieval questions with the same method. The third belongs in a different workflow and should not be settled by attaching a file.

Match product, lot and dates with genuine records

Look for the lot or batch reference in the fulfilment record, packing record or inventory allocation tied to the order. Where the business records lot assignment, that entry is the bridge between the purchase and the evidence archive. Where it does not, record the absence honestly; do not infer a lot from the purchase date alone, because receipt of new stock and the switch to shipping it rarely happen on a single documented day.

Then search the report archive for that product, not the live website. The archive should hold each retained report with the lot it names, its issuer and its printed dates, including files no longer public. Compare the candidate report's product identifier, lot and issue date against the order. A matching product name with a different lot is not a match. If two retained reports name the same lot, check report identifiers and dates and keep both in the record until the document owner resolves which applies.

A date comparison is not an invented expiry rule. An older report is not automatically the wrong one for an older purchase; it is frequently the right one. The question is whether the document's identifiers connect it to the lot supplied, not whether it looks current.

A new batch is not an issuer correction

Two different events can put a new file on the product page. In one, the store restocks with a new lot and publishes that lot's report; the earlier report remains the correct evidence for earlier orders. In the other, the issuer corrects a report about the same lot, and every reference to the superseded version needs review. The replacement-history record for the file should say which event occurred. If it does not, that gap is part of your finding.

This page handles the first case: retrieving the historical document when a legitimate batch change moved the public file on. A correction notice from an issuer changes what the store should publish and what earlier statements relied on, and that needs its own traceable replacement process. Do not treat a corrected report as merely a newer batch, and do not treat a new batch as a correction.

When the records do not settle it

Three outcomes are legitimate. The archive yields a report whose lot and product match the order, and support supplies that file with a note of why it was selected. The archive holds no report for that lot, and support says the association cannot be established from retained records. Or the records conflict — two candidate reports, an unreadable lot entry, a replacement history that does not say what changed — and the question leaves the support queue.

Unresolved cases belong to whoever owns the document library, typically the person who manages supplier documentation and publication history, with the support lead deciding what the customer is told in the meantime. What neither should do is send the current file with wording that implies it covers the earlier lot. Under the FTC's substantiation policy, an objective claim needs its evidentiary basis to exist; a report for a different lot is not evidence about this one, and presenting it as such manufactures support the records do not contain.

Keep the answer within the evidence

Write the response around what was matched: the order, the lot record and the report identifier supplied. Avoid adding assurances the document does not carry — a retrieved report describes what its issuer recorded for that lot, and it does not establish safety, legality or eligibility for any purpose. If the customer asks for interpretation of the results, that is a question for the issuer or a qualified reviewer, not for support.

The durable improvement is the archive itself: every product's reports indexed by lot, with the date each file became public and the date it was replaced, so the next request is a lookup rather than a reconstruction. If a provider or reviewer asks how the store connects purchases to evidence, this retrieval map is the honest answer. For a Prism website-review consultation, describe how public evidence links are organized and where the historical files live; scope, responsibilities, fees and terms are confirmed before work, and no review authenticates a report or its results.

Purchase-to-batch retrieval map

Complete one map per customer request, working from the order outward to the archive. Record references to genuine records and mark a missing link as missing; never substitute the current public file for an unmatched lot.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.