Review workflow
How to audit an HTS classification
A reviewable classification audit ties product facts, exact-version tariff evidence, rejected alternatives, uncertainty, and reviewer state together.
Inputs a reviewer needs
- The code already in use, destination, and claimed tariff-system version.
- The product facts that distinguish realistic candidates: material, construction, function, intended user, composition, and presentation.
- The original rationale, source links, decision date, assumptions, and known changes to the product or schedule.
Audit flow and record
- Resolve the available tariff systems and the exact release being reviewed.
- Confirm the supplied code exists in that exact version and inspect its hierarchy and governing notes.
- Search for realistic alternatives and record why each was selected or rejected.
- Record assumptions, uncertainty, missing facts, evidence URLs, and the reviewer state.
- Escalate when the available facts do not support a defensible conclusion.
Reviewer state should be explicit: unreviewed, needs facts, reviewed, or escalated. A generated recommendation is not the same as human approval.
When a classification is not defensible
Do not defend a result when a material product fact is missing, the cited code does not exist in the claimed version, the evidence belongs to another release, a plausible alternative has not been examined, or the rationale conflicts with the hierarchy or notes.
The public API currently designates 2026-rev-16 as the default U.S. HTS release. Inspect the exact release; do not silently substitute it for a historical release under audit.
See the synthetic evidence packet and the version guide.