Tariff math without the TradeMap detour
Tariff resolution sounds simple — HS code in, ad-valorem rate out. In practice it's a forest of corridor-specific exceptions, partial coverage, and quietly-zero defaults. Here's how Qootna handles the gaps without lying.
A buyer asks: what's the tariff on shipping this HS code from origin A to destination B? Most tools answer with a number. Sometimes that number is right. Often it's stale, or wrong-corridor, or silently zero because the lookup missed.
Tariff math is one of those problems that looks like a database join and behaves like a research project.
Why it's harder than the join
Coverage — public datasets cover most major economies, but the granularity drops for small trade flows and recent rate changes. A WITS extract from last quarter may already be wrong on a corridor where a trade agreement just landed.
Scope drift — the corridor in the dataset may be a regional bloc; the corridor in the quote may be country-to-country. Joining them silently is a category error. We render the line as the dataset gives it and label the scope explicitly.
Toggles — tariff is on or off per analysis, depending on the trade-restriction profile, the buyer's filing posture, and the engagement's contractual terms. The engine respects an explicit toggle rather than guessing.
Defaults — when a corridor is unresolved, the math runs at 0%. The temptation is to leave the line blank or render a clean "no duty applies" message. Either choice is a quiet lie; the corridor probably does attract duty, we just don't have it loaded.
What we render instead
When a tariff cannot be resolved, the line renders explicitly:
Tariff (TD) $0/MT
⚠ tariff_rate_not_loaded — calculated at 0%.
Verify with importer / customs broker.
Confidence dot: low. Source kind: fallback. Tooltip: the full reason string. The calc still runs (so the rest of the breakdown is internally consistent), but the operator sees the placeholder for what it is.
When the tariff toggle is off — for example a quote scoped to FOB only — the same line renders with reason tariff_toggle_not_enabled and the same low-confidence labelling. We don't pretend the absent line is a zero rate; we tell the user the toggle is off.
What "verified" looks like
When the corridor + HS pair is loaded, the line renders with the source row, the ad-valorem percentage, the resulting per-MT value, and the source kind (verified or benchmark depending on the row's scope and recency). Confidence tier follows the standard rules.
No magic, no smoothing, no imputation. The number on the line is the number from the resolver, applied to the CIF basis (which itself includes insurance, per the engine's CIF semantics).
Why this matters
Tariff is one of the line items where a wrong number is genuinely dangerous. A budget committed against a hidden 8% duty rate that the engine quietly zeroed will blow the budget on first delivery. A budget committed against an explicit "tariff_rate_not_loaded" placeholder will trigger a verification step before commitment.
The two outcomes look the same on a spreadsheet. They look very different at the audit committee.
Coming next
The WITS / UNCTAD ad-valorem resolver continues to expand. Coverage improves as we backfill corridors and as more recent rates land. The line-rendering contract — explicit placeholder when unresolved, full decomposition when resolved — does not change as coverage grows.
Tariff math without a quiet zero. That's the contract.