Method
How a record is built
EZVET is only useful if a reader can check it. The pipeline is designed so every visible value can be traced to a source field, a source document and a moment in time.
1 · Retrieve from an official source
Product data is fetched from the publishing authority's own machine-readable feed, never from a secondary aggregator. Each fetch records the feed's publication timestamp and our retrieval timestamp.
2 · Store the raw record first
The untouched source payload and a content hash are stored before anything is normalised, so any published value can be traced back to exactly what the source said.
3 · Normalise conservatively
Names, species and ingredients are normalised for search only. Where the source is silent, EZVET says 'not stated in source' instead of filling the gap.
4 · Record field-level evidence
Every published field keeps its raw value, its source identifier, its source URL and its extraction method, so a reviewer can audit a single field without re-importing anything.
5 · Track extraction and review state
Clinical sections carry an explicit status — extraction pending, in review, approved. Nothing clinical appears until it moves past extraction and review.
6 · Re-import idempotently
Imports are repeatable: the same source record updates the same row instead of creating duplicates, so the catalogue can be refreshed as the register changes.
On artificial intelligence
EZVET's architecture reserves a place for a locally run extraction model to read official product documents and propose candidate values. That is a proposal step only: candidate values will be stored as candidates, shown with their source paragraph, and published only after a human reviewer approves them. No clinical text on this site is model-written today, and none will be published without that review trail.