How the AI classifies goods

How our classification AI works today and where we're taking it: model choices, the classification reasoning structure (GRI), how GRI mixes with CROSS rulings, the data strategy, and the improvement roadmap.

---

Part 1 — Cross-cutting AI principles (all agents)

These hold for every agent (classifier, extractor, screener, …).

• Grounded, not freeform. Every agent is grounded on real, live data (HTSUS, CROSS, sanctions lists) and cites its basis. In a regulated product the audit trail is the feature.
• Human-in-the-loop. The AI proposes; a licensed broker approves. Confidence routes low-certainty work to review. We never auto-file.
• Closed feedback loop — every broker correction improves the system. This is core, not incidental. Each override is captured and fed back two ways: (1) as few-shot precedent in the classifier prompt, so the next matching line defers "per recent broker precedent"; and (2) into the eval gold set, so measured accuracy reflects production signal. The system learns from your data with use — and that learning is segregated to your own organization by default: corrections are scoped per-org, never pooled across customers (contributing to a shared model is opt-in). Mechanically it happens at the data/prompt layer — few-shot precedent, not weight retraining — with fine-tuning a future lever (see below). Verified end to end: a single broker correction on a navy-chinos line changed the model's next prediction on the matching line. The highest-authority future signal is CBP's own verdict (CF28/CF29), gated on ACE. As-built mechanism: HTS Classifier → Feedback loop.
• Your data improves your classification — privately by default. Each customer's broker corrections improve their own classification, segregated by organization (shared is opt-in, never the default). "Improving the model" means a better retrieval corpus, a better prompt/reasoning structure, and the broker-correction feedback loop above. Today that learning is retrieval + few-shot precedent rather than weight fine-tuning; fine-tuning is a future mechanism for the same promise (triggers in Part 2).
• Model choice is empirical. We pick models by eval, not reputation. The current default is Sonnet 4.6, thinking: disabled, effort: low — chosen because it matched the larger model on accuracy at lower latency, and because adaptive thinking was truncating structured output. Revisited per agent when the eval says so.
• Measure before believing. Every change ships behind the eval harness, and the number we quote is the number the harness reproduces — never an aspirational figure.
• Structured, validated output. Outputs are JSON validated against a schema (e.g. Zod rejects any HTS code not in the live HTSUS → 0% hallucinated codes).

---

Part 2 — HTS Classifier: methodology & roadmap

Goal: product description (+ material, use, value) → the correct 10-digit HTSUS code, with a calibrated confidence, a cited, GRI-structured justification, and 2–3 alternatives for the broker.

2.1 Model

Sonnet 4.6, thinking disabled, effort low (see Part 1). The classifier is retrieval-grounded and broker-supervised, so the model's job is disciplined selection + reasoning over a strong context, not open-ended recall. Target: a gated "thinking-on" reasoning pass for the ambiguous minority (see 2.3 / 2.4).

2.2 How GRI comes into play (the reasoning structure) — target

The General Rules of Interpretation (GRI 1→6) are the legally mandated framework in the HTSUS General Notes. They must become the classifier's explicit reasoning structure, not an implicit side-effect. Applied in sequence, stopping at the first rule that resolves:

• GRI 1 — classify by the terms of the headings + Section/Chapter Notes. If a heading and its notes clearly cover the good, stop.
• GRI 2(a) — incomplete/unassembled but has the essential character of the finished article → classify as finished.
• GRI 2(b)/3 — competing headings: 3(a) most specific wins; else 3(b) essential character; else 3(c) heading last in numerical order.
• GRI 4 — most akin (rare). GRI 5 — packaging/containers.
• GRI 6 — repeat 1–5 at the subheading level (where the 8- and 10-digit choice is legally made).

Four structural changes to make GRI native (design detail; all target):

1. Feed GRI-1 inputs — Section & Chapter Notes. GRI 1 needs the Notes (the include/exclude rules), which we do not retrieve today. Ingest the HTSUS Section/Chapter Notes (public domain; not in the current exportList — a real new ingest) and attach them to the candidate set. Do not ingest WCO Explanatory Notes (copyrighted) without a licence.
2. Scaffold GRI 1→6 in the prompt — replace the ad-hoc ambiguity cues with the sequence above.
3. Capture the GRI path as structured, auditable output — turn freeform rationale into a gri object: resolved_at, path[], notes_cited[], essential_character{determinant,reason}, subheading_logic. This is the audit artifact and a scorable eval target.
4. Two-pass execution — Pass A (current, cheap) for clean GRI-1 hits; Pass B (thinking-on GRI adjudication over top candidates + their Notes) only for low-confidence/competing-heading cases, with a final JSON-formatting step so reasoning tokens never truncate the answer. This keeps blended cost flat and is the generalized form of the existing "self-explain pass for <70% confidence" idea.

2.3 How GRI mixes with CROSS rulings

They are complementary, not competing. CROSS gives you how CBP applied the GRIs to a similar good; the GRI engine gives you the method when no ruling fits and the structure to explain any answer. Authority order stays: a matching broker correction or CROSS ruling is the GRI-1 evidence ("heading terms + notes, as CBP already applied them in NY N123456"). The strongest output cites both: "GRI 1 + Chapter 64 Note; consistent with NY N123456."

2.4 Retrieval

Per line, in parallel: top-40 HTSUS candidates (Postgres FTS over walked-up descriptions + a consumer→tariff synonym map) + top-5 CROSS rulings + broker- correction few-shot. Target: attach Section/Chapter Notes to candidates (2.2); add pgvector semantic retrieval only if the eval shows candidate recall (right code absent from the 40) is the ceiling — gated behind the CROSS expansion below.

2.5 Data & training strategy

For a RAG + few-shot system, what improves the model is the retrieval corpus + broker-correction few-shot + eval sets — each customer's own corrections train their own classification (segregated by org), while weight-level fine-tuning stays a future lever (§2.8), not a prerequisite.

Bottom line: the cheapest, highest-impact data work is expanding the CBP rulings corpus we already own and capturing broker corrections — both free. Paid external data is a later lever for eval realism, not a prerequisite.

2.6 Eval — how we measure accuracy

We measure the classifier against held-out CBP rulings: the ruling that would confirm the answer is excluded from retrieval, so the model has to reach the code from the description alone. Every case is scored at three levels of precision — heading, subheading, and the exact 10-digit code — and we run the same set with and without RAG so the contribution of retrieval is measured, not assumed.

What the eval consistently shows:

• Grounding on CBP's binding rulings measurably improves accuracy, with the largest gains on the part of the tariff where our rulings corpus has coverage — which is exactly why expanding that corpus is the top data lever (§2.5).
• Zero hallucinated codes. Schema validation rejects any code absent from the live HTSUS, so the model cannot invent a heading.
• Confidence is calibrated and honest at the heading level, and deliberately more cautious at the exact-10 level — where the 8- and 10-digit choice is hardest — so those lines route to broker review rather than post a false certainty.
• Every classification cites the ruling(s) it relied on, so a broker checks the basis instead of trusting a number.

We re-run the harness after any prompt, model, or retrieval change, and the number we quote is the number the harness reproduces — never an aspirational one.

Target: add a GRI-trace check (does it cite the right rule + Note?) using the flexify reasoning paths as reference.

2.7 Classifier roadmap (ordered by impact ÷ effort)

2.8 Fine-tuning — deferred; the triggers

Published benchmarks show even a fine-tuned classifier still falls well short of removing the broker from the loop, so ROI today is low vs. retrieval + feedback. Revisit (likely a self-hosted open model) when any of: a design partner requires data residency (a self-host also resolves the API data-exposure flagged for SOC 2); accuracy plateaus despite retrieval/feedback gains; or API cost at scale exceeds a self-hosted model.

---

Part 3 — Invoice Extractor: methodology & roadmap

Goal: commercial invoices / packing lists / BoLs → structured line items (description, qty, value, origin, HTS if present) that feed the classifier.

• Schema-first, each field with confidence + source location (audit).
• Grounding: vision-LLM over the document; same model family as the classifier.
• Roadmap: (a) target — build a labeled-invoice eval harness (today extraction is unmeasured, which silently caps end-to-end accuracy); (b) target — description enrichment so thin lines carry material/construction/use before classification (materially improves downstream accuracy); (c) per-supplier templates for high-volume senders.

---

Part 4 — Other agents (intent stubs)

Filled in as each is built; each gets a full implementation doc under agents/ when live.

• Screening agent (target) — LLM-rank fuzzy sanctions matches with rationale (name/address/DOB/programs); today screening is deterministic pg_trgm. Next natural build.
• Duty calculator (target) — landed cost incl. Section 301/232/IEEPA; depends on Section 301 ingest.
• Post-entry audit / risk modeler (target) — anomaly detection on filed entries.

---

What we deliberately DON'T do (yet)

• Fine-tune model weights / self-host — deferred; the learning today is few-shot + retrieval, segregated per org. Triggers in 2.8.
• Pool one customer's data into another's model — never. Corrections are org-scoped; a shared/collective model is strictly opt-in.
• Treat purchased shipment/BoL data as a weight-training set — it's a future eval/retrieval asset only.
• Embeddings retrieval — FTS + synonyms until recall is the proven ceiling (gated after CROSS expansion).
• Multi-line joint classification — each line independent, errors contained.
• Quote accuracy we can't reproduce — the harness number is the number.

---

Sources

• GRIs: HTSUS General Rules of Interpretation (General Notes). CROSS rulings are GRI applications: https://rulings.cbp.gov/
• ATLAS benchmark & dataset: https://arxiv.org/abs/2509.18400 · https://huggingface.co/datasets/flexifyai/cross_rulings_hts_dataset_for_tariffs