Methodology notices

What changed. weighted_median in src/tci/index.py returns the first price at which cumulative weight reaches half the total. When the weights below a price sum to exactly half, the print sits on a tie between two adjacent prices. Python 3.12 made the built-in sum() use compensated summation, which can move the total by the last bit of a floating-point number, enough to decide which side of such a tie a print falls on. The index is computed on Python 3.11, so no published print was affected, but the record could only be recomputed on that interpreter. The total is now an explicit fold that gives the same result on every version.

Why it is a version. index.py is part of the hash-locked calculation path, and GOVERNANCE.md §1 requires a version and a notice for any change to it, including one that moves no number.

What does not change. The unit definition, the estimator and its tie rule, the trim, the weights, the concentration cap, the publication gate, the panel and every series. Prints dated before 11 October keep the version they record.

What is priced. A spot row is a price the seller itself publishes for capacity it may reclaim: AWS and Google Cloud spot through the gpuhunt catalogues, Azure Spot, CoreWeave, Nebius and Verda spot, and from 27 September Together AI's preemptible rate. The collectors have stored these rows as tier spot since 11 September (Azure), 12 September (CoreWeave) and 17 September (the gpuhunt catalogues); the on-demand series never read them and still do not.

What is not. Two stored tiers stay out. Azure's interruptible rows are its Low Priority meter, a retired product. vast.ai's are min_bid, the lowest bid a host will accept, which is a floor nobody has necessarily paid. RunPod's API publishes a spot price equal to its on-demand price and is not collected as spot.

Where the moving and the fixed prices come from. AWS spot is EC2's own spot price history at the time of the catalogue build, the cheapest availability zone in each region. Google Cloud spot changes with Google's published rates. Nebius's is the rate its own price calculator returns for a preemptible instance, which its pricing page names as the place current spot prices are shown; the page itself publishes only a floor. Azure, CoreWeave and Together publish fixed spot rates, and a fixed rate is still a price anyone can buy at.

Population. Every segment: marketplace, neocloud and hyperscaler. The on-demand headline leaves the hyperscalers out; the spot market is mostly theirs, and without them each region would have two sellers. The spot page shows each constituent under its segment, so the categories stay visible.

The spread. TCI-CRI-H100-SPOTSPREAD, -SPOTSPREAD-US and -SPOTSPREAD-GLOBAL are the region's on-demand series minus its spot series, in USD per GPU-hour, published only on a day both legs publish. The two legs draw on different populations by design, so the spread is what a buyer saves by moving from the on-demand market to the spot market, not one seller's discount. The spot page also shows each seller's own discount where it publishes both prices in the same region.

Where each seller counts. The same blocks as on-demand: CoreWeave in US and Global only, Together in Global only through unplaced.

What does not change. The unit definition, the estimator, the trim, the weights, the concentration cap, the publication gate and every existing series. Prints dated before the effective date keep the version they record.

What is added. CoreWeave's HGX H100 on-demand rate, read from its pricing page ($49.24 per 8-GPU instance-hour on 26 September, $6.16/GPU-hr). Civo's 8 x H100 SXM on-demand rate ($23.92 per instance-hour, $2.99/GPU-hr). Together AI's GPU Clusters on-demand rate for HGX H100 ($3.99/GPU-hr), read by a new collector from the visible table on its pricing page that states every price is per GPU per hour. All three are neoclouds and enter the headline population of the series they are priced in. Only the H100 class is admitted.

Where each one counts. CoreWeave publishes a North America table and a Europe table. North America rows are placed in the US, as they have been stored since 12 September, and count in the US and Global series. The Europe table also covers the United Kingdom and names no site, so its rows count in the Global series only and never in an EU/EEA series. Civo and Together name no region on the page, in their documentation or in their terms. Their rows count in the Global series only.

Rows with no country. Every block in the methodology is a list of countries, and until this version a row with no country failed all of them. The Global block asks only that the hour is sold somewhere, which one price a seller charges wherever it runs the hardware satisfies. The block therefore also counts country-less rows from providers named one by one in config/factors.yaml (unplaced). A provider that places some of its rows itself, as Hyperstack does from its stock feed, is never named there, because its unplaced row would count the same hour a second time.

Node size. Civo's rows are its 8-GPU instance. Together's page gives no GPU count; its GPU Clusters documentation sells capacity in 8 x H100 steps, and rows are recorded at 8 GPUs. Both clear the two-GPU floor.

Screened and not added. Denvr Dataworks ($2.45/GPU-hr, 8 x H100 SXM): its terms forbid automated access to the website. Massed Compute (H100 SXM5, $25.12 per 8-GPU hour): its terms render only with JavaScript and could not be read. Crusoe ($3.90/GPU-hr): no node size is stated. Vultr ($23.92 per 8 x H100 bare-metal hour): its public plan API lists no location where the plan can be deployed.

What does not change. The unit definition, the estimator, the trim, the weights, the concentration cap, the publication gate and every EU/EEA series. Prints dated before the effective date keep the version they record.

What is added. A GLOBAL block in config/factors.yaml holding every ISO 3166-1 alpha-2 code, 249 in all, copied from the IANA time zone database's iso3166.tab, and one regional series over it, EU-CRI-H100-GLOBAL, defined exactly as the US series is: class H100, the headline's population (marketplace and neocloud). A row with no country is not placed in this block any more than in the others.

Why a list and not "any country". Every block in the methodology is a list of codes that a reader can check a row against. A wildcard would move the meaning of the block out of the locked parameters and into code.

Before the effective date. The intraday page shows this series, and the US series before 1 October, computed from the hourly reads under the version that introduces it, and labels those values indicative. None of them is a print, none is stored as one, and the first published value is the 4 October fixing.

What does not change. The unit definition, the estimator, the trim, the weights, the concentration cap, the publication gate and the panel. Prints dated before the effective date keep the version they record.

Effective date brought forward. Announced on 24 September for 22 October. On 27 September the date moved to 3 October, unchanged in content, so that the Global series (notice 2026-N6) can follow within days rather than weeks. No print has been computed under this version or any later one.

What is added. Hyperstack's on-demand price list names no region. It also publishes a stock feed per datacentre (NORWAY-1, CANADA-1, US-1), listing for each GPU flavour how many virtual machines of each size can be deployed now. The collector already reads both. From this version it records, beside the unplaced row, one row per datacentre where the feed shows at least one deployable machine of that flavour, with that country and the largest deployable size as the node. A flavour listed at zero, or not listed, places nothing. Only Norway is in the EU/EEA.

Form factor. The feed names Hyperstack's three H100 flavours H100-80G-PCIe, H100-80G-PCIe-NVLink and H100-80G-SXM5, which match the price list's "NVIDIA H100", "NVIDIA H100 NVLink" and "NVIDIA H100 SXM" one for one. The plain "NVIDIA H100" is therefore priced in the H100 PCIe class and never as the SXM reference unit. The NVLink-bridged cards enter no class. A100 follows the same pattern.

Segment. Neocloud. Hyperstack is not added to the sovereign list.

What does not change. The unit definition, the estimator, the trim, the weights, the concentration cap and the publication gate. No row collected before the effective date is admitted. Prints dated before it keep the version they record.

Effective date brought forward. Announced on 24 September for 8 October. On 27 September the date moved to 2 October, unchanged in content, so that the Global series (notice 2026-N6) can follow within days rather than weeks. No print has been computed under this version or any later one.

Seeweb. Until this version Seeweb's on-demand H100 price, EUR 1.89 per GPU-hour, entered the index from config/providers/seeweb.yaml, last checked by hand on 13 September. A collector has read the same page since 15 September and stores its rows under its own name. It now records the size of the 8-GPU node Seeweb's own configurator offers. Seeweb prices every node size at the same rate per GPU, and the 8-GPU node is the size the hand-kept entry used. From the effective date the panel reads Seeweb through that collector and not through the file.

Removed. Hetzner, Genesis Cloud and Leaseweb were admitted through hand-kept files that never held a price, because none of them published a verifiable hourly H100 rate when last checked. They leave the panel. None of them has ever contributed to a print. Any of them can return through a collector that reads a public price, under a later version and its own notice.

What does not change. The unit definition, the estimator, the trim, the weights, the concentration cap and the publication gate. Prints dated before the effective date keep the version they record.

Why. CME Group plans to list compute futures on 5 October 2026, pending regulatory review, that settle in cash on third-party H100 and B200 rental indices. A European buyer who hedges with them carries a basis: the difference between what the EU/EEA population of sellers charges and what the reference population charges. Nobody publishes that difference.

What is measured. EU-CRI-H100-US applies the headline's unit definition (one H100 SXM GPU-hour, on-demand, datacenter-hosted, at least 2 GPUs per offer), its weighted median over offers, its trim, its tier weights, its concentration cap and its five-provider gate to offers delivered from data centres in the United States. EU-CRI-H100-BASIS-US is EU-CRI-H100 minus EU-CRI-H100-US, with a EUR companion at the day's FX. A day on which either leg gaps is a gap in the basis, with the reason; the basis is never computed against a carried-forward leg.

What it is not. It is not the basis to the index behind the CME contracts. That index's methodology is not public, and a spread against it would mix a regional difference with a methodological one that nobody outside can measure. This series measures the regional part, with the method held constant.

Where the US rows come from. vast.ai offers carry their own location. Lambda's catalogue rows carry a region. DigitalOcean sells its H100 Droplets in New York at the same price as in Amsterdam. RunPod's price is the same in every region; a US row is recorded only on days RunPod reports stock of that GPU type in a US datacentre. Voltage Park operates only in the United States (its own statement: clusters in Texas, Virginia, Washington and Utah).

New constituents. Three EU/EEA sellers enter through dstack's open-source gpuhunt catalogues, which list a location per row: Verda (Finland and Iceland), Nebius (Finland, France, and a private region in Iceland) and Lambda (europe-central-1, Germany). DigitalOcean enters through its public pricing page: its H100 Droplets are "NVIDIA HGX H100" by its own description and are sold in Amsterdam, New York and Toronto at one price, recorded as one row per region, of which only Amsterdam is in the EU/EEA population. Oracle Cloud Infrastructure enters the hyperscaler segment, where it is priced in the -HS series and never in the headline. OVHcloud enters through its public order-catalogue API in the H100 PCIe class only; its H100 instances are "80 GB HBM2e - PCIe 5.0", a different product from the SXM reference unit.

One company, one vote. Verda is DataCrunch under a new name. The static datacrunch entry leaves the panel on the day the Verda feed enters it, and the sovereign list names Verda in its place. Nebius's static entry is likewise replaced by its catalogue feed rather than kept beside it.

Classes. vast.ai is admitted to the H100 PCIe, H200, B200 and B300 classes, whose listings it already publishes and which the index has stored since 11 September. The new catalogue feeds are admitted to the classes they list.

FX. The EUR companion uses the ECB reference rate dated strictly before the print date. Until now it used the latest rate dated on or before it, which is T-1 when the run finishes before the ECB publishes around 14:00 UTC and T when it finishes after: the 11 September run finished at 18:22 UTC and took the same-day rate. A print's EUR value therefore depended on when it was computed. The rate each earlier print used is recorded with it and is what a recomputation converts at.

What does not change. The unit definition, the estimator, the trim, the weights, the concentration cap and the publication gate are untouched. The collectors that feed these rows run from the day this notice is published, so each new constituent has stored history before its first print; nothing collected before the effective date is admitted retroactively, and prints dated before it keep the version they record.

Norway. config/factors.yaml lists the EU/EEA constituent countries, and it has never contained Norway. The token NO is read by YAML 1.1 as boolean false, so eu_eea_countries holds False where it should hold the string NO. Every Norwegian observation collected since Azure's norwayeast region began reporting on 2026-08-16 has been dropped by the country filter: 126 observations as of the date of this notice. Norway is in the EEA, the published unit definition says EU/EEA, and the index has therefore been narrower than its own stated scope.

Node-size floor. filters.min_gpu_count has been 2 since v0.3.0, which is the floor the methodology publishes. The gpuhunt_ collector has continued to discard offers below 8 GPUs at collection time, before storage. Because collectors record live prices that cannot honestly be re-collected for a past date, those offers are not recoverable; the correction applies from the effective date forward.

Both are corrections toward the published methodology rather than changes to it. Neither alters the unit definition, the estimator, the trim or the weighting. They are handled as a minor version bump because each changes the constituent population, which is a parameter change under GOVERNANCE.md §1.

Prints computed before the effective date remain valid under the version they record in daily_index.methodology_version and are not restated. A gap stays a gap.

Added 11 September 2026: the panel becomes explicit, with the same membership. Until this version a provider was in the constituent population if any collector produced a row for it, and an unlisted name defaulted to the neocloud segment. From v0.4.0 the population is an enumerated panel in config/factors.yaml: provider, segment, and for each collector the classes it may contribute to. The v0.4.0 panel names exactly the providers, collectors and classes that could reach a print before it, so by itself it moves no number; every stored print recomputes to the same value under it (python -m tci.run reproduce). It exists so that a new collector can store rows for weeks without any of them reaching a print until a later version admits them after its own notice.

Effective dates are now enforced in code. Each version is committed on the day of its notice and selected for a print only from its effective date (config/methodology/succession.yaml), so this version applies to the 15 September print whenever the change is merged.