How to Review an Existing Tariff Classification with an AI Agent

Start with the decision you need

A greenfield classification asks, “Which code should I use?” An existing-code review asks a narrower operational question: “Does the evidence support this code for this product, place, and exact review version?”

That difference matters. A useful review preserves the supplied code, tests it rather than assuming it is right, researches realistic alternatives independently, and returns one clear outcome.

The four possible outcomes

What to give the agent

• The tariff system or import destination
• The code exactly as it appears in your source record
• For a historical or future review, the classification, entry, or review date that matters; omit it for a current review
• Product facts such as material, construction, function, intended use, processing, dimensions, and composition

With no date, the agent reviews the exact active runtime version and omits effective-time filters. A dated review preserves the supplied date, normalizes a calendar date to midnight UTC for graph calls that accept it, and requires an authoritative date-to-version mapping. Do not add shipment value or other calculation inputs unless a separate duty workflow needs them. This review is about classification supportability and currency, not landed cost.

Reusable canonical prompt

The prompt below is sourced from the same public skill used by the native MCP prompt. Replace the bracketed inputs; keep the evidence and outcome instructions intact.

Review this existing tariff classification using versioned Tariff Code Compliance evidence:

- Tariff system or import destination: [tariff system or import destination]
- Existing tariff code: [existing tariff code]
- Relevant classification, entry, or review date (optional; omit for a current review): [not supplied — use current review mode]
- Known product facts: [known product facts]

First discover the enabled tariff system and exact active runtime version. If the user supplied a destination rather than a system, map it to a returned system only when tool evidence or the selected runtime guide supports that mapping. If no relevant date was supplied, use current review mode: select the discovered exact active runtime version and omit `effective_at`. If a historical or future date was supplied, preserve the supplied value in the report, keep the exact active runtime version separate from the date-applicable version, and require authoritative evidence that maps the date to one exact version. Never infer date coverage from a revision label, version ordering, default status, or the current date. If that mapping is unavailable, ask for exact-version confirmation and return `Insufficient facts`.

Resolve the supplied code exactly, preserving both the user-supplied form and any guide-permitted normalized form. Inspect its declarable or reporting status, hierarchy, descriptions, notes, definitions, exclusions, annotations, relationships, effective-time evidence, and provenance. Independently research realistic alternatives from the product facts and nearby legal structure; do not treat the supplied code, a fuzzy search result, or the closest visible sibling as presumptively correct. For each serious alternative, resolve it exactly and explain why it fits better or why it was rejected. Use only nodes and relationships from the selected exact version. In dated mode, normalize a supplied `YYYY-MM-DD` calendar date to `YYYY-MM-DDT00:00:00Z`, or accept an already-valid RFC3339 instant, and pass that one exact instant only to graph calls whose runtime contract accepts `effective_at`. The current `search_nodes` contract does not accept `effective_at`; use it only to identify candidates, then resolve and inspect serious candidates in the selected exact version with accepted date filters.

Return exactly one primary outcome, using one of these labels verbatim: `Supported`; `Needs review — better alternative identified`; `Supplied code absent or superseded`; `Insufficient facts`. Do not return multiple outcomes, a score, or an unqualified yes/no. Include the supplied and normalized code, exact system and version, review mode, supplied date and normalized `effective_at` when dated, facts relied on, graph evidence and provenance, alternatives considered and rejected, currency/version finding, uncertainty, and focused follow-up questions. When the supplied code is absent, distinguish a confirmed supersession from an unknown code; do not present a nearby result as its replacement without stored same-version evidence. When product facts are insufficient, ask only questions that could change the outcome.

Keep the result non-binding, session-local, and read-only. If a proposed change, unresolved version/date issue, or uncertainty could materially affect declarations, duty exposure, prior entries, or compliance history, recommend review by a qualified customs professional before the user acts.

Use only the customer-facing `reference` and `references` fields returned by Tariff Code Compliance when naming graph evidence. For every relevant recommended, ancestor, candidate, or rejected code and every decisive note, exclusion, term, or annotation, render a Markdown link in the exact form `[<reference.label>](<reference.url>)` only when `reference.url` is present, substituting both values verbatim from that returned reference. When `reference.url` is absent, show `reference.label` as plain text with readable official provenance; never guess or hand-build a link. Never print or transform node IDs, `system_version_id`, source or storage keys, UUIDs, or page or continuation tokens, including values beginning `ent:`, `sysv:`, or `NATIONAL_`. If an entity-specific reference is unavailable, use the returned exact system/version reference under the same URL-present rule; do not expose the opaque value.

You can also inspect the complete Review Existing Classification skill.

End-to-end example: review a live donkey code

In an observed production-equivalent sandbox evaluation, ChatGPT and Claude independently returned the same single outcome: Supported. The review selected US_HTS 2026-rev-16, system version sysv:US_HTS:US:2026-rev-16. It preserved the supplied date 2026-08-21 and normalized it to 2026-08-21T00:00:00Z for graph calls whose runtime contract accepted effective_at.

Exact resolution returned ent:code:US_HTS:US:2026-rev-16:NATIONAL_10:0101300000, a declarable NATIONAL_10node described as “Asses.” The hierarchy was Section I > Ch 01 > 0101 > 0101.30 > 0101.30.00 > 0101.30.00.00. The provision carried provenance digest source-manifest:9814e20dc6d663304995431041078f1c3300814cc7bab16da7ce9d4b8a300f3f at locator exportList[8].

Chapter 1 note locators #note-1 through #note-4 excluded categories that did not match the stated animal. U.S. Note 2 at #note-6 raised a special Chapter 98 context, but the supplied facts did not establish that context. The independent alternative review rejected 0101.21 and 0101.29 because those provisions cover horses, and rejected 0101.90 because it covers mules and hinnies.

The remaining uncertainty was whether special heading 9508 or Chapter 98 facts existed outside the supplied record. With no such context established, the ordinary-code finding remained Supported. The result was session-local, read-only, and non-binding; it did not change a record or calculate duty. The handoff recommended that a qualified customs professional verify the evidence before it is used for a material declaration or compliance decision.

Observed on August 21, 2026 in the production-equivalent TCC sandbox. A later review must report the exact version, nodes, locators, and product facts it retrieves rather than reusing this result as a binding ruling.

How to interpret the evidence

When to hand the result to a customs professional

The agent's review is useful research, not a binding ruling. Ask a qualified customs professional to review the evidence before acting when a proposed change could affect declarations, prior entries, compliance history, or material duty exposure; when an exclusion or legal note remains ambiguous; or when the relevant date cannot be tied to an authoritative tariff version.

A strong handoff includes the supplied and normalized code, exact system/version/date, facts relied on, node and relation paths, official locators, alternatives and rejections, uncertainty, and the focused unresolved question. That gives the specialist something concrete to verify.

Keep the workflow read-only

Reviewing a code does not approve a replacement, update a product, amend an entry, or create a durable proposal. The user decides what to do next after reviewing the evidence and, when material, consulting a qualified professional.

For a product that has no existing code, use the greenfield classification workflow. For calculations after the ordinary code is already decided, use the separate Calculate Duty skill.