Methodology
Methods, data sources and assumptions
The sources behind Scrutica's records, the authority tier each carries, and the formulas, defaults and ranges behind its estimates.
9 corrections · latest 26 Sep 2026
- 26 Sep 2026 · Compute estimates: communication losses discounted twice
- 25 Sep 2026 · Export-control cross-reference: 101 of 102 ownership-chain matches could not be traced to the designated entity
- 23 Sep 2026 · Supply-chain relationship counts: the count of the graph they describe
- 23 Sep 2026 · Cascade: relationships last disclosed five or more years before the latest filing wave no longer propagate
- 23 Sep 2026 · Cascade: partnerships no longer propagate as supply
- 23 Sep 2026 · Compute attribution: control classed only where a source establishes the role
- 22 Sep 2026 · EDA market shares in scenario and coordination analysis
- 7 Sep 2026 · Stargate UAE chip inventory withheld
- 5 Sep 2026 · Unsupported supply-chain values withheld
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.
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 / Filing | Quarterly (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 / Filing | As amended | Entity List entries and associated licensing information |
| GAO / SIA CHIPS Act reports Government assessments and semiconductor-industry summaries of CHIPS Act implementation. | T1: Government / Filing | As published | Semiconductor 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 Database | Monthly | GPU 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 Database | Annual | Semiconductor 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 Database | Quarterly | Sovereign 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 / Analyst | Daily | Private 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 / Analyst | Daily | Corporate 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 / Analyst | Monthly | Generation 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 / Analyst | As published | 36 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 / Secondary | As published | Facility 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.
| Dataset | Records | Sources and scope | Coverage statement |
|---|---|---|---|
| Facilities | 4,583 across 110 countries |
| 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 records | 20,798 supply-chain records across all sources |
| 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 designations | 3,435 records (3,420 without a recorded removal date) |
| 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 programs | 36 country / program profiles |
| The 36 profiles are individually researched, with sources listed for each programme. No global programme list underlies the count. |
| FLOP / compute capacity estimates | 4,109 facility-level deployments |
| 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 Index | GPU rental prices and modelled ownership costs |
| 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 chains | 103,771 directed links between organisations; 130,407 organizations; 15,365 aliases |
| 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 records | Awards, solicitations and funding opportunities |
| 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 trade | Trade values by country pair, product code and reporting period |
| 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 |
| 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. |
Estimation Methodologies
- FLOP Estimation (3 paths)Facility compute capacity estimated from GPU counts, power capacity or capital expenditure, with uncertainty bounds for each method.
- Compute Cost IndexCost per petaFLOP-day for on-demand, spot and reserved cloud instances, from published prices, and for on-premises hardware, from a cost model.
- Cascade SimulationSimulated downstream effects of a supplier disruption. Every edge uses the default input share until a source states one; criticality is derived from the source’s relationship rank or defaults to 5; the decay is set per scenario.
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.
- Tier 2: Research Database
- Value from a research organization or curated research database with documented methodology; includes peer-reviewed academic publications.
- Tier 3: Estimated
- Value derived from proxy methods, industry analyst estimates, or press reports.
- Tier 4: Speculative
- Value from secondary inference, expert opinion, or interpolation. Widest estimation bounds.
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.
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
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
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
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.
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.00 | 0.60–1.00 | Scrutica 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.40 | 0.20–0.50 | SemiAnalysis, “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.49 | 0.35–0.65 | Scrutica 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.15 | 1.05–1.45 | Scrutica 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.45 | 0.30–0.60 | Scrutica modeling assumption |
Interactive FLOP estimator
Highest Confidence. Counts the disclosed GPUs and reads their published throughput.
In plain language
- 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
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
- Peak FP16 Throughputpeak_flops = gpu_count × per_gpu_fp16_tflops × 1e12
- gpu_count
- 10,000
peak_flops9.89 times 10 to the 18 FLOP/s - Effective Throughputeffective_flops = peak_flops × interconnect_efficiency
- interconnect_efficiency
- 1.00
effective_flops9.89 times 10 to the 18 FLOP/s - Training Throughputtraining_flops = effective_flops × mfu_assumptiontraining_flops3.96 times 10 to the 18 FLOP/s
- Daily FLOP Budgetdaily_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 source | Cadence | Method |
|---|---|---|
| Cloud Provider APIs (Azure, OCI; AWS spot) | Daily | Vercel cron |
| AWS Pricing Bulk API (on-demand) | Daily | GitHub Actions |
| Cloud Provider Pricing Pages (GCP, CoreWeave, Lambda) | Manual refresh | Manual 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
- Epoch AI Notable AI Models (authority tier 2). Per-run training-cost estimates in 2023 US dollars.
- Cottier et al. “The rising costs of training frontier AI models.” arXiv:2405.21015, version 2 (2025) (authority tier 2). Most published figures cover the final training run; this paper also estimates full development costs, including experiments and staff, for four models.
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
| Parameter | Default | Range | Description |
|---|---|---|---|
max_hops | 6 hops | 6–6 | Fixed maximum path length. Hop count is graph distance, not elapsed time. |
initial_shock_severity | 1 | 0.1–1 | Severity of the initial disruption at the source node (1.0 = complete disruption). |
Parameter sensitivity
Complete loss of TSMC Taiwan fab capacity (natural disaster, blockade).
ScenarioTSMC Taiwan Disruption
Simulated at decay0.90Affected organizations141 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.
| Scenario | Decay | Rationale |
|---|---|---|
| TSMC Taiwan Disruption | 0.90 | TSMC 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 Halt | 0.95 | The 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 Impact | 0.70 | Domestic 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 Denial | 0.80 | Upstream 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 Bottleneck | 0.70 | Multi-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 Disruption | 0.80 | The 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 Restriction | 0.80 | Synopsys 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 Disruption | 0.75 | Compound 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.75 | The 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 Shortage | 0.80 | The 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.95 | The 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.65 | Recycling, 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 Constraint | 0.85 | Structural 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.82 | Silicon-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 Restriction | 0.90 | Substitutability 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 Expansion | 0.80 | Substitutability 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 China | 0.85 | DUV 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 Restriction | 0.65 | Substitutability 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 Restriction | 0.75 | Restricted-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 Only | 0.95 | Substitutability 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.
| Category | Substitutability | Description |
|---|---|---|
| EUV Lithography | 0.02 | Near-zero substitutability. ASML sole source. |
| Advanced Foundry (<7nm) | 0.05 | TSMC dominant. Samsung limited alternative. |
| GPU Accelerators | 0.15 | NVIDIA dominant but AMD MI300X is a partial substitute. |
| HBM Memory | 0.10 | SK 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.15 | TSMC 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.30 | Ethernet 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 Construction | 0.50 | Many EPC contractors globally. Highly substitutable. |
| Power Delivery | 0.25 | Regional 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.
| Layer | Buffer | Range | Shape | Tier |
|---|---|---|---|---|
| EUV Lithography | None | 0–0 wk | cliff | T4 |
| Advanced Wafers (N3/N5) | 10 wk | 8–16 wk | linear | T4 |
| Packaged Chips (GPU) | 3 wk | 2–5 wk | cliff | T4 |
| Server Assembly | 14 wk | 8–26 wk | exponential | T4 |
| HBM Memory | 3 wk | 0–8 wk | cliff | T4 |
| ABF Substrates | 12 wk | 4–30 wk | linear | 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 supplier | Substitute | Qualification | Ceiling | Tier |
|---|---|---|---|---|
| TSMC Advanced Node | Samsung Foundry | 24mo | 15% | T4 |
| Intel Foundry (IFS) | 36mo | 5% | T4 | |
| ASML EUV | No viable substitute | |||
| SK Hynix HBM | Samsung HBM | 0mo | 45% | T4 |
| Micron HBM | 0mo | 25% | T4 | |
| NVIDIA Training GPUs | AMD MI300X/MI350 | 12mo | 15% | T4 |
| TSMC CoWoS Packaging | Amkor (OSAT) | 18mo | 20% | T4 |
| SPIL (OSAT) | 18mo | 10% | 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.
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.
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.
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.
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()inscripts/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.
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 Source | Data Type | Coverage | Methodology Difference |
|---|---|---|---|
| Epoch AI GPU Clusters | Facility PFLOP/s estimates | Imported cluster records | Epoch 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 / Counterpoint | Semiconductor market share | Quarterly updates | The 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 Inference | Hardware specifications (accelerator type, memory, count) | Recorded v4.1 configurations | Submitted 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.
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_efficiencyDefault 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_assumptionThe 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_itCorrects 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_rubinAligned 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_200Added 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-availabilityNumeric 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
gb300Added 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_910bAdded 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_v6eAdded 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-mappingThe 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
trainium2Added 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-scopeThe 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-mvsCountry-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-designationsRemoved 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-copyCorrects 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-copyMethodology 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_assumptionDescription 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_assumptionSource 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_itDefault 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
pueDefault 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-toleranceEU 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-weightingCascade 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,b200Canonicalized 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-hbmHBM 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-checkExternal 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
gb200Added NVIDIA GB200 (Blackwell, per-GPU). Dense FP16 = 2,500 TFLOP/s, 1.2 kW TDP. Verified against Epoch AI ml_hardware.csv. - Added
mi350xAdded 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
trainium3Added Amazon Trainium3. Dense BF16 = 671 TFLOP/s, FP8 = 2,517 TFLOP/s. Cloud-only. Verified against Epoch AI ml_hardware.csv. - Added
tpu_v7_ironwoodAdded Google TPU v7 Ironwood. BF16 = 2,307 TFLOP/s. Cloud-only. Verified against Epoch AI ml_hardware.csv. - Added
r100_rubinAdded NVIDIA R100 (Rubin) placeholder. Announced GTC 2026, volume H2 2026. FP16 specs not yet disclosed; set to 0. - Added
maia_200Added Microsoft Maia 200 placeholder. TSMC 3nm, 216GB HBM3E. Perf specs not yet disclosed; set to 0. - Modified
b200Corrected 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).