At onboarding
One document for the whole catalog
A single PDF listing every SKU the store sells, the lot currently shipping for each, and the verified certificate behind that lot. It is built from the store's own records, and it names the SKUs it cannot document.
It is the document a processor asks for at onboarding and at reapplication. Provkeep generates it from the catalog and order history it already holds, so the document reports what the store has recorded rather than what was gathered for the occasion.
The completeness check is what distinguishes it. The catalog on its own is not the scope. A SKU can appear on an order without ever having a product record, and walking the catalog will not find it.
The check runs before the document does
So the readiness screen combines two sets: every SKU in the catalog, plus every SKU that has appeared on an order, whether or not it was ever catalogued. The second set is where an omission comes from, because a SKU with no product record appears in no catalog at all.
The screen below shows both sets for a demonstration store. A SKU that was sold and never catalogued is named, with its state and a link to the order it appeared on. The gap can be closed from that link.
The document always generates. The button reads Generate anyway and carries the count of what is undocumented. Handing over the strongest true document available is more useful than waiting for the catalog to be complete.
The document names its own holes
The cover carries the counts before it carries any evidence: the SKUs in scope, the ones with a published certificate, and the ones without. They are set in the same weight as the rest of the document rather than in alarm red, because the document is a report and not an apology.
The consent paragraph is worth reading closely. It does not say a checkbox was shown. It says which mode each order’s own consent record was written under, and whether the store’s checkout form can create an order without one. The stronger sentence prints only when every order in the document recorded blocking mode and the order table has no gaps. Otherwise the document prints the weaker true statement and the counts.
It also names what it does not cover. Orders created by other routes do not pass through the checkout: an order keyed in by staff, a subscription renewal, a payment link, an order paid with Apple Pay, Google Pay or another express checkout, an upsell that creates a second order after the first, or an order created through the store's API or command line. The scope travels with the claim, so the claim still makes sense to someone whose store takes orders another way.
A weaker claim that holds is worth more than a stronger one that does not. The document prints whichever of the two its own records support, and it does not choose the flattering one.
What the document contains
Per SKU: the lot currently shipping, the purity, the method, the laboratory, and the source report appended in full. Only certificates that a person at the store has verified appear. Model output never reaches this document, at any confidence.
No content hash, storage path or internal identifier reaches the file or its filename either. That is checked by decoding every text stream in the generated PDF and searching the result, rather than by reading the code that writes it.