Skip to main content

Methodology

SourcesParameters & modelsDerived quantitiesVendor spec sheets feeds throughput and power per chip family. Stated in versions.ts GPU_MODELS — per-chip dense throughput and TDP quoted from NVIDIA and AMD datasheets.The Epoch AI datasets feeds throughput and power per chip family. Stated in cost-index-section.tsx — per-GPU dense BF16 throughput sourced from the Epoch AI ML Hardware dataset.MLPerf submissions feeds throughput and power per chip family. Stated in validation-section.tsx VALIDATION_SOURCES — MLPerf hardware configurations cross-checked against the chip catalogue.Published training runs feeds the MFU calibration and its range. Stated in versions.ts mfu_assumption and FlopCalculator.tsx CalibrationScopeNote — the 0.40 default calibrated against utilization reported for training runs, LLaMA 3 405B at 0.384 and PaLM 540B at 0.462 among them.The Epoch AI datasets feeds the compute unit definition. Stated in cost-index-section.tsx — the cost unit denominated in the same Epoch-sourced dense BF16 throughput.Cloud price sheets feeds the compute unit definition. Stated in cost-index-section.tsx — published hourly instance pricing normalised into the compute unit.Supply-chain relationship data feeds the cascade edge weights and decay. Stated in cascade-section.tsx — criticality derived from the supply-chain relationship rank.SEC and registry filings feeds the ownership chain-walk rules. Stated in ownership-investigator-section.tsx — the chain-of-title walk reads ownership edges populated from filings.SEC and registry filings feeds the authority-tier ladder. Stated in confidence-level-guide.tsx — tier 1 is a primary regulatory filing.The Federal Register feeds the authority-tier ladder. Stated in ownership-investigator-section.tsx — a designation, and every affiliate chain walked down from one, cites the Federal Register notice the ladder rates tier 1.SEC and registry filings feeds the reality-ratio rules. Stated in methodology page — deployed capacity verified through primary-source procurement disclosures.Customs and trade data feeds the corridor counterfactual rules. Stated in trade-flow-attribution-section.tsx — the HS 8542 filter and counterfactual window applied to declared customs values.Interconnection queues feeds the county capacity rollup. Stated in methodology page — the generator queue aggregated to county-level capacity totals.Throughput and power per chip family feeds facility FLOP capacity. Stated in derivations.ts — peak throughput from GPU count times per-chip dense throughput.The MFU calibration and its range feeds facility FLOP capacity. Stated in derivations.ts — the training-throughput step multiplies effective throughput by the MFU assumption.The MFU calibration and its range feeds the estimation bounds. Stated in derivations.ts deriveFromHardware — the bounds are the MFU range at its floor and ceiling.Throughput and power per chip family feeds the estimation bounds. Stated in derivations.ts deriveFromHardware — peak throughput is the common factor in both bounds.The MFU calibration and its range feeds threshold crossings. Stated in flop-methodology-section.tsx — time-to-threshold divides the statutory threshold by the daily FLOP budget.Throughput and power per chip family feeds threshold crossings. Stated in flop-methodology-section.tsx — the same daily budget applies the per-chip throughput.The compute unit definition feeds the cost index. Stated in cost-index-section.tsx — the index is the compute unit priced per provider and region.Throughput and power per chip family feeds the cost index. Stated in cost-index-section.tsx — dense BF16 throughput is the denominator of the cost unit.The cascade edge weights and decay feeds cascade reach. Stated in cascade-simulator.ts — each hop multiplies the impact arriving at it by the edge’s flow share, by its criticality (a 1–10 score, divided by ten), and by the scenario’s per-hop decay.The corridor counterfactual rules feeds trade-corridor attribution. Stated in trade-flow-attribution-section.tsx — corridor change measured against the pre-event baseline window.The reality-ratio rules feeds the announced-versus-deployed reconciliation. Stated in methodology page — the reality ratio is deployed over announced, per programme.The ownership chain-walk rules feeds the compute visibility index. Stated in methodology page — the index reads the ownership chain walk to find an ultimate beneficial owner.The county capacity rollup feeds grid headroom context. Stated in methodology page — the grid context reports county totals, because a generator-queue row cannot be resolved to a named data center.Vendor specsheetsEpoch AIdatasetsMLPerfsubmissionsPublishedtraining runsSEC & registryfilingsFederalRegisterSupply-chainrelationship dataCustoms &trade dataCloud pricesheetsInterconnectionqueuesThroughput & powerper chip familyMFU calibrationand rangeCompute unit($/petaFLOP-day)Edge weightsand decayCorridorcounterfactual rulesOwnershipchain-walk rulesReality-ratiorulesAuthority-tierladderCounty capacityrollupFacility FLOPcapacityEstimationboundsThresholdcrossingsCost index($/petaFLOP-day)CascadereachTrade-corridorattributionAnnounced vsdeployedComputevisibility indexGrid headroomcontext
SourcesParameters & modelsVendor spec sheets feeds throughput and power per chip family. Stated in versions.ts GPU_MODELS — per-chip dense throughput and TDP quoted from NVIDIA and AMD datasheets.The Epoch AI datasets feeds throughput and power per chip family. Stated in cost-index-section.tsx — per-GPU dense BF16 throughput sourced from the Epoch AI ML Hardware dataset.MLPerf submissions feeds throughput and power per chip family. Stated in validation-section.tsx VALIDATION_SOURCES — MLPerf hardware configurations cross-checked against the chip catalogue.Published training runs feeds the MFU calibration and its range. Stated in versions.ts mfu_assumption and FlopCalculator.tsx CalibrationScopeNote — the 0.40 default calibrated against utilization reported for training runs, LLaMA 3 405B at 0.384 and PaLM 540B at 0.462 among them.The Epoch AI datasets feeds the compute unit definition. Stated in cost-index-section.tsx — the cost unit denominated in the same Epoch-sourced dense BF16 throughput.Cloud price sheets feeds the compute unit definition. Stated in cost-index-section.tsx — published hourly instance pricing normalised into the compute unit.Supply-chain relationship data feeds the cascade edge weights and decay. Stated in cascade-section.tsx — criticality derived from the supply-chain relationship rank.SEC and registry filings feeds the ownership chain-walk rules. Stated in ownership-investigator-section.tsx — the chain-of-title walk reads ownership edges populated from filings.SEC and registry filings feeds the authority-tier ladder. Stated in confidence-level-guide.tsx — tier 1 is a primary regulatory filing.The Federal Register feeds the authority-tier ladder. Stated in ownership-investigator-section.tsx — a designation, and every affiliate chain walked down from one, cites the Federal Register notice the ladder rates tier 1.SEC and registry filings feeds the reality-ratio rules. Stated in methodology page — deployed capacity verified through primary-source procurement disclosures.Customs and trade data feeds the corridor counterfactual rules. Stated in trade-flow-attribution-section.tsx — the HS 8542 filter and counterfactual window applied to declared customs values.Interconnection queues feeds the county capacity rollup. Stated in methodology page — the generator queue aggregated to county-level capacity totals.Vendor specsheetsEpoch AIdatasetsMLPerfsubmissionsPublishedtraining runsSEC & registryfilingsFederalRegisterSupply-chainrelationship dataCustoms &trade dataCloud pricesheetsInterconnectionqueuesThroughput & powerper chip familyMFU calibrationand rangeCompute unit($/petaFLOP-day)Edge weightsand decayCorridorcounterfactual rulesOwnershipchain-walk rulesReality-ratiorulesAuthority-tierladderCounty capacityrollupParameters & modelsDerived quantitiesThroughput and power per chip family feeds facility FLOP capacity. Stated in derivations.ts — peak throughput from GPU count times per-chip dense throughput.The MFU calibration and its range feeds facility FLOP capacity. Stated in derivations.ts — the training-throughput step multiplies effective throughput by the MFU assumption.The MFU calibration and its range feeds the estimation bounds. Stated in derivations.ts deriveFromHardware — the bounds are the MFU range at its floor and ceiling.Throughput and power per chip family feeds the estimation bounds. Stated in derivations.ts deriveFromHardware — peak throughput is the common factor in both bounds.The MFU calibration and its range feeds threshold crossings. Stated in flop-methodology-section.tsx — time-to-threshold divides the statutory threshold by the daily FLOP budget.Throughput and power per chip family feeds threshold crossings. Stated in flop-methodology-section.tsx — the same daily budget applies the per-chip throughput.The compute unit definition feeds the cost index. Stated in cost-index-section.tsx — the index is the compute unit priced per provider and region.Throughput and power per chip family feeds the cost index. Stated in cost-index-section.tsx — dense BF16 throughput is the denominator of the cost unit.The cascade edge weights and decay feeds cascade reach. Stated in cascade-simulator.ts — each hop multiplies the impact arriving at it by the edge’s flow share, by its criticality (a 1–10 score, divided by ten), and by the scenario’s per-hop decay.The corridor counterfactual rules feeds trade-corridor attribution. Stated in trade-flow-attribution-section.tsx — corridor change measured against the pre-event baseline window.The reality-ratio rules feeds the announced-versus-deployed reconciliation. Stated in methodology page — the reality ratio is deployed over announced, per programme.The ownership chain-walk rules feeds the compute visibility index. Stated in methodology page — the index reads the ownership chain walk to find an ultimate beneficial owner.The county capacity rollup feeds grid headroom context. Stated in methodology page — the grid context reports county totals, because a generator-queue row cannot be resolved to a named data center.Facility FLOPcapacityEstimationboundsThresholdcrossingsCost index($/petaFLOP-day)CascadereachTrade-corridorattributionAnnounced vsdeployedComputevisibility indexGrid headroomcontext
10 sources
9 parameters
9 derived quantities
26 dependencies drawn
References for diagram connections
  • Vendor spec sheets → throughput and power per chip family — versions.ts GPU_MODELS — per-chip dense throughput and TDP quoted from NVIDIA and AMD datasheets
  • The Epoch AI datasets → throughput and power per chip family — cost-index-section.tsx — per-GPU dense BF16 throughput sourced from the Epoch AI ML Hardware dataset
  • MLPerf submissions → throughput and power per chip family — validation-section.tsx VALIDATION_SOURCES — MLPerf hardware configurations cross-checked against the chip catalogue
  • Published training runs → the MFU calibration and its range — versions.ts mfu_assumption and FlopCalculator.tsx CalibrationScopeNote — the 0.40 default calibrated against utilization reported for training runs, LLaMA 3 405B at 0.384 and PaLM 540B at 0.462 among them
  • The Epoch AI datasets → the compute unit definition — cost-index-section.tsx — the cost unit denominated in the same Epoch-sourced dense BF16 throughput
  • Cloud price sheets → the compute unit definition — cost-index-section.tsx — published hourly instance pricing normalised into the compute unit
  • Supply-chain relationship data → the cascade edge weights and decay — cascade-section.tsx — criticality derived from the supply-chain relationship rank
  • SEC and registry filings → the ownership chain-walk rules — ownership-investigator-section.tsx — the chain-of-title walk reads ownership edges populated from filings
  • SEC and registry filings → the authority-tier ladder — confidence-level-guide.tsx — tier 1 is a primary regulatory filing
  • The Federal Register → the authority-tier ladder — ownership-investigator-section.tsx — a designation, and every affiliate chain walked down from one, cites the Federal Register notice the ladder rates tier 1
  • SEC and registry filings → the reality-ratio rules — methodology page — deployed capacity verified through primary-source procurement disclosures
  • Customs and trade data → the corridor counterfactual rules — trade-flow-attribution-section.tsx — the HS 8542 filter and counterfactual window applied to declared customs values
  • Interconnection queues → the county capacity rollup — methodology page — the generator queue aggregated to county-level capacity totals
  • Throughput and power per chip family → facility FLOP capacity — derivations.ts — peak throughput from GPU count times per-chip dense throughput
  • The MFU calibration and its range → facility FLOP capacity — derivations.ts — the training-throughput step multiplies effective throughput by the MFU assumption
  • The MFU calibration and its range → the estimation bounds — derivations.ts deriveFromHardware — the bounds are the MFU range at its floor and ceiling
  • Throughput and power per chip family → the estimation bounds — derivations.ts deriveFromHardware — peak throughput is the common factor in both bounds
  • The MFU calibration and its range → threshold crossings — flop-methodology-section.tsx — time-to-threshold divides the statutory threshold by the daily FLOP budget
  • Throughput and power per chip family → threshold crossings — flop-methodology-section.tsx — the same daily budget applies the per-chip throughput
  • The compute unit definition → the cost index — cost-index-section.tsx — the index is the compute unit priced per provider and region
  • Throughput and power per chip family → the cost index — cost-index-section.tsx — dense BF16 throughput is the denominator of the cost unit
  • The cascade edge weights and decay → cascade reach — cascade-simulator.ts — each hop multiplies the impact arriving at it by the edge’s flow share, by its criticality (a 1–10 score, divided by ten), and by the scenario’s per-hop decay
  • The corridor counterfactual rules → trade-corridor attribution — trade-flow-attribution-section.tsx — corridor change measured against the pre-event baseline window
  • The reality-ratio rules → the announced-versus-deployed reconciliation — methodology page — the reality ratio is deployed over announced, per programme
  • The ownership chain-walk rules → the compute visibility index — methodology page — the index reads the ownership chain walk to find an ultimate beneficial owner
  • The county capacity rollup → grid headroom context — methodology page — the grid context reports county totals, because a generator-queue row cannot be resolved to a named data center

Connections omitted because no calculation is documented:

  • Interconnection queues → reality-ratio rules — the PJM section presents the county rollup as context for the US programme, and says a generator-queue row cannot be resolved to a named facility; nowhere does it feed the queue into the ratio, so the queue is drawn as its own short chain instead.
  • Customs & trade data → cascade edge weights — two unrelated bodies of data — the cascade weights come from supply-chain relationship rank, and the trade sections state that customs declarations and BIS licence actions are rendered side by side and never combined into a single figure.
  • MLPerf submissions → MFU calibration — MLPerf’s documented role is cross-checking accelerator types and memory specs against the chip catalogue, and the MFU default is calibrated against published training runs — both dependencies are drawn, each from its own source, and neither of them is this pair.
  • Authority-tier ladder → compute visibility index — the index names four tiers of its own: its classifier reads which sources record the ownership links above an organization, and whether the organization has an SEC identifier, and never reads a record’s authority tier.
Sources are on the left, parameters and models in the middle, and calculated quantities on the right. Connections indicate the inputs to each calculation; line thickness has no quantitative meaning. The totals count items in this diagram. Select a label to read the relevant method, or expand the references above for the calculation behind a connection.
IThe evidence base

Record counts are from the snapshot dated 2026-10-22, including licensed records that cannot be browsed individually.

For regulatory and market records, the age labels change to “aging” after 7 days and “stale” after 30 days. Structural records have thresholds of 90 and 365 days; narrative records, 180 and 365 days. The age is measured from the date shown beside the label.

Data Sources

Coverage
SEC EDGAR / XBRL
Primary source for US-listed company financials. Capex, revenue, and subsidiary disclosures from regulatory filings.
T1: Government / FilingQuarterly (10-Q, 10-K)US-listed companies: financials, capex, segment data, Exhibit 21 subsidiaries
BIS Entity List
US Department of Commerce list of entities subject to export license requirements. Primary source for export control status.
T1: Government / FilingAs amendedEntity List entries and associated licensing information
GAO / SIA CHIPS Act reports
Government assessments and semiconductor-industry summaries of CHIPS Act implementation.
T1: Government / FilingAs publishedSemiconductor manufacturing investments and federal funding
Epoch AI infrastructure datasets
Research datasets assembled from public reports and other sources. Cluster upgrades may appear as separate records; location detail and measurement uncertainty vary by entry.
T2: Research DatabaseMonthlyGPU clusters and frontier data centres, including hardware, power, location and operating dates
CSET Supply Chain Data
Georgetown CSET analysis of semiconductor supply chain relationships and market share data.
T2: Research DatabaseAnnualSemiconductor supply chain topology: equipment, foundry, packaging relationships
NVIDIA Earnings Transcripts
Company disclosures on sales, customers and demand for AI hardware, including commentary on sovereign AI programmes.
T2: Research DatabaseQuarterlySovereign AI revenue, customer disclosures, GPU shipment context
Licensed corporate-ownership / fund database
Licensed records of ownership, investors and fund commitments. Transaction amounts may be undisclosed; access to the underlying records is restricted.
T3: Industry / AnalystDailyPrivate capital deals: DC investments, AI infrastructure funding rounds
Licensed corporate-event feed
Corporate announcements classified into event records, including capacity additions and investments. Access to the underlying licensed feed is restricted.
T3: Industry / AnalystDailyCorporate announcements: facility expansions, capacity additions, GPU deployments
Grid Queue Filings (PJM)
Proposed connections to the electricity grid. These records concern electricity supply and transmission; data centres awaiting power are a different population, held in no register here.
T3: Industry / AnalystMonthlyGeneration and transmission service requests, with project capacity and status
Sovereign AI Research Files
Compiled from government announcements, NVIDIA earnings transcripts, CRS reports, and press coverage.
T3: Industry / AnalystAs published36 country sovereign AI programs: announced investment, government vs. private split, deployed-vs-announced reconciliation
Press Reports / Industry Analysis
Secondary reporting may contain both quoted company figures and a journalist’s or analyst’s estimates; the source type alone does not distinguish them.
T4: Press / SecondaryAs publishedFacility announcements, capacity rumors, deployment speculation

Coverage by dataset

The counts are records held; a coverage percentage would need a defined universe to divide by, which most of these sources lack.

DatasetRecordsSources and scopeCoverage statement
Facilities4,583 across 110 countries
  • Epoch frontier-DC dataset (CC BY 4.0) — frontier data centres
  • Epoch GPU clusters dataset (CC BY 4.0) — GPU clusters
  • GAO / SIA CHIPS Act Investment Tracker — semiconductor investment projects
  • PJM interconnection queue — grid interconnection requests
  • PeeringDB + OpenStreetMap + IM3 — no published total
Facility records by source: 70 from the Epoch frontier-DC dataset, 437 from Epoch GPU clusters, 1,572 from PeeringDB, 1,173 from the expanded OpenStreetMap dataset, 391 from IM3-PNNL, and the balance from cloud-provider documentation, grid-queue discovery and direct research.
Supply-chain records20,798 supply-chain records across all sources
  • Licensed supply-chain and segment databases (held under subscription, not redistributed) — no published total
  • SEC EDGAR segment and customer disclosures (10-K, 20-F) — no published total
  • Re-derived from public primary sources (SEC EDGAR, public registries, company disclosures) — no published total
  • Scrutica research additions (chip-deployment chains citing Epoch AI, CSET ETO, vendor and press sources) — no published total
The relationship count excludes records naming only one counterparty, partnership records and association observations not yet reviewed, merges repeated records of one relationship, and drops relationships whose every record is an SEC disclosure for a fiscal period at least 5 years before the latest period-end disclosed by 20 or more filers: 11,858 supplier–customer relationships, with each product or service counted separately.
Export-control designations3,435 records (3,420 without a recorded removal date)
  • Trade.gov Consolidated Screening List: Entity List entries — supplemented with Federal Register removal records
The total includes historical records and related export-control authorities. Of the matches to organisations, 40 use name similarity and 1 an affiliate chain.
Sovereign AI programs36 country / program profiles
  • Country and programme research files — global coverage not measured
The 36 profiles are individually researched, with sources listed for each programme. No global programme list underlies the count.
FLOP / compute capacity estimates4,109 facility-level deployments
  • Hardware path: facilities with disclosed GPU count — coverage stated per path, in FLOP estimation
  • Power path: facilities with disclosed power capacity — coverage stated per path
  • Cost path: facilities with disclosed capex — coverage stated per path
The platform-level rate counts tracked facilities where at least one path produces a bounded output; per-path coverage is stated in FLOP estimation. The hardware path produces narrow bounds, and the power and cost paths widen them.
Compute Cost IndexGPU rental prices and modelled ownership costs
  • Provider pricing APIs, rate cards and third-party price mirrors — selected providers, regions and GPU instances
Rental prices are attributed to the provider’s published rates or to a third-party price mirror. On-premises costs are model estimates. The Compute Cost Index includes the source and date for individual prices; provider and instance coverage varies.
Ownership chains103,771 directed links between organisations; 130,407 organizations; 15,365 aliases
  • SEC EDGAR + HKEX public filings + licensed corporate-ownership databases (priority-targeted; held under subscription, not redistributed) — no published global total
Public-filing research targets selected companies and is combined with licensed ownership data. Coverage has not been measured against a defined set of companies or ownership relationships.
Procurement and grant recordsAwards, solicitations and funding opportunities
  • USAspending — selected industry and product codes, agencies and programmes
  • EU TED — selected procurement product codes
  • simpler.grants.gov — funding categories and text matches
Source-specific filters select records for review of AI relevance. Solicitations and funding opportunities are distinct from awards; their advertised budgets are not evidence of money spent.
Semiconductor tradeTrade values by country pair, product code and reporting period
  • UN Comtrade, CEPII BACI and national customs statistics — selected semiconductor product codes
Customs product codes group many chip types together. Trade values cannot identify individual accelerator models or establish how many GPUs crossed a border.
Chip sales (Epoch AI)Quarterly and cumulative chip-sales estimates
  • Epoch AI chip-sales dataset (CC BY 4.0) — chip types and organisations in the imported dataset
These estimates concern chip sales, with uncertainty intervals where supplied. They are separate from the customs trade records above and do not establish where the chips were installed. Source: Epoch AI.

Data Quality Framework

Provenance

data_source names the corpus a record came from, and source_url links the document where the record holds one. Every facility and company record has a data_source and an is_estimated value. A company record from a licensed corpus names that corpus and links no document. is_estimated, where a table has it, is a per-record flag, set by the pipeline step that last wrote it, under that step’s own rule. A false flag supplies no independent verification of the underlying claim.

Temporal Tracking

Capacity values are versioned in an append-only table, compute_capacity_snapshots: a change writes a new row stamped with the date the new value was learned, and the old row stays.

False Precision Ban

An unknown value is stored as null, or as 0 in the accelerator registry, where every calculation refuses a zero operand; a blank on the site means no source gives it.

The source manifest

Facility records come from Epoch AI's Frontier Data Center catalog (Tier 2), the IM3 OpenStreetMap data-center bulk corpus (Tier 3), PeeringDB facility participation tables (Tier 2), a licensed corporate-ownership database (Tier 2), SEC EDGAR primary filings (Tier 1), gridstatus.io interconnection-queue data (Tier 2) and operator press releases (Tier 3). Supply-chain edges come from licensed supply-chain databases (Tier 2), SEC Exhibit 21 subsidiary filings (Tier 1) and CSET entity classification (Tier 2). Regulatory events are pinned to Federal Register documents (Tier 1).

Confidence levels

Four authority tiers run from T1, a primary measurement or filing, down to T4, an estimate or an inference. A value takes the tier of the source it originated with: a CRS report citing a Goldman Sachs estimate takes the Goldman estimate’s tier, T3.

Tier 1: Verified
Value from a primary authoritative source with direct measurement or legal disclosure obligation.
Treatment: 123.4 MW
Examples: SEC 10-K filing capex figures; Government grant award amounts (CHIPS Act); Official facility registry coordinates; Company-reported GPU counts
Tier 2: Research Database
Value from a research organization or curated research database with documented methodology; includes peer-reviewed academic publications.
Treatment: 123.4 MW
Examples: Epoch AI training compute estimates; CSET supply chain market share analysis; Academic papers on semiconductor economics
Tier 3: Estimated
Value derived from proxy methods, industry analyst estimates, or press reports.
Treatment: 123.4 MW
Examples: GPU count derived from power capacity (Path B); Licensed-database deal size estimates; Licensed-database NLP-extracted facility capacities; SemiAnalysis capex breakdowns
Tier 4: Speculative
Value from secondary inference, expert opinion, or interpolation. Widest estimation bounds.
Treatment: 123.4 MW
Examples: GPU count from investment amount (Path C); Sovereign AI "announced" figures (government + private conflated); Grid queue entries with withheld applicant

Aggregate Confidence Calculation

A derived value takes the tier of its weakest input: a GPU count estimated from power capacity (T3) combined with a disclosed power capacity (T1) is published at T3. In tier numbers that is the largest of them, T1 being the strongest tier.

aggregate_tier = max(input_1.tier, input_2.tier, ..., input_n.tier)

Contradiction Protocol

Where sources disagree on a value, both are published with their attributions and one is named as primary. Notes give possible explanations for the difference, including differences in reporting date, method or scope.

The is_estimated Flag

A per-record flag, set by the pipeline step that last wrote it, under that step’s own rule. True means that step judged the record estimated, on grounds that include a modeled, derived or inferred value, an unconfirmed record and a secondary source. Read the flag with the record’s authority tier. Uncertainty and missingness are recorded separately: bounds where an estimate has them, and null where a value is unknown.

is_estimated: false

False means no such judgment is recorded; it is not a verification. A record holding a figure its source calculated can be flagged false. Examples: SEC 10-K capex; a research database’s reported power.

is_estimated: true

Examples: GPU count from power capacity; FLOP estimate from investment amount; market share from analyst reports; an unconfirmed cluster.

Relationships re-sourced to public filings

Some supply-chain and ownership relationships first reached Scrutica through a licensed database and have since been found in a public primary document; those now cite the public document's URL in place of the vendor's. Re-sourcing one takes a public filing that confirms both the relationship and its direction, and a verbatim quote naming both parties, before the record is re-labelled. Relationships that no public document discloses keep their licensed provenance and stay off anonymous surfaces. Three families result, named for where the public document sits: sec-edgar-rederived (a filing on sec.gov; Tier 1), public-registry-disclosure-rederived (a foreign primary registry: SIRENE, the Handelsregister, Companies House, HKEX, DART, MOPS, and equivalents; Tier 1), and company-disclosure-rederived (a company's own press release, IR page, or current report; Tier 1). A re-sourced relationship counts as a public filing wherever the site reads provenance: it ranks at primary-source authority in the chain-of-title walk, and it renders the public document's own URL. Live counts per family appear in the source breakdown on the Supply Chain dependency graph and the cascade simulation.

IIThe estimation engines

FLOP Estimation Methodology

The calculators below explore hardware, power and capital scenarios with shared utilization and interconnect assumptions. Their ranges describe sensitivity to the selected parameters.

A named-facility estimate requires operational compute-site status and a complete inventory whose partitions reconcile to the facility total. Each partition must be present capacity, be counted in accelerators and resolve to exactly one accelerator model with a dense FP16 rate that has passed evidence review (evaluateFacilityCompute() at src/lib/compute/facility-compute-evidence.ts). A partition that fails any of these is held with its reason, and one held partition withholds the facility figure; every partition and its verdict stay visible, and where a source names a family without its variant the documented variants are listed and none is applied. An admitted sum is the sum of per-partition estimates at dense FP16 under the utilization and interconnect assumptions; installed hardware does not establish availability or throughput for one training job. Named power estimates remain withheld pending separate review of the power quantity, scope, date and source.

Highest Confidence

Path A: Hardware-Based

Counts the disclosed GPUs and reads their published throughput.

In plain language
The chip count and the model are both disclosed, so the estimate rests on published spec sheets.

peak = gpu_count × fp16_tflops × 1e12

Medium Confidence

Path B: Power-Based

Works back from a facility’s disclosed power capacity to the number of GPUs that capacity supports.

In plain language
Only the electricity capacity is disclosed, so the estimate has to infer how many chips that power runs.

gpus = power × 1000 / pue × gpu_frac / tdp

Lowest Confidence

Path C: Cost-Based

Breaks a reported capital budget down into the hardware it buys.

In plain language
Only the money is disclosed, so the estimate has to assume how much of it bought chips and at what price. That is the widest assumption on the page.

gpus = invest × gpu_frac / cost_per_gpu

GPU specifications (fixed values)

Throughput is dense 16-bit tensor throughput, with no structured sparsity. Volta does not support native BF16 tensor operations, so the V100 row gives its FP16 rate.

ModelDense 16-bit TFLOP/sTDP (kW)Cost (USD)Source
NVIDIA V100 SXM21250.300—NVIDIA Tesla V100 datasheet (Volta, SXM2). Tensor performance 120 TFLOP/s at the Jul-2017 launch-datasheet clocks; NVIDIA’s later canonical V100 page and Epoch AI ml_hardware quote 125 TFLOP/s (production boost clock), used here. PCIe variant is 112. FP16 tensor throughput; Volta has no native BF16 tensor operations. Pre-Ampere: no structured-sparsity mode, so dense = the only figure. 300 W SXM2 TDP per datasheet. Long out of production; no current ASP — cost N/A.
NVIDIA A100 SXM 80GB3120.400$12K $8K–$15KNVIDIA spec sheet (Ampere). Cost: secondary market estimates, no official ASP.
NVIDIA A100 PCIe 80GB3120.300$10K $6K–$12KNVIDIA spec sheet (Ampere PCIe). Same FP16 dense as SXM; lower TDP (300W vs 400W). Cost: secondary market estimates.
NVIDIA H100 PCIe7560.350$25K $20K–$30KNVIDIA spec sheet (Hopper PCIe). Dense FP16 = 756 TFLOP/s (vs 989.5 for SXM). HBM2e (not HBM3). 350W TDP. Cost: secondary market estimates.
NVIDIA H100 NVL8350.400$30K $25K–$35KNVIDIA spec sheet (Hopper NVL). Dense FP16 = 835 TFLOP/s. 94GB HBM3 per GPU (not 80GB). Dual-GPU NVL pairs share 188GB. Cost: secondary market estimates.
AMD MI250X3830.560$12K $8K–$15KAMD MI250X datasheet (CDNA 2). Dense FP16 = 383 TFLOP/s (FP64 = 47.9). Used in LUMI (10,752 GPUs), Frontier (37,888). 128GB HBM2e. Cost: secondary market estimates.
Google TPU v42750.192—Google Cloud TPU v4 docs: 275 TFLOP/s (bf16 or int8) per chip; 32 GiB HBM at 1,200 GBps. Power: Google publishes measured min/mean/max of 90/170/192 W per chip, not a TDP — 0.192 kW (measured max) used here; Epoch AI ml_hardware lists 340 W, which reads as a per-chip share of system power. Cloud-only. Cost N/A.
Huawei Ascend 910B3750.400—No vendor datasheet exists. Dense FP16 = 375 TFLOP/s per the 910B2 row (the mid-table variant) of CSET Georgetown "Pushing the Limits" Appendix Table 2; the variant family spans 280 (910B4) to 400 (910B1). Epoch AI ml_hardware lists 376 for its base 910B row; the 375 here is CSET verbatim. TDP 400 W per Epoch; other analyses report 310–350 W. SMIC N+2 (7nm-class). Authority tier 2 (research database); treat as estimated. Cost N/A (no public ASP; domestic Chinese channel).
Google TPU v5e1970.225—Google Cloud TPU v5e docs: 197 TFLOP/s BF16 per chip; INT8 393 TOPS; 16 GB HBM at 800 GiBps. Google publishes no TDP; 225 W per Epoch AI ml_hardware (Epoch-curated, tier 2). Cloud-only. Cost N/A.
Google TPU v5p4590.540—Google Cloud TPU v5p docs: 459 TFLOP/s BF16 per chip (FP8 also 459); 95 GiB HBM at 2,765 GBps. Google publishes no TDP; 540 W per Epoch AI ml_hardware (Epoch-curated, tier 2). Cloud-only. Cost N/A.
NVIDIA H100 SXM59900.700$30K $25K–$40KNVIDIA spec sheet (Hopper). Cost: secondary market estimates, no official ASP.
NVIDIA H200 SXM9900.700$30K $25K–$35KNVIDIA H200 spec sheet (Hopper). Same compute as the H100 SXM5; the H200's advantage is memory — 141GB of HBM3e at 4.8 TB/s. Cost: secondary market estimates, no official ASP.
NVIDIA B2002,2501.000$45K $35K–$55KNVIDIA Blackwell Technical Brief (HGX B200, 1000W). Dense FP16; sparse = 4,500.
AMD MI300X1,3070.750$15K $10K–$25KAMD MI300X datasheet (CDNA 3). 1,307.4 TFLOPS is dense FP16; 2,614.9 with sparsity. Cost: secondary market estimates, no official ASP.
NVIDIA GB200 (per GPU)2,5001.200$60K $40K–$70KNVIDIA spec sheet (Blackwell). Dense FP16/BF16 Tensor = 2,500 TFLOP/s per GPU. GB200 superchip contains 2 GPUs; values here are per-GPU. Cost is estimated (no official ASP; range from analyst estimates). Verified against Epoch AI ml_hardware.csv.
NVIDIA GB300 (per GPU)2,5001.400—NVIDIA GB300 NVL72 page (Blackwell Ultra): FP16/BF16 Tensor = 360 PFLOP/s with-sparsity per 72-GPU rack → 5,000 sparse / 2,500 dense per GPU under NVIDIA’s 2:4 convention; Epoch AI ml_hardware lists 2,500 dense directly. FP8 dense = 5,000, NVFP4 dense = 15,000 per NVIDIA Technical Blog "Inside NVIDIA Blackwell Ultra" Table 2. 288 GB HBM3E. Per-GPU TDP not vendor-published; 1,400 W per Epoch ml_hardware, corroborated by deployment analyses (liquid-cooled in all form factors). The air-cooled HGX B300 runs 2,250 dense at 1,100 W — this entry is the NVL72 configuration, and any facility record naming a GB300 resolves to it. Cost: no official ASP; N/A.
AMD MI325X1,3071.000—AMD Instinct MI325X data sheet (CDNA 3). Dense FP16 = BF16 = 1,307.4 TFLOP/s (2,614.9 with 2:4 sparsity); FP8 dense = 2,614.9. Same compute silicon as MI300X — the generational change is memory: 256 GB HBM3E at 6 TB/s (vs 192 GB HBM3 at 5.3 TB/s). Max TBP 1,000 W. Matches Epoch AI ml_hardware. Cost: no verified ASP or secondary-market range in hand; N/A.
AMD MI350X2,3101.000$20K $15K–$30KAMD product brief (CDNA 4). Dense BF16 = 2,309.6 TFLOP/s; FP8 = 4,600. 288GB HBM3E, 8 TB/s bandwidth. Shipped Q3 2025. Cost is estimated (no official ASP). Verified against Epoch AI ml_hardware.csv.
Amazon AWS Trainium26670.500—AWS Neuron docs (Trainium2 architecture). Dense BF16 = 667 TFLOP/s; FP8 = 1,299 TFLOP/s; 96GB HBM3e. TDP ~500W (SemiAnalysis). Not sold individually; cloud-only via EC2 trn2 instances (Anthropic Project Rainier). Cost N/A. Corroborated by SemiAnalysis Trainium2 architecture teardown; the facility ingest applies the same 667 per chip.
Amazon AWS Trainium36710.700—AWS Neuron docs. Dense BF16 = 671 TFLOP/s; FP8 = 2,517 TFLOP/s (2.52 PFLOPS). TDP 700W (SemiAnalysis estimate). Not sold individually; cloud-only via EC2 trn3 instances. Cost N/A. Verified against Epoch AI ml_hardware.csv.
Google TPU v6e (Trillium)9180.380—Google Cloud TPU v6e docs: 918 TFLOP/s BF16 per chip; INT8 1,836 TOPS; 32 GB HBM at 1,638 GBps. Google publishes no TDP; 380 W per Epoch AI ml_hardware (Epoch-curated, tier 2). Cloud-only. Cost N/A.
Google TPU v7 Ironwood2,3070.960—Google Cloud TPU docs. BF16 = 2,307 TFLOP/s; FP8 = 4,614. TDP ~960W (derived: 29.3x efficiency vs TPUv2 per Google blog). Cloud-only via TPU API. Cost N/A. Verified against Epoch AI ml_hardware.csv.
NVIDIA Rubin preliminary; subject to change4,000——NVIDIA HGX Rubin platform specifications (preliminary; subject to change). One Rubin GPU is listed at 4 PFLOP/s dense FP16/BF16. NVIDIA’s 50 PFLOP/s NVFP4 figure is sparse and is not substituted for dense training throughput. Per-GPU TDP and unit price are not recorded here.
Microsoft Maia 200—0.750—Microsoft Maia 200 launch article. Each Maia 200 chip is listed at 750 W SoC TDP. Dense FP16/BF16 throughput and per-unit price are not recorded in this registry; Microsoft’s published FP4/FP8 throughput is not substituted for the dense training-throughput field.

Parameters shared by every path

Range
Interconnect Efficiency
Throughput multiplier for interconnect losses beyond those in the utilization rate. The default applies none, because the utilization default is an end-to-end rate reported from training runs. Lower it only for a cluster whose interconnect is weaker than that of the runs behind that rate, such as one built from the export-restricted H800 or A800.
1.000.60–1.00Scrutica modeling assumption
Model FLOP Utilization (MFU)
Utilization multiplier applied to dense peak throughput. PaLM 540B reports 46.2% model FLOP utilization and 57.8% hardware FLOP utilization; the latter includes rematerialization, and both figures describe that run.
0.400.20–0.50SemiAnalysis, “100,000 H100 Clusters” (2024-06-17); benchmark context: PaLM, Table 3

Path A: Hardware-Based: tunable parameters

Path A: Hardware-Based has no parameter of its own; it runs on the shared ones above.

Path B: Power-Based: tunable parameters

Range
GPU Fraction of IT Load
Assumed share of IT power allocated to accelerator chips. The remainder covers other IT equipment; cooling outside the IT boundary is handled through PUE. A facility’s rack composition and operating GPU count require separate evidence.
0.490.35–0.65Scrutica modeling assumption
Power Usage Effectiveness (PUE)
Total facility power divided by IT-equipment power. The default converts a reported facility power figure to an assumed IT load; a site's own disclosure, for the same facility scope and operating period, replaces it where one exists.
1.151.05–1.45Scrutica modeling assumption

Path C: Cost-Based: tunable parameters

Range
GPU Fraction of Capex
Assumed share of a project’s capital expenditure allocated to accelerator purchases. A project budget may also cover later phases, land, buildings and infrastructure, which this share does not separate.
0.450.30–0.60Scrutica modeling assumption

Interactive FLOP estimator

Highest Confidence. Counts the disclosed GPUs and reads their published throughput.

In plain language
The chip count and the model are both disclosed, so the estimate rests on published spec sheets.
10,000
1.00
0.40
Peak dense 16-bit throughputMaximum processing speed
9.89 times 10 to the 18 FLOP/s
Training throughputEffective training speed
3.96 times 10 to the 18 FLOP/s
Daily FLOP budgetDaily compute capacity
3.42 × 1023 FLOP
Estimation bounds (log scale)0.6 orders of magnitude
1.03 × 10233.42 × 10234.27 × 1023

EU AI Act 1025 thresholdAt the selected daily budget, 1025 FLOPs equals 29 days of compute

Under Article 51(2), a general-purpose AI model trained with more than 1025 FLOPs is presumed to have high-impact capabilities. Article 52 requires provider notification and permits a substantiated argument against systemic-risk classification. Providers of models classified with systemic risk must assess and mitigate those risks under Article 55.

Derivation steps

  1. Peak FP16 Throughput
    peak_flops = gpu_count × per_gpu_fp16_tflops × 1e12
    gpu_count
    10,000
    per_gpu_fp16_tflops
    989.5
    peak_flops9.89 times 10 to the 18 FLOP/s
  2. Effective Throughput
    effective_flops = peak_flops × interconnect_efficiency
    interconnect_efficiency
    1.00
    effective_flops9.89 times 10 to the 18 FLOP/s
  3. Training Throughput
    training_flops = effective_flops × mfu_assumption
    mfu_assumption
    0.40
    training_flops3.96 times 10 to the 18 FLOP/s
  4. Daily FLOP Budget
    daily_flop_budget = training_flops × 86,400
    seconds_per_day
    86,400
    daily_flop_budget3.42 times 10 to the 23 FLOP/day

Compute Cost Index

The index divides published rental prices by hardware throughput to compare the cost of compute across GPU configurations. Cloud rates price peak capacity; the on-premises calculator also accounts for assumed utilisation.

Compute units

1 petaFLOP-day = 1 petaFLOP/s sustained for one day
    = 8.64 × 1019 FLOP

The cloud calculation divides daily instance cost by GPU count and per-GPU dense BF16 throughput in PFLOP/s.

In plain language

A lower hourly price can buy less compute if the instance contains fewer or slower GPUs. Price per petaFLOP-day accounts for that difference. Workload efficiency still determines how much training those rented hours accomplish.

Cost normalization

Per-GPU hourly rate (rate ÷ GPUs)
$0.4375/hr
GPU throughput (peak, dense BF16)
0.990 PFLOP/s
$/petaFLOP-hour (rate ÷ throughput)
$0.442142
$/petaFLOP-day (hourly cost × 24)
$10.6114

Cloud converts a quoted rate at peak throughput into the price of a petaFLOP-day of purchased capacity; that is the conversion the Cost Index applies to every published rate. On-premise divides lifetime cost by output at MFU, so it prices a petaFLOP-day delivered. Purchased and delivered are different denominators, so the two are not competing estimates of one number.

BF16 TFLOP/s dense, no 2:4 structured sparsity (source: Epoch AI ML Hardware dataset). On-prem defaults: MFU , PUE , $5K networking + $3K facility share per GPU (editorial estimates, tier 4).

Sub-indices

Cloud on-demand and spot

Published on-demand and spot rates for GPU instances from AWS, Azure, GCP, Oracle, CoreWeave and Lambda.

Provider pricing APIs · Published price pages

Cloud reserved

One-year and three-year reserved rates, where a provider publishes them.

Provider pricing APIs · Published price pages

On-premises

Lifetime cost per GPU (a secondary-market hardware price, power at an adjustable price per kWh and PUE, and per-GPU networking and facility shares) divided by lifetime output at the selected utilization.

Secondary-market GPU price estimates · Editorial networking and facility shares (tier 4)

Data collection scheduleHow prices are collected

Data sourceCadenceMethod
Cloud Provider APIs (Azure, OCI; AWS spot)DailyVercel cron
AWS Pricing Bulk API (on-demand)DailyGitHub Actions
Cloud Provider Pricing Pages (GCP, CoreWeave, Lambda)Manual refreshManual snapshots of published pricing pages

Published training costs

Every training-cost figure on the site is one someone else published: an Epoch AI estimate, in 2023 US dollars, or a lab’s own statement, each listed with its publisher, its dollar basis and a public source link. Runs without a published figure are omitted. The ledger sits at the foot of the Compute Cost Index.

Sources

Chokepoint Cascade Simulation

The simulation walks outward from the disrupted supplier through a weighted directed graph of supply-chain relationships, breadth-first, one hop at a time. The impact carried forward at each hop is parentImpact × flowShare × (criticality / 10) × propagationDecay. flowShare is the share of the customer’s input for that product that comes from this supplier, and defaults to 30% where no share is recorded. criticality is derived from the licensed supply-chain database’s relationship-rank field (seven buckets: 2, 3, 4, 5, 6, 7, 8) where the licensed record behind the edge has a rank, and defaults to 5 where no source states a score, curated-seed edges included. propagationDecay is a per-scenario judgment of how readily the input can be sourced elsewhere. The licensed database’s annual_value_usd is stored as edge metadata and is not used in this formula. The cutoff is applied after all per-hop attenuation. Non-seed scores below 5% are omitted, and paths stop after six hops. The strongest path determines each score; independent supplier losses are not added. This is an exposure calculation with uncalibrated weights, rather than a product-level production model.

In plain language

The simulation traces conditional exposure through recorded supplier–customer relationships. No source states a supply share for any pair, so every edge uses the 30% default; the sensitivity runs below vary only the per-hop decay. It has not been calibrated to predict production losses or recovery dates.

How disruptions propagate

// Depth-indexed propagation — simulateForwardDisruption() in src/lib/compute/cascade-simulator.ts
frontier = unique, present seeds with their per-node severity
result = frontier
for depth = 1..6:
  next = empty map
  for each (parent, impact) in frontier:
    for each supplier-to-customer edge from parent:
      candidate = impact × flowShare × criticality/10 × decay × policyFilter
      if candidate >= 0.05:
        next[customer] = max(next[customer], candidate)
  result = nodewise_max(result, next)
  frontier = next

Each depth is solved independently. No per-node visit cap.
For upstream runs, replace flowShare with the normalized customer-weight proxy.
Bidirectional runs take the nodewise maximum of separate forward and reverse runs.

propagationDecay is a per-scenario constant in the 0.65–0.95 range; the table below gives each scenario’s value and the reasoning behind it. The reverse walk, from customer back to supplier, uses approximateRevenueShare in place of flowShare to model demand loss propagating upstream.

Model settings

ParameterDefaultRangeDescription
max_hops6 hops6–6Fixed maximum path length. Hop count is graph distance, not elapsed time.
initial_shock_severity10.1–1Severity of the initial disruption at the source node (1.0 = complete disruption).

Parameter sensitivity

Complete loss of TSMC Taiwan fab capacity (natural disaster, blockade).

Propagation decay0.90
0.30 · rapid attenuation0.95 · near-full propagation
Decay 0.300orgs, 0 hops
Decay 0.9014orgs, 1 hop
Decay 0.9514orgs, 1 hop
Affected organizationsPropagation decay

ScenarioTSMC Taiwan Disruption

Simulated at decay0.90Affected organizations141 hop

Affected organizationsPropagation decay; Affected organizations; Select a simulated point; 0.30, 0 affected organizations, 0 hops; 0.35, 14 affected organizations, 1 hop; 0.40, 14 affected organizations, 1 hop; 0.45, 14 affected organizations, 1 hop; 0.50, 14 affected organizations, 1 hop; 0.55, 14 affected organizations, 1 hop; 0.60, 14 affected organizations, 1 hop; 0.65, 14 affected organizations, 1 hop; 0.70, 14 affected organizations, 1 hop; 0.75, 14 affected organizations, 1 hop; 0.80, 14 affected organizations, 1 hop; 0.85, 14 affected organizations, 1 hop; 0.90, 14 affected organizations, 1 hop; 0.95, 14 affected organizations, 1 hop

Results from BFS propagation over the live supply-chain graph (5 scenarios, 14 decay points each). For the full animated simulation, see the Cascade Simulation. Higher decay means more severe propagation: each hop retains a larger fraction of the disruption.

Decay rate per scenario

These per-scenario propagationDecay constants are editorial tier-4: hand-authored per scenario against market-share data, sole-source status and substitution-path qualification. This implementation has not fitted the decay parameters to historical observations. Although chosen to express relative substitutability, the numbers enter a multiplicative formula and therefore make cardinal assumptions. Their ranking alone cannot justify the resulting magnitudes. Source of truth: PREBUILT_SCENARIOS in src/lib/compute/cascade-simulator.ts.

ScenarioDecayRationale
TSMC Taiwan Disruption0.90TSMC is deeply embedded in advanced-node logic, but some customers maintain Samsung Foundry and Intel Foundry relationships at lower nodes — a non-trivial fraction of impact is absorbed at the first hop.
ASML Export Halt0.95The high propagation factor assumes limited substitution for ASML equipment. Effects on individual customers depend on their fabrication processes and alternative capacity.
US–China Full Decouple: Revenue Impact0.70Domestic substitution (Huawei Ascend, SMIC at advanced nodes, domestic EDA pilots) dampens each upstream hop as US revenue loss propagates back through the supply chain.
US–China Full Decouple: Access Denial0.80Upstream dependency on US tools (EDA, advanced equipment, foundry access) is structural for Chinese AI compute consumers — domestic substitutes exist but cover narrow node ranges, so impact propagates with little dampening per hop.
CoWoS Advanced Packaging Bottleneck0.70Multi-source packaging via OSAT partners (Amkor, SPIL handling 240–270K wafers/year overflow) now dampens downstream propagation; CoWoS capacity tripled to ~75K wafers/month by end-2025 per TrendForce.
SK Hynix HBM Disruption0.80The model assumes that alternative HBM suppliers dampen propagation at each hop. Product qualification and spare capacity are not measured by the supplier revenue shares.
EDA Export Restriction0.80Synopsys and Cadence jointly control ~62% of the global EDA market; open-source alternatives (qflow, OpenROAD) exist at trailing nodes but not at production scale for advanced logic, so most downstream chip-design work cannot continue without them.
Chiplet Assembly Disruption0.75Compound packaging + EDA disruption hits chiplet-architecture chips (AMD MI300X, NVIDIA Blackwell) disproportionately; some single-die monolithic designs and trailing-node products are insulated, providing modest per-hop attenuation relative to the blanket scenarios.
Qatar helium disruption (March 2026)0.75The decay assumes partial substitution through alternative supplies and inventories. Their availability to the selected companies is not quantified; USGS reports no government helium stockpile in 2026.
InP/EML Laser Shortage0.80The per-hop decay of 0.80 is a scenario assumption. CW lasers feeding silicon-photonics modulators can still require InP, so switching modulator designs does not establish independence from this material.
ABF build-up film supply (Ajinomoto)0.95The high decay factor assumes limited near-term substitution for the insulating film. No verified replacement timeline or customer-level switching estimate is supplied.
Gallium/germanium controls return (after 27 Nov 2026)0.65Recycling, stockpiling, and alternative sourcing (allied gallium production restarts, germanium recovery from zinc smelting) dampen downstream impact; the run models a hypothetical return of restrictions at the scheduled end of the suspension rather than a current disruption, so the per-hop attenuation reflects substitution options rather than realized substitution.
CoWoS 2026 Allocation Constraint0.85Structural shortfall with no alternative CoWoS-L packaging at volume; OSATs cannot replicate Blackwell-class packaging at scale, and NVIDIA holds more than half of TSMC’s CoWoS allocation (above 60% on Morgan Stanley and Bernstein estimates, above 50% on TrendForce’s), so non-NVIDIA AI GPU production absorbs the constraint with limited dampening.
Japan Semiconductor-Input Seismic Shock (Korea coupling)0.82Silicon-wafer and advanced-photoresist supply is highly Japan-concentrated with thin qualified second sources, so the first hop from the input makers carries most of the shock; downstream memory customers hold some inventory buffer and partial multi-sourcing, which dampens each subsequent hop.
Allied Coordination: TSMC Advanced Node Restriction0.90Substitutability is unchanged from the blanket TSMC disruption (Samsung Foundry / Intel Foundry absorption capacity is identical regardless of who is restricted); what separates this from a blanket outage is a country test applied to every edge, which zeroes impact on allied-country customers and leaves everyone else at full impact, rather than anything in the per-hop decay.
EDA License Restriction: China Entity List Expansion0.80Substitutability is unchanged from the blanket EDA scenario; the ~62% market concentration of Synopsys + Cadence holds whether the restriction targets China specifically or all customers, so per-hop attenuation tracks the underlying tool dependency rather than the policy framing.
Netherlands DUV Export Restriction to China0.85DUV is replaceable at mature nodes (Nikon and Canon retain ArF and KrF capacity for nodes ≥28nm), so per-hop attenuation is meaningfully greater than for EUV — but advanced-DUV ArF immersion remains effectively sole-source ASML for 7nm-class multi-patterning work.
China Critical Minerals Retaliatory Restriction0.65Substitutability tracks the "Gallium/germanium controls return (after 27 Nov 2026)" scenario (recycling, stockpiling, allied gallium production restarts dampen each hop); the two runs share seeds, severity and decay, and differ only in the country filter that passes impact to allied-country targets and zeroes it elsewhere.
Multilateral Cloud Compute Access Restriction0.75Restricted-jurisdiction customers have domestic cloud alternatives (Alibaba Cloud, Tencent Cloud, Yandex, regional sovereign clouds); the decay assumes those substitute for part of the lost US-hyperscaler capacity and model access, not all of it.
Netherlands EUV Restriction: Allied Countries Only0.95Substitutability is unchanged from the blanket ASML export-halt scenario — EUV remains zero-alternative-supplier regardless of which jurisdictions retain access; the allied-only carve-out is a country test applied to every edge, zeroing impact on allied-country customers, rather than anything in the per-hop decay.

Domain reference: substitutability by category

Category-level substitutability, scored 0 to 1: 0.02 for EUV lithography, where ASML is the sole source, up to 0.50 for data-centre construction, where contractors are interchangeable. These scores are a domain reference with their own provenance in market shares, sole-source status and capacity data; the simulator runs on the per-scenario propagationDecay constants in the table above, which are separate editorial assessments about the same subjects. The two scales point opposite ways: a low score here means no substitute exists, while a high decay there means a shock travels far.

CategorySubstitutabilityDescription
EUV Lithography0.02Near-zero substitutability. ASML sole source.
Advanced Foundry (<7nm)0.05TSMC dominant. Samsung limited alternative.
GPU Accelerators0.15NVIDIA dominant but AMD MI300X is a partial substitute.
HBM Memory0.10SK Hynix ~50%, Samsung ~33%, Micron ~18% of HBM revenue (Counterpoint Research, Q2 2026). HBM4 mass production began Feb 2026 (SK Hynix at M16/M15X; Samsung at Pyeongtaek). Concentrated but multi-source. Updated 2026-10-23.
Advanced Packaging (CoWoS)0.15TSMC dominant for CoWoS; capacity ramping 75-80K wafers/month (early-mid 2026) toward 120-130K by end-2026 (TrendForce + TSMC Q1 2026 earnings; CoWoS yield reported >98% May 2026). OSAT partners (Amkor ~180-190K, SPIL ~60-80K wafers/year) handle overflow. CoWoS-L/S reported fully booked through 2026 — the bottleneck analysts had called "effectively resolved" is now allocation-bound (NVIDIA >50% of capacity) rather than capacity-bound. Substitutability still meaningful from OSAT overflow. Source: TrendForce + TSMC IR (Tier 2). Updated 2026-05-19.
AI Networking (InfiniBand + Ethernet)0.30Ethernet surpassed InfiniBand in AI back-end network revenue in 2025 (Dell'Oro Group). UEC 1.0 (June 2025) achieves InfiniBand-class performance. Meta validated Ethernet RoCE at 24K GPUs. Higher substitutability than pre-2025 InfiniBand monopoly. Trajectory unchanged through Q1 2026; no material movement in InfiniBand-vs-Ethernet share. Updated 2026-05-19.
Data Center Construction0.50Many EPC contractors globally. Highly substitutable.
Power Delivery0.25Regional utilities, PPAs, on-site generation available in theory, but PJM capacity prices surged 10x ($329/MW-day for 2026-27 vs $29/MW-day for 2024-25). AEP Ohio paused new DC interconnections. FERC issued a Dec 18, 2025 final order directing PJM to file new co-location tariffs (compliance Jan 20 + Feb 16, 2026); reforms are progressing but the queue remains binding (TC1 process ~1.75y entry-to-cluster-end vs the 1y efficient-process target). Power remains a binding constraint on expansion. Substitutability lower than pre-2025 assessment. Source: PJM capacity auction (Tier 1); FERC final order (Tier 1). Updated 2026-05-19.

Inventory buffers in the week-by-week run

Every duration, depletion shape and range below is a Tier-4 scenario assumption. Company-wide inventory accounting does not identify usable stock at a particular customer; order lead times and installation times do not establish an inventory buffer. In the implemented temporal envelope, an edge’s depletion clock starts when a positive upstream impact first reaches it. Its buffer protects only that edge. The engine then propagates the attenuated impact onward. This is not a conserved-stock inventory simulation; stock replenishment and a temporary shock’s duration are absent.

LayerBufferRangeShapeTier
EUV LithographyNone0–0 wkcliff T4
Advanced Wafers (N3/N5)10 wk8–16 wklinear T4
Packaged Chips (GPU)3 wk2–5 wkcliff T4
Server Assembly14 wk8–26 wkexponential T4
HBM Memory3 wk0–8 wkcliff T4
ABF Substrates12 wk4–30 wklinear T4

Source check: NVIDIA’s Q3 FY2026 filing reports inventory carrying values; it does not measure customer-specific GPU cover. Micron’s December 2025 remarks describe agreements covering its 2026 HBM supply, which does not establish spare supply for replacing a disrupted competitor. Server assembly and ABF buffer definitions above are retained reference assumptions; the edge builder currently attaches the EUV, wafer, packaged-chip and HBM categories.

Substitution elasticity in the week-by-week run

Qualification time, ramp duration and spare-capacity ceilings are Tier-4 assumptions. Qualification for one product or customer does not establish compatibility elsewhere, and market share does not establish uncommitted capacity. The assumed recovery follows an S-curve on its own edge; a substitute affected by the same static scenario receives proportionately less recovery credit. Capacity is not allocated across competing customers, and unidentified alternative suppliers remain an assumption. Inventory and substitution adjustments apply only to supply-direction propagation; upstream revenue exposure has no calibrated timing model.

Disrupted supplierSubstituteQualificationCeilingTier
TSMC Advanced NodeSamsung Foundry24mo15% T4
Intel Foundry (IFS)36mo5% T4
ASML EUVNo viable substitute
SK Hynix HBMSamsung HBM0mo45% T4
Micron HBM0mo25% T4
NVIDIA Training GPUsAMD MI300X/MI35012mo15% T4
TSMC CoWoS PackagingAmkor (OSAT)18mo20% T4
SPIL (OSAT)18mo10% T4

Historical reference cases

These cases provide context for the mechanisms under discussion. The model has no fitted objective, event-matched prediction errors or held-out evaluation against them. The archived scenario runner compares alternative graph weights; it does not calibrate buffer depletion or substitution. A future empirical evaluation requires dated supplier networks, product-level outcomes and shock timing, with parameters fixed before the evaluation period.

Samsung Austin power outage

Date
April 2021 earnings report
Company statement
Samsung reported an Austin production interruption from a major power outage. Production had resumed by April 29; the company expected effects on System LSI to continue into Q2.
What it establishes
The release does not measure the propagation delay or inventory duration used by this model.

Source: Samsung Q1 2021 earnings release T1

TSMC materials-supply assessment

Date
April 2022 earnings call
Company statement
TSMC said it sourced neon and xenon from suppliers in multiple regions, held inventory, and expected no operational impact from materials supply.
What it establishes
This was one company’s contemporaneous expectation. It does not establish subsequently observed zero losses across major fabs or a measured inventory duration.

Source: TSMC Q1 2022 transcript, page 4 T1

CoWoS capacity expansion

Date
October 2023 earnings call
Company statement
TSMC said supplier capabilities and capacity constrained CoWoS expansion and maintained its target to double CoWoS capacity by the end of 2024.
What it establishes
An expansion target does not measure realized substitution capacity, order lead times or inventory protection.

Source: TSMC Q3 2023 transcript, page 17 T1

Edge Weight Coverage

Cascade propagation runs server-side over the whole dataset: 20,798 source rows across every source, licensed and public, entity-resolved and deduplicated to 11,858 supplier–customer relationships, keyed on the published product or service. Rows naming only one endpoint (“this supplier sells to N unnamed customers”) are dropped before that count is struck, because a cascade needs two named ends to travel between. Rows recording a partnership rather than supply (a partner relationship in the licensed database, or product text naming a partnership) are left out of it, since a partnership moves nothing from supplier to customer, and so are the historical relationships described next: the count is the graph the engine walks. The engine rebuilds that graph live and walks 11,920 edges across 4,201 organizations, which is the figure the simulation API reports. These counts read from the dataset snapshot of 2026-10-22 and move with every refresh, so the engine’s live count and the snapshot’s can sit a refresh apart. Where several rows record the same relationship, its edge takes every weight from one of them, the latest that states a share or criticality score. The coverage figures below were measured before that rule, when an edge combined the weights of all its rows.

A relationship is historical when every observation of it is an SEC disclosure for a fiscal period ending five or more years before the corpus’s latest filing wave: the latest period-end that at least 20 filers disclose (2024-12-31 on the measurement day, so 2019-12-31 or earlier). A wave sets the clock rather than the newest single date, which one issuer’s filing can set: every December period-end since 2019 has 83 to 101 filers, and no other more than 12. Within a pair, consecutive disclosures fall one year apart 91.2% of the time and at most five years apart 98.5%, so five silent years is where the corpus’s own evidence of a continuing relationship ends; that is a statement about evidence, not a proven end, since a supplier stops naming a customer once it falls below 10% of revenue. Only dated SEC disclosures can be historical, and an undated or curated observation keeps its relationship current. The rule marks 1,367 of 13,233 supplier–customer pairs in the full corpus and 991 of 1,938 in the public projection. A recorded end date is a separate test that any observation can meet: a relationship whose every observation records an end on or before the day the graph is built has ended, and it is neither drawn nor propagated, though the graph’s JSON keeps it with the latest of those dates. An SEC disclosure of a customer above 10% of revenue, the commonest public source for these relationships, evidences that the relationship exists and that the supplier’s revenue is concentrated on that customer; it does not evidence the customer’s dependence on the supplier, the direction in which a disruption travels here.

Of these relationships, 1,924 come from a licensed layer limited to relationships between organizations already in Scrutica's records.

Edge weights draw on three signals. Supply share (% of the customer’s input from this supplier) enters only where a source states it for the pair, and no propagation edge currently has one, so every edge uses the default of 30%. Of the four shares that previously reached propagation edges, one cites no source and three measure the supplier’s revenue from the customer, a different quantity. Criticality (1–10 replaceability) is populated on 86.11% of propagation edges (59.08% of raw rows), all of it bucketed from the relationship-rank field of the primary licensed supply-chain database, which takes seven values, 2 through 8; the two re-derived disclosure sources have the rank inherited from that record on 22.9% and 79.4% of their raw rows. Scores assigned during curation are withheld, since no source states them, and every other edge falls back to a default of 5. An edge whose cited source states a sole-source relationship is raised to criticality ≥ 9; none currently does, and the stored sole-source flags are withheld with the reason each fails, set out on the supply-chain sheet.

The third signal is experimental financial-comovement weighting (off by default), which blends criticality with the 3-month stock-price correlation (Pearson r, available on 67.54% of propagation edges and 45.98% of raw rows, from the same measurement) via adjustedCriticality = w × clamp(5(1+r), 1, 10) + (1−w) × current, where w defaults to 0.5. For edges without correlation data the unblended criticality stands alone, and an admitted sole-source edge keeps criticality ≥ 9 regardless of correlation. Pearson correlation measures symmetric financial association; this conversion has not been validated as a directional supply-dependency measure. Price correlations are from licensed market-data downloads held under subscription, not redistributed (vintage: April 2026).

Total Affected Compute Metric

The run declares one weighting basis. With facility estimates, it sums each organization’s exposure score times its recorded estimated FLOP/day and divides by the recorded compute denominator. Organizations with no attributed estimate contribute zero; their exposure is still listed. If facility estimates are absent for the whole graph, the engine uses a separate degree-based network score, which is not a percentage. The two bases are never blended. A compute-weighted exposure score does not establish that installed capacity stops operating when a supplier’s new deliveries stop.

Graph Edge Sources

Every edge enters the simulation payload with the data_source it was ingested from and the authority tier of that source. Neither enters the propagation formula, which runs on flow share, criticality and per-hop decay alone.

CSET Provision Data

T2 · Equipment supplier → foundry, foundry → chip designer

Topology only (no bilateral specificity).

SEC filings

T1 · Supplier → customer

Both counterparties are named in the source.

Licensed supply-chain database

T2 · Supplier → customer

Both counterparties are named in the source.

Trade-Flow Attribution

For each US action dated 2012 to 2023, Trade Impact compares chip trade along selected country pairs in the calendar year after the action with its average over the two calendar years before, and prints the difference without adjustment for the chip cycle.

One source per corridor

The sources that report a corridor measure the same trade, so they are never added together. A corridor’s figures come from the first of UN Comtrade, Taiwan Customs, the US Census Bureau, CEPII BACI and Japan e-Stat to report every year of both windows in the corridor’s direction, and the others are drawn beside it in the corridor’s evidence. China GACC files each partner’s imports and exports as one figure, so it is drawn but never read as a corridor. A featured corridor that no single source covers is listed as not measured. The order is set in HEADLINE_BASIS_ORDER.

Verdicts

Featured corridors are chosen by hand for the actions that have them; the United States–China corridor is read from China’s own filings. Each featured corridor’s verdict compares its change with the change in the reporting country’s total trade in the same direction, read from the same source, over the same two windows:

  • Reduced: the corridor fell 10% or more, and the total fell by more than 5%, no more than 20 percentage points from the corridor’s change.
  • Redirected: the corridor fell 10% or more while the total fell 5% or less, or grew.
  • Expanded: the corridor grew 10% or more and the total did not fall by more than 5%.
  • Absorbing: the corridor grew 10% or more while the total fell by more than 5%.
  • Ambiguous: the corridor moved less than 10% either way, or both fell but more than 20 points apart.
  • Not measurable: the corridor or the total has no baseline, or the partners the reporting country still reports after the action held less than half of its baseline trade.

A card names any of the 2020 COVID crash, the 2021 boom or the 2023 trough that falls in either window, and actions in the same calendar year, which share both windows, list one another. Subsidy and framework actions, such as the CHIPS and Science Act, get neither a verdict nor a cycle caveat; their cards say instead that corridor changes reflect the restrictions and market conditions around them. When an action is selected, the view adds the largest dollar changes among other corridors that averaged at least $100 million a year in the baseline, each read from one source in the same order and from export rows only; these are shown without a verdict. The windows and caveats are set in getTradeFlowImpactData() in src/lib/data/trade-flow-impact.ts, the thresholds in classifyCorridorChange(), the featured pairs in EVENT_CORRIDORS and the added ones in discoverTopCorridors().

Regional billings

Beside the corridors, the page compares WSTS Blue Book semiconductor billings for the Americas, Europe, Japan and Asia Pacific, month by month, with a counterfactual: each month a year earlier, scaled by one factor per region. The level-anchored factor, the default, is the action month’s billings over the same month a year before, so the two lines meet in the action month; the six-month anchor divides the six months before the action by the same six months a year earlier; raw year-over-year applies no factor. Where a month a factor needs is missing, the factor is 1, which is the raw comparison. The gap is summed over the action’s month and the eleven after it, as many of them as the series holds, per region and then across regions, and a window of fewer than twelve months says how many it covers. The redirection ratio is the regions’ gains above the counterfactual over their losses below it, capped at 1. None of the three separates an action from the chip cycle. The factors are set in computeEventImpact().

Sources

  • WSTS Blue Book (authority tier 1). Monthly semiconductor billings by region; the counterfactual comparison only.
  • UN Comtrade (authority tier 1). Trade as each reporting country files it, 2010 to 2024.
  • CEPII BACI (HS92) (authority tier 2). Comtrade filings with the exporter’s and the importer’s reports of each flow reconciled, in the 1992 edition of the Harmonized System; 2010 to 2024.
  • US Census Bureau international trade statistics (authority tier 1). US-reported trade, 2022 to 2024; no featured corridor uses it.
  • Taiwan Customs (DGCAS) (authority tier 1). Taiwan-reported trade from 2010, with 2026 partial.
  • China General Administration of Customs (GACC) (authority tier 1). China-reported trade from 2015, with 2026 partial; each row combines imports and exports with one partner. China’s filings also reach Scrutica through Comtrade, which is the same reporting by a second route; the independent check on China’s figures is what its partners report.
  • Japan e-Stat (Ministry of Finance customs statistics) (authority tier 1). Japan-reported trade from 2011, with 2026 partial.

Limitations

  • Chips, not equipment. The series covers integrated circuits: UN Comtrade, Taiwan Customs and China GACC are read on HS 8542.31/.32/.39; Japan e-Stat on HS 8542.31/.32/.33/.39; the US Census Bureau on HS 8542.31/.32/.33/.39/.90; CEPII BACI on HS 8542.11/.19/.90 in the 1992 edition of the Harmonized System. Semiconductor manufacturing equipment (HS 8486) is outside it, so the two October 2023 corridors labelled for equipment restrictions (the Netherlands and Japan to China) measure chip trade, not the equipment their labels name.
  • One baseline. Only the two-year baseline is computed; a longer baseline or a synthetic control could give different magnitudes.
IIIOwnership & attribution

Ownership Investigator

The Ownership Investigator answers four questions about an organization, each from its own derivation below: who owns it (the chain-of-title walk), whether an export-control designation reaches it directly or through affiliates (designation reach), which sovereign investors back funds that hold it (sovereign LP attributions), and which deals changed its ownership (ownership-change events). Each draws in part on licensed records, which are covered at the end, under the licensed databases.

Chain-of-title walk

The walk reads parent edges from ownership_upward_edges one hop at a time, at most OWNERSHIP_WALK_MAX_HOPS = 8, and ends in one of the six terminal classes below. Each edge is read against ownership_edge_control_review; a candidate parent whose every edge that review withholds is listed as a holding and never followed. Backing function: walkOwnership() in src/lib/data/ownership-investigator.ts.

In plain language

The walk climbs from a company to its recorded parent, then to that parent’s parent, for up to eight steps. It stops at a listed company or a government, where the records name no further parent, at an offshore holding structure, at a loop, after the eighth step, where two documents name different parents with nothing to choose between them, or where every recorded shareholder has been reviewed as not controlling the company. A shareholding becomes a parent only where a source establishes control, which a place in a shareholder list or a funding-round stake does not; where a company’s own filing says it has no controlling shareholder, the page quotes it. When sources disagree about a parent, both are shown.

Where the walk stops

  • reached_ubo: a parent carries both an SEC CIK and a ticker, or is a government; or no further parent is recorded and the last organization reached does not match the patterns under opacity. An organization with no recorded parent at all ends here too.
  • opacity: no further parent is recorded and the last organization reached has a Cayman Islands, British Virgin Islands, Bahamas, Jersey or Guernsey country (stored as KY, VG, BS, JE, GG) and no SEC CIK, or a name such as HoldCo, SPV, special purpose, nominees or blind trust. A CIK marks an SEC registrant, whose ownership is filed, so a domicile alone does not make it opaque.
  • no_controlling_holder: the organization has recorded holders and the control review withholds every one, so no source establishes that any of them controls it. The holders are listed with their shares; where a filing states that the organization has no controlling shareholder, the review row’s quote, document and page are printed.
  • cycle_detected: the chosen parent was already visited.
  • depth_capped: the eighth hop was reached.
  • contested: the two strongest candidates are different parents that tie on confidence and authority tier, with no later as-of date to separate them, and they are not named together in one document. Every claim is shown with where it leads, and no owner is named.

Algorithm

// walkOwnership() in src/lib/data/ownership-investigator.ts
function walkOwnership(entityId) {
  start = resolveCanonicalId(entityId)
  visited = { start }
  frontier = expandWithLicensedDbBridge(getAllIdsForOrg(start))
  chain = [hop0(start)]
  for hop in 0..MAX_HOPS-1:
    raw = SELECT * FROM ownership_upward_edges WHERE child_org_id IN frontier
    rows = filterPhantomSelfEdges(raw, frontier)
    if rows.empty: terminal = looksOpaque(tail)? opacity : reached_ubo; break
    edges = enrichEdges(rows)  // join source_url, authority_tier, share_pct
    edges = edges.map(e => withControlVerdict(e, ownership_edge_control_review))
    groups = groupBy(edges, canonicalParent)
    holders = groups.filter(g => every edge withheld)
    tail.holders = nestHolders(holders, unwithheldEdgesBetween(holders))  // "Of which", each citing its edge
    candidates = groups.filter(g => some edge not withheld).map(g => pickStrongestEdge(not withheld))
    if candidates.empty: terminal = no_controlling_holder (+ filing statement); break
    candidates.sort(compareEdgeStrength, then share desc, then canonical id before vendor id, then id)
    if tiesWithoutArbitration(candidates[0], candidates[1])
       && !sameDocument(candidates[0], candidates[1]): terminal = contested; break
    primary = candidates[0]; alternates = candidates[1..]
    if primary.canonicalParent in visited: terminal = cycle_detected; break
    visited.add(primary.canonicalParent)
    chain.push({ primary, alternates })
    if parent.cik && parent.ticker: terminal = reached_ubo; break
    if parent.org_type == 'government': terminal = reached_ubo; break
    if hop == MAX_HOPS-1: terminal = depth_capped
    frontier = expandWithLicensedDbBridge(getAllIdsForOrg(primary.canonicalParent))
  return { chain, terminal, terminal_detail }
}

At each hop compareEdgeStrength() ranks the candidate parents by confidence (HIGH, then MEDIUM, then LOW; an edge without a label counts as LOW), then by authority tier, then by the later as-of date, and the walk follows the first. Candidates still equal after that are ordered by the larger recorded share, then a canonical identifier before a vendor-keyed one, then identifier, so the database’s row order never chooses a parent. pickStrongestEdge() keeps one edge per parent; the others at that hop are listed as alternates with their own sources and dates. A recorded share is a fact about a holding and never decides control on its own: a 54.82% nominee holding confers none, and a 20.09% holder the issuer names as its controlling shareholder is a parent. Tier and confidence come from each source’s row: most SEC EDGAR edges are tier 1, most licensed edges tier 2, and every hop shows its own. Both functions live in src/lib/data/ownership-investigator.ts.

Edge cases handled

  • Phantom self-edges (filterPhantomSelfEdges()). When one firm is held under two identifiers with a parent edge between them, merging the identifiers turns that edge into a self-loop; the walk drops it instead of stopping on a false cycle.
  • Placeholder names. A hop can land on a licensed record that carries only a placeholder name. The walk continues through it, and the page shows the record’s identifier without the placeholder, so the link still resolves.
  • Co-parents. Parents named together in one document (a founder’s holding vehicles, a stake split across two holding companies) are co-parents rather than a contest: the walk follows the strongest and shows where each of the others leads.
  • A holding inside another (nestHolders()). A holder’s figure can count shares held through companies it controls, and one of those companies can be listed as a holder too. SMIC’s 2025 annual report gives CICT 14.97%, which includes the shares of Datang HK, a wholly-owned subsidiary of CICT that the same report lists at 14.06%. The walk draws Datang HK under CICT as “Of which” on a recorded edge from Datang HK to CICT that cites CICT’s own document, and the entry cites that edge; an edge citing anything else counts only where a review row for it establishes control, and an edge the review withholds never counts. CICT’s figure must count holdings through controlled companies, and its document must give Datang HK a share at the same date, no larger than CICT’s and not a share of the voting power. Holders are placed from the top down, so a figure is judged as it is drawn, and a holder whose recorded container has a figure that does not count it goes under the nearest holder above that container whose figure does. Edges reaching two branches of one holding put a holder under the nearest holder above both whose figure counts it; edges reaching different holdings, or running in a loop, leave it at the top, because the records contradict one another. A nested holder’s strongest record, when it is another reading, gets a line of its own; its weaker records are not shown, and no remainder is computed.

Outside this walk

  • Limited-partner stakes. A limited partner’s stake in a fund is not control of that fund’s portfolio companies, so sovereign-wealth and pension-fund commitments are excluded from this walk. They appear separately, in the sovereign-LP attributions.
  • Ownership through debt. The ownership tables carry equity edges only; convertible notes, mezzanine instruments and contingent-equity structures are not modelled.

Worked example

Xilinx walks one hop, to AMD, on an SEC EDGAR edge with an as-of date of 26 September 2025, and stops there because AMD carries both an SEC CIK and a ticker. The Investigator also marks the chain as incomplete: subscription sources hold further ownership records for Xilinx that cannot be republished.

BIS designation reach

A direct lookup matches the organization’s identifiers and name against export_control_designations; an affiliate lookup reads designation_closures, walks computed offline downward from each designation through the ownership graph and never upward to a parent’s other subsidiaries. Backing function: getDesignationReachForEntity() in src/lib/data/ownership-investigator.ts; the walks are built by scripts/lib/bis-cascade.ts.

In plain language

Two findings are reported separately: whether the organization is itself on the Entity List, and whether a listed organization reaches it through a recorded chain of affiliates. Each designation is shown with its Federal Register citation.

Algorithm

// getDesignationReachForEntity() in src/lib/data/ownership-investigator.ts
function getDesignationReachForEntity(orgId) {
  allIds = getAllIdsForOrg(orgId)
  direct = []
  for match in precomputed_crossref:
    if match.confidence_score >= 0.9 && match.matched_org_id in allIds: direct.push(match)
  // Belt-and-suspenders ILIKE on entity_name (catches entities the crossref pipeline missed)
  direct ∪= SELECT * FROM export_control_designations WHERE entity_name ILIKE orgName
  direct ∪= SELECT * FROM export_control_designations WHERE id IN allIds
  closures = SELECT * FROM designation_closures WHERE canonical_closure_entry_id IN allIds
  return direct.map(d => { ...d, hop_count: 0, is_direct: true, authority_tier: 1 }) ∪
    closures.map(c => { ...c, is_direct: false })
}

A walk starts from an anchor: the licensed ownership record taken to be the designated entity. A record anchors a designation only when it carries the designation’s exact name, legal form aside, in the designation’s own country; when that match survives a reading that keeps “holding” and “holdings”, which tell a holding company from the company it holds; and when no differently named designation claims the same record (admissible_anchors() in scripts/lib/bis_closure_anchor.py). The walks from the anchors fill designation_closures, and the matches are drawn from them offline (scripts/lib/bis-cascade.ts) by four routes:

// scripts/lib/bis-cascade.ts (offline; produces bis_crossref_matches AFFILIATE_CLOSURE rows)
  (1) direct      — the closure entry IS a compute-universe org
  (2) canonical   — the closure entry resolves to one via canonical_org_map
  (3) edge_extend — the closure entry's own SUBSIDIARY is one, one recorded edge down
    // confidence drops one tier (HIGH→MEDIUM, MEDIUM→LOW, LOW→LOW)
    // never the entry's PARENT, a JV or an AFFILIATE: a designation does not reach them
  (4) designation_chain — SUBSIDIARY edges down from the org an active name match
      links the designation to, at most 6 hops
  // A reviewed refusal (bis_matcher_overrides, match_decision 'reject') holds on
  // every route; route 4 walks nothing below a refused org.
  // Routes 3 and 4 follow no edge the ownership control review records as
  // conferring no control, so a designation does not reach a company through
  // a stake in it (a funding-round investment, for instance).

Edge cases handled

  • A designation’s own record. Each designation creates an organization record of its own; a walk that returns to that record is not counted as reach (isCascadable() in scripts/lib/bis-cascade.ts).
  • Removed designations. When a Federal Register notice removes a designation, its matches stop counting as active and stay on record, so what it once reached can still be traced.
  • Direct and affiliate matches. The page marks a direct designation as such, at tier 1, and shows each affiliate match with the relationships it crossed.

Coverage ceiling

A designation can reach an affiliate only if the ownership graph holds the designated organization. 30 of the 3,435 designations on record (0.87%) have that anchor, and 1 (0.03%) reaches at least one compute-relevant organization. The other 99.13% were never matched into the graph, so their silence says nothing about whether the designated entity has compute-relevant affiliates.

Worked example

HiSilicon is on the Entity List in its own right (added May 2019, 84 FR 22961), and the Investigator also reaches it through one recorded affiliate chain: Huawei Technologies Co., Ltd., listed by the same rule, anchors on its own ownership record, which lists HiSilicon as a subsidiary. The chains that reached HiSilicon from 52 other Huawei-group designations, Huawei Cloud Guangzhou among them, were withdrawn on 25 September 2026 because their anchors failed the rule above. Checked against the ownership records on 25 September 2026.

Direct designations are tier 1, cited to the Federal Register. Affiliate matches carry the tier of the ownership records they walk; a match that needs a one-edge bridge beyond the end of a walk is downgraded one confidence step (HIGH to MEDIUM, MEDIUM to LOW).

Section 1260H, NS-CMIC and FASCSA listings

Three US government listings that are not export controls appear on company records, each under its own name and never in the export-control count: the Department of Defense’s Section 1260H list of “Chinese military companies”; the Non-SDN Chinese Military-Industrial Complex Companies List (NS-CMIC), kept by the Treasury’s Office of Foreign Assets Control under Executive Order 13959, as amended, which prohibits US persons from buying or selling the listed companies’ publicly traded securities other than to divest; and the Department of Homeland Security’s exclusion orders under the Federal Acquisition Supply Chain Security Act (FASCSA). Every row is parsed from a primary source stored byte for byte with its sha256, never typed: the Section 1260H lists of 28 June 2021, 2 April 2024, 7 January 2025 and 10 June 2026 and the FASCSA order of 20 October 2026, from the Federal Register, and the 68 NS-CMIC entries of OFAC’s list file published 19 October 2026. The latest Section 1260H list is the current one; the earlier lists, and the names the 2025 and 2026 lists remove, stay on record as history.

How a listed name is matched to a record

  • Names compared. The name as listed, any former name the source prints, and the names a Federal Register notice says the entity is also known as, against every organization’s name and recorded aliases, ignoring case, runs of whitespace and full stops. A match on a merged duplicate counts as the record it was merged into, and only records the site publishes count.
  • Names not compared. The short names a notice prints in parentheses, and OFAC’s a.k.a. names. They abbreviate or brand: OFAC prints CHINA TELECOM as an a.k.a. of two entries, CHINA TELECOM CORPORATION LIMITED and CHINA TELECOMMUNICATIONS CORPORATION; compared, it would put both listings on one record.
  • One record, several, none. A name that matches exactly one record is attributed to it, and the record shows the listing with the printed name that matched. A name that matches several records, or none, is attributed to no record and held for review; the MCP company record returns the rows that name it among several, with the other records.

What a missing listing means

A record shows a listing only when a listed name resolves to it. Names that match no record, or several, are attributed to none, so the absence of a listing is not a finding that a company is unlisted. OFAC’s Specially Designated Nationals and Blocked Persons List is not ingested, so no record shows an SDN listing.

Each listing is tier 1, cited to its Federal Register notice or OFAC list file. Rows: us_restrictive_listings.

Sovereign LP attributions

getSovereignAttributionsForEntity() in src/lib/data/ownership-investigator.ts matches the organization’s identifiers against the sovereign investment chains (sovereign investor, fund, portfolio company) and returns each commitment, newest first.

In plain language

A sovereign investor can finance a private-equity fund whose portfolio includes the company. That connection identifies a source of capital at fund level; the fund’s investment in the company needs its own amount and terms.

Algorithm

// getSovereignAttributionsForEntity() in src/lib/data/ownership-investigator.ts
function getSovereignAttributionsForEntity(orgId) {
  allIds = getAllIdsForOrg(orgId)
  return SELECT id, sovereign_lp_name,
    intermediate_fund_name, intermediate_fund_id,
    commitment_date, commitment_usd_m, is_dollar_disclosed,
    commitment_status, data_source, source_url, data_vintage,
    authority_tier
    FROM sovereign_investment_chains
    WHERE target_canonical_org_id IN allIds
    ORDER BY commitment_date DESC
}

Reading the ledger

  • Missing statuses. The source-status column shows a dash when none of an investor’s commitments has a recorded status. Where statuses are recorded, the ledger keeps the source’s wording and counts commitments under each label.
  • Commitment amounts. A commitment covers the fund’s portfolio, so its amount cannot be assigned to one company. The public ledger counts how many commitments have a dollar amount in the source; fund names and amounts are withheld under licence.

National AI budgets and project spending are compiled separately in the sovereign AI programmes.

Ownership-change events

Deals in pe_investments in which the organization is the acquired company or a named party, newest first, with their parties from pe_deal_investors. Backing function: getOwnershipChangeEventsForEntity() in src/lib/data/ownership-investigator.ts. The extraction query retains ten deal types that imply a transfer of ownership — M&A, buyout/LBO, secondary buyout, corporate divestiture, asset sale, reverse merger, joint venture, spin-off, platform creation and public-to-private — and drops seed, Series A–H, growth, PIPE and debt financings before ingest (the extractor’s OWNERSHIP_EVENT_TYPES filter). As of 24 September 2026 every event comes from the licensed deal records, at authority tier 2, and the ledger reads them through v_pe_investments_grey, which withholds a licensed record’s date, amount and source link at the database: each licensed event shows its year and a size band (under $10M, $10M to $100M, $100M to $1B, $1B to $10B, $10B or more, the bands the capital-flow records use), with the source’s deal type and status beside them. Where a deal’s terms have been checked against the parties’ own filings, those terms and their citations replace the band.

In plain language

This chain lists the deals that changed who owns a company, whether the company was acquired or took part in the deal. Funding rounds that raise money without changing ownership (Series A, B, C and the rest) are left out.

Algorithm

// getOwnershipChangeEventsForEntity() in src/lib/data/ownership-investigator.ts
function getOwnershipChangeEventsForEntity(orgId) {
  allIds = getAllIdsForOrg(orgId)
  partyDeals = SELECT pe_investment_id FROM pe_deal_investors
    WHERE canonical_party_org_id IN allIds
  // licensed rows: year + size band; date, amount, source URL withheld
  deals = SELECT * FROM v_pe_investments_grey
    WHERE canonical_target_org_id IN allIds OR id IN partyDeals
    ORDER BY deal_year DESC, announced_year DESC, id
  if deals.empty: return []
  investors = SELECT * FROM pe_deal_investors WHERE pe_investment_id IN deals.ids
  partiesByDeal = groupBy(investors, pe_investment_id).map(invs =>
    invs.map(inv => {
      name = inv.canonical_party_org_id ? getCanonicalName(inv.canonical_party_org_id) : null
      party_name = suppressPlaceholderStubName(name)  // placeholder label → null
      return { party_role, canonical_party_org_id, party_name, fund_name, fund_id }
    })
  basis = loadConsiderationBasis(deals.ids)   // raw fields of filing-checked deals only
  return deals.map(d => {
    e = { ...d, parties: partiesByDeal[d.id] ?? [] }
    terms = basis[d.id] ? qualifyDealConsideration({ ...basis[d.id], parties: e.parties }) : null
    return terms ? { ...e, primary_consideration: terms, amount_band: null } : e
  })
}

A party with no resolved name reads “Name withheld under licence” on a licensed record; otherwise the panel falls back to the fund name, then to “— name not recorded”. A licensed deal reads its year and size band (“2005 · Completed · $100M to $1B”); a deal with no recorded value reads “value unrecorded”.

Outside this chain

Conversions of debt into equity: a convertible note enters the deal table as the debt issuance it was on the day it was written, and the equity it converts into years later is a transfer the extraction query does not retain.

The licensed databases

Subscription sources

Licensed rows are withheld at the database, where the public role cannot read them. What a subscription source contributes to a page is metadata (how complete a result is, whether a public document exists for a relationship there is reason to think is there, which records were worth chasing into a registry) and, on a company’s record, the names of the suppliers, customers and partners a licensed supply-chain database records for it, without the database’s figures.

In plain language

A subscription database is used the way a librarian is used: it says where to look. What gets published is the document at the end of that search (a filing, a registry entry, a company’s own announcement) with its own link, readable without a subscription.

Published and withheld records

Scrutica serves 71,288 directed links between organisations (ownership, supply and partnership), each citing a source a reader can open. A further 32,483 are established only in subscription sources and are withheld — so the published graph is 69% of 103,771 links held in total, as of 2026-10-22.

The facility corpus splits the same way: 4,267 records published of 4,583 held, with 316 established only in subscription sources. The headline facility count is of every record held: the 316 licence-held records are counted in that total but cannot be opened, listed, or drawn on the map.

The three provenance markers

Located via subscription source means the record beside it is a public primary, cited and linked and readable without a subscription, and that a commercial source is what pointed to it. Of the published links, 7,515 across 4,844 organisations were re-sourced this way: each was re-established against a public document naming both parties before it was re-tagged, and it is that document the page cites.

Subsidiary coverage appears in an organisation’s ownership chapter when the licensed database records subsidiaries that public sources do not establish. The sentence beside it gives two counts over the subsidiaries in our records up to four levels below the organisation: all of them, and those a public source establishes, with the latest record year on each side. A subsidiary is reached only through ownership records that establish control, by the same review the organisation’s parent chain reads: a funding-round stake, or a holding its issuer says controls nothing, is not a subsidiary.

A licensed corporate-structure database also places entities below many organisations; it records operating hierarchies, which establish no control. Entities that only such a tree places below the organisation are not counted as subsidiaries; a second sentence gives their count, and the note appears for that count alone when the licensed database adds no subsidiary.

The public count is exact. The total and the second count are exact below 20, rounded to the nearest 5 up to 100, and to two significant figures above that (roundSubsidiaryTotal() in src/lib/provenance/subsidiary-coverage.server.ts). Where the rounded total would not exceed the public count, the sentence gives no total: it gives the public count and says the rest are recorded only in the licensed database, because printing a total there would print the exact one.

All three markers link here from wherever they appear.

Supply relationships named from a licensed database

A company’s record names the suppliers, customers and partners that a licensed supply-chain database records for it and that the public sources on the page do not show, grouped by where each counterparty is headquartered. A partnership is listed as one, since its recorded direction means nothing. A counterparty already shown from a public source is named again only when the database holds a later company filing for it than any shown; the record says how many others the database also holds.

When the database was loaded, most of its companies were matched to Scrutica’s records by name, and a name can match the wrong company. So a relationship reaches a record only when that company’s own link to it rests on more than a name: the database was read from that company’s own supply-chain listing, or the row names the company by its identifier in the database, or the company is the database’s own entity, entered from the same load, or the name match has been checked. A match passes the check when the name the database gives the company, corporate form included, belongs to that record and to no other, and the country the database gives it is the record’s. A counterparty is named on the same terms. One whose match is unchecked, or failed the check, is counted and not named.

The database’s figures are withheld: no relationship value, share, price correlation or product description is published. One amount does appear, because a company filing disclosed it: the sales a supplier reported to a named customer in a fiscal year, printed with its year as a range on a 1–2–5 scale (magnitudeBand() in src/lib/provenance/licensed-grey-forms.ts). A counterparty whose only evidence is such a filing more than 5 years old is listed apart as historical.

Growth and spending bands from licensed annual statements

A listed company’s record shows, for each fiscal year, the band its revenue and its capital spending grew in against the year before, and the bands its capital spending and its research and development spending fell in as shares of that year’s revenue. The figures come from the consolidated annual statements that a licensed financial-statements database standardises; only the band is published. Growth bands are cut at −50, −25, −10, 0, +10, +25, +50, +100 per cent; capital spending as a share of revenue at 0, 2, 5, 10, 20, 35, 50, 100 per cent; R&D at 0, 1, 3, 6, 10, 15, 25, 50 per cent. A band includes its lower cut and stops short of its upper one.

Growth compares a fiscal year with the one before it, in the currency the company reports in, and only when the earlier year ended about a year before: a company that moved its year end, or changed its reporting currency, has no growth band for that year. Years are labelled by the month they end, because companies number their fiscal years differently. A cell without a band says why: no prior year, a line the statements leave out, a ratio over nil revenue, or two filers on one record whose bands disagree.

A record shows these bands only when an identifier ties it to the filer in the database: the company’s SEC registration, the identity crosswalk, or a merge of the database’s own record into Scrutica’s. A name match never does, and a filer that two identifiers tie to two different records shows on neither.

Compute Visibility Index: the per-country ownership-transparency classifier

The Compute Visibility Index measures, per country, what share of in-country compute capacity falls in each of four tiers and one coverage state. A facility's tier depends on whether its linked organization has an SEC identifier and on which sources record the ownership links above it, up to six hops. The checks run in this order, and the first that matches sets the tier:

  • Data Gap: no company linked. The facility has no operator, owner or hardware-owner record.
  • Tier 1: company has an SEC identifier or a parent linked through filing, registry or supply-chain data. The Tier 1 sources are SEC filings, the GLEIF LEI registry, the BIS Entity List and BIS documents in the Federal Register, relationships re-sourced to public filings, and licensed corporate-ownership and supply-chain databases.
  • Tier 2: parent linked through licensed ownership data, from a private-market database.
  • Tier 3: parent linked through other sources. No link above the organization comes from a Tier 1 or Tier 2 source.
  • Tier 4: company identified; parent unrecorded.

A Tier 1 result can follow from an organization's SEC identifier alone. It does not establish property ownership, facility operation or authority over the compute.

Tier 4 covers three situations at once: organizations no consolidation regime ever required to name a parent, organizations that could name one and do not, and relationships Scrutica has not yet joined. The Compute Visibility Index page splits Tier 4 into those states, attributes each to the registrant, the registry or Scrutica, and gives the gap a column of its own.

Hosted vs Controlled. A facility physically located in country A whose ultimate beneficial owner is domiciled in country B counts toward country A on the “hosted” view and country B on the “controlled” view. The Allied Coordination Gap Analyzer, which lists the facilities where that split crosses an allied export-control boundary, treats the divergence as the policy-relevant signal, because export-control authority follows the controlling jurisdiction.

Compute Under Control: the strict jurisdictional-control classifier

The Compute Under Control metric is the jurisdictional-attribution counterpart to the Compute Visibility Index. It answers a strict question: of the compute physically hosted inside country C, what fraction is operated by a C-incorporated firm whose ultimate corporate parent is also C-incorporated? The classification starts only at an organisation a source establishes as the facility's operator, owner or AI-hardware owner (the admitted role claims), and each facility falls into one of six named classes. Domestic: host country, operator country, and ultimate parent country all equal C. Foreign-concentrated: operator and ultimate parent agree on a non-host jurisdiction. Bifurcated: operator and ultimate parent jurisdictions disagree. Opaque: a jurisdiction the classifier needs is unresolved, either because the chain terminates without a country-attributable node, because no ownership chain that establishes control is recorded above the organization, or because the organization itself has no documented country. Licensed, unreviewed: a licensed source names an owner that has not been reviewed, so it starts no chain and is counted apart. Data gap: no source establishes an owner, operator or AI-hardware owner for the facility, whether because no organization is recorded in those roles or because the one recorded is supported only as an association, so there is no organization to classify from.

A single-jurisdiction pick hides the bifurcated cases. Reading owner_org.country_hq at one hop smooths a facility whose operator and ultimate parent sit in different jurisdictions into whichever side that pick landed on. The strict criterion refuses the smoothing: such a facility appears in the drill-down for both countries as a jurisdictional-axis contributor, and in neither's “Under control” column. Bifurcation is one of the six reported classes, with its own count.

Ultimate-parent resolver. The classifier walks the upward ownership edges itself, bounded at six hops. For each facility's starting organization, the ultimate parent is the deepest reachable ancestor; ties at the same hop depth are broken on the ancestor's canonical id, then a public edge source before a licensed one, which makes the pick deterministic. An organization present in the ownership graph with nothing above it resolves to itself. An ownership edge reviewed as not establishing control (a source whose trees are operational rather than legal hierarchies, a join on a one-word name, a vehicle whose filing states a holding but not control) is treated as absent, and each review cites its document; an organization recorded only through such edges has no parent. The resolver does not infer beneficial ownership from indirect signals.

Sovereign AI funding gaps: breakdown withdrawn

An earlier overlay split each programme’s gap between announced and disbursed spending across six named reasons, by percentage, without recording an amount for any reason or either figure the percentages were taken from, so none could be checked against the money it describes; the breakdown, the cross-programme matrix built from it and the totals derived from either are withdrawn. They return only after an independent editorial verification of every amount against its source, in comparable units and on comparable dates, and a UI republication audit of each figure the page would display; the automated check on the archived allocations covers receipt structure and arithmetic only and does not verify source content. Each programme’s own split by financing type remains on Programs, and the capital ledgers remain on Funding.

Comparing model scores and training hardware

The Capability Frontier places scores from Epoch, Artificial Analysis and LMArena beside available training-compute estimates and hardware attributions. Each index retains its own scale and recorded vintage. The curation combines selected model variants across the sources, so a difference between scores cannot be read as a comparison under matched inference budgets, tools or model endpoints.

The country groups are Scrutica’s editorial categories, assigned from the trainer organization’s country and open-weights field. Downloadable weights take precedence over country. Among closed-weight models, UAE and Saudi Arabia form one group; China, Russia, Iran and North Korea form another. The “allied” group is an editorial set of 24 countries: the United States, the United Kingdom, Australia, Canada, New Zealand, Japan, South Korea, Israel, Taiwan, Norway, Switzerland and 13 EU members. The EU members are Austria, Belgium, Denmark, Finland, France, Germany, Ireland, Italy, the Netherlands, Poland, Portugal, Spain and Sweden. A label records the trainer organization’s country and open-weights status, and nothing about where a model was trained or what licence its hardware needed.

Hardware evidence. The curator uses a joined Epoch hardware field or a supporting developer disclosure. Meta’s Maverick model card reports H100-80GB pretraining and identifies the FP8 release as a quantized variant. Google’s Gemini 2.5 report, §2.3 describes TPUv5p training for the family that includes Pro and Flash; it does not give a chip count for each model. Inferences from a sibling model alone are withheld, and an empty chip class means the snapshot records no chip for that model. A chip name and a release date do not carry the transaction facts an export-control assessment needs.

Date-and-score frontier. An outlined model has no competitor in the selected subset with a later or equal release date and a higher or equal score, with at least one strict advantage. This highlights recent, high-scoring models. The calculation has no training-compute operand and does not reconstruct which model led at its release date.

Available-metric rank. Each model receives a rank within every index where it has a score. Scrutica averages its available ranks, then ranks those averages; ties in the averages break by ECI rank, then model ID. Equal underlying scores receive successive ranks in input order. The calculation uses the full cohort before the country/weights filter; models with no score receive no rank. Because indices cover different populations and some models have only one score, this ordering can reflect missing coverage as well as performance.

IVValidation & limits

External Validation

Facility estimates reuse Epoch inputs, so agreement with those inputs cannot independently validate them. The checks below concern estimator assumptions, market-share calculations and recorded hardware configurations.

Validation Sources

Validation SourceData TypeCoverageMethodology Difference
Epoch AI GPU ClustersFacility PFLOP/s estimatesImported cluster recordsEpoch supplies some of the facility inputs. Reusing its figures cannot provide an independent check; comparisons must use the same site or cluster scope and distinguish peak from sustained compute.
TrendForce / CounterpointSemiconductor market shareQuarterly updatesThe concentration calculation can be reproduced from the cited shares. This checks the arithmetic; the shares’ market definition and date still govern what the result measures.
MLPerf InferenceHardware specifications (accelerator type, memory, count)Recorded v4.1 configurationsSubmitted accelerator names and memory specifications provide a reference for the chip catalog. Matching must distinguish hardware variants before a difference is treated as an error.

MLPerf Hardware Cross-CheckRecorded accelerator names: AMD Instinct MI300X, NVIDIA H100, NVIDIA L40S, NVIDIA Jetson AGX Orin 64G, NVIDIA H200, AMD MI300X, NVIDIA L4, NVIDIA B200, NVIDIA A100, NVIDIA GH200, TPU v5e, TPU v6, NVIDIA GH200 Grace Hopper Superchip 144GB, NVIDIA GH200 Grace Hopper Superchip 96GB, UntetherAI speedAI240 Preview, UntetherAI speedAI240 Slim. Names retain the submitters’ spellings, so different entries can refer to the same hardware.

No per-facility agreement score is published. The earlier matching procedure could pair a whole-site estimate with a cluster inside it, so the resulting difference did not measure accuracy. To examine how hardware counts, power and utilisation affect an estimate, adjust the Interactive FLOP estimator.

BIS license actions: the series ends at CY2022

BIS’s Office of Technology Evaluation publishes a per-country “Annual Country Licensing and Trade Analysis” (bis.gov · OTE) under Section 1765 of ECRA (50 USC §4824). Scrutica holds its license-action tables for 33 jurisdictions, calendar years 2015 to 2022, from reports for calendar years 2018 to 2022 (authority tier 1).

Customs trade data for HS 8542 records what crossed borders as declared (UN Comtrade and CEPII BACI through 2024, US Census for 2022 to 2024, and Taiwan, China and Japan customs into 2026); BIS licensing decisions are not in it, so the trade and diversion views show the two side by side without combining them. No per-country, per-ECCN license-action series has been published for 2023 onward, so the site computes no split of trade into licensed, denied and grey-market flows. CRS report R48642 (Sutter, updated 19 September 2025, crs · R48642) summarises the export-control posture since 2023; the license values it cites, from press releases, end in the first quarter of 2022.

PJM grid context: generator-queue capacity by county

On the US sovereign program, this indicator totals the generation capacity in PJM Interconnection's queue archive county by county across PJM's territory (13 eastern states and DC), because several of the program's largest sites lie inside it: the NAIRR Pilot's Purdue Anvil node in Indiana, and CHIPS Act recipients in Pennsylvania and Ohio, Intel's New Albany fab among them. Data-center load planned on the same grid competes for the headroom new procurement needs. The indicator covers none of the program's sites outside PJM, such as SDSC's Expanse in San Diego or the New York CHIPS recipients on NYISO, and appears on no other country's program.

The queue lists proposed generation (gas turbines, solar farms, storage, wind), and 72.9% of its entries, as of 22 September 2026, were withdrawn before they produced power. No entry can be tied to a particular data center, so the indicator reports county totals.

VInterfaces & history

Query engine: the natural-language interface to the data

The query engine answers questions in plain English from Scrutica's records and the analyses built on them. A question is stripped of a fixed list of instruction-override phrases and control characters and passed to the model. The default is GPT-6 Sol through OpenRouter. A supported Anthropic model can instead use Anthropic's API when its credentials are provisioned. The model writes out a plan and then calls data tools, in parallel where they are independent. It gets at most five rounds and 8 data-tool calls; a call past that budget is not run, and the model is told to answer from what it has gathered and say which parts of the question it could not cover.

The engine has 55 public tools, covering the records, the analyses derived from them and the site's own pages and corrections log; the tool reference lists each with its parameters. An answer can use only what those tools return.

Citations. The model is instructed to tag each claim that rests on an identifiable record with the tool that returned it and the record's identifier, and the page lists every cited record beside the answer with its source link, estimate flag, vintage and authority tier where the tool returned them; a tier the model supplied itself is labelled as its own assertion. Once the answer is written, a server-side check confirms that each cited identifier was returned in that run by the tool the tag names, and flags one it cannot match as unverified provenance. The check does not read the record, so it cannot show that the record supports the claim or that a value was copied correctly, and untagged claims are outside it; if the check itself fails, the saved answer carries no verdict.

Version history

v1.4.0

  • Modified
    interconnect_efficiency Default 0.85 → 1.00, and the maximum 0.95 → 1.00. The utilization default, an end-to-end rate reported from training runs, already includes communication losses, so the estimator no longer discounts interconnect a second time: at the defaults an estimate sustains 0.40 of dense peak throughput, where it sustained 0.85 × 0.40 = 0.34. Throughput and daily FLOP estimates at the defaults rise by a factor of 1/0.85, about 17.6%; days to a threshold and the accelerator count a fixed duration needs fall by 15%, before any rounding up. The upper end of the estimation bounds rises by a factor of 1/0.95 with the maximum; the lower end, set by the 0.60 minimum, is unchanged. Lower the setting only for a cluster whose interconnect is weaker than that of the runs behind the utilization rate. 0.85 → 1
  • Modified
    mfu_assumption The 0.40 default is now credited to the figure it equals: SemiAnalysis’s reported FP16 model FLOP utilization for trillion-parameter H100 training runs (“100,000 H100 Clusters”, 2024-06-17), with PaLM’s Table 3 as benchmark context. The source had read “Scrutica modeling assumption”. The value is unchanged.
  • Modified
    gpu_fraction_of_it Corrects v1.3.0’s description of its anchor. SemiAnalysis’s 100,000-H100 power decomposition is one analyst estimate (authority tier 3), which v1.3.0 called ground truth and a measured decomposition. v1.3.0 also called it “the only published primary-adjacent component-level breakdown of a frontier AI training cluster”; no survey of published breakdowns was made to support that. The 0.49 default is unchanged.
Earlier releases (11)

v1.3.7

  • Modified
    r100_rubin Aligned the display name with NVIDIA’s current product-facing name, Rubin, while preserving the stable internal key. Added NVIDIA’s preliminary per-GPU dense FP16/BF16 figure of 4,000 TFLOP/s; the separately published 50 PFLOP/s NVFP4 figure is sparse and is not substituted. Per-GPU TDP and unit price remain absent. 0 → 4,000 TFLOP/s
  • Modified
    maia_200 Added Microsoft’s published per-chip 750 W SoC TDP for Maia 200. Dense FP16/BF16 throughput and per-unit price remain absent; FP4/FP8 figures are not converted into the registry’s dense training-throughput field. 0 → 0.75 kW
  • Modified
    gpu-spec-availability Numeric callers now reject any estimate whose required accelerator fields retain the registry’s zero absence marker. Partially specified models remain available to calculations whose own operands are recorded: Rubin can run throughput-only hardware calculations, while its power and cost outputs remain withheld; Maia 200 remains withheld from throughput-dependent outputs.

v1.3.6

  • Added
    gb300 Added NVIDIA GB300 (Blackwell Ultra, per GPU, NVL72 configuration). Dense FP16/BF16 = 2,500 TFLOP/s — derived from NVIDIA’s GB300 NVL72 page (360 PFLOP/s with-sparsity per 72-GPU rack → 5,000 sparse / 2,500 dense per GPU under NVIDIA’s 2:4 convention) and listed directly by Epoch AI ml_hardware; 1,400 W per Epoch (NVIDIA publishes no per-GPU TDP). Before this, the Threshold Atlas had no GB300 spec and silently fell back to the H100 SXM5 assumption for GB300 sites — 743,001 GPUs across 6 facility inventories at the 2026-07-22 substrate probe, including Stargate UAE Phase 1 and HUMAIN Phase 1 — understating their per-second dense throughput by ~2.53× (2,500 vs 989.5).
  • Added
    v100_sxm2,tpu_v4,tpu_v5e,tpu_v5p,ascend_910b Added five accelerators that are the dominant on-record hardware at live facilities but had no spec entry, so every one of their sites was silently H100-SXM5-assumed — in these cases OVERSTATING capacity: V100 SXM2 (125 dense tensor FP16, NVIDIA Volta datasheet; ~54 facilities incl. legacy supercomputers, overstated 7.9×), TPU v4 (275 BF16, Google docs; overstated 3.6×), TPU v5e (197 BF16; overstated 5.0×), TPU v5p (459 BF16; overstated 2.2×), Huawei Ascend 910B (375 dense FP16 per CSET "Pushing the Limits" 910B2 row, Epoch lists 376 — divergence surfaced; overstated 2.6×, a bad direction for an export-control-focused surface to err on a Chinese site). TPU TDPs are Epoch-curated where Google publishes none; TPU v4 power uses Google’s measured max (192 W) with Epoch’s 340 W divergence noted.
  • Added
    mi325x,tpu_v6e Added AMD MI325X (CDNA 3: dense FP16/BF16 1,307.4 TFLOP/s per the AMD data sheet — compute-identical to MI300X, memory-upgraded to 256 GB HBM3E at 6 TB/s; 1,000 W) and Google TPU v6e Trillium (918 BF16 per Google Cloud docs; 380 W per Epoch), closing the 2025-generation coverage gap between MI300X and MI350X and between TPU v5 and v7. All values cross-checked against the live Epoch ml_hardware release of 2026-07-21.
  • Modified
    threshold-atlas-hardware-mapping The Threshold Atlas gpu_inventory → spec-key mapping now recognizes GB300, V100, TPU v4/v5e/v5p/v6e, MI325X, and Ascend 910B inventory strings (previously all fell to the H100 SXM5 fallback). Parts deliberately left unmapped, with the fallback intact, because no primary or research-database spec could be pinned: Trainium1 (AWS Neuron docs read as 190 TFLOP/s per NeuronCore-v2 × 2 cores/chip while Epoch lists 190 per chip — an unresolved 2× ambiguity), Gaudi3 (Intel materials 1,835 vs Epoch 1,678 BF16, unresolved), Intel Max 1550 (no tensor-FP16 figure in Epoch; Intel materials do not disambiguate), MI300A (980.6 dense ≈ 0.9% from the H100 fallback — immaterial), and pre-tensor-core / non-GPU-comparable architectures (Kepler/Pascal Teslas, Cerebras WSE, Groq LPU, PEZY, Tesla Dojo D1, Maia 100). A gap statement beats a guessed spec.

v1.3.5

  • Added
    trainium2 Added Amazon Trainium2. Dense BF16 = 667 TFLOP/s, ~500W TDP, 96GB HBM3e; cloud-only via EC2 trn2 (Anthropic Project Rainier). Verified against AWS Neuron Trainium2 architecture docs and the SemiAnalysis Trainium2 teardown; matches the value the Epoch GPU-cluster ingest already used (amazon trainium2 = 667). Before this, the Threshold Atlas had no Trainium2 spec and silently fell back to the H100 SXM5 assumption for Trainium2 sites, overstating their per-second dense FP16 by ~48% (989.5 vs 667).
  • Modified
    threshold-atlas-facility-scope The Threshold Atlas per-country capacity view now (a) excludes chip-manufacturing facility types (logic_fab, memory_fab, packaging) from the "sites that hold the compute to train a model" universe — a memory fab’s power draw is not model-training compute — and (b) reads each facility’s own dominant hardware_type from its gpu_inventory before falling back to the H100 assumption. Prior behavior counted powered fabs as threshold-capable and assumed H100 for every site regardless of the accelerator the platform already had on record.

v1.3.4

  • Modified
    country-aggregate-mvs Country-level aggregate views (country stats, Compute Visibility rollup, Compute Under Control rollup) now apply the editorial numerical-corrections overlay that per-facility surfaces have applied since 2026-06-20 — a correction row supersedes the substrate value, including corrected-to-withheld (null) values for superseded build-phase capacity. Before this, database-side country totals silently disagreed with page-side totals by the corrected amounts (double-counting superseded Builds-Upon phases and keeping the uncorrected Stargate-UAE chip estimate). No parameter values changed; the same correction rows now bind everywhere.
  • Removed
    affiliate-rule-inferred-designations Removed four affiliate-rule-inferred export-control designations (undisclosed-entity surrogates; designations count 3,426 → 3,422). Two independent grounds, both verified: the legal basis for the inference — the BIS 50%-affiliates rule — was suspended effective 2025-11-10, eighteen days before the rows’ effective date, so the inferred designations were never operative; and the ownership evidence underlying the inference is no longer reproducible from the current substrate (verified 2026-07-11). Explicitly-named Entity List designations are unaffected. Version history is append-only: a full snapshot of the removed rows is retained for auditability, and the suspension status (stayed to 2026-11-09) remains tracked — if the rule takes effect, affiliate coverage will be re-derived from then-current evidence.

v1.3.3

  • Modified
    methodology-overview-copy Corrects the freshness-TTL claim in v1.3.2, which drifted out of truth 10 days after publication and stood uncorrected for 53 days. v1.3.2 (2026-05-08) verified the then-live FRESHNESS_TTLS ranges of 1–6h / 6–24h / 24–72h / 24–168h (introduced by commit 306fee58, 2026-04-08); commit bf41b310 (2026-05-18) then recalibrated all four classes upward — structural data was surfacing as "aging" after a single day, a false-alarm staleness signal across most of the platform — and no correcting entry landed until this one (2026-07-10 audit). Current values, interpolated directly from FRESHNESS_TTLS in src/lib/freshness.ts at build so this entry cannot itself drift (the same binding discipline this registry's header mandates for parameter values): regulatory fresh <168h / stale >720h; market fresh <168h / stale >720h; structural fresh <2160h / stale >8760h; narrative fresh <4320h / stale >8760h. Version history is append-only: v1.3.2's text stands as published, with this entry as the correction of record. No parameter values changed.

v1.3.2

  • Modified
    methodology-overview-copy Methodology overview copy calibrated against live Supabase substrate (probe 2026-05-08T22:46Z, paginated to avoid PostgREST’s default row cap). Three quantitative claims corrected for substrate drift: (a) facility country coverage 128 → 110 (the 110 distinct non-null countries that contain facilities; 157 facilities have NULL country and are not counted as a country); (b) export-control designation count 3,349 → 3,354 (substrate query: 3,354 total rows in `export_control_designations`, all with `removal_date IS NULL`, i.e. all active; the prior 3,349 reflected an older snapshot before five BIS-Entity-List additions landed); (c) cron-route count Ten → Fourteen (live `vercel.json` declares 14 entries; the Inngest function-definition file is retained for reference but is not the live scheduler, and pg_cron jobs are retention-only, not table-feeders). Five claims verified-and-kept-as-is: (~)4,500 facilities (substrate 4,529, ~ rounds correctly), (~)18,600 supply-chain edges (substrate 18,579, ~ rounds correctly), 34 sovereign AI programs (exact match), 13 GPU/accelerator generations + 2 placeholders (matches `GPU_MODELS` constant in this file: 13 entries with non-zero `fp16_tflops` plus R100 Rubin and Maia 200 placeholders), TTL ranges 1–6h / 6–24h / 24–72h / 24–168h (matches `FRESHNESS_TTLS` in `src/lib/freshness.ts` exactly). No parameter values changed; this is a copy-only calibration.

v1.3.1

  • Modified
    mfu_assumption Description corrected after methodology validation. Prior copy attributed an MFU range of 0.46–0.57 to Chinchilla; Hoffmann et al. 2022 (arxiv 2203.15556) does not directly publish MFU for the 70B run. The 0.46–0.57 range is from PaLM (Chowdhery et al, arxiv 2204.02311, Table 3), and conflated MFU 0.462 with HFU 0.578 — these are distinct metrics (MFU strict vs hardware FLOP utilization including rematerialization). Updated description anchors the 0.40 default explicitly above Epoch AI 2022's 0.30 LLM recommendation, with PaLM 0.462 MFU and LLaMA 3 0.384 MFU as primary calibration points. No numeric default changed.
  • Modified
    interconnect_efficiency,mfu_assumption Source URL canonicalized from https://epochai.org/... to https://epoch.ai/blog/estimating-training-compute (Epoch AI publishes under epoch.ai; the older epochai.org redirects). Source attribution made specific: "Epoch AI (Sevilla et al, 2022)" replaces the bare "Epoch AI" string for interconnect_efficiency.

v1.3.0

  • Modified
    gpu_fraction_of_it Default revised 0.70 → 0.49 to match SemiAnalysis's 100,000-H100 cluster power decomposition (the only published primary-adjacent component-level breakdown of a frontier AI training cluster). The decomposition: 70 MW GPU compute / 142.5 MW total IT load = 49% GPU share. The previous 0.70 default treated GPU TDP as covering server-level draw, which it does not — in-server CPUs, NICs, and PSUs draw an additional ~575 W per GPU; external storage and networking add another ~10% of total IT. Applied alongside the unchanged 700 W H100 TDP, the corrected default reduces predicted GPU count from 100 MW gross by ~27% (from ~83K to ~61K H100), which closes the discrepancy against the SemiAnalysis ground truth and aligns the Capacity Estimator with measured frontier facility decompositions. 0.7 → 0.49
  • Modified
    pue Default revised 1.20 → 1.15 to match empirical fleet disclosures from operators running frontier AI training clusters. Anchors: Microsoft FY25 fleet PUE 1.16 (Americas; 1.28 APAC), AWS 2024 fleet 1.15, xAI Colossus Memphis 1.18 (current; 1.10 planned for liquid-cooled expansion), Oracle Stargate Abilene 1.12 (with heat recovery). Outliers: Google fleet 1.09 (Central Ohio 1.04), Meta FY23 1.08 — both below the new default. No operator publishes AI-training-pod-specific PUE separately from fleet averages; the 1.15 default reflects the median of fleet-level disclosures with documented data-center cooling architecture. The max bound tightened from 1.60 (which captured legacy enterprise) to 1.45 (which captures hot-climate AI facilities). 1.2 → 1.15
  • Added
    eu-ai-act-measurement-tolerance EU AI Act §51(2) compliance methodology now reflects the July 2025 GPAI Guidelines (European Commission, 18 July 2025). The guidelines establish a ±30% measurement tolerance on cumulative training FLOP, accept both hardware-based and architecture-based estimation paths, and exclude RLHF reward-model training from the cumulative count while including continued pre-training and supervised fine-tuning. The 10²³ FLOP floor introduced in the same guidelines defines the GPAI scope itself — below this, no GPAI obligations attach. Article 51(3) delegated-act authority remains unexercised as of April 2026.

v1.2.0

  • Modified
    cascade-edge-weighting Cascade propagation now blends editorial criticality with a 3-month stock price correlation (Pearson r) when market correlation weighting is enabled. Edges without correlation data (the second licensed database, unlisted companies) keep editorial scores unchanged; sole-source edges retain criticality ≥ 9 regardless of correlation. Default blend weight w = 0.5.
  • Modified
    h100_sxm5,a100_sxm,b200 Canonicalized BF16 throughput on DENSE (no 2:4 structured sparsity) across the FLOP engine and Cost Index: 989.5 TFLOP/s per H100 SXM, 312 per A100, 2,250 per B200. Pre-Pass-46 the FLOP engine quoted dense and the Cost Index computed against sparsity-inclusive specs; both defensible from NVIDIA’s datasheet, but the two features disagreed on units. Dense matches Epoch AI ml_hardware (the cited source) and the throughput real training workloads achieve. Cost-per-petaFLOP-day values landed roughly 2x higher; provider ordering invariant.
  • Modified
    substitutability-decay-hbm HBM Memory decay description refreshed for HBM4 mass production (Feb 2026 at SK Hynix M16/M15X and Samsung Pyeongtaek) and the Q3 2025 share split SK Hynix ≈57%, Samsung ≈22%, Micron ≈21% (Counterpoint Research Q3 2025 memory market tracking, as reported through Semiecosystem and corroborated by Counterpoint’s own Q3 2025 press summaries). Samsung’s share recovered from ≈15% in Q2 2025 on the HBM3E NVIDIA qualification cycle. Concentrated but multi-source.
  • Added
    mlperf-cross-check External validation now incorporates MLPerf Inference v4.1: 53 unique datacenter system configurations covering 16 accelerator families (NVIDIA A100/H100/H200/B200/GH200/L4/L40S, AMD MI300X, Google TPU v5e/v6, plus accelerator-startup submissions). Provides independent verification of accelerator type, count, and memory specifications against the Scrutica chip catalog.

v1.1.0

  • Added
    gb200 Added NVIDIA GB200 (Blackwell, per-GPU). Dense FP16 = 2,500 TFLOP/s, 1.2 kW TDP. Verified against Epoch AI ml_hardware.csv.
  • Added
    mi350x Added AMD MI350X (CDNA 4). Dense BF16 = 2,309.6 TFLOP/s, 1.0 kW TDP. Shipped Q3 2025. Verified against Epoch AI ml_hardware.csv.
  • Added
    trainium3 Added Amazon Trainium3. Dense BF16 = 671 TFLOP/s, FP8 = 2,517 TFLOP/s. Cloud-only. Verified against Epoch AI ml_hardware.csv.
  • Added
    tpu_v7_ironwood Added Google TPU v7 Ironwood. BF16 = 2,307 TFLOP/s. Cloud-only. Verified against Epoch AI ml_hardware.csv.
  • Added
    r100_rubin Added NVIDIA R100 (Rubin) placeholder. Announced GTC 2026, volume H2 2026. FP16 specs not yet disclosed; set to 0.
  • Added
    maia_200 Added Microsoft Maia 200 placeholder. TSMC 3nm, 216GB HBM3E. Perf specs not yet disclosed; set to 0.
  • Modified
    b200 Corrected B200 fp16_tflops from 1,125 (was TF32) to 2,250 (dense FP16/BF16 Tensor). Verified against Epoch AI ml_hardware.csv and NVIDIA datasheet. 1,125 → 2,250 TFLOP/s

v1.0.0

  • Added
    Initial methodology release. Three estimation paths (hardware, power, cost) with parameters from NVIDIA/AMD spec sheets and Epoch AI research.

Citing this methodology

Scrutica. “Methodology.” v1.4.0, September 2026. https://scrutica.com/methodology

For a specific estimate, include the methodology version and the estimation path (for example “Hardware Path, v1.4.0”) so the calculation reproduces against the same parameter set. Published under CC BY-SA 4.0 except where source-attributed otherwise.

Packaged datasets

Cite the Compute Cost Index dataset (v2026.4, released 2026-09-25): scrutica.com/datasets/compute-cost-index (No DOI assigned; cite the version and checksum on the dataset page).

Cite the Sovereign AI Program Index dataset (v2026.4, released 2026-09-25): scrutica.com/datasets/sovereign-ai-index (No DOI assigned; cite the version and checksum on the dataset page).