← Methodology

Hormuz Index changelog.

Every methodology change is logged here with the reasoning. Live-published values (the number that was on the page at the time) are preserved alongside retro-computed values (what the current methodology would have produced for the same inputs). Both are available at the audit endpoint.

Current version · v0.5.0

1. v0.5.0

   19 Jul 2026

   minor release

   Manifold component was measuring Iranian regime change rather than Hormuz escalation. Matching tightened to a theatre-and-event gate, and a per-venue liquidity floor now redistributes the component when its genuine Hormuz shelf is too thin to carry weight.

   • Root cause: functions/src/inputs/manifold.ts matched contracts against a flat substring list that included the bare terms "iran" and "war". On a catalogue as broad as Manifold's, that pulled in the venue's entire Iran-politics shelf. Measured at audit time on live data: 93.5% of the component's dollar weight sat in regime and leadership contracts, with "Will Iran's regime fall in 2026?" alone accounting for 80.7%, while genuine Hormuz contracts were 1.2% of matched volume. Regime change is not one of the forecast targets (closure, Gulf-infrastructure strike, US casualty, Iranian retaliation, Brent above $150), and it priced far lower than the strait itself, so the component was dragging the published forecast down for a reason unrelated to the strait.
   • Matching is now a two-gate test: a contract must name a theatre (the strait, the Persian or Arabian Gulf, or Iran) AND a conflict event, oil-price shock, or explicit de-escalation of one. Patterns are word-anchored regexes rather than bare substrings, which also removes a class of false match the old list allowed ("mine" matching inside "determine", "war" inside "toward"). A short exclusion list drops novelty and comparison contracts that clear both gates on wording alone, such as a market comparing Hormuz ship counts to World Cup goals, along with the Israel-Hamas and court-ruling shelf that reached the gates only through incidental wording.
   • Added a per-venue liquidity floor of $5,000 in matched Manifold volume. Below it the reading is marked stale, so computeHormuzIndex redistributes the nominal 0.25 weight across the remaining forecast components and reports the redistribution in the degradedComponents field already published on /api/index. This is separate from LOW_CONFIDENCE_VOLUME_FLOOR_USD, which is a combined-venue floor and is therefore always cleared by Polymarket alone, so it could never have caught this. On the audit-day catalogue the honestly-matched Manifold volume was $2,141, so the component redistributes and the effective weights become Polymarket 0.533, Brent-WTI spread 0.267, Kalshi 0.200. The floor is deliberately self-healing: if Manifold lists liquid Hormuz contracts again, the component re-enters with no code change.
   • Orientation heuristic extended for ship-count threshold framings. Manifold phrases the reopening question as "Will 200 or more ships cross the strait of Hormuz in a day?" rather than in Kalshi's "transit calls" wording, so the v0.4.0 patterns missed it and the contract entered at 0.01 when it should have entered at 0.99. High traffic is de-escalation and now inverts correctly on both phrasings.
   • Nominal weights in ESCALATION_PROBABILITY_WEIGHTS are unchanged. What changed is which contracts are eligible and when a component is thin enough to stand down. No change to the Crisis Pressure Index. API schema unchanged; escalationProbability.components still carries the manifoldForwardContracts key, with raw and score preserved for audit while the weight redistributes. Historical values are not recomputed.
   • Fixed the anchor lookup behind delta24h, delta7d and the anti-whipsaw rails. It ordered the whole tolerance window by timestamp descending and took the newest five documents, then picked the nearest of those five, so with 5-minute ticks and a 12-hour tolerance the 7-day anchor consistently landed about 11.6 hours off target. delta7d was really a 6.5-day delta and the per-24h rails were anchoring on a roughly 22-hour-old value. It now reads the nearest document on each side of the target age and takes the closer one, which is both exact and cheaper. On audit-day data every anchor returned the same value under both methods, so no published delta changes; the defect was latent and would have bitten during a fast move.
   • crisisPressure.indexHealth was the literal string "fresh" and could never report anything else, so a field published on /api/index and /status as a data-quality signal was a constant. Both indices now derive health from how much nominal weight was redistributed away from missing or stale inputs, tripping to low-confidence above a 0.30 share. The threshold sits above 0.25 on purpose: standing a thin component down is not a loss of information, and flagging the Manifold standdown as low-confidence would tell readers the opposite of the truth. Individual redistributions remain listed in the degraded field either way. The escalation index keeps its existing combined-liquidity floor in addition to this rule.
   • Corrected two documentation claims that live data disproved: the Manifold component description asserted the venue "consistently carries more Hormuz-specific forward contracts than the regulated US venues", and a comment in inputs/polymarket.ts asserted Manifold could afford a bare "iran" match "because its catalogue is framed differently". Both were false. Kalshi's KXHORMUZNORM series alone carried roughly $11M against Manifold's few hundred dollars of genuine Hormuz volume.

   ReasonA quarter of the published Escalation Forecast was being set by a play-money market about whether Iran's government falls, which is a different question from whether the Strait of Hormuz stays shut. The effect was not cosmetic: with the contaminated component the raw composite read 46.0 while the published value sat at 58, a gap the anti-whipsaw decay was quietly absorbing. With the component correctly stood down the raw composite reads 57.1, which agrees with what was already published, so the correction removes a persistent downward drag rather than introducing a jump. The v0.3.3 rename already warned readers that "nearly a third is fake-money betting"; this release makes the fake-money portion actually measure the strait, and stand aside when it cannot.

2. v0.4.0

   10 Jun 2026

   minor release

   Kalshi re-included in the Escalation Forecast composite after a fresh audit found heavily traded Hormuz series; weights revert to the pre-drop v0.3.1 split.

   • A 2026-06-10 audit of the Kalshi catalogue (series-level search, then per-series market pulls, verified both authenticated and unauthenticated) found three live Hormuz series: KXHORMUZNORM ("When will traffic at the Strait of Hormuz return to normal?", monthly buckets out to July 2027), KXHORMUZWEEKLY (weekly transit-count threshold buckets), and KXCLOSEHORMUZ (no open markets). KXHORMUZNORM resolves on the IMF PortWatch 7-day moving average of transit calls reaching 60, the same criterion Polymarket’s reopening contracts use. At audit time it carried roughly 8.26M contracts lifetime volume, 357k contracts in the prior 24 hours, 3.94M open interest, and tight two-sided quotes. This clears the $15k low-confidence volume floor by orders of magnitude, so the v0.3.2 drop rationale (zero traded contracts) no longer holds.
   • Escalation Forecast weights revert to the v0.3.1 split: Polymarket 0.47 to 0.40, Brent-WTI spread 0.24 to 0.20, Manifold 0.29 to 0.25, Kalshi restored at 0.15. This is the v0.3.2 pro-rata redistribution applied exactly in reverse. Sum still 1.0.
   • Restored: functions/src/inputs/kalshi.ts (dollar-weighted aggregate with per-contract orientation, unchanged from its v0.3.1 form); the readKalshiForwardContracts wiring in computeHormuzIndex.ts; the kalshiForwardContracts entries in ESCALATION_PROBABILITY_WEIGHTS, ESCALATION_PROBABILITY_META, and the public component keys. Kalshi volume re-enters the combined low-confidence floor accounting.
   • Orientation heuristic extended for the transit-threshold framings the new series use: "transit calls at or above N" and "more than N transit calls" are now classified yes-good (traffic flowing equals de-escalation), so a likely reopening reads as LOW escalation probability. The patterns are anchored on the phrase "transit calls" so oil-price framings like "Brent above $150" still read yes-bad.
   • Root cause note: the late-May zero-volume readings that motivated v0.3.2 were partly an artifact of Kalshi migrating its API to fixed-point string fields (volume_fp, open_interest_fp, last_price_dollars) that the fetcher did not read, on top of the catalogue genuinely lacking Hormuz series at the 2026-05-27 audit. fetchMarkets.ts now reads the new schema with legacy fallback, and queries the three Hormuz series directly by series_ticker instead of relying on a first-page scan of a 20,000-market catalogue.
   • No changes to Crisis Pressure Index. API schema unchanged; escalationProbability.components carries the kalshiForwardContracts key again. Historical values are not recomputed.

   ReasonThe v0.3.2 exclusion was conditioned on an empirical fact that has changed: Kalshi now hosts the single most directly Hormuz-relevant contract family on any regulated venue, resolving on the exact PortWatch criterion this site tracks on the reopening page. Excluding a regulated-exchange signal of that size while including play-money Manifold would be indefensible. Reverting to the pre-drop weights rather than inventing new ones keeps the change auditable: v0.3.2 redistributed 0.15 pro-rata, v0.4.0 puts it back. Values published between 2026-05-27 and 2026-06-10 were computed without Kalshi and are not retro-computed.

3. v0.3.3

   31 May 2026

   patch release

   Renamed the Escalation Probability index to Escalation Forecast. Display-only; no input, weight, or math change.

   • Every reader-facing surface that displayed the index by name now reads "Escalation Forecast": the homepage hero, the standalone Hormuz Index block, the OG image, the /embed/index widget, the public disclaimer string (lib/methodology.ts INDEX_DISCLAIMER), the /api page JSON-LD PropertyValue, the dataHealth provenance label, and the dailyBrief prompt. Internal identifiers are untouched: the Firestore collection (escalationProbabilityIndex/{ts} + /latest), the API component object (escalationProbability), ESCALATION_PROBABILITY_KEYS/WEIGHTS/META, and the API schema id all keep their names, so no integrator or stored series breaks.
   • No change to inputs, weights (Polymarket 0.47 / Brent–WTI spread 0.24 / Manifold 0.29; these are the pre-v0.4.0 weights, before Kalshi was restored at 0.15 in v0.4.0), normalization, decay, rails, or the low-confidence liquidity floor. Published values are identical to what v0.3.2 would have produced.

   ReasonThe composite blends prediction-market odds with a Brent–WTI price spread and play-money Manifold contracts. "Probability" invited readers, especially journalists quoting the number, to read "Escalation Probability 58" as "markets price a 58% chance of escalation," which the inputs do not support: roughly a quarter of the number is a price-spread mapping with no probabilistic meaning and nearly a third is fake-money betting. "Forecast" keeps the forward-looking claim the inputs do support while dropping the false precision. Renaming rather than re-architecting preserves the time series.

4. v0.3.2

   27 May 2026

   patch release

   Kalshi dropped from the Escalation Probability composite; weights redistributed pro-rata across the surviving three components.

   • A full audit on 2026-05-27 paginated all 20,000 currently-open Kalshi markets via /trade-api/v2/markets and found zero actively-traded Iran/Hormuz forecast contracts. The Mideast-adjacent listings that do exist (KXABRAHAMSY, KXABRAHAMSA, KXABRAHAMQ for Israel-Syria/Saudi/Qatar normalization; KXNEXTISRAELPM for Israel next PM) all carry volume:null, open_interest:null, no last_price, no bid/ask: structurally listed in the catalogue but unused by traders.
   • Escalation Probability weights restructured: Polymarket 0.40 → 0.47, Brent term structure 0.20 → 0.24, Manifold 0.25 → 0.29 (pro-rata redistribution of Kalshi's 0.15 across the surviving three components, preserving the v0.3.0 design intent). Sum still 1.0.
   • Removed: functions/src/inputs/kalshi.ts; readKalshiForwardContracts import in computeHormuzIndex.ts; the kalshi entry from ESCALATION_PROBABILITY_WEIGHTS in both methodologyConfig.ts (functions) and methodology.ts (lib); the kalshiForwardContracts key from ESCALATION_PROBABILITY_META; the Kalshi totalVolumeUsd contribution to the combined-liquidity floor (now Polymarket + Manifold only).
   • fetchMarkets.ts still pulls Kalshi opportunistically into predictionMarkets/; if Kalshi ever lists Iran/Hormuz markets with real volume, they'll surface in /api/v1/markets and on the homepage prediction-markets panel. They simply no longer feed the Escalation Probability composite.
   • The v0.2.1 "weight reactivates automatically when Kalshi volume returns" mechanism is removed. v0.2.1 had this on the theory the catalogue would refill; six weeks later it has not, and the redistribution math was load-bearing for nothing.
   • No changes to Crisis Pressure Index. API schema unchanged at hormuz-index-v0.2; the escalationProbability.components object simply no longer carries a kalshiForwardContracts key.

   ReasonThe v0.2.1 promise (keep Kalshi present in the methodology with the assumption that markets would eventually be listed) has not held over six weeks. Every published Escalation Probability value since v0.2.1 has had kalshiForwardContracts at health:missing with weight:0, the redistribution math silently doing the work. Dropping Kalshi formally aligns what the methodology page claims with what the function actually computes. Time series from v0.3.1 forward are unaffected; the redistribution math was already producing the v0.3.2 weights via the missing-input pathway.

5. v0.3.1

   27 May 2026

   patch release

   Brent term-structure input substituted with the Brent–WTI front-month spread; v0.3.0 source path returned no data.

   • v0.3.0 spec called for a Brent forward-curve slope from Stooq numbered contracts (cb1.f, cb2.f, cb3.f). Empirical check on deploy day: Stooq returns N/D for every numbered Brent contract; only the continuous front-month (cb.f) carries data. The input adapter was returning missingReading on every cycle and the 0.20 weight was redistributing to the three prediction-market venues, defeating the v0.3 thesis.
   • Substituted: Brent–WTI front-month spread = cb.f close − cl.f close. Both symbols are already in use by fetchOilPrices, both are quoted continuously by deeply liquid markets. The spread is the price gap between waterborne Mideast crude (Brent) and US/Cushing crude (WTI): a widening Brent premium is real money pricing Brent-specific access risk over US supply, which is a Hormuz signal by construction.
   • New anchor calibration: spread $0 → score 0, $2 → 15, $4 → 35, $7 → 70, $10 → 90, $15+ → 100. Linear interpolation. Calibrated empirically against the 2011 Arab Spring / Libya disruption (sustained $15+), the 2022 Russia-Ukraine acute phase ($5–10), and normal pre-crisis bands ($2–4). Negative spreads (WTI premium) clamp to 0; those reflect Cushing logistics, not Hormuz.
   • Doc shape changes (Firestore brentTermStructure/latest): brentClose + wtiClose + brentPremium replace the prior frontMonth + threeMonth + slopePct fields. The component key in the API stays at brentTermStructureSlope for backward compatibility with v0.3.0 integrators; the methodology page renames the displayed label to "Brent–WTI spread."
   • Weights and the rest of the index unchanged. No changes to Crisis Pressure. No changes to API schema (still hormuz-index-v0.2). The data semantics of the Brent component changed; the structure did not.

   Reasonv0.3.0 was the right idea but built on a free-data assumption that did not hold. The intent (give Escalation Probability a non-market, deeply liquid forward signal independent of the prediction-market crowd) is preserved. The Brent–WTI spread is arguably a tighter Hormuz-specific signal than the absolute Brent curve would have been: it isolates the regional premium directly rather than inferring it from term-structure shape. v0.3.0 ran for less than two hours in production; no historical values were published with the broken input contributing signal (every v0.3.0 cycle had brentTermStructureSlope at health:missing, so the weight redistributed to peers).

6. v0.3.0

   26 May 2026

   major release

   Brent forward-curve slope added as a fourth Escalation Probability input: the first non-market forward signal in the composite.

   • New input: Brent forward-curve slope, weight 0.20. Computed as (front-month close − ~3-month close) / front-month × 100 from Stooq numbered Brent contracts (cb.f vs cb3.f). Positive slope (backwardation) maps to a high score; flat curves score near 30; deep contango scores near zero. Anchors at slope = -3% → 0, 0% → 30, +3% → 60, +6% → 85, +10% → 100, linearly interpolated.
   • Escalation Probability weights restructured: Polymarket 0.50 → 0.40, Manifold 0.30 → 0.25, Kalshi 0.20 → 0.15, new Brent term-structure 0.20. Sum still 1.0. Relative ranking among prediction-market venues is preserved.
   • New Cloud Function: fetchBrentTermStructure (every 30 min). Writes brentTermStructure/latest with frontMonth, threeMonth, slopePct, source, sourceName, sourceUrl, updatedAt, lastAttemptAt, lastAttemptOk. Failure-path stamps lastAttemptOk:false without touching the prior reading, mirroring the silent-fail mitigation introduced for oil prices in the same window.
   • New input reader: functions/src/inputs/brentTermStructure.ts. Returns missingReading when the doc is absent or the slopePct is non-finite; returns a staleReading when lastAttemptOk is false (prior slope kept, health flagged degraded). Weight redistributes pro-rata if the input is missing; Polymarket / Manifold / Kalshi absorb the 0.20 in proportion to their existing weights.
   • The low-confidence volume floor (combined prediction-market 7-day volume below $15k) is unchanged in logic but now applies only to the three prediction-market venues. Brent futures volume is enormous and not comparable to prediction-market liquidity; the term-structure component is excluded from the floor accordingly.
   • No changes to Crisis Pressure Index. Bands, decay, rails unchanged. API schema unchanged at hormuz-index-v0.2 except that escalationProbability.components now carries a fourth entry, brentTermStructureSlope, with totalVolumeUsd:null (Brent futures volume is not meaningfully tracked at this layer).

   ReasonA reviewer reading the v0.2.2 Escalation Probability Index could fairly observe that all three inputs are prediction-market venues sampling broadly the same population: a poll, not a forecast in the sense an oil-market trader would recognize. The Brent forward curve is the deepest, most liquid forward signal in oil markets: when backwardation steepens, money is pricing near-term scarcity, independent of what Polymarket traders think. Adding it as a 20% weight gives the composite an independent forecast pillar without overwhelming the prediction-market signal it was originally built on. In calm regimes the term-structure input scores near zero (modest backwardation is normal for Brent and our anchors reflect that); during a developing crisis it should rise alongside the prediction-market venues and provide confirmatory or divergent evidence. Time series before 0.3.0 should not be compared on a like-for-like basis with values from 0.3.0 onward; v0.2.x docs are not retro-computed.

7. v0.2.2

   26 May 2026

   minor release

   Escalation Probability now distinguishes YES=bad-outcome contracts from YES=de-escalation contracts before aggregation.

   • New per-contract orientation tagger (functions/src/inputs/orientation.ts). Each matched Polymarket / Manifold / Kalshi market is classified yes-bad or yes-good using regex heuristics on the title; yes-good markets have their YES probability inverted before entering the dollar-weighted average so the signal flows toward the forecast target (bad outcome within 30 days).
   • Audit on 2026-05-26 found that the largest-volume Manifold and Polymarket contracts in our catalogue frame YES as de-escalation: "Strait of Hormuz traffic returns to normal by end of May" ($27M, p=0.02), "US x Iran permanent peace deal by May 31" ($54M, p=0.255), "US-Iran ceasefire holds through June". Without inversion, those contracts dragged the published escalation reading sharply down: a low YES probability on "returns to normal" reads as the situation being bad, but pre-v0.2.2 the aggregation interpreted it as the situation being calm.
   • Manifold input adapter (functions/src/inputs/manifold.ts) widens its keyword set to capture peace / ceasefire / invade / uranium / nuclear / sanctions / lifted / reopen / resume framings that Manifold uses heavily. The orientation tagger handles the YES=good ones; the rest contribute as direct readings.
   • No changes to Crisis Pressure Index inputs or weights. The Escalation Probability weights stay at Polymarket 0.5 / Manifold 0.3 / Kalshi 0.2; only the aggregation step inside each input changed.

   ReasonThe published Escalation Probability reading on 2026-05-26 was 37 with confidence 2: Manifold was contributing nothing (its title-keyword filter missed the bulk of relevant contracts) and Polymarket alone was being pulled DOWN by de-escalation-framed contracts that an honest aggregator should invert. The forecast index is supposed to read "what markets price for the bad outcome." A high-volume contract that markets price at 0.02 for "Hormuz traffic returns to normal" is markets saying the bad outcome is overwhelmingly likely; the v0.2.2 aggregation makes that visible in the headline number. Time series before 0.2.2 should not be compared on a like-for-like basis with values from 0.2.2 onward; the v0.1/v0.2 currentValue fields are NOT retro-computed because the orientation classification was never recorded on historical input docs.

8. v0.2.1

   26 May 2026

   minor release

   Added Manifold Markets as a third Escalation Probability venue; reduced Kalshi weight to reflect its empty open catalogue.

   • New venue: Manifold Markets (api.manifold.markets). Pulled via the same fetchMarkets ingestion path as Polymarket and Kalshi, deduped across seed terms (hormuz, iran, israel, oil price, tanker, middle east), filtered through the same relevance keyword + exclude lists, written to predictionMarkets with venue: "manifold".
   • Manifold volume is denominated in mana and converted to USD-equivalent at the conservative 100 mana ≈ $1 USD rate Manifold itself uses for charity redemption and subsidy budgets. The methodology page calls this out explicitly so readers can discount accordingly; the combined Polymarket + Manifold + Kalshi liquidity floor uses the converted figure.
   • Escalation Probability weights restructured: Polymarket 0.6 → 0.5; Kalshi 0.4 → 0.2; new Manifold weight 0.3. Sum still 1.0. Kalshi weight halved because an empirical audit of its open catalogue on 2026-05-26 surfaced no matching forward contracts (the KXUSAIRANAGREEMENT, KXNEXTIRANLEADER, KXIRANVISITUSA series exist but list no open markets); the new weight assignment reflects which venue is actually carrying signal.
   • Relevance keyword list in fetchMarkets.ts widened from 16 strict phrases to a broader Iran/Israel/oil/conflict surface, paired with a new EXCLUDE_KEYWORDS list that filters substring collisions from sports and entertainment markets (player names containing "iran", awards containing "war", etc.). Top-N retained per cycle raised from 20 to 30 to accommodate the three-venue catalogue.
   • No changes to Crisis Pressure Index inputs or weights. Bands, decay, and rails unchanged. API schema unchanged at hormuz-index-v0.2; only the per-component breakdown in the escalationProbability.components object now carries a manifoldForwardContracts entry alongside polymarketAggregate and kalshiForwardContracts.

   ReasonLive audit of the Escalation Probability Index on 2026-05-26 returned confidence=2 (effectively meaningless) because Kalshi was flagged missing, meaning the 0.4 Kalshi weight redistributed pro-rata to Polymarket, leaving Polymarket as the only signal. Investigation showed Kalshi's relevant event tickers (US-Iran agreement, next Iran leader, Iran-visits-USA) carry zero open markets at the moment; the catalogue exists structurally but the contracts have not been listed. Manifold, by contrast, was running 20+ active Hormuz-specific binary markets with real trading interest. Folding Manifold in restores the cross-venue diversification the methodology requires while keeping Kalshi available for automatic reactivation when its catalogue refills.

9. v0.2.0

   21 May 2026

   major release

   Split the index into two: Crisis Pressure (state) and Escalation Probability (30-day forecast).

   • The single 0–100 Hormuz Index becomes two parallel indices, each backed only by inputs that match its claim. Both ship in lockstep and share the same bands, decay, and rails.
   • Crisis Pressure Index (state) carries the four current-state inputs: AIS transit deviation (30%), war-risk insurance multiple (25%), GDELT event pressure (25%), Brent options dread / OVX (20%). Override rule (max × 0.9 when any score ≥ 75) is carried over; the physical-strait override is load-bearing for crisis severity.
   • Escalation Probability Index (30-day forecast) launches with two inputs: Polymarket aggregate (60%) and Kalshi forward contracts (40%). Dollar-weighted aggregation by 7-day volume. No override rule: a forecast should be a smooth probabilistic number, not a threshold flipper.
   • Polymarket binary liquidity gate ($25k floor, 5% gated weight) replaced by a continuous low-confidence reporting floor at $15k combined Polymarket + Kalshi 7-day volume. Under the floor the Escalation Probability Index reports indexHealth: "low-confidence" and the hero shows a muted treatment; weights are unchanged.
   • New Firestore collections: crisisPressureIndex/{ts} + /latest and escalationProbabilityIndex/{ts} + /latest. The legacy hormuzIndex/ collection is frozen: no further writes go there from v0.2 onward; reads stay open so prior published values remain citeable.
   • API schema bumped to hormuz-index-v0.2. Top-level shape: { indices: { crisisPressure: {...}, escalationProbability: {...} } }. CORS unchanged.
   • OG image, embed widget, and homepage hero restructured to a dual-number layout (side-by-side on desktop, stacked on mobile). Daily brief weaves both numbers into prose when either is in high or extreme.
   • currentValue on existing v0.1.x historical docs is NOT recomputed in this bump. The v0.2 structure is incompatible with the v0.1.x single-value shape, and silently rewriting historical currentValue to the new Crisis Pressure value would change what the field means for those docs. v0.1.x docs are frozen entirely; the v0.1.2 methodology page is archived at /methodology/v0.1 for historical reference.

   Reasonv0.1.2 was an honest reframing of the band language but left the structural problem unresolved: the headline was a state composite marketed as a forecast. Four of the five v0.1 inputs measured what just happened; only Polymarket was genuinely forward-looking. With the headline at 90 and Polymarket reading ~18%, the gap was load-bearing. Splitting the brand into two parallel indices lets each carry only the claims its inputs support: Crisis Pressure for what is happening, Escalation Probability for what markets price in the next 30 days. The two-number presentation also makes the state-vs-forecast divergence visible directly, which is itself editorially useful: readers can see when markets disagree with the present.

10. v0.1.2

    20 May 2026

    patch release

    Honest reframing: index describes measured state, not forecast.

    • Band framings updated to describe the current measured state rather than claim forecasting power. The previous "all signals point to imminent escalation" framing for the extreme band conflated current crisis severity with forward probability.
    • Methodology page intro rewritten to position the index as a composite of current crisis pressure across measured signals, not "the probability of severe escalation in the next 30 days." Added a "What the index is not" section calling out that four of the five inputs measure current state; only Polymarket is genuinely forward-looking.
    • No weight, threshold, decay, rail, or output changes; the index value at any given moment is exactly what v0.1.1 would have produced. Only rendered framing changed.

    ReasonA reader pointed out that "all signals point to imminent escalation" claims more than the inputs actually support. The current AIS, insurance, and event-pressure components measure existing crisis severity; the Polymarket component (the one true forecast input) reads only 18% probability of closure even as the headline sits at 90. Honest disclosure is methodology's most-important property; this corrects the overclaim. A v0.2 will likely restructure the inputs to genuinely forecast (e.g., heavier Polymarket weighting, term-structure inputs, separating current-state and forward-probability into two distinct numbers).

11. v0.1.1

    20 May 2026

    patch release

    CBOE OVX integration lights up the Brent options vol input.

    • New ingestion Function fetchVolatilityIndex pulls CBOE OVX every 15 minutes. Primary source: FRED daily-close series OVXCLS (St. Louis Fed). Fallbacks: Stooq, Yahoo Finance.
    • Writes volatilityIndex/latest with { ovx, skew, source, sourceUrl, updatedAt }; brentOptionsDread adapter now returns fresh data instead of "missing".
    • No weight or threshold changes; the 25% target weight that was previously redistributed pro-rata is now actually applied.
    • Methodology page updated to reflect the new upstream and remove the "pending integration" disclosure.

    ReasonOVX is the input most likely to give the index intraday motion during sustained-closure periods (when AIS/insurance read steady). With v0.1.0 publishing the headline as 90 every 5 minutes because the override fires on AIS, the page felt static. OVX moves continuously during US/EU trading hours and restores the breathing the chart needs.

12. v0.1.0

    19 May 2026

    major release

    Initial public release.

    • Five-component composite: Polymarket+Kalshi (25%), Brent options vol (25%), GDELT event pressure (20%), AIS transit deviation (15%), war-risk insurance multiple (15%).
    • Weighted-average composition with single-component override above score 75.
    • Polymarket liquidity gate at $25k 7d volume; gated weight 5%.
    • Asymmetric decay: instant rises, 36h half-life falls.
    • GDELT event decay 72h half-life.
    • 24h rails: +25 ceiling / -10 floor; ceiling overridable on flagged crisis events.
    • Dual-value Firestore structure: liveValue immutable, currentValue retro-computable on methodology bumps.
    • Brent options vol input ships in stub state (returns missing); upstream CBOE OVX integration is pending and weight is redistributed pro-rata in the interim.

    ReasonFirst publishable version. Calibration expected to evolve across the next 4–8 weeks as we observe how the index reads across more market and event regimes.

← Back to methodology