Reading the Hormuz signal: what a closed chokepoint really costs
A closed chokepoint is not a freight surcharge — it's a route that doesn't execute. Here's how Qootna separates the executable cost from the published benchmark, and why that distinction is load-bearing for planning.
When a major chokepoint goes hot, the natural product instinct is to add a fuel-style surcharge and call it a day. Hormuz closed? Add $X/MT and Y days. That feels right in a spreadsheet. It's wrong in a planning surface.
A closed chokepoint means the lane is not executable at any price. War-risk underwriters pull cover. Carriers reroute their networks. The number you read off a published schedule no longer corresponds to a vessel you can actually book this week. A buyer who plans against a "Hormuz surcharge" model will commit to a delivery date they cannot meet, then take the political hit when the cargo doesn't arrive.
What we ship instead
When a chokepoint blocks a lane, Qootna renders two things side by side.
The first is a hard "NOT EXECUTABLE" banner. The headline landed cost is suppressed. No accidental cost-per-MT figure leaks into a decision document or PDF export. The branch short-circuits at low confidence — even if our benchmark resolver came back high — because the operational answer is "you cannot ship this".
The second is a "normal-market benchmark" sub-block, rendered in amber, never red. It shows what the lane would cost in a normal market: base freight plus baseline fuel, no crisis surcharge, no toggles, no executable promise. Exclusions are listed inline. The note reads, in plain language: executable cost requires a live carrier or war-risk quote, not a benchmark line.
That separation is the entire point. Planning teams need both numbers — the realism that the lane is closed, and the reference that says what normal looks like — but they need them rendered as different things, in different palettes, with different language.
Why fail-soft on the benchmark
The benchmark resolver runs unconditionally on every blocked match. If base freight resolves, we render the benchmark sub-block. If it doesn't, we drop the sub-block silently. There is no admin toggle, no per-scenario gate, no JSON modifier that has to be re-seeded when a new chokepoint appears.
We learned that the hard way. An earlier version gated the benchmark behind a benchmarkPolicy: "show" | "hide" field on the crisis scenario row. The first prod test on IND→ARE SEA with active Hormuz showed only the red banner — because the existing scenario row didn't carry the new field. We re-seeded; we shipped; we then rolled it back to fail-soft and stripped the gate entirely.
The "NOT EXECUTABLE" badge plus the amber palette plus the exclusions list plus the executable-cost note are the misread protection. A per-row admin opt-in was over-engineering.
Generalising past Hormuz
Red Sea, Suez, Panama on a low-water year, future chokepoints we haven't named — the same mechanism fires. There is no per-scenario hand-tuning. A new chokepoint becomes blocked-mode when its row says so; the engine and the UI light up automatically.
That's the planning property we wanted: the operator sees the constraint the moment the data says it's there, not the moment we ship a new code path.
What it doesn't do
The benchmark sub-block is not a war-risk price. When Lloyd's JWLA or IHS Markit data is in scope, the sub-block evolves into a priced S_war line — same slot, different copy. Until then, it's a reference number with explicit disclaimers, and the operator carries the executable conversation with their carrier.
The right number is the one you can defend.