Confidence tiers: verified, benchmark, fallback
Every input in a Qootna result carries a source kind and a confidence tier. Here's what each tier means, why we label them this way, and what changes for the operator when an input drops a tier.
A planning surface that mixes verified contract data with broad benchmarks with literal fallbacks, and presents the result as a single number, is a liability waiting to happen. The auditor will find the fallback. The budget committee will ask. The operator should have known.
Qootna labels every input explicitly. Three source kinds, three confidence tiers, both visible on every line in the breakdown.
Source kinds
Verified — the input came from an authoritative, recent, contract-grade source. A live carrier rate. A published port tariff under a specific Q. A government-published duty schedule. The criterion is attributability — we can name the source on a slide.
Benchmark — the input came from a published rate, average, or index that is not contract-grade but is widely accepted and recent. Carrier-published THC averages by country. Country-level customs fees. Drewry-style indices. The criterion is industry-accepted reference — the kind of number a procurement professional would expect to see in a benchmark conversation.
Fallback — the engine could not resolve a verified or benchmark input and used an explicit fallback rule. Often $0 with a labelled reason: tariff_rate_not_loaded, tariff_toggle_not_enabled. The criterion is honest no_data — we tell you the field was unresolved, render the math at 0 (or the documented fallback value), and label the line accordingly.
The verified → benchmark → fallback ladder is monotonic in defensibility. A buyer can act on a verified line, can negotiate on a benchmark line, and must verify a fallback line before commitment.
Confidence tiers
Source kind is what kind of data it is. Confidence tier is how strong the inference from that data is.
High — single recent source, clean read, no exclusions. Medium — recent but published rather than contract, or single source with caveats. A country-level port handling charge applied to a specific port is medium because the granularity is below the geographic scope of the source. Low — fallback, missing input, or blocked-mode short-circuit. A chokepoint-blocked branch always emits confidence low regardless of how good the benchmark resolver was — because the operational answer is "this doesn't execute".
The two axes interact. A line can be verified-medium (real contract, narrow geography). It can be benchmark-medium (good published source, applied to a country rather than the specific port). It can be fallback-low (no data, explicit placeholder).
Why it matters at the line level
The breakdown card renders one row per cost component. Each row carries a colour-coded confidence dot, a source-kind badge, and a tooltip with the reason string. A line that reads "Tariff: 0% (tariff_rate_not_loaded for this corridor — verify with importer/customs broker)" tells a planner everything they need: the math is 0, the reason is honest, the next action is on them.
A single landed-cost number with no decomposition would have rendered the same line as a clean $0 and the planner would have committed to a number they could not defend.
Why this isn't just a UI choice
The engine emits source kind and confidence at the resolver layer, then the rendering layer reads them. That separation matters. A future PDF export, an admin audit log, a CSV download, a future API consumer — all of them get the same labels because the labels live with the data, not with the component.
If we were going to compromise on any property of the engine to ship a feature faster, this would not be one of them.