Evidence Layer¶
Technical documentation is only useful if a buyer can tell what is verified, what is a published standard, and what still needs confirmation for a specific order. This section makes that separation explicit instead of leaving it to the reader.
The model¶
Every substantive statement on this site is intended to resolve to four fields:
| Field | Meaning |
|---|---|
| Claim | The statement, in one line |
| Source | Where it comes from — a published standard, a regulation, a named method, or a company document |
| Status | Standard (published, externally verifiable) · Documented (company document exists and is referenced) · Company confirmation required (not yet evidenced) |
| Last reviewed | The date the claim was last checked against its source |
The registers live in the two companion sections:
- Claims register — the substantive claims by topic area (company data, product specification, ASTA, COA, testing, certifications, food safety, regulatory, supplier audit, traceability), each with source, status and review date.
- Sources register — the standards bodies, regulations and official publications the site draws on, with the identifier used and a direct link to the issuing organisation.
What this layer does not do¶
- It does not certify anything. A
Standardstatus means "this is what the published standard says", not "our product meets it". - It does not replace certificates, test reports or specifications. Those are issued per order and per batch.
- It does not carry figures the company has not confirmed. Where a company-specific number is still open, it is listed as
Company confirmation requiredin the claims register and tracked in the human verification list.
Why it matters for buyers¶
Three questions decide most paprika purchases: is the specification achievable, is the certificate real, and will the documentation survive an import inspection. A published evidence layer answers them faster than a sales page, and it lets a buyer's QA team check the same sources the supplier used.