Why AI Struggles With HS Code Classification

Ask a language model to classify a product under the Harmonized System and it will return a code, confidently, in the right format. Ask a customs broker to check it and the failure rate is high enough that no serious operation would act on the output unchecked.

The gap is not a model quality problem. It is a mismatch between what the task looks like and what it actually is. HS classification presents as text matching — read a product description, find the closest heading — and it is in fact a rule-governed legal determination with a fixed order of operations. A system designed for the first will fail at the second regardless of how good the underlying model is.

What the Harmonized System actually is

The Harmonized System is the international nomenclature maintained by the World Customs Organization and used by most trading nations to classify goods. Its structure matters for anyone building against it.

The first six digits are international. Chapters, headings and subheadings are common across all members, which is what makes a code portable between countries. Beyond six digits, each country extends the code for its own tariff and statistical purposes, so national codes are longer and are not comparable across borders. A code that is correct for one country's declaration is not automatically the code another country expects.

The nomenclature is revised periodically, roughly every five years, as goods and technologies change. Headings are created, merged and retired between editions. Any system that stores classifications has to record which edition a decision was made under, because a code that was correct is not necessarily correct now.

Alongside the headings sit legal notes at section and chapter level. These notes are not commentary. They are binding text that includes or excludes specific goods from specific chapters, and they routinely override what the heading description appears to say on its face.

Classification follows rules, in order

The General Rules of Interpretation govern how a code is reached. They apply in sequence, and skipping ahead produces a wrong answer even when the final code looks plausible.

Rule 1 establishes that classification is determined by the terms of the headings and by the section and chapter notes. This is the rule that does most of the work and the one most often ignored. The note comes first; the intuitive reading of the heading does not.

Rule 2 deals with incomplete or unfinished articles that have the essential character of the finished good, and with goods presented unassembled. A disassembled machine is still the machine.

Rule 3 handles goods that appear to fall under more than one heading, and it has its own internal order: the most specific description wins; failing that, the material or component giving the good its essential character decides; failing that, the heading occurring last in numerical order applies. Essential character is a judgement, and it is where two competent brokers most often disagree.

Rule 4 covers goods most akin to those already classified. Rule 5 deals with cases, containers and packing materials. Rule 6 extends the same logic to the subheading level, with the constraint that only subheadings at the same level may be compared.

That last constraint is a structural fact a naive system violates constantly. Comparing a four-digit heading against a six-digit subheading is not a close call between two candidates; it is a category error.

Where a plain language model goes wrong

Set a general model loose on this and the failures are predictable.

It matches vocabulary instead of applying notes. A product description containing a material name pulls the model toward the chapter for that material, even where a chapter note explicitly excludes goods of that type. The heading text is visible and persuasive; the exclusion note is somewhere else and gets no weight.

It skips the rule order. The model reaches a plausible code directly rather than working through Rule 1, then 2, then 3 in sequence. Often the answer is right, which is worse than being consistently wrong, because it produces a system that cannot be trusted and cannot be diagnosed.

It produces codes that do not exist. Codes are numeric and structured, which makes them easy to generate and easy to generate incorrectly. A model can emit a well-formed code that has no counterpart in the nomenclature, or one retired in a previous revision.

It has no notion of edition or jurisdiction. Trained on mixed sources from different years and different countries, the model blends national extensions and superseded editions into a single answer without signalling which it used.

It does not ask. Classification frequently depends on facts that are not in the product description — composition by weight, processing state, intended use, packaging for retail sale. A human broker asks. A model fills the gap with an assumption and returns an answer that is correct only under the assumption it did not disclose.

Designing a system that holds up

The workable architecture treats the model as a reasoning component inside a constrained process, not as the classifier.

Ground every candidate in the actual nomenclature. Headings, subheadings and the full text of section and chapter notes are retrieved from a stored copy of the nomenclature at query time. The model never recalls a code from memory. If a code is proposed, it exists, because it came from the index.

Retrieve the notes with the heading, not separately. A heading fetched without its governing notes is incomplete information, and the model will treat the heading text as the whole rule. Chunking should keep the legal context attached to the candidate it governs.

Decompose the task. Determine the chapter, then the heading, then the subheading, as separate steps with separate retrieval. This mirrors the nomenclature's own hierarchy, keeps comparisons at the same level as Rule 6 requires, and makes each step inspectable when the result is disputed.

Validate structurally after generation. Check the proposed code against the nomenclature for the relevant edition and jurisdiction. A code that does not resolve is rejected before the user sees it, not explained away afterwards.

Require the reasoning to name its rule. The output should state which heading text and which notes drove the decision, and which General Rule was applied at the point where alternatives were eliminated. This is not decoration. It is what makes the answer reviewable by someone qualified to overrule it.

Detect missing facts and ask for them. When the distinction between two subheadings turns on a material percentage or a processing state the description does not supply, the correct output is a question, not a code. Systems that always answer are less useful than systems that know when they cannot.

Record the edition and the date. Every stored classification carries the nomenclature edition it was made under and when. Revisions are the normal case, not an exception.

Evaluate against disagreement, not against a key

Accuracy here is a subtler measurement than it first appears, because HS classification is not always a task with one objectively correct answer. Binding rulings from different authorities can differ. Essential character determinations are contested by professionals in good faith.

A useful evaluation set is built from published binding rulings and classification decisions, where the reasoning is on record and can be compared against the system's stated reasoning. Two things are then measured separately: whether the final code matched, and whether the path to it was legitimate. A system that reaches the right code by the wrong route will break on the next product.

The honest framing for the output matters as much as the evaluation. A classification produced by software is a candidate for review by someone with authority to file it. Declaring goods is a legal act with liability attached, and no retrieval system changes who carries that liability.

Where our work sits

Ara, our trade intelligence agent, is in development, and HS classification is one of the problems it is being built to handle — alongside tariff lookup, documentation requirements and route risk, answered from live regulatory sources rather than from model memory. The design follows the structure above: the nomenclature is retrieved, not recalled; the notes travel with the heading; every answer carries its sources so a broker can check the reasoning rather than trust the code.

It is built for the Türkiye–Iran–Caucasus–Central Asia corridor, where the sources that settle a classification question are published by different authorities in different languages — which makes it a multilingual retrieval problem layered on top of a legal reasoning problem.

The general lesson transfers beyond trade. Any domain where the answer is governed by rules with a defined order — tax, licensing, standards compliance — has the same shape. The model is not the classifier. The rules are, and the model's job is to apply them visibly enough that a qualified human can disagree.

https://hublinktech.com/en/ara https://hublinktech.com/en/blog/multilingual-retrieval-ai-search-across-languages https://hublinktech.com/en/blog/rag-vs-fine-tuning-what-each-one-fixes https://hublinktech.com/en/services/applied-ai