How to flag a Sourzi error, and what we do about it

The 9 May 2026 internal audit of the regulatory dataset found thirteen confirmed factual errors. That number was not zero and is unlikely to ever be zero. The discipline at /methodology reduces the error rate; the discipline below catches and fixes the residual.

How to flag an error

Email corrections@sourzi.com with the URL of the page, a one-line description of the claimed error, and the primary source that contradicts the Sourzi entry. The most useful messages name the specific fact (case number, regulation reference, listing date, percentage, producer plus city), point at the line where Sourzi asserts it, and link to the EUR-Lex, ECHA, OEHHA, USITC, OSHA, IARC, or company-website page that gives the binding state. We will acknowledge every email; we will not engage with messages that do not name a specific fact.

The same channel handles a constructive disagreement on framing rather than fact. If a Sourzi entry calls a Chinese supplier's quote "almost always cheaper" on FOB versus CIF and the operator's experience disagrees, the explanation goes into the email. We will respond with the supporting rationale or amend the entry. Practitioner disagreement is genuinely useful.

What we do about it

Acknowledgement: within 72 hours of receipt, the corrections team will reply confirming we have the report and have begun verifying.

Fix: within 7 days of the acknowledgement, the published page will reflect either the corrected fact (with the primary-source link) or a hedge of the form "(verify against current [primary source name] before invoicing)" if the binding state cannot be locked within the window. We do not leave a known-wrong fact published while the fix is in flight; the page goes to a hedge in the interim.

Public log: every fix is recorded in the correction log below, with the date logged, the date fixed, the reporter (or "Internal audit" if found by Sourzi), the severity tier, the affected URLs, and a link to the fix commit. The log is part of the published surface, not an internal record.

Severity tiers

Critical: wrong fact that directly causes a customs entry failure, an anti-dumping cash-deposit error, a REACH authorisation error, or a workplace exposure-program error. Examples: wrong AD case number, wrong Annex XIV inclusion, wrong OSHA PEL. Critical corrections get same-day acknowledgement and 24-hour fix where the primary source is available.

Material: wrong fact that misleads landed-cost modelling, sourcing-decision modelling, or compliance-program scoping but does not directly trigger a customs or workplace failure. Examples: wrong percentage rate, wrong listing date, wrong producer-site pair. 72-hour acknowledgement and 7-day fix.

Editorial: writing-quality fix that does not change the operative meaning. Examples: typo, broken link, voice drift toward LinkedIn cadence, kill-list phrase that slipped through. 7-day fix; not always logged publicly (link breakage and typo fixes are silent).

Version history

Every regulatory-dataset entry carries an updatedDate field in the source. When a substance entry is updated, the date moves and the change is committed with a descriptive message. The git history for the repository is the version history; we will not retro-edit a published assertion without leaving the change visible. For material and critical fixes, the public correction log below is the operator-facing summary.

What we will not do

We will not silently amend a critical fact without leaving the public log entry. We will not respond to messages that ask for content removal without naming the fact at issue and the binding primary source. We will not back-fill stale data when an upstream primary source goes through a structural change (403 from ECHA, MOF site reorganisation); we will hold the snapshot date visible and point the reader at the primary source for the binding state. The voice and sourcing discipline at /editorial-policy applies here too.

Public correction log

The entries below are the published corrections to date. Each row links to the fix commit in the public repository. Empty is the honest state until the first reported error has been logged; the audit history that pre-dates this policy lives in the internal REGULATORY-AUDIT.md document.

If we get it wrong twice

A reported error that recurs after the public fix means the verification process upstream of publication missed a class signature. When that happens, we treat it as a methodology fix rather than a one-off page edit: the next version of the audit checklist at /methodology picks up the gap, the Pro tool dataset refresh scripts get the extra guard, and the recurring-class signature is documented in the public log as a process correction rather than just a content correction. The published surface gets smaller before it gets larger; we will not paper over a process gap with a content patch.

Compliance team and counsel

A correction request from a counterparty's compliance team or external counsel is routed through the same channel. Where the request alleges defamation, trade-mark or copyright infringement, or unauthorised disclosure of confidential information, please copy a brief and identify the cease-and-desist basis along with the contested fact. We will engage in good faith on factual correction; we will not remove a sourced, accurate fact in response to a takedown without an evidentiary basis. The Australian Defamation Act 2005 (or its state-by-state equivalents) and the Privacy Act 1988 govern our response; we do not represent that they are the only frameworks in scope.

Related

The verification methodology that catches the failure earlier is at /methodology. The voice and sources discipline that shapes the published content is at /editorial-policy. The Pro tools that direct operators to the binding primary sources (US AD/CVD, EU REACH SVHC plus Annex XIV, EU CBAM scope, US HTS plus Section 301, China VAT export rebate, Korea KCS plus KCFTA plus RCEP, AU anti-dumping, DFAT sanctions, AICIS inventory) sit under the Pro section of the tools hub.