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

  1. Resolve the available tariff systems and the exact release being reviewed.
  2. Confirm the supplied code exists in that exact version and inspect its hierarchy and governing notes.
  3. Search for realistic alternatives and record why each was selected or rejected.
  4. Record assumptions, uncertainty, missing facts, evidence URLs, and the reviewer state.
  5. 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.