Why our model is forbidden from inventing codes

Rule number one of our customs tool, Urgenth, is simple: the model gets no free rein. It does not generate Harmonized System (HS) codes out of thin air. It is architecturally blocked from doing so. Every digit it outputs must exist in the real world first.

In a consumer chat app, hallucination is a joke or a minor bug. At a customs desk, a hallucinated code is an immediate compliance incident. A wrong HS code leads directly to an incorrect duty rate. Importers end up overpaying duties, underpaying duties, or facing severe penalties during audits.

In our previous field note, we argued that vertical knowledge must come before AI. This article shows how that principle translates directly into architecture. We do not ask the model to memorize the tariff schedule. We force the model to operate inside hard, verifiable boundaries.

Urgenth takes a raw product description and produces a valid HS classification. Instead of asking an LLM to predict the final ten-digit code in one shot, we split the workflow into distinct stages. The model is never allowed to bridge the gap between description and code on its own.

In the first step, the AI reads the product description and extracts only tariff-relevant terms. It identifies key classification attributes: material composition, technical specifications, and intended function. It does not guess an HS code at this stage. Its only job is turning messy supplier text into clean classification parameters.

Next, our system takes those extracted parameters and queries the official USITC public API. We search the live US Harmonized Tariff Schedule database to pull real candidate codes. This query retrieves the relevant 4-digit heading subtree along with all legal subheadings. These candidate codes are real, active, and legally defined.

Then, and only then, the model returns to make a decision. We pass the candidate subtree and the original product details back to the model. The model is strictly constrained to choose an option from that retrieved list. It cannot edit the numbers, combine different codes, or invent a new branch.

If the candidate list does not contain a matching code, the model cannot guess. Once the model selects a valid path from the candidate set, our system takes over again. The system parses the exact duty rates for the chosen subcodes directly from the official data. The model never generates the duty rate.

Many engineering teams avoid high-stakes enterprise domains like customs, trade, and tax. They look at the baseline error rates of LLMs and conclude the risk is too high. They assume building in these spaces requires waiting for a model that never hallucinates.

That assumption is wrong. You do not solve high-stakes accuracy by fine-tuning prompts or asking the model to think step-by-step. You solve it by replacing free generation with constrained retrieval. When the system controls the candidate pool, the failure modes become predictable and manageable.

What matters in production is not how creative the model is, but whether you fence it in. A foundation model has no internal sense of customs compliance. It will generate an invalid eight-digit tariff code with the exact same confidence as a real one.

The fence cannot come from the model. The fence is built by engineers who know the domain and wire deterministic data sources around the model. In Urgenth, the USITC database sets the boundaries. The model makes choices inside those boundaries, and nowhere else.