Origin fields, batch identifiers, immutable records, and an audit trail — designed into your product data model, webshop, or PIM, so that a claim on the product page can be traced back to the batch it actually came from — and so the same data can carry a new business model, not just a compliance answer.
A claim is only as good as the record behind it. In most webshops, origin is a sentence in a free-text description field. It cannot be queried, cannot be versioned, and cannot be proven after the fact — and when a buyer or an authority asks where a particular delivery came from, the answer is reconstructed from memory and email.
We fix the model underneath. Producer, farm or lot, batch, certificate, claim, and the evidence link between them become first-class fields rather than prose. Batch records become append-only, so a correction leaves a visible trail instead of quietly overwriting what was published last spring. Validation refuses to publish a claim that has no evidence record behind it. Existing free-text origin data gets migrated into the structured fields rather than left behind as a second source of truth.
This is the same work we did for Willit Oy, a marketplace for Finnish small producers, where origin is the entire product. It transfers cleanly to any catalogue: a custom database, a Rails or Django backend, Shopify metafields, or a PIM that was designed before traceability mattered.
The point is not the schema. Once producer, batch, and evidence are queryable, the model around them can change: documentation generates itself, buyers self-serve the proof they used to phone for, a premium tier is backed by a record instead of a sentence. None of that is available while origin is prose.
Because you cannot query it, version it, or prove it. When a buyer asks which farm a particular delivery came from, or an authority asks what the product page said last spring, a free-text description gives you neither answer. Structured fields for producer, lot, batch, certificate, and evidence link give you both, and let the system refuse to publish a claim that has nothing behind it.
Corrections add a new record rather than overwriting the old one. The current value is what you see on the product page; the history remains readable, showing who changed what and when. This matters because the question after a complaint is rarely "what does it say now" but "what did it say when the customer bought it".
Usually yes. We have done this on custom Rails and Django backends, on Shopify metafields, and inside PIM systems designed before traceability mattered. The model is the deliverable; where it gets implemented depends on where your catalogue actually lives. If the honest answer is that your current system cannot carry it, we will say so rather than bolt it on badly.
It gets migrated into the structured fields, with a written report of what could not be resolved automatically — usually the entries where a description names a region but no identifiable producer. Those come back to you as a work list rather than being silently dropped or guessed at.
Next: Documentation — The paperwork, produced automatically.