--- name: review-existing-classification description: Review whether an existing tariff classification is supported, current, or better replaced using versioned tariff evidence and product facts. Use when a user already has a code and wants a read-only second opinion; do not use for greenfield classification or duty calculation. --- # Review Existing Classification Use this workflow when the user already has a tariff code and wants to know whether the available versioned evidence supports continuing to use it. The result is session-local research support, not a binding ruling, legal advice, an automatic reclassification, or permission to change a customs, catalog, or product record. ## Boundaries - Require an existing code plus either its tariff system or import destination. Gather the product facts needed to distinguish the supplied provision from realistic alternatives. Accept a relevant classification, entry, or review date when the user needs a historical or future review; otherwise use current review mode. - Tariff Code Compliance tools only read tariff evidence. Do not create or update a proposal, product, customs entry, Shopify record, or other durable state. - Review the supplied code before considering alternatives. Do not silently turn this workflow into greenfield classification. - Never mix nodes, edges, notes, or provenance from different tariff-system versions. Treat the exact system, version, and review mode as part of the finding. - In current review mode, use the exact active runtime version returned by discovery and omit `effective_at`. Do not claim that this proves what governed a historical or future date. - In historical or future review mode, do not infer that a version covers the supplied date from a revision label, ordering, default status, or the current date. If discovery and the runtime guide do not establish an authoritative date-to-version mapping, ask the user to confirm the exact version or provide that mapping. - Preserve a user-supplied calendar date in the report. For a graph call whose runtime contract accepts `effective_at`, normalize `YYYY-MM-DD` to `YYYY-MM-DDT00:00:00Z`, or accept an already-valid RFC3339 instant, and use that exact instant consistently. Do not pass `effective_at` to a graph call whose runtime contract does not accept it. - Normalize punctuation or spacing only when the selected runtime guide permits it. Always preserve and report the code exactly as supplied alongside any normalized form used for resolution. - Treat authored annotations such as `tcc.annotation` as commentary, not source tariff law. Identify their author and provenance separately from official source text. - Do not calculate duty, rates, fees, taxes, or landed cost in this workflow. - Send only product and tariff facts needed for the review. Do not send personal information, credentials, authentication secrets, or unrelated commercial data. ## Starter request The native MCP prompt and public skill use the request delimited below. 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 `[]()` 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. ## Workflow 1. Confirm the existing code and either its tariff system or import destination. Gather the product facts the supplied provision appears to depend on. If the user is reviewing a historical or future classification, entry, or event, gather that relevant date; otherwise record that the review is current. Do not ask for shipment values or other duty-calculation inputs. 2. Call `list_tariff_systems`. Select only a returned system and exact version. When the input is a destination, require tool or guide evidence for the destination-to-system mapping. Always record the exact active runtime version. 3. Call `describe_tariff_system` for the selected exact version. Treat its profile and `guide_markdown` as the contract for identifiers, normalization, node kinds, hierarchy, relations, declarable/reporting status, effective-time fields, annotations, and source provenance. 4. Select one review mode: - **Current:** no relevant date was supplied. Use the discovered exact active runtime version. Omit `effective_at` from every graph call. - **Historical or future:** a relevant date was supplied. Preserve that value in the report. Normalize a `YYYY-MM-DD` value to `YYYY-MM-DDT00:00:00Z`, or accept an already-valid RFC3339 instant. Use explicit validity metadata or authoritative graph evidence to map the date to one exact version. If that mapping is unavailable, stop with `Insufficient facts`; do not substitute the active runtime version. 5. Resolve the supplied code exactly with `resolve_nodes`, using guide-permitted code normalization. In dated mode, pass the one normalized instant as `effective_at` only if the selected runtime contract accepts it. Record the original code, normalized code, resolution result, node kind, and declarable/reporting status. 6. If the supplied code does not resolve in the selected exact review version, use exact-code checks in other available versions and stored replacement, successor, or supersession relationships only to determine whether it is unknown, absent in this version, or explicitly superseded. Do not use fuzzy search to invent a replacement. Return `Supplied code absent or superseded` only after the current-version or dated-version boundary is established; otherwise return `Insufficient facts`. 7. For a resolved code, use `get_node`, `list_node_edges`, and bounded `traverse_nodes` to inspect the complete decision-relevant path: ancestors, descendants needed to assess reporting specificity, descriptions, notes, definitions, exclusions, inclusions, annotations, effective-time evidence, and official provenance. Follow only relations described by the runtime guide. 8. Independently research realistic alternatives. For a discovered `US_HTS` system and exact review version, use `search_hts` for lexical provision and note discovery and `semantic_search_hts` separately for conceptual product descriptions. Use `search_nodes` for classification prefixes or terms, not as a universal notes search. None of these searches accepts `effective_at`; resolve and inspect each serious candidate exactly in the selected review version. In dated mode, apply the same normalized instant to each later candidate call whose runtime contract accepts `effective_at`. Check relevant siblings and competing headings rather than merely validating the supplied path. Reject an alternative only with product facts or graph evidence. 9. Choose exactly one outcome: - `Supported`: the supplied code resolves in the selected current or date-applicable exact version, is an appropriate declarable or reporting node, the relied-on product facts support its legal path, and no researched realistic alternative is better supported. - `Needs review — better alternative identified`: the supplied code resolves, but a contradiction, exclusion, specificity problem, or independently researched alternative is better supported by the stated facts. Present the alternative as non-binding research, not an automatic replacement. - `Supplied code absent or superseded`: the selected current or date-applicable exact version is established and the supplied code does not resolve there, or stored official evidence explicitly identifies it as withdrawn, replaced, or superseded. State whether a successor is proven or merely unknown. - `Insufficient facts`: missing product facts prevent a defensible comparison, or the system or selected exact version cannot be established. In dated mode, this also applies when the relevant date cannot be mapped authoritatively to one exact version. Ask only focused questions that could change the outcome. 10. Stop once the single outcome is supported by traceable evidence and every serious alternative is either compared or explicitly left unresolved. ## Decision cases - Current supported case: no relevant date is supplied, an exact declarable code resolves in the discovered exact active runtime version without `effective_at`, the product facts satisfy its hierarchy and notes, and the independent alternative search finds no better-supported provision. Outcome: `Supported`. - Dated supported case: a relevant date is authoritatively mapped to one exact version, an exact declarable code resolves there using the same normalized `effective_at` on supported calls, the product facts satisfy its hierarchy and notes, and no researched realistic alternative is better supported. Outcome: `Supported`. - Better-alternative case: the supplied code resolves, but the stated material, construction, function, or other legally relevant fact supports a different exact provision and contradicts or excludes the supplied path. Outcome: `Needs review — better alternative identified`. - Absent-code case: the selected current or date-applicable exact version is established and exact resolution returns no supplied code, or official graph evidence shows a successor. Outcome: `Supplied code absent or superseded`. - Version/date-mismatch case: the active runtime version is known but available evidence does not prove that it applies to the relevant historical or future date. Outcome: `Insufficient facts`, with a focused exact-version or authority question. - Insufficient-information case: the code resolves, but missing decision-relevant product facts prevent comparison with realistic alternatives. Outcome: `Insufficient facts`, with only the questions that distinguish those paths. ## Response contract Return these fields in a reviewable structure: - **Outcome:** exactly one of the four labels above. - **Supplied code:** the user's exact input. - **Normalized code:** the guide-permitted form used for resolution, or `Not normalized`. - **System, exact version, and review mode:** for a current review, report the exact active runtime version and state that `effective_at` was omitted. For a dated review, preserve the supplied date, report the normalized RFC3339 `effective_at`, distinguish the active runtime version from the date-applicable version, and explain the authoritative evidence for their relationship. - **Facts relied on:** only facts that affected resolution, support, or alternative comparison; identify assumptions separately. - **Graph evidence:** readable linked references, hierarchy and relation paths, decisive notes, definitions, inclusions or exclusions, declarable/reporting status, annotations identified as commentary, source URLs or locators, and provenance. - **Alternatives considered:** each serious candidate, its exact code and readable linked label, and the evidence-based reason it was preferred, rejected, or left unresolved. - **Currency/version finding:** whether the supplied code is present and supportable in the selected current or date-applicable exact version, absent, explicitly superseded, or not verifiable because a dated review lacks an authoritative date/version mapping. - **Uncertainty:** material evidence limits without invented confidence scores. - **Focused questions:** `None` when the outcome is fully supported; otherwise only questions whose answers could change the outcome. - **Boundary and handoff:** state that the review is session-local, read-only, non-binding research support. Recommend a qualified customs professional before action when the result or uncertainty is material. ## Tool discipline 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 `[]()` 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. - Use the exact `system` and selected exact `version` on every version-scoped call. In current review mode, omit `effective_at`. In dated mode, use one normalized RFC3339 instant consistently, and pass it only to graph calls whose selected runtime contract accepts `effective_at`. - Under the current runtime contract, call `search_nodes` without `effective_at`. Treat its results as candidate discovery only, then exactly resolve and inspect serious candidates in the selected version with date filters on calls that accept them. - HTS searches are US-specific and have no date filter or pagination input. Pin the exact review version, and use optional `scope: {type: "general_note" | "gri" | "chapter", number: string}` only when justified. `"*"` covers the general-note or chapter family, not GRI; `chapter` with `number: "*"` and `kinds: ["note"]` covers chapter and section notes. Scope intersects kinds before ranking. - Ranking and similarity are discovery signals, not support for the supplied code or its replacement. Empty results or an unavailable selected-version index are evidence gaps, not proof that no alternative exists. Never silently change the version, destination, or search mode to conceal a gap; do not promise systems absent from discovery. - Treat opaque node IDs and continuation tokens as tool-call inputs only, never customer-facing evidence. - Follow continuation tokens only when another page is needed to evaluate the supplied code or a serious alternative. - Respect traversal bounds. If a result is truncated, narrow the relation, direction, or starting nodes. - Cite official source URLs and locators returned by the graph when available. Clearly distinguish official source text, authored annotations, and model interpretation. ## First response and account recovery Ask for the missing existing code, destination or system, or most consequential product fact; do not ask the user to repeat supplied information. Lead a completed review with its outcome and practical reason, not internal tool terminology. If a research tool is denied for account access or credits, call `get_account_status` on the existing connection. Explain its safe `access_message` and returned `profile_url`; do not expose account IDs. Pause paid research calls until a fresh status confirms access and credits are available. If status itself is unavailable, explain the blocker without guessing the balance or retrying paid tools. For an authentication failure, direct the user to reconnect through the client's normal connection controls. Never request passwords or tokens, send verification emails, buy credits, or change billing or authentication settings.