WEO Methodology Manual

Warmth Engine Observatory

January 2026 | Version 1.5 (July 2026)

CANONICAL SOURCE DECLARATION

This work is the authoritative version published at DOI: 10.5281/zenodo.18427565

Novel terminology, frameworks, and methodological innovations introduced herein originated with this publication as of January 2026.

Version 1.5 (July 2026) introduces Infrastructure Threads as a supplementary factual-linking layer with four link types (Chapter 10), Response Bands for CC Type 5 temporal calibration (§9.4.1), Parallel Policy assessment refinements including the Criterion 1 mandatory gate with specificity sub-test, Industry Similarity formalisation of Criterion 2, and CC-A confidence ceiling (§9.3.2, §9.4.3), revised Option E with confidence tier and status designation (§3.5), the Basel 5-Factor object-of-assessment rule, F3 strategic-concentration qualifier, and entity-specific evidence requirement (§4.4), PISA-5 F2/F4 assessment object for non-regulatory events (§4.9), Framework Family parent→member direction (§9.2.1), the Distinct Actor Requirement common-control extension (§9.1.6), ENT-4 coupled gate architecture (§8.3.4), WER provisionality and n-disclosure (§8.5), a reduced verification lag for verified product releases with mandatory maturity re-review (§3.9.2, §3.15.13), and a convergent implementation evidence accommodation for Policy events with unpublished instruments (§4.11).

The canonical version is the Zenodo publication. Derivative works, summaries, or adaptations should cite this canonical source.

Author: Warmth Engine | [email protected] | warmthengine.com

NOVEL TERMINOLOGY — PRIORITY DOCUMENTATION

The following terms and frameworks were originated by this author:

Originated by: Warmth Engine

About the Author

Warmth Engine is the founder of the Warmth Engine Observatory, a platform tracking AI infrastructure coordination dynamics across geopolitical blocs. Other published work by this author includes The Warmth Engine Series: Analytical Prophecy and the Convergence of AI Sovereignty, Infrastructure Colonialism, and the Coordination Imperative (Zenodo DOI: 10.5281/zenodo.17451629), conducted as separate independent research.

Table of Contents

Abbreviations

Notation

Code-formatted names (likeThis) denote the methodology’s data-model vocabulary: the canonical name under which each recorded element is held, whatever system the analyst uses to record it. Names print exactly as defined — including case and nesting; each name’s meaning is given by the provision where it appears, and where a provision defines a closed value set, its values print in the same form.

Terminology Disambiguation

Three terms in this Manual have multiple meanings depending on context.

“Tier” — Three Distinct Systems

How to distinguish: Claim verification tiers use letters (A/B/C) and appear only in Section 3.4. Event classification tiers use numbers (1/2/3) and appear throughout the rest of the document. Context makes the distinction clear: “Tier A claim” refers to verification; “Tier 1 event” refers to classification. J-Tiers are always written with the “J-” prefix and appear only in §4.9.

“Infrastructure” — Three Distinct Meanings

How to distinguish: Event Type “Infrastructure” answers “how did this happen?” (mechanism). Domain “Energy/Infrastructure” answers “what is this about?” (subject matter). An event can be Event Type: Policy (mechanism) but Domain: Energy/Infrastructure (subject) — for example, a regulation governing data centre construction. An “Infrastructure Thread” is not a classification of the event at all — it is a documented material link between two events (Chapter 10).

Key principle: Event Type and Domain are orthogonal classification systems. Any combination is valid.

“Coordination” — Three Distinct Usages

How to distinguish: “Coordination dynamics” appears in platform-level descriptions and encompasses all tier classifications including T2 Fragmentation. “Coordination” (specific dynamic) appears paired with “Fragmentation” when the two dynamics are being distinguished. “Coordination” (Event Type) appears in event classification contexts alongside Infrastructure, Policy, and Corporate.

Key principle: WEO’s methodology scope is the full field of AI infrastructure coordination dynamics — cooperative and competitive. This scope extends established usage. In foundational IR/IPE scholarship (Keohane, 1984; Stein, 1982), “coordination” denotes cooperative policy adjustment. WEO adopts the broader framing from coordination dynamics in complexity science (Kelso, 1995), where cooperation and competition are complementary patterns within a single dynamical field, and from regime complexity theory (Keohane & Victor, 2011; Zürn & Faude, 2013), where fragmentation is a structural feature of governance rather than merely coordination’s absence. Fragmentation events are within scope because they are observable dynamics between blocs within this field — not because they involve cooperative coordination in the Keohane (1984) sense.

Chapter 1: Executive Summary

What WEO Is

This methodology enables systematic tracking of AI infrastructure coordination dynamics across geopolitical blocs through verified events and mapped coordination connections.

Why It Exists

No existing framework systematically documents AI infrastructure coordination dynamics at the intersection of technology deployment, geopolitical alignment, and institutional governance. Existing frameworks address either technology (AI capability benchmarks), economics (trade flows), or politics (governance indicators) — but none classify and document their coordination interdependencies.

WEO addresses this gap by applying institutional-grade classification methodology to this emerging domain. The methodology adapts proven frameworks for this purpose:

Where external precedent is unavailable, category creator choices are flagged explicitly. Calibration justifications are documented in Methodology Rationale.

Core Principles

Evidence-only observation. Classification is based on observable facts from official public documentation. Implementation evidence required, not announcements. Hidden intent, private communications, and future intentions are explicitly outside measurement scope.

Reproducibility over comprehensiveness. Classification criteria are explicit and evidence-based, enabling independent verification. Where ambiguity exists, documented escalation protocols ensure transparent resolution.

Verification rigour. Evidentiary requirements are adapted from gold-standard cross-sector practices; WEO aims to meet the verification rigour of major financial indices.

Target Audiences

Institutional Investors — Actionable insight on AI infrastructure coordination dynamics, with transparent methodology and verifiable data.

Policy Makers — Neutral analysis with clear definitions, documented rationale, and explicit classification logic.

Independent Researchers — Replicable methodology with full source transparency, enabling verification and challenge of findings.

Technologists — Precise definitions, clear classification methodology, and documented technical specifications.

AI Systems & Autonomous Agents — Structured, deterministic data with schema-level transparency linking data fields to methodology provisions.

Manual Navigation

Supporting Documents

The following companion documents are referenced throughout this manual and maintained separately:

The 10-chapter Manual is self-contained for operational use. The Methodology Rationale provides deeper technical detail for users requiring full methodological transparency regarding the derivation and grounding of calibration choices.

Methodology Evolution & Source Accuracy

WEO methodology is a living framework subject to refinement as empirical data accumulates and validation milestones are reached. Whilst every effort has been made to ensure accuracy in citations and source material, minor discrepancies may exist in historical details. Full documentation of methodology evolution commitments and source accuracy notes is provided in Methodology Rationale (§2.5, Appendix C).

End of Chapter 1: Executive Summary

Chapter 2: Methodology Architecture

Overview

This methodology enables systematic tracking of AI infrastructure coordination dynamics through a structured classification framework. Events enter a processing sequence where they are verified, assessed for significance, classified by tier and domain, and mapped for coordination connections.

The methodology captures two distinct dynamics:

• Coordination — active integration, cooperation, and alignment
• Fragmentation — structural separation between blocs

These dynamics manifest differently depending on scale:

• Cross-bloc (Tier 1): Verified cross-bloc adoption or implementation by the principal AI actor of each of at least two distinct ecosystems
• Between-bloc (Tier 2): Structural separation between blocs through restriction, parallel buildout, or regulatory barriers
• Intra-bloc (Tier 3): Coordination within a single bloc

2.1 Processing Sequence

Processing Phases

WEO methodology operates in three phases containing five stages:

PHASE 1: QUALIFICATION (Does this event belong in WEO? What is it?)

• Stage 1: Event Verification — Source quality, evidence standards, Event Type determination
• Stage 2: Significance Assessment — Keohane Pre-Filter, Basel 5-Factor, Route-Based, PISA-5

PHASE 2: CLASSIFICATION (What kind of event is this?)

• Stage 3: Tier Classification — Coordination scale (T1 Cross-Bloc, T2 Between-Bloc, T3 Intra-Bloc)
• Stage 4: Domain Classification — Subject matter (Energy/Infrastructure, Security, Technology, Trade)
• Industry Tags — Identify which industries each event’s documented provisions address (Chapter 7)
• Environmental Nexus Tags — Assess environmental intersections across five tag types (Chapter 8)

PHASE 3: RELATIONSHIP MAPPING (How does it connect to other events?)

• Stage 5: Coordination Connections — Cross-database analysis after all events complete Stages 1-4

Stages 1-4 process events individually and sequentially. Stage 5 operates across the complete verified database as a cross-event analysis phase.

Five-Stage Sequence

Events progress through five sequential stages. Failure at Stage 1 or Stage 2 excludes the event from the database. Stages 3-5 classify qualifying events and document their relationships.

CANDIDATE EVENTS
       ↓
  ┌─────────────────────────────────┐
  │  STAGE 1: EVENT VERIFICATION    │  → Chapter 3
  │  Source verification,           │
  │  implementation evidence,       │
  │  Keohane coordination criteria  │
  └─────────────────────────────────┘
       ↓
  ┌─────────────────────────────────┐
  │  STAGE 2: SIGNIFICANCE          │  → Chapter 4
  │  Keohane Pre-Filter (auto)      │
  │  Part A: Physical Infrastructure│
  │  Part B: Software/Platforms     │
  │  Part C: Policy/Institutional   │
  └─────────────────────────────────┘
       ↓
  ┌─────────────────────────────────┐
  │  STAGE 3: TIER CLASSIFICATION   │  → Chapter 5
  │  T1 / T2 / T3                   │
  └─────────────────────────────────┘
       ↓
  ┌─────────────────────────────────┐
  │  STAGE 4: DOMAIN CLASSIFICATION │  → Chapter 6
  │  4 domains                      │
  └─────────────────────────────────┘
       ↓
  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
    INDUSTRY TAGS                      → Chapter 7
    Industry addressed by provisions     
  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
       ↓
  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐
    ENVIRONMENTAL NEXUS TAGS           → Chapter 8
    Environmental intersection tags      
  └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
       ↓
  ┌─────────────────────────────────┐
  │  STAGE 5: COORDINATION          │  → Chapter 9
  │  CONNECTIONS                    │
  │  Cross-event relationships      │
  └─────────────────────────────────┘
       ↓
    VERIFIED EVENT DATABASE
    + COORDINATION CONNECTIONS

Sequence Principle: Reproducibility over comprehensiveness.

2.2 Stage Summaries

Stage 1: Event Verification (Chapter 3)

Events must meet gold-standard verification requirements: 2+ Primary sources OR 1 Primary + 2 Corroborating sources, implementation evidence (not announcements), and HIGH or MEDIUM confidence. Infrastructure events require $100M minimum. The 6-month verification lag ensures implementation confirmation before database entry; verified product releases enter under a 60-day reduced lag with mandatory maturity re-review (§3.9.2).

Stage 2: Significance Assessment (Chapter 4)

Events are assessed for geopolitical significance via one of four pathways:

• Keohane Pre-Filter: Multi-nation coordination events meeting Keohane criteria auto-qualify
• Part A (Basel 5-Factor): Physical AI infrastructure — 2+ of 5 factors required
• Part B (Route-Based): Software/platform infrastructure — four strategic routes
• Part C (PISA-5): Policy/institutional events — five-factor assessment

Stage 3: Tier Classification (Chapter 5)

Events are classified by bloc participation scope:

• Tier 1: Cross-bloc coordination (verified adoption or implementation by the principal AI actor of each of at least two distinct ecosystems)
• Tier 2: Between-bloc fragmentation (structural separation through restriction, parallel buildout, or regulatory barriers)
• Tier 3: Intra-bloc coordination (within a single bloc)

Stage 4: Domain Classification (Chapter 6)

Events are assigned to one of four domains based on primary subject matter: Energy/Infrastructure, Security, Technology or Trade. The critical distinction is durability: Energy/Infrastructure events (20-60 years typical) versus Technology domain events (2-5 years typical).

Stages 1–4 complete individual event processing. Before Stage 5 cross-event analysis, two analytical enrichment layers are applied. These are not additional stages — they inherit the evidentiary assurance of the upstream pipeline and produce metadata consumed by downstream analysis.

Industry Tags (Chapter 7). Verified events are tagged with the specific industry their documented provisions most directly address, drawn from an 11-category taxonomy mapped to GICS. Each event receives one primary tag and up to two secondary tags, each supported by a mechanism statement documenting the pathway from event provisions to industry operations.

Environmental Nexus Tags (Chapter 8). Verified events are assessed for environmental intersections across five tag types: Resource Demand (ENT-1), Environmental Enablement (ENT-2), Environmental Consequence (ENT-3), Environmental Dependency (ENT-4), and Environmental Coordination (ENT-5). Each applied tag carries a mechanism statement and evidence-basis descriptor.

Stage 5: Coordination Connections (Chapter 9)

Events are analysed for relationships with other verified events. Seven connection types document observable relationships: Policy Cascade, Joint Issuance, Funding Flow, Regulatory Enablement, Response, Framework Family, and Parallel Policy. Each connection carries a confidence level (CC-V, CC-E, or CC-A).

Infrastructure Threads (Chapter 10). A supplementary factual-linking layer records documented material links between verified events. Threads are established outside the five-stage sequence and are not Coordination Connections.

2.3 Component Navigation

Chapters 6–9 carry inline category and confidence annotations summarising each provision’s derivation. The complete categorisation — confidence bands and grounding assessments for all chapters — is maintained in the Methodology Rationale; where an inline annotation and the Rationale diverge, the Rationale governs.

2.4 Classification Systems

Three independent classification systems are applied to each verified event:

These classifications are orthogonal — any combination is possible. An Infrastructure event (mechanism) can be Tier 2 (scale) in the Technology domain (subject). Event Type is determined during verification (Stage 1); Tier and Domain are determined during classification (Stages 3-4).

2.5 Industry Tags

Industry tags are a distinct analytical layer applied during Phase 2, after domain classification (Stage 4) and before coordination connections (Chapter 9). They identify which specific industry each event’s documented provisions most directly address.

Industry tags are conceptually distinct from the three classification systems in §2.4. Classification assigns intrinsic properties — for example, the event IS Tier 1. An industry tag identifies an external relationship — for example, the event’s provisions ADDRESS the semiconductor industry. This directional distinction is why industry identification is treated as tagging rather than classification.

Industry tags do not modify the “three phases containing five stages” architecture documented in §2.1, nor add a fourth entry to the three independent classification systems in §2.4. They are a separate analytical layer that inherits the evidentiary assurance of the upstream pipeline (Stages 1–4) and produces metadata consumed by downstream analysis.

The methodology is documented in Chapter 7: Industry Tags. Complete reference material is maintained in the companion Industry Tagging Reference.

2.6 Environmental Nexus Tags

Environmental Nexus Tags (ENTs) are a distinct analytical layer applied during Phase 2, after industry tags (Chapter 7) and before coordination connections (Chapter 9). They identify which environmental dynamics each event intersects — resource demand, environmental enablement, environmental consequence, environmental dependency, or environmental coordination.

ENTs are conceptually distinct from the three classification systems in §2.4. Classification assigns intrinsic properties — the event IS Tier 3. An ENT identifies an external intersection — for example, the event INTERSECTS WITH documented resource demand. This directional distinction is why environmental intersection identification is treated as tagging rather than classification.

ENTs do not modify the “three phases containing five stages” architecture documented in §2.1, nor add a fourth entry to the three independent classification systems in §2.4. They are a separate analytical layer parallel to industry tags (§2.5) that inherits the evidentiary assurance of the upstream pipeline (Stages 1–4) and produces metadata consumed by downstream analysis.

The methodology is documented in Chapter 8: Environmental Nexus Tags. Rationale for ENT design decisions is documented in Methodology Rationale.

2.7 Methodological Foundations

For empirical derivations and calibration justifications, see Methodology Rationale.

2.8 Explicit Limitations

The methodology tracks observable dynamics from verified public documentation. The methodology explicitly cannot capture:

• Hidden strategic intent not documented in public sources
• Private diplomatic communications
• Future intentions not yet announced
• Implicit understandings without official documentation
• Strategic ambiguity when documents are intentionally vague
• Classified military and intelligence cooperation

Trade-offs accepted:

While classified military and intelligence cooperation remains outside WEO’s evidentiary scope, the methodology’s discovery process actively monitors publicly accessible defence procurement databases, enacted appropriation documents, and published audit reports to maximise coverage of the observable portion of Security domain activity. These sources serve as discovery signals; all candidate events identified through them must independently satisfy the full qualification standards documented in Chapters 3 and 4 to enter the database.

Note on structural visibility asymmetry: WEO’s documentation-based standard applies consistently across blocs but produces directional under-representation of Eastern Bloc events. Three sources contribute: application-agnostic instrument design conventions common to upstream supply chain controls in both blocs; a documentation layer within Chinese-language databases and platform-integrated channels beyond the current reach of WEO’s verification approach; and structurally thinner regulatory process architecture in Chinese governance. Eastern Bloc event coverage should be treated as a conservative lower bound on Eastern Bloc AI infrastructure activity. See §4.11: Structural Visibility Asymmetry for full documentation.

2.9 Analytical Framework Boundaries

The bloc classification model (at V1.5 publication, Western and Eastern, with Non-Aligned nation attribution per §3.10) is a first-order analytical framework prioritising usability and classification consistency over geopolitical granularity. Bloc designation reflects primary AI ecosystem alignment — the ecosystem through which a nation’s AI capabilities are developed, deployed, and governed — not a comprehensive geopolitical assessment. The framework is documentation-based and measures verified coordination dynamics through primary and corroborating sources.

The principal actor requirement (§5.3) produces a conservative classification for events where participation spans multiple blocs but verified adoption or implementation by the principal AI actor of each of at least two distinct ecosystems has not been demonstrated. Principal AI Actor designations and bloc structure are reassessed at methodology version milestones (§5.3 Review Mechanism).

2.10 Analytical Layer Model

The methodology produces a layered analytical stack. Each layer operates on a defined unit of analysis and is defined by the chapter shown.

Each layer is authored under the evidence standards of its defining chapter and carries direct evidentiary grounding.

The three classification systems (§2.4), the two tag layers (§2.5, §2.6), and the inter-event layers (Chapters 9 and 10) are independent analytical operations. Adding or removing a layer does not modify the processing sequence architecture (§2.1) or the classification system count (§2.4).

End of Chapter 2: Methodology Architecture

Chapter 3: Event Verification

Gold Standard Requirements

WEO aims to meet the verification rigour of major financial indices (S&P, MSCI, FTSE). This section defines the exact standards that all coordination events must meet to be included in the WEO database.

All events must first pass the AI Connection Filter (Section 3.5) to establish they belong within WEO’s scope before proceeding through the verification sequence.

3.1 Source Quality Hierarchy (What Counts as Evidence)

Primary Sources

Government Official Documents:

• Federal Register (US), Official Gazettes (global)
• Parliamentary/Congressional records
• Official statements from heads of state/ministers (verified via .gov domains)
• International treaty texts (UN archives, WTO documents)
• Audited budget allocations (OMB, treasury reports)

Regulatory Filings:

• SEC filings (US), equivalent bodies globally
• Central bank reports (Fed, ECB, PBoC official publications)
• Official statistics agencies (BEA, Eurostat, National Bureau of Statistics China)

Multilateral Organisation Publications:

• UN agency reports (UNDP, ITU, WIPO - official publications)
• OECD, IMF, World Bank (published reports, data releases)
• WTO trade data and dispute records

Corroborating Sources

Academic & Research:

• Peer-reviewed papers in indexed journals (IEEE, Nature, Science)
• University research centres (Stanford HAI, MIT, Oxford, Tsinghua)
• Think tank analysis (CSIS, Brookings, Chatham House - research reports, not opinion)

High-Quality Journalism:

• Major wire services (Reuters, AP, Bloomberg - investigative pieces, not opinion)
• Financial Times, Wall Street Journal, Economist (fact-based reporting)
• Investigative journalism with named sources and document trails

Industry Documentation:

• Official industry consortium announcements (with member verification)
• Trade association reports (Semiconductor Industry Association, etc.)
• Vendor contracts and procurement records (when public)

Supplementary Sources (Never Use Alone)

Supplementary Evidence:

• Commercial intelligence (satellite imagery providers - Maxar, Planet Labs)
• Trade databases (UN Comtrade, national customs, 6-12 month lag acceptable)
• Expert testimony to official bodies (Congressional hearings, etc.)

Explicitly Excluded (Never Use)

✗ Social media (even verified accounts - no verification standard)
✗ Press releases without implementation proof
✗ Op-eds and commentary (subjective, not evidence)
✗ Unnamed sources / anonymous leaks
✗ Non-peer-reviewed academic or opinion white papers (note: technical documentation from implementing entities remains valid per Section 3.4.4)
✗ Wikipedia, Reddit, forums, blogs

Primary Source Substitution

Where an event is evidenced by ≥2 independent Grade 1 primary sources (canonical instruments directly documenting the event — e.g., statutory text, official gazette entry, regulatory filing, audited financial disclosure, direct benchmark output), the corroborating source requirement is satisfied in full. Multiple independent Grade 1 instruments provide verification that meets or exceeds the base standard, because each canonical instrument independently confirms the event’s occurrence without interpretive intermediation. This substitution applies only to Grade 1 sources as defined in the Source Authority Hierarchy (§5.3.4); Grade 2 and Grade 3 primary sources do not substitute for corroborating sources.

This principle is consistent with §3.4.9, which specifies “2+ Primary OR 1P + 2C” as acceptable verification for Tier A claims (event existence, implementation status). The substitution rule formalises and extends this pathway as a general evidence principle grounded in the same quality-over-quantity logic applied to the dimension evidence standard in §5.3.4.

Source Accommodations

Four source accommodations within this Manual expand what constitutes qualifying primary evidence for specific event classes where standard primary sources do not exist by structural convention. Each specifies its own evidence standard and qualifying conditions at the section where the accommodation is defined:

• Structural Visibility Asymmetry — state media (§4.11) — state media with official documentary function, under specified conditions
• Structural Visibility Asymmetry — convergent implementation evidence (§4.11) — convergent multi-stream evidence including an accountability-bearing disclosure, for Policy events where the instrument is unpublished, under specified conditions
• Operational Evidence Protocol (§3.5, Option D) — independent technical laboratory analysis for Infrastructure events
• Post-Implementation Evidence Track (§3.5.1) — gate evidence at primary source standard for Policy restriction events

Events verified through accommodated pathways satisfy §3.1 requirements. See §3.4.11 for verification assessment guidance where accommodated sources are the sole or principal basis for Tier A claims.

3.2 Verification Protocol (Step-by-Step)

For Every Event, Complete These Steps

Step 1: Initial Discovery

• Source: News aggregators, government websites, think tank reports
• Note: AI research tools used for event discovery and source identification; all sources verified manually by analyst
• Output: Candidate event identified

Step 2: Primary Source Verification (MANDATORY)

• Find 2+ Primary sources OR 1 Primary + 2 Corroborating sources (at least one with direct access)
• For government actions: Find official .gov document or parliamentary record
• For infrastructure: Find construction permits, budget allocations, vendor contracts
• For policies: Find enacted legislation or official regulatory text
• Archive sources: Document all URLs with access dates (archive.org optional for critical sources)

Step 3: Fact Verification Checklist

✓ Date confirmed: Exact implementation date (not announcement date)
✓ Scope verified: Geographic reach, budget amount, participant list
✓ Status confirmed: Operational (not just proposed or under construction)
✓ Independence verified: Multiple sources confirm (no circular reporting)

Step 4: Implementation Evidence (Not Just Announcements)

• For infrastructure: Construction completion, operational status, utilisation evidence
• For policies: Enacted law (not just proposed bill), enforcement actions
• For agreements: Ratified treaty (not just MOU or framework), implementation mechanisms
• For standards: Adoption evidence (# of entities implementing, market penetration)

Step 5: Documentation

Complete all required Phase 1 metadata and documentation: - Event ID, dates, sources, confidence level - Event Type classification with rationale - Bloc attribution (WB/EB) for NA nation events (via Section 3.10) - Analyst notes explaining verification decisions

Note: Event Tier classification and Fragmentation Type are assigned during Phase 2 Classification (Chapter 5). See Section 3.13 for Phase 1→Phase 2 Handoff Protocol and validation checklist.

3.3 Non-English Source Verification Protocol

Non-English language events require enhanced verification protocols. WEO’s analyst base is predominantly English-language, which presents challenges for efficient navigation and filtering of primary sources in other languages. To maintain equivalent verification rigour across all blocs, WEO employs advanced translation systems and region-specialist research tools. These protocols apply to any event where primary sources are not in English, regardless of bloc — including Chinese, Russian, French, German, Japanese, Arabic, and other non-English documentation.

Primary Application: Chinese-Language Sources

Chinese-language sources represent the most common non-English verification scenario for AI infrastructure events.

Minimum Evidence Standard:

• Official State Council documents (english.gov.cn) OR
• Ministry-level announcements (MIIT, CAC, NDRC official sites) AND
• Third-party confirmation from:
  • World Bank/ADB project databases OR
  • UN agency reports OR
  • Peer-reviewed academic papers (Chinese Academy of Sciences) OR
  • Trade statistics (China Customs + UN Comtrade cross-check)

Infrastructure Claims:

• State announcement + satellite imagery OR
• Budget allocation + construction permits OR
• Vendor contracts + operational evidence

Financial Claims:

• Official announcement + IMF/World Bank country data OR
• China Customs statistics + UN Comtrade cross-verification OR
• Academic analysis with primary data sources

Other Non-English Sources

Eastern Bloc (Russian, Farsi, etc.):

• Official government sources + third-party confirmation from internationally recognised outlets OR
• Academic research + multilateral organisation data OR
• Trade statistics + satellite/commercial intelligence

Western Bloc and Non-Aligned (French, German, Japanese, Arabic, etc.):

The same enhanced verification principles apply to non-English Western and Non-Aligned sources:

• Official government sources in original language + English-language confirmation OR
• Academic research with primary source citations + multilateral organisation data OR
• Trade statistics + third-party reporting from internationally recognised outlets

Examples:

• French government AI strategy documents (gouvernement.fr) → verify via EU-level reporting or English-language official summaries
• Japanese semiconductor policy (METI announcements) → verify via English-language ministry publications or trade press
• Saudi AI investment announcements (Arabic sources) → verify via sovereign wealth fund English disclosures or international financial press

Enhanced Verification Considerations

The following indicators warrant additional scrutiny for any non-English source, regardless of bloc:

Caution indicators:

• Only reported by state-controlled or government-funded media without third-party confirmation
• Round numbers without granular detail (e.g., “100 billion yuan”, “€50 billion”)
• Contradicts prior verified data without explanation
• No English-language confirmation available from official or recognised international sources

Confidence Scoring

Applies to all non-English source events regardless of bloc:

• High (90%+): Primary sources + implementation evidence + third-party confirmation
• Medium (70-90%): Primary + Corroborating sources, implementation pending or partial
• Low (<70%): Insufficient verification — DO NOT INCLUDE in the database

3.3.1 CJK Language Conventions

Chinese, Japanese, and Korean (CJK) text in the Manual and event database follows a four-pattern taxonomy governing when and how CJK characters appear alongside English text.

Pattern A — Verbatim Citation. CJK text appears in a dedicated sub-field paired with an English translation when citing official instrument text for CC evidence. The CJK text is the verbatim source; the English text is the working translation. Both are required. Example: a 根据 (pursuant to) clause cited as CC evidence for a Policy Cascade connection.

Pattern B — Methodology-Functional Term. CJK text appears inline in English prose when the term is operative within the methodology — meaning its removal would lose methodology-substantive information. An English gloss is provided on first use. Example: 根据 (pursuant to) as a regulatory citation marker in §9.5.2.

Pattern C — Named Programme. Programmes, initiatives, and policy instruments are rendered English-first with a CJK parenthetical on first mention only. Subsequent mentions use the English name. Example: “East-Data-West-Compute (东数西算) programme” on first mention; “East-Data-West-Compute programme” thereafter.

Pattern D — Direct Quantity. Numeric figures quoted directly from CJK primary sources are preserved in their original rendering where the numeric value is the methodologically relevant content. Use sparingly and only where the original figure is the primary evidence.

Methodology-functional test: Before including CJK text, apply the test: “Would removing this CJK text lose methodology-substantive information?” If no, the CJK text is decorative and should be omitted. Commercial brand names in CJK form are not methodology-functional and are excluded unless they are the formal name of a qualifying entity in the event database.

3.4 Source Requirements by Claim Type

Purpose: This section specifies the verification requirements for different types of claims within an event. Grounded in cross-sector verification standards from intelligence (ICD 203/206, UK PHIA), wire services (Reuters, AFP), fact-checking (EFCSN), defence intelligence (Jane’s), academia (GRADE, Cochrane), and legal due diligence.

Terminology Note: This section uses “Tier A/B/C” for claim verification levels (indicating evidentiary rigour required). This is distinct from “Tier 1/2/3” used for event classification (Tier 1: Cross-Bloc Coordination; Tier 2: Between-Bloc Fragmentation; Tier 3: Intra-Bloc Coordination). Context makes the distinction clear: claim verification tiers appear only in Section 3.4; event classification tiers appear throughout the rest of the document. J-Tiers are always written with the “J-” prefix and appear only in §4.9.

Quick Reference — Tier Systems in This Manual:

3.4.1 Tier A Claims: Primary Sources Mandatory

Claim types requiring primary source verification:

• Event existence — Whether the project, policy, or agreement has been formally announced, signed, or enacted
• Implementation status — Whether infrastructure is operational vs planned/under construction
• AI connection evidence — Technical documentation demonstrating AI/ML purpose or capability
• Government/public investment amounts — Specific appropriated or committed figures
• Participant entities (official role) — Identity of governments, agencies, or companies that are named parties

Rationale: These claims carry the highest risk to database integrity. Errors propagate through all subsequent analysis. Cross-sector consensus (Reuters, AFP, ICD 203, EFCSN, Jane’s) requires primary sourcing for existential claims, quantitative data, and attribution of official roles.

Verification Standard:

Consequence if only lower-tier sources available: - Claim cannot be verified at Tier A confidence - Downgrade to Tier B with appropriate confidence language (“Reported” rather than “Confirmed”) - Or exclude from verified event database pending additional sourcing

3.4.2 Tier B Claims: Primary Preferred, Corroborating Acceptable

Claim types:

• Private investment amounts — Disclosed figures from corporate sources or credible estimates
• Technical specifications — Capacity, scale, architecture, performance metrics
• Event dates and timelines — Announced milestones, commissioning dates, phases
• Geographic scope — Locations, regional coverage, cross-border elements
• AI connection/purpose — Where technical documentation unavailable but multiple quality sources converge

Rationale: These claims are important for comprehensive event profiles but errors are less catastrophic than Tier A. Cross-sector practice (EFCSN, Jane’s, credit ratings) accepts quality secondary sourcing with appropriate attribution.

Verification Standard:

Handling Conflicts: If credible sources conflict on a Tier B claim: - Present both figures with clear attribution and range, OR - Default to most conservative estimate with uncertainty noted

3.4.3 Tier C Claims: Quality Corroborating Sources Acceptable

Claim types:

• Contextual background — Industry trends, historical context, geopolitical environment
• Analyst assessments — Expert opinions, strategic interpretations, risk evaluations
• Market positioning — Competitive landscape, alignment with national strategies
• Secondary metrics — Estimated figures, derived calculations, indirect indicators
• Operational metrics beyond threshold — Performance data not critical to event verification

Rationale: These claims provide context and analytical value but are inherently interpretive or estimated. Academic practice (GRADE Level 4-5) and journalism standards accept secondary sources for background material.

Verification Standard:

Quality Threshold: Sources must meet at least two of: - Established institutional reputation (Brookings, Chatham House, RAND, Jane’s, CSIS, etc.) - Published methodology or editorial standards - Track record of accuracy in domain - Clear attribution of their own sources

3.4.4 Source Definitions

Primary Source: A source with direct, first-hand knowledge or formal documentary authority over the claim in question.

Examples for WEO: - Official government announcements, legislation, budget documents, gazette publications - Corporate SEC/equivalent filings, annual reports, official press releases - Signed agreements, treaties, memoranda of understanding - Technical white papers from implementing entities - Regulatory filings, permit applications, environmental impact assessments - Satellite imagery or sensor data from verified providers

Grounding: Reuters defines first-hand witnesses as “recognised first-hand source”; ICD 206 mandates “most original applicable source”; EFCSN requires “best available primary sources.”

Secondary Source: A reputable outlet that reports, synthesises, or comments on information originating from primary sources not directly accessed by WEO.

Examples: - Major wire services (Reuters, AFP, Bloomberg, AP) - Quality newspapers of record (FT, NYT, WSJ, established regional papers) - Specialist trade publications with editorial standards - Think-tank reports citing primary material

Grounding: AFP notes “when we do not have an AFP journalist present or a direct source we can use secondary sources, in which case thorough verification of the veracity of the information is required.”

Corroborating Source: An independent source (primary or secondary) that confirms or supports information from another source.

Critical requirement: True independence—sources must be institutionally independent. Two articles citing the same press release do not constitute independent corroboration.

Grounding: This principle is consistent with cross-sector verification standards (ICD 203, Reuters, EFCSN) requiring independent sourcing chains.

Official Source: A primary or secondary source speaking with formal institutional authority.

Examples: Government ministry spokespersons, agency heads, corporate executives, regulators, official press offices.

Authoritative Source: A source recognised for subject-matter expertise, methodological rigour, and track record of accuracy.

Examples: Academic experts with publication records, established think-tanks (RAND, Chatham House, Brookings, CSIS), professional standard-setting bodies, peer-reviewed technical journals.

Grounding: ICD 206 “source descriptors” assess “accuracy, completeness, potential bias, motivation, and expertise.”

3.4.5 Confidence Language

Usage Rules: - Never mix confidence terms within same claim without explanation - Always pair confidence term with source attribution where practical - Flag single-source claims explicitly in database and outputs

3.4.6 Handling Source Conflicts

Protocol when credible sources provide conflicting information:

For quantitative claims (amounts, dates, specifications): - Present range with attribution: “Investment reported as $X billion (Source A) to $Y billion (Source B)” - If resolution required, prefer: official source > quality secondary > estimate - Document conflict and resolution rationale in verification notes

For qualitative claims (status, purpose, scope): - Present both positions with attribution - Do not synthesise into artificial consensus - Flag as “contested” if sources are comparably authoritative

Escalation triggers: - Conflicts between official sources from same entity - Primary source contradicted by multiple quality secondary sources - Material discrepancies affecting event classification

Documentation requirement: - All conflicts and resolutions recorded in verification notes - Accessible for audit and review

Grounding: ICD 203 mandates “incorporation of analysis of alternative hypotheses, especially when dealing with uncertainty or complexity.”

3.4.7 Audit Trail Requirements by Tier

Format for Verification Notes:

Claim: [Specific claim being verified]
Tier: [A/B/C]
Sources:
  - [Source 1]: [Type: Primary/Secondary/Corroborating] [URL] [Access date]
  - [Source 2]: [Type] [URL] [Access date]
Conflicts: [None / Description]
Resolution: [If applicable]
Confidence: [Term from Section 3.4.5]
Verified by: [Identifier]
Verification date: [Date]
Notes: [Any additional context]

Grounding: ICD 206 mandates detailed Source Reference Citations including “originator/author, source identifier, document title, date of issuance, page number”; EFCSN requires evidence “accessible for reader replication.”

3.4.8 Currency Windows

Evidence older than the specified currency window should be flagged for refresh or excluded from Tier A/B verification.

Note: Currency windows govern source publication dates. For event implementation date requirements, see Section 3.9 (6-Month Verification Lag Standard). Both requirements must be satisfied.

Exception for Stable Events:

Currency windows apply to verification of current operational status. For events with documented stable, unchanging status, sources older than the currency window may be used if accompanied by:

1. Analyst note confirming no change indicators were found in recent searches
2. Documented attempt to locate current sources (search terms, dates, null results)
3. Explicit flag in verification notes: “Status unchanged since [original source date]; no current sources available”

This exception does not apply to financial data, which must always meet the ≤12 month currency requirement.

For conflict-era adjustments to these windows, see §3.4.12.

3.4.9 Application to WEO Event Claims

For events verified through accommodated sources, see §3.4.11 for confidence assessment guidance.

3.4.10 Precedent Citations

This framework is grounded in established verification methodologies:

• Intelligence Community: ICD 203 (Analytic Standards), ICD 206 (Mandatory Sourcing), UK PHIA probability/confidence framework
• Wire Services: Reuters Handbook of Journalism, AFP Twenty Principles of Sourcing
• Fact-Checking: EFCSN European Code of Standards for Independent Fact-Checking, IFCN Code of Principles
• Defence Intelligence: Jane’s Defence verification standards (“3 secondary if no primary available”)
• Academia: Cochrane Handbook, GRADE methodology, OCEBM Levels of Evidence
• Legal: Court admissibility standards, legal due diligence requirements
• OSINT: Guidelines for Public Interest OSINT Investigations (ObSINT 2023)

3.4.11 Verification Assessment for Accommodated Sources

Four source accommodation pathways (§4.11 Structural Visibility Asymmetry — two accommodation types, §3.5 Option D OEP, §3.5.1 PIET) expand the primary source definition for specific event classes. This subsection provides the authoritative confidence assessment guidance for Tier A claims verified through accommodated sources.

Standard primary sources (no accommodation): Assessed under the standard confidence language framework (§3.4.5) with no additional constraint.

§4.11-accommodated sources — state media (sole basis): Where no independent standard-qualifying primary source separately verifies the same Tier A claim, the confidence term ceiling is “Officially reported” (§3.4.5). Where independent standard primary sources also verify the Tier A claims, the accommodation does not constrain the assessment.

§4.11-accommodated sources — convergent implementation evidence (sole basis): Where no independent standard-qualifying primary source separately verifies the same Tier A claim, the confidence term ceiling is “Officially reported” (§3.4.5). Convergent implementation evidence draws on multiple independent source categories (§4.11), but the absence of a published instrument means verifiable event scope and implementation detail are established solely by what the convergent sources report. Where independent standard primary sources also verify the Tier A claims, the accommodation does not constrain the assessment.

OEP-accommodated sources (sole basis): Events verified exclusively through OEP pathway evidence reflect a single underlying physical evidence base. The confidence term ceiling is “Officially reported” (§3.4.5). Where supplemented by independent standard primary or corroborating sources, the standard assessment applies.

PIET-accommodated sources: PIET gate evidence draws on multiple independent evidence streams across distinct empirical domains. The assessment is determined by gate pass count and evidence quality under the standard confidence framework — no ceiling applies. A 3-of-4 gate pass with primary source evidence across three independent domains provides convergent verification not structurally weaker than standard §3.1 multi-source confirmation.

3.4.12 Conflict-Era Source Currency Adjustment

The currency windows in §3.4.8 are calibrated for peacetime documentation cycles. Armed conflict bifurcates documentation production: emergency instruments (sanctions, executive orders, martial law decrees) accelerate to revision cycles of weeks rather than years, whilst routine regulatory output decelerates or halts entirely. Infrastructure verification may become physically impossible in conflict-affected territories. The following provisions adjust currency ceilings during formally defined conflict-era conditions.

Conflict-Era Determination

A conflict-era determination is active when all three of the following criteria are met:

1. External conflict classification. The Uppsala Conflict Data Program (UCDP) classifies an active armed conflict at its highest intensity level (war), and at least one state party to the conflict is a nation within WEO’s classification scope (Western Bloc, Eastern Bloc, or Non-Aligned per §3.10).

2. Documented disruption to the documentation landscape. The conflict materially disrupts at least one of:

   1. Trade flow through a chokepoint handling ≥10% of global volume in any commodity class tracked by WEO-relevant events

   2. Regulatory publication infrastructure of a participating state

   3. International standards body or trade agreement proceedings involving participating states

   Sub-criterion (a) provides the quantified disruption pathway. Sub-criteria (b) and (c) are qualitative assessments — the disruption must be demonstrable through specific documented evidence under criterion 3, not inferred from the existence of the conflict itself.

3. Documented evidence and periodic review. The determination is recorded with specific evidence for each criterion satisfied. Active determinations are reviewed at six-month intervals. A determination lapses when the underlying criteria are no longer met.

A conflict-era determination is territory-scoped: it adjusts currency windows for source documentation produced within or about the conflict-affected territory, not for the database as a whole. Events drawing on sources from unaffected jurisdictions continue to be assessed against the standard §3.4.8 windows.

Adjusted Currency Ceilings

When a conflict-era determination is active, the following adjusted currency ceilings replace the corresponding §3.4.8 windows for events whose source documentation is produced within or about the conflict-affected territory. The §3.4.8 “Policy/regulatory status” category is split into emergency and routine instruments to reflect the documented bifurcation in production cycles:

These are ceilings (maximum permissible source age), not floors. A more recently published source is always valid regardless of whether a conflict-era determination is active. Shortening the ceiling for emergency instruments means the methodology treats older sources as potentially stale because rapid revision cycles increase the likelihood of supersession. Extending the ceiling for routine instruments means the methodology tolerates older sources because production halts do not invalidate the governing instrument — the absence of a replacement is evidence of continuity, not obsolescence.

What is not affected: Coordination Connection temporal windows (§9.4.1) are not adjusted during conflict-era conditions. CC temporal windows govern coordination timing between events, not documentation freshness. Conflict conditions may accelerate coordination activity, but the windows measure the temporal relationship between events, which is independent of source currency.

Scope: Where an event draws on sources from both conflict-affected and unaffected jurisdictions, each source is assessed against the applicable window for its origin.

The stable event exception (§3.4.8) remains available during conflict-era conditions, subject to the same requirements: analyst note, documented search attempt, and explicit flag in verification notes.

For empirical derivation: See Methodology Rationale, Section 3.10.1.

3.5 AI Connection Filter (Scope Determination)

All events must demonstrate substantive AI infrastructure connection before proceeding to geopolitical significance assessment. This filter determines whether an event belongs within WEO’s scope.

Stage 1: AI Infrastructure Domain Relevance

Does the event relate to AI infrastructure in at least one domain?

Qualifying Domains:

• Technology & Infrastructure (compute, chips, data centres, algorithms)
• Security & Defence (AI military applications, cyber capabilities)
• Trade & Investment (AI company deals, technology transfer, export controls)
• Energy (AI for energy management, grid optimisation)
• Policy & Governance (AI regulation, standards, governance frameworks)
• Research & Development (AI research programmes, academic initiatives)
• Other AI Infrastructure Relevance (requires documented justification linking event to AI infrastructure deployment, capability, or governance)

Assessment: If event touches ANY domain above → Proceed to Stage 2

If NO domain connection → EXCLUDE (not AI infrastructure)

Stage 2: Substantive AI Connection

Event must demonstrate ONE of the following:

Option A: Measurable AI-Specific Allocation (≥10% Threshold OR ≥$100M Absolute)

• ≥10% of documented budget explicitly designated for AI purposes, OR
• ≥10% of infrastructure capacity explicitly designated for AI workloads, OR
• ≥$100M absolute AI-designated allocation regardless of percentage

Absolute Threshold Rationale: Large-scale infrastructure projects may have significant AI components ($400M+) that fall below 10% due to parent project size. The $100M absolute threshold ensures material AI infrastructure is captured regardless of percentage calculation.

Clarification: If both metrics (budget and capacity) are documented, the event qualifies if EITHER metric meets the 10% threshold. Both metrics do not need to satisfy the threshold simultaneously.

Precedent: SEC ASC 280-10-50-12 (segment reporting materiality), Basel III (large exposure definition thresholds)

Evidence Required:

• Official budget documents showing AI-designated allocation
• Technical specifications showing AI-designated capacity
• SEC filings, government appropriations, corporate disclosures

Documentation Requirement:

Option A requires documentary evidence of AI designation, not merely corporate claims. Acceptable documentation includes:

• Official filings, permits, or regulatory submissions mentioning AI allocation
• Technical specifications designating AI workload capacity
• Procurement records specifying AI-related equipment
• Government announcements with AI allocation figures

If documentary evidence is unavailable:

Corporate presentations, press releases, or marketing materials claiming AI allocation do NOT satisfy Option A without supporting documentation. In such cases:

1. Attempt to verify through Options B or C instead
2. If Options B and C also fail, proceed to Assessment Logic below for event-type-specific routing (Option D, Option E, Option F, Option G, or PIET where applicable)
3. Document the unverifiable claim in verification notes for potential future re-verification if documentation emerges

Examples:

• ✓ “$500M data centre with 60% capacity for AI training workloads” (60% > 10%)
• ✓ “€2B semiconductor programme with €300M designated for AI chips” (15% > 10%)
• ✓ “$5B semiconductor fab with $400M AI chip production line” (8% < 10%, but $400M > $100M absolute)
• ✗ “$1B general-purpose data centre with no AI-specific designation” (fails threshold)
• ✗ “$500M data centre with $30M AI workloads” (6% < 10% AND $30M < $100M absolute)

Option B: Dedicated AI Provisions (≥1 Section/Chapter)

• ≥1 titled section or chapter explicitly about AI in official documents

Precedent: ISO/IEC standards structure (Annex/Section designation), US Congressional bill structure (Title/Section organisation), UK legislative drafting conventions

Evidence Required:

• Treaty/agreement/regulation with titled AI section
• Standards document with AI-specific chapter
• Policy framework with dedicated AI provisions

Examples:

• ✓ “Treaty Article 7: Artificial Intelligence Cooperation” (dedicated section)
• ✓ “Regulation Chapter 3: AI System Requirements” (titled chapter)
• ✗ “Digital Services Act mentioning AI in passing” (no dedicated section)

Option C: AI-Explicit Mandate

• Charter, agreement, or scope explicitly states AI as primary purpose

Evidence Required:

• Official founding documents stating AI focus
• Organisational mandate explicitly naming AI
• Programme scope statements designating AI objectives

Examples:

• ✓ “International AI Safety Institute - Charter: Advance AI safety research”
• ✓ “National AI Strategy 2025 - Scope: AI capability development”
• ✗ “Digital Innovation Fund supporting various technologies including AI” (not AI-explicit)

Option D: Operational Evidence Protocol (OEP) — Infrastructure Events

Applies to Infrastructure events where official primary documentation is absent, generic, or application-agnostic, and Stage 2 Options A, B, and C have all failed. OEP is not available to Policy, Coordination, or Corporate events.

Note: Unlike PIET (§3.5.1), OEP does not require a fixed post-implementation waiting period. Assessment is conducted when sufficient operational evidence is available.

Pathway A — Technical Output Analysis

Establishes that the facility produces AI-specific chip architectures confirmed by independent technical characterisation.

Evidence Required: Semiconductor reverse engineering or chip decapsulation reports from independent technical laboratories confirming AI-specific chip architecture — Neural Processing Unit (NPU), AI accelerator, or equivalent compute silicon attributable to the facility under assessment. AI-specific chip architecture is assessed by reference to export control authority technical parameters for advanced computing integrated circuits.

Confidence: STRONG

Note: Where coverage limitations arise from regulatory or geopolitical constraints on laboratory access to chips from specific jurisdictions, Pathway A capacity for affected facilities may be impaired. Pathways B or C should be assessed as alternatives.

Pathway B — Product-Type Designation

Establishes that the facility produces a product category officially designated as AI-enabling by a recognised export control authority.

Evidence Required: 1. Official designation of the product type as AI-enabling by a recognised export control or regulatory authority (US Bureau of Industry and Security Federal Register rulemaking or equivalent) 2. Confirmation that the facility produces that product type (from technical sources or official business filings)

Confidence: PROBABLE

Jurisdictional limitation: AI-enabling product designation logic is not corroborated by EU, METI, or Wassenaar frameworks, which use technical list controls without explicit AI rationale. Pathway B is US-regulatory dependent.

Regulatory currency check required: BIS product-type designations can be modified or rescinded. Confirm the designation is currently in force before citing as Pathway B evidence.

Component manufacturing. Pathway B extends to component manufacturing events where the manufactured component holds an AI-specific export control classification — a classification whose regulatory text explicitly identifies the component’s function in advanced computing or AI systems (the ECCN 3A090.c paradigm). Two conditions constrain this extension: (1) the component must hold such a classification, which serves as the evidence gate — WEO references the designation and does not independently assess or replicate it; and (2) the component must have no significant general-purpose market, ensuring the extension admits only components whose commercial existence is AI-dependent. High Bandwidth Memory (HBM) qualifies: classified under ECCN 3A090.c with an explicit advanced-computing basis, manufactured for AI accelerator integration, with no significant commodity market. DRAM, NAND flash, substrates, and general-purpose semiconductor equipment do not qualify: these serve broad commercial markets regardless of their incidental use in AI infrastructure.

Pathway C — Hardware Deployment Evidence

Establishes that the facility contains AI-specific hardware at material scale via official procurement or operational records.

Evidence Required: ≥10% of deployed compute infrastructure confirmed as AI-specific hardware. This threshold is provisional; see Methodology Rationale §3.8.3 for the validation commitment.

Source standard: Government procurement notices, official intelligent computing centre classification records, official business disclosures meeting primary source standard per §3.4.4.

Hardware Classification Indicators

The following indicators identify rack density and hardware configurations that substantially exceed general-purpose compute norms and are characteristic of AI workload deployment in the current technology landscape. They are calibration illustrations grounded in engineering consensus — not formal classification standards from any standards body.

Rack density: - ≥30 kW per rack: substantially above general-purpose compute norms; consistent with GPU-intensive or HPC workloads - ≥60 kW per rack: characteristic of AI training rack configurations in the current technology generation - Liquid cooling deployment: supporting indicator; not a standalone qualifier

Hardware configuration:

• GPU-to-CPU ratio ≥4:1 in procurement specification: characteristic of current AI compute configurations
• ≥8 GPU units per server in procurement specification: characteristic of AI server architecture

Hardware generation review note: These indicators are calibrated to current-generation GPU hardware. Review is triggered by any major GPU platform transition that materially changes rack density or GPU-to-CPU ratio norms across the deployed AI infrastructure base.

Chinese Infrastructure Classification

The MIIT Computing Infrastructure High-Quality Development Action Plan (工信部联通信〔2023〕180号, October 2023, jointly issued by MIIT, CAC, MOE, NHC, PBOC, and SASAC) establishes an official tripartite framework for Chinese computing infrastructure:

• 通用算力 (tōngyòng suànlì) — general computing: CPU-based
• 智能算力 (zhìnéng suànlì) — intelligent computing: GPU/FPGA/ASIC-based AI workloads — AI-specific for OEP purposes
• 超算算力 (chāosuàn suànlì) — supercomputing/HPC

OEP operative distinction: Official designation as 智算中心 (intelligent computing centre) or 智能算力 in procurement documentation establishes AI connection for Pathway C.

Confidence outputs: - STRONG: hardware deployment confirmed in procurement records naming AI-specific hardware models, or official 智算中心 designation - PROBABLE: deployment indicated by rack density or cooling indicators without named hardware confirmation

Pass Logic

Required: Any one pathway confirmed at primary source standard.

OEP establishes a binary fact — does this facility serve AI workloads? One confirmed pathway from independent technical characterisation, regulatory designation, or direct hardware deployment evidence is sufficient to answer affirmatively.

Confidence gradation:

Combination rules: - Multiple pathways of the same confidence level yield that same confidence level - Multiple pathways with at least one STRONG yield STRONG overall - Two PROBABLE pathways do not aggregate to STRONG

Pipeline Exit

On OEP pass: Stage 2 AI Connection status — ESTABLISHED (Operationally-Verified). Event proceeds to Chapter 4 as standard. OEP pathway evidence that meets primary source standard simultaneously satisfies §3.1 event verification requirements — the same evidence that establishes AI connection inherently verifies event existence. See §3.4.11 for confidence assessment guidance.

Schema note: OEP assessments are recorded in the event’s oep object (assessmentDate, pathwaysConfirmed, pathwaysRequired, confidence, result, pathways).

For empirical derivation: See Methodology Rationale, Section 3.8.

Option E: Corporate Strategic Disclosure (Corporate events only)

For Corporate events where the operative instrument (power purchase agreement, equity investment agreement, procurement contract, or equivalent commercial instrument) does not contain AI-specific language — meaning Options A, B, and C cannot be satisfied from the instrument’s operative text — the AI Connection Filter is satisfied if an official corporate communication characterises the transaction as serving AI infrastructure purposes in terms that would satisfy the AI Connection Filter (Options A, B, or C) if the same language appeared in the instrument’s operative text, and meets all three requirements below.

Three requirements:

• Transaction specificity: Names the specific transaction, facility, agreement, or counterparty. General corporate strategy statements that do not identify a specific transaction are insufficient
• Contemporaneity: Published within the same or immediately following reporting period as the transaction. Not retrospective recharacterisation years later.
• Senior authorisation: Appears in a document authorised by senior management — not analyst commentary, marketing materials, or unofficial communications.

Qualifying communication types:

Official corporate communications satisfying the three requirements include:

• Regulated financial disclosures: SEC filings (10-K, 10-Q, 8-K, proxy statement); UK Companies Act annual report or FCA-regulated disclosure; EU Transparency Directive periodic report or Prospectus Regulation filing; CSRC-regulated filing (SSE/SZSE); EDINET filing or TSE-regulated disclosure (Japan); SEBI-regulated filing (India); or equivalent regulated financial disclosure filed with the jurisdiction’s securities regulator or financial supervisory authority
• Official press releases issued by the implementing entity
• Official partner or customer announcements issued by a named counterparty
• Published annual reports, including audited voluntary reports from entities with no regulatory filing obligation
• Official product launch documentation
• Conference presentations by senior management at industry or investor events

Social media posts, analyst commentary, marketing materials, leaked documents, and unnamed-source media reports attributing corporate intent do not qualify.

Confidence tier:

Option E confidence tiers classify the qualification evidence for the AI Connection Filter; they are distinct from the claim-level confidence language of §3.4.5. Events qualifying through Option E are assigned a confidence tier:

• Confirmed — The qualifying communication is a regulated financial disclosure (from the jurisdiction list above) explicitly linking the transaction to AI infrastructure; OR the qualifying communication meets the three requirements AND at least one corroborating signal is present:
  • 1. The counterparty or implementing entity has documented AI compute operations in the geographic service area of the facility or transaction
  • 2. The implementing entity’s investor communications (earnings call transcript, regulated investor presentation) explicitly frame the transaction as part of an AI infrastructure strategy
  • 3. A corroborating source from a qualifying category (wire service, quality newspaper, think tank per §3.1) independently characterises the transaction as AI-infrastructure-motivated
• Likely — The qualifying communication meets the three requirements without independent corroboration

Events not meeting the Likely threshold do not qualify through Option E.

Status designation:

Events qualifying through Option E carry a status designation:

• Operational — The transaction, facility, or deployment is documented as functional
• Announced — The facility, deployment, or infrastructure referenced by the transaction is documented as committed or under construction but not yet operational

Schema note: The confidence tier and status designation are recorded in the event’s qualification object as confidenceTier (values: confirmed, likely) and status (values: operational, announced).

Scope limitation: Option E is not available to Policy, Infrastructure, or Coordination events. Infrastructure events should use OEP (Option D). Policy restriction events should use PIET (§3.5.1).

Asymmetry safeguard: Option E is an additional qualifying pathway. The absence of AI-specific language in an entity’s corporate communications does not independently disqualify an event that satisfies Options A, B, or C through other evidence.

On Option E pass: Stage 2 AI Connection status — ESTABLISHED (Disclosure-Verified, [Confidence Tier], [Status]). Event proceeds to Chapter 4 as standard.

For empirical derivation: See Methodology Rationale, Section 3.6.2.

Option F: Defence Appropriation Evidence (Policy events only)

For Policy events where Options A, B, and C all fail, the AI Connection Filter is satisfied if the event is evidenced by a published defence appropriation document meeting both conditions below.

Eligible document types:

Option F accepts three categories of defence financial document, provided each carries binding appropriation authority — that is, the document commits public funds to specific programmes, rather than stating policy intent or authorising future appropriation:

Excluded document types: Authorisation legislation that establishes policy direction without appropriating funds (e.g., NDAA policy provisions without dollar-valued programme lines); white papers; strategy documents; policy proposals; ministerial press releases; parliamentary debate transcripts; non-binding budget forecasts.

Pass criteria — both conditions required:

1. AI designation is explicit in the document. The document names artificial intelligence, machine learning, or a specific AI capability (e.g., “autonomous systems,” “AI-enabled targeting”) in a programme title, budget line name, appropriation section heading, or call topic title. The AI designation must appear in the financial instrument itself — not inferred from the programme’s broader scope, not established by cross-reference to a separate strategy document, and not dependent on contextual knowledge of what a programme does.

2. The AI-designated commitment is financially quantified. The document states a monetary value associated with the AI-designated programme, line item, or funding pool. This includes:

   • Dedicated AI budget lines where the stated value funds AI exclusively (e.g., a named AI programme element with its own allocation)
   • Ring-fenced capability pools where the stated value funds AI alongside explicitly named companion capabilities (e.g., “Cyber, Digital, and AI Capabilities: £1B”), provided AI is explicitly listed as a legally mandated beneficiary of the pool

   The monetary value need not be financially isolated to AI alone, but the document must make clear that AI is a designated recipient — not merely a possible application within an undifferentiated general fund.

What Option F does not require:

• Financial disaggregation of AI spending from companion capabilities within a shared pool. Where a document commits funds to “Cyber, Digital, and AI,” the AI share need not be separately stated.
• Post-implementation operational verification. Option F qualifies on the basis of enacted financial commitment. Downstream operational detail may be behind classification barriers — this is the structural condition that Option F addresses.
• Minimum monetary threshold. No Basel-style floor applies. The qualifying criterion is the existence of an explicit, quantified AI commitment in a binding appropriation document, not its scale. Scale is assessed separately during the Geopolitical Significance Assessment (Chapter 4).

Scope limitation: Option F is not available to Infrastructure, Coordination, or Corporate events. Infrastructure events should use OEP (Option D). Corporate events should use Option E (Corporate Strategic Disclosure). The defence appropriation document requirement inherently limits Option F’s applicability to events funded through defence budgets.

On Option F pass: Stage 2 AI Connection status — ESTABLISHED (Appropriation-Verified). Event proceeds to Chapter 4 as standard.

For empirical derivation: See Methodology Rationale, Section 3.6.3.

Option G: Supply-Chain Response Evidence (Policy events only)

For Policy events where Options A, B, and C all fail, the AI Connection Filter is satisfied if both conditions below are met:

Condition 1 — Documented AI Infrastructure Input. The instrument controls, secures, subsidises, or stockpiles a material that is a documented input to AI infrastructure manufacturing or operation. The material must appear on the WEO AI-Critical Materials Register (maintained as a separate versioned reference document) or satisfy both sub-conditions:

• 1. The material is used in the manufacture of semiconductors, AI accelerators, data centre hardware, energy storage for data centre operations, or permanent magnets used in data centre mechanical systems (HDD actuators, cooling motors, power conversion); AND
• 2. The causal chain from the controlled material to the AI infrastructure application is documented at primary source standard — meaning the material’s role in AI infrastructure manufacturing or operation is established through industry technical documentation, materials science publications, supply-chain analysis from recognised institutions (USGS, BGS, EU JRC, CSET), or manufacturer specifications, not through analyst inference alone.

Condition 2 — Instrument Text Absence. Options A, B, and C have all failed because the instrument’s operative text addresses the material, not AI — with a written determination and source-cited rationale recorded for each failure. This confirms that Option G is the appropriate pathway rather than a shortcut bypassing stricter options.

What Option G does not require:

• AI-specific language in the instrument’s title, definitions, or operative provisions. Option G exists precisely because supply-chain response instruments address the material, not the downstream application.
• Post-implementation waiting period. Unlike PIET, Option G does not require a 12–18 month post-implementation evidence window. The AI infrastructure relevance of the controlled material is established through the material’s documented role in AI infrastructure manufacturing (Condition 1), not through post-implementation impact evidence.

Scope limitation: Option G is not available to Infrastructure, Coordination, or Corporate events. Infrastructure events should use OEP (Option D). Corporate events should use Option E. Coordination events must satisfy the AI Connection Filter through Options A, B, or C.

Option G does not cover general industrial policy, broad economic stimulus, or multi-sector technology frameworks that incidentally include AI-relevant materials among many other provisions. The instrument must be specifically directed at the controlled material (mining, processing, stockpiling, subsidy, trade response, or supply-chain security of that material). Where the instrument is a general-purpose economic package with a minerals component, only the minerals-specific provisions qualify — assessed per the same specificity standard applied in Option A’s ≥10% threshold logic.

On Option G pass: Stage 2 AI Connection status — ESTABLISHED (Supply-Chain-Verified). Event proceeds to Chapter 4 as standard. Events qualifying through Option G route to Part C (PISA-5) for significance assessment, with F3 satisfied by the pathway exemption (§4.9, Factor 3 — Pathway exemption).

For empirical derivation: See Methodology Rationale, Section 3.6.4.

Assessment Logic

• Event must pass Stage 1 (domain relevance) AND Stage 2 (substantive connection)
• Stage 2 requires only ONE option (A, B, C, D, E, F, or G) — not cumulative
• Infrastructure events failing Options A, B, and C → proceed to Option D (OEP) within this section
• Policy restriction events on physical AI-critical materials or physical technology products failing Options A, B, and C → proceed to §3.5.1 (PIET)
• Corporate events failing Options A, B, and C → proceed to Option E (Corporate Strategic Disclosure) within this section
• Policy events failing Options A, B, and C where a qualifying defence appropriation document exists → proceed to Option F (Defence Appropriation Evidence) within this section
• Policy events failing Options A, B, and C where the instrument controls, secures, or subsidises a documented AI infrastructure input material → proceed to Option G (Supply-Chain Response Evidence) within this section
• All other events failing all applicable options → EXCLUDE from database

Partial Compliance: Events that partially meet multiple options but fully meet none are EXCLUDED. Thresholds are minimum requirements, not targets for approximation. For example, an event with 8% AI budget allocation (fails Option A’s 10% threshold), AI mentioned in passing but not in a titled section (fails Option B), and AI as one purpose amongst many but not primary (fails Option C) does NOT qualify. Apply conservative interpretation: when uncertain, exclude rather than include.

Rationale: This filter ensures the methodology captures genuine AI infrastructure events, not tangentially AI-related activities. The 10% threshold and ≥1 section requirement have strong empirical precedent from financial reporting, legislative drafting, and international standards practice.

For empirical derivation: See Methodology Rationale, Section 3.6 (Options A–C, Option E, Option F, Option G); Section 3.8 (Option D).

AI-Critical Materials Register: The current register is maintained as a separate versioned document (WEO AI-Critical Materials Register, V1, May 2026). The register defines materials that qualify under Condition 1 without requiring individual causal-chain documentation. Materials not on the register may still qualify through individual Condition 1(a)+(b) documentation. The register is reviewed at methodology version milestones.

3.5.1 PIET — Post-Implementation Evidence Track

Post-Implementation Evidence Track (PIET) addresses a precisely bounded gap in Stage 2 qualification: Policy restriction events controlling physical AI-critical materials or physical technology products where official primary documentation contains no AI-specific language — meaning Options A, B, and C cannot be satisfied from documentary sources alone — but where the AI connection is real and post-implementation empirical evidence can establish it at primary source standard. PIET activates only after all three Options have failed with documented rationale for each failure.

Eligible Event Class

PIET applies only where all four conditions hold:

1. Event type is Policy.
2. Event subtype is restriction — controlling or restricting cross-border flow of physical AI-critical materials or physical technology products.
3. The controlled items are physical AI-critical materials or physical technology products with HS-code-trackable trade flows in official customs databases.
4. Stage 2 Options A, B, and C have all failed due to absence of AI-specific language in primary official documentation — with a written determination and source-cited rationale recorded for each failure.

Note: Where a restriction covers both physical materials and technology transfer, PIET applies to the physical materials component only. Technology transfer is not HS-code-trackable via official customs databases.

Excluded events: Investment screening; data governance; security technology controls; researcher mobility restrictions.

Trigger and Pending Designation

Stage 2 Options A, B, C → all fail (document rationale with source citation for each)
         ↓
Is this event a Policy restriction on physical AI-critical materials or physical technology products
with HS-code-trackable trade flows?
         ↓
YES → Pending Designation: event held pending PIET assessment at 12-month+ mark
NO  → Exclude (standard disqualification)

On Pending Designation, the event is assigned status PENDING-PIET with implementation date recorded. Assessment is triggered at the 12-month post-implementation mark. The 18-month outer bound is available where gate evidence is insufficient at 12 months. Where evidence does not reach threshold by 18 months, the event is disqualified and recorded with gate scores.

Gate Specifications

PIET requires 3 of 4 gates to pass at primary source standard.

Gate 1 — Trade Flow Disruption

Measures quantitative disruption to cross-border trade flows of the controlled material via official customs data.

Pass criteria — either threshold: - >50% sustained decline in global export volumes, sustained for ≥3 months post-implementation - >90% sustained decline in export volumes to the other bloc, sustained for ≥3 months post-implementation

Evidence Required: - China General Administration of Customs — monthly HS-code level bilateral export data - US International Trade Commission DataWeb — monthly HS-code level import data - Eurostat COMEXT — EU official external trade database; HS-code level bilateral data - Japan Ministry of Finance Trade Statistics — monthly HS-code level data - UN Comtrade — cross-validation (note: reporting coverage reaches adequate levels approximately 12–18 months after the reference period; national sources preferred for time-sensitive assessment)

Note: Where the controlled material is not separately resolvable at the international 6-digit HS code level — because that code aggregates multiple unrelated materials — Tier A national sources must be queried at national extended code granularity (8+ digit). The applicable code level should be verified at time of assessment.

Suspended or reversed restrictions: Where a restriction is suspended or reversed before the 3-month threshold, Gate 1 cannot pass on that basis. Record in verification documentation.

Gate 2 — Commodity Price Movement

Measures sustained price movement in the controlled material’s commodity market.

Pass criteria: >20% price change, sustained for ≥3 months post-implementation.

Evidence Required: - Tier A (exchange-traded materials): London Metal Exchange; Shanghai Futures Exchange; COMEX - Tier B (non-exchange-traded minor metals): Argus Media; Fastmarkets; Shanghai Metals Market (SMM) - IOSCO Principles for Price Reporting Agencies (2012) — institutional quality anchor for Tier B sources

Gate 3 — Government Policy Response

Measures cross-bloc political salience through other-bloc government primary-source policy responses.

Pass criteria: ≥2 other-bloc government primary-source policy responses within 18 months of implementation.

Qualifying response types: executive orders, official strategy documents, legislative proposals with government sponsorship, regulatory actions, official gazette publications, budget appropriations, enacted legislation. Qualifying jurisdictions: any other-bloc government with accessible primary documentation.

Linkage standard: The response must be contemporaneously documented as responsive in official government sources. Analyst inference from timing alone does not qualify.

Note: Enacted standalone statutory legislation typically requires 24–60+ months from triggering event to enactment. Absence of enacted legislation within 18 months does not constitute Gate 3 failure and should not be recorded as evidence insufficiency. Where a legislative proposal with government sponsorship is documented as responsive within 18 months, this qualifies regardless of whether enactment is subsequently achieved within the window.

Gate 4 — Named Entity Commercial Disclosure

Measures corporate-level confirmation of cross-bloc supply chain impact via primary securities disclosure.

Pass criteria: ≥1 named entity primary corporate disclosure citing the specific restriction as an operational impact within 18 months of implementation.

Qualifying disclosure types: SEC Form 10-K, SEC Form 10-Q, equivalent EU/UK regulatory filings, official earnings call transcripts with attributed executive statements, or other primary corporate disclosures meeting Tier A source standard per §3.4.4. The disclosure must name the specific restriction instrument or controlling jurisdiction and material — not merely reference general supply chain risk.

Pass Logic

Required: 3 of 4 gates at primary source standard.

All four valid combinations are permissible:

• Gates 1 + 2 + 3
• Gates 1 + 2 + 4
• Gates 1 + 3 + 4
• Gates 2 + 3 + 4

Note: T2 Impact-Demonstrated classification at Chapter 5 requires Gate 3 specifically. Where Gate 3 is amongst the failing gates, T2 Impact-Demonstrated is unavailable via the PIET pathway; record this in verification notes.

For each failing gate, the analyst records which gate failed and the reason — evidence unavailable, evidence below threshold, or evidence standard not met.

Pipeline Exit

On PIET pass (3 of 4 gates): Stage 2 AI Connection status — ESTABLISHED (Impact-Verified). Event proceeds to Chapter 4 as standard.

Schema note: PIET assessments are recorded in the event’s piet object (implementationDate, assessmentDate, gatesPassed, gatesRequired, confidence, result, gates, with t2ImpactDemonstrated and t2Basis where the Gate 3 byproduct applies).

T2 Impact-Demonstrated byproduct: Where Gate 3 has been cleared (≥2 other-bloc government primary-source policy responses within 18 months), T2 Restriction classification is supported on an Impact-Demonstrated basis as a natural byproduct of PIET qualification. Gate 3 clearance alone is sufficient; Gate 4 evidence strengthens the basis but is not mandatory. See Section 5.5, T2 Restriction Test: Impact-Demonstrated Pathway.

Dual-purpose evidence: PIET gate evidence that meets primary source standard simultaneously satisfies §3.1 event verification requirements — confirming both the restriction’s AI supply chain impact (Stage 2) and the restriction’s existence and implementation (§3.1). See §3.4.11 for confidence assessment guidance.

For empirical derivation: See Methodology Rationale, Section 3.7.

3.6 Event Types

Context: All verified events are classified by event type during Phase 1 verification.

Four Event Types

1. Coordination - Multi-nation agreements, joint initiatives, standards cooperation
2. Infrastructure - Physical/digital systems deployment (compute, networks, facilities)
   
3. Policy - Regulations, laws, executive orders, governance frameworks
4. Corporate - Private-sector entity action (unilateral or coordinated): disclosures, partnerships, market structure events

Event Type Qualification and Tier Applicability

Event Type classification is mechanism-based — determined by HOW the action occurs, not its subject matter or effects.

Event Type Definitions

Event Type × Tier Applicability

Notes:

• T1 exclusion: Policy’s unilateral mechanism precludes T1 qualification. Policy events with cross-bloc effects may qualify as T2 (typically Restriction, rarely Buildout) or T3, not T1. Coordinated multilateral policy alignment (involving mutual accommodation between parties) qualifies as Coordination Event Type, not Policy.
• T2 environment: T2 captures fragmentation. Fragmentation Type (Buildout/Restriction) determines fragmentation classification — see Chapter 5: Tier Classification.
• Detailed Coordination criteria: See Section 3.7 (Verification Thresholds and Coordination Criteria) for Keohane framework, three qualifying coordination types, and implementation verification standards.

Event Type Classification Decision Tree

Decision Tree

STEP 1: Does this involve 2+ sovereign entities acting jointly 
        (agreements, treaties, MOUs, joint frameworks, standards bodies)?
├── YES → COORDINATION
└── NO  → Continue to Step 2

STEP 2: Is the primary actor a government/sovereign entity?
├── YES → Is the action DEPLOYMENT of physical/digital systems?
│         ├── YES → INFRASTRUCTURE
│         └── NO  → Is it regulation, law, executive order, or policy directive?
│                   ├── YES → POLICY
│                   └── NO  → Flag for review
└── NO  → Continue to Step 3

STEP 3: Is the primary actor a private sector entity?
├── YES → CORPORATE
└── NO  → Flag for manual review

Boundary Case Resolution

Empirical Basis

This framework draws on established precedent: CAMEO taxonomy (mechanism-based event coding), Abbott & Snidal legalization framework, Lowi’s policy typology, and emerging Digital Public Infrastructure literature. Infrastructure as a distinct category extends beyond existing taxonomies, supported by growing DPI scholarship distinguishing infrastructure materiality from infrastructure governance.

For detailed empirical derivation: See Methodology Rationale, Section 3.3: Event Type Classification Rationale.

Relationship to Tier Classification

Event type classification is distinct from tier classification: - Event Type determines how the action occurs (mechanism) - Tier determines the coordination scale

For Tier 2 events specifically: Additional “Fragmentation Type” classification (Buildout vs Restriction) further categorises the fragmentation mechanism.

Examples:

• Major Economy Semiconductor Manufacturing Incentive Programme → Event Type: Infrastructure, Fragmentation Type: Buildout
• US semiconductor export controls → Event Type: Policy, Fragmentation Type: Restriction
• EU AI Act → Event Type: Policy, Fragmentation Type: Restriction
• China domestic GPU production → Event Type: Infrastructure, Fragmentation Type: Buildout

Full classification methodology — including fragmentation type determination — documented in Chapter 5: Tier Classification.

3.7 Coordination Criteria and Verification Thresholds

To qualify as a verified event, the following criteria and thresholds apply:

Coordination Event Criteria

Definition: Coordination events occur when two or more sovereign entities (nations, blocs, international organisations) or established international standards organisations (ISO, IEC, IEEE, ITU) make observable policy adjustments through negotiation or mutual accommodation, where each entity’s actions facilitate achievement of partners’ objectives (Keohane 1984).

This distinguishes coordination from:

• Harmony: Automatic alignment without negotiation
• Parallel independent action: Similar policies developed separately
• Aspirational statements: Declarations without implementation mechanisms

Three Types of Qualifying Coordination:

Type 1: Explicit Coordination (Formal Agreements)

• Bilateral/multilateral treaties, MOUs, cooperation agreements
• Alliance frameworks (Five Eyes, AUKUS, Quad, SCO)
• Multilateral initiatives (G7, G20, BRICS AI programmes)

Evidence Required:

• Signed agreement, treaty text, or official communiqué
• Signatures/endorsements from 2+ sovereign entities
• Published on government/international organisation website
• Date of signing/adoption

Examples:

• AUKUS Advanced Capabilities Pillar
• US-UK AI Safety Partnership Agreement
• G7 Hiroshima AI Process Code of Conduct

Type 2: Institutional Coordination (Standards Bodies)

• International standards organisation consensus processes (ISO, IEC, IEEE, ITU)
• Published standards with multi-nation participation
• Consensus voting with 2+ nations represented

Evidence Required:

• Published standard with number/date (e.g., ISO/IEC 23894:2023)
• Documentation of consensus process (voting records, participating nations)
• List of participating nations/organisations in development

ISO/IEC Deliverable Type Eligibility: For ISO/IEC deliverables, only International Standards (IS) qualify under Type 2. Technical Specifications (TS) and Technical Reports (TR) do not qualify — TS deliverables lack full member body consensus (committee-level approval only) and TR deliverables are informative documents containing no normative requirements. This reflects ISO/IEC’s own formal taxonomy, where the word “standard” is reserved for IS deliverables. IEEE and ITU deliverable hierarchies should be assessed on equivalent grounds: the qualifying deliverable type is the one produced through full consensus ballot with normative force.

Qualifying Bodies:

• ISO (International Organisation for Standardisation): 169 member nations
• IEC (International Electrotechnical Commission): 89 member nations
• IEEE (Institute of Electrical and Electronics Engineers): Global consensus-based standards
• ITU (International Telecommunication Union): UN agency, 193 member states

Examples:

• ISO/IEC 23894:2023 AI Risk Management
• ISO/IEC 42001:2023 AI Management System
• IEEE P7000 Series AI Ethics Standards

Type 3: Demonstrated Convergence (Multi-Nation Adoption)

• Single-nation framework OR technical standard
• Approximately one-third of relevant states officially adopt, endorse, or incorporate in policy documents
• Adoption is governmental (not merely academic citation)

Threshold Rationale: The approximately one-third threshold derives from Finnemore & Sikkink (1998) norm cascade research. Their analysis identified a “critical mass of actors” creating a tipping point, empirically approximated at around one-third of states based on historical norm adoption patterns. WEO operationalises this at 33% (~50 nations) as a practical threshold, acknowledging this reflects an empirical approximation rather than a precise theoretical requirement.

“Relevant States” Definition: For AI infrastructure domain: ~150 nations publish AI policy, governance frameworks, or strategy documents. One-third ≈ 50 nations.

Evidence Required:

• Government white papers, regulations, or strategies explicitly adopting, endorsing, or incorporating the framework
• Approximately 50 nations (one-third threshold) with documented adoption
• Verification via official government websites (not media reports)

Examples:

• NIST AI Risk Management Framework (adopted by EU, UK, Japan, Singapore, Australia, Canada, etc.)
• OECD AI Principles (endorsed by 50+ nations)

Implementation Verification Standards:

All coordination events classified via six-level evidence hierarchy:

Type 2 Level 5 — Operational Evidence Requirement:

For standards body events qualifying under Type 2, Level 5 (Implemented) requires verified operational evidence beyond institutional publication and national catalogue adoption. Publication establishes that the consensus process produced a formal output (Level 4). Catalogue adoption by national standards bodies (listing the international standard within a national standards catalogue, e.g., BS ISO/IEC 42001) constitutes administrative incorporation without independent operational significance. Level 5 requires at least one of the following:

1. Active certification or conformity assessment activity against the standard, with at least one organisation assessed.

2. Formal reference by a national or supranational regulatory instrument as a compliance pathway or harmonised standard.

3. Normative dependency from other operationally implemented standards via Clause 2 normative references, provided at least one standard in the dependency chain independently satisfies pathway (a), (b), or (d). A normative dependency chain cannot be self-referencing; the chain must terminate in a standard satisfying pathway (a), (b), or (d).

4. Documented adoption by at least one organisation in its operational framework, verified through primary or corroborating sources.

Standards that do not satisfy any of the four pathways do not achieve Level 5 regardless of publication or catalogue adoption status.

Critical Rule:

• Binding agreements: Require Level 3 (ratified) minimum for qualification
• Non-binding frameworks: Require Level 5 (implemented) minimum for qualification
• Account for 3-10 year implementation lag (track adoption date and implementation date separately). This lag is informational context for long-term monitoring, not an entry barrier.

Precedent: Vienna Convention on the Law of Treaties (ratification procedures), OECD policy tracking standards, SIPRI arms control verification literature, UN Disarmament Commission implementation monitoring.

Exclusions — Examples of What Is NOT Coordination:

✗ Parallel independent action: Multiple nations develop AI strategies separately without cross-reference or joint mechanisms ✗ Unilateral policy with international effects: EU AI Act affects US companies but represents unilateral regulation by a single entity, not multi-nation coordination ✗ Corporate multinational operations: Microsoft operates in 30 countries (corporate activity, not sovereign coordination) ✗ Informal dialogue without commitment: US-China AI Safety Dialogue discussions without formal outcome document ✗ Academic/industry collaboration: University consortia without government endorsement or funding

Confidence Assessment:

• Type 1 (Formal agreements): HIGH - Keohane framework is gold-standard IR theory (40+ years consensus)
• Type 2 (Standards bodies): HIGH - ISO/IEC consensus processes well-documented
• Type 3 (Convergence): HIGH - One-third threshold empirically grounded in norm cascade research (Finnemore & Sikkink 1998)
• Implementation hierarchy: HIGH - Vienna Convention + OECD/SIPRI precedent

Precedent Citations:

• Keohane, R. O. (1984). After Hegemony: Cooperation and Discord in the World Political Economy. Princeton University Press.
• Finnemore, M., & Sikkink, K. (1998). “International Norm Dynamics and Political Change.” International Organization 52(4): 887-917.
• Vienna Convention on the Law of Treaties (1969), Articles 54-56 (treaty withdrawal procedures)
• OECD.AI Policy Observatory (coordination tracking standards)
• SIPRI Arms Control Database (verification methodologies)

Infrastructure Projects

• Minimum investment: $100M USD (institutional infrastructure investment threshold)
• Construction evidence: Permits, satellite imagery, vendor contracts
• Operational status: Completed and operational (not just groundbreaking)
• Capacity verification: Specific metrics (GPU count, petaflops, etc.)

See Chapter 4, Section 4.4 for full Basel 5-Factor qualification criteria.

Software/Platform Events

Software/platform events bypass the physical infrastructure threshold ($100M) due to different economic models. Entry filtering and significance assessment are combined in Chapter 4 Part B (Route-Based Assessment), which includes its own thresholds:

• Route 1: Official critical infrastructure designation
• Route 2: $100M+ auto-qualification OR $50M–$99M with Route 3 support
• Route 3: Dependency and adoption metrics (2+ criteria required)
• Route 4: AI model capability thresholds

See Chapter 4, Section 4.8 for full Route-Based qualification criteria.

Policy/Institutional Events

Single-jurisdiction policy and institutional events (national AI regulations, AI safety institutions, governance frameworks) have no capital threshold. Entry filtering and significance assessment are combined in Chapter 4 Part C (PISA-5 Assessment), which evaluates:

• Factor 1: Jurisdictional significance (G7/G20/AI hub status)
• Factor 2: Regulatory scope and binding authority
• Factor 3: AI centrality (mandatory gating factor)
• Factor 4: Implementation mechanism
• Factor 5: Potential for extraterritorial effect or international adoption

See Chapter 4, Section 4.9 for full PISA-5 qualification criteria.

Note on Threshold Relationships

Section 3.7 thresholds are entry criteria for event consideration. Events meeting these thresholds proceed to Geopolitical Significance Assessment (Qualification Criterion 4 / QC4). See Chapter 4: Geopolitical Significance Assessment for Basel 5-Factor, Software Routes, and PISA-5 qualification methodology.

Key relationships:

• Coordination events: Keohane criteria → Auto-qualify for geopolitical significance
• Physical infrastructure: $100M entry → Part A Basel 5-Factor assessment (2+ factors required; events $100M-$499M can qualify via non-Size factors)
• Software infrastructure: Bypass physical thresholds → Part B Route-Based Assessment
• Policy/institutional events: → Part C PISA-5 assessment (single-jurisdiction AI policy/governance)

3.8 Audit Trail Requirements

For every event in the WEO database:

Mandatory Documentation

1. Sources (Verification Evidence): - Sources meeting the §3.4.1 standard: 2+ independent Primary sources OR 1 Primary + 2 independent Corroborating sources (with full citations); ≥2 independent Grade 1 primaries satisfy the corroborating requirement per §3.1. Recorded in the event’s primarySources and corroboratingSources arrays (id, desc, url per entry) - Implementation evidence: Specific proof of deployment/operation - Source documentation: All URLs documented with access dates

2. Event Metadata: - Event ID: Sequential numeric identifier (zero-padded string), recorded as id; never reused - Discovery date: When event first identified - Implementation date: Actual operational/enactment date (verified, not announced) - Verification date: When verification completed - Geographic scope: Nations/regions involved - Participant list: Entities/organisations involved - Budget/scale metrics: Specific quantitative data - Tier classification: With justification — recorded as tier, with the justification as tierRationale - Event Type: Coordination/Infrastructure/Policy/Corporate — recorded as type - Fragmentation Type: (Tier 2 only) Buildout/Restriction - Bloc Classification: Cross-Bloc (Tier 1 only) or WB/EB (see Section 3.10 for NA-Bloc determination methodology) — recorded as bloc

3. Analysis & Verification: - Verification notes: Analyst explanation of sourcing decisions - Confidence level: High (90%+) / Medium (70-90%) / Low (<70%) - Version history: If event data updated based on new information — maintained as the event’s versionHistory (§3.15.7)

Interpretation for Platform Use:

• HIGH confidence events can be confidently cited in platform outputs and external communications.
• MEDIUM confidence events are defensible and suitable for database entry, and flagged for subsequent re-verification.
• LOW confidence events are excluded from the database entirely.

Quality Standards

Verification Requirements: - ✓ All sources documented with full citations and access dates - ✓ Verification trail enables independent replication (clear notes, complete metadata) - ✓ Uncertainties documented (assumptions, data gaps, edge cases) - ✓ Low-confidence events (<70%) excluded from database

Quality Assurance:

• Critical events (Tier 1) undergo delayed self-review after minimum 1 week
• Edge cases documented with clear rationale
• Methodology reviewed annually or when issues identified

3.9 Verification Window

6-Month Verification Lag Standard

Window Definition: - Start: 1st January 2022 - End: 6 months prior to date of analysis - Rolling window: Advances monthly as verification lag period progresses - Applies to: Event implementation dates (not source publication dates)

Implementation Date Definition:

“Implementation date” means the date an event becomes operational or enacted, NOT announcement, approval, or construction dates:

NOT Implementation Dates: Announcements, memoranda of understanding, groundbreaking ceremonies, permit approvals, construction milestones, proposed legislation.

Events are included when their implementation date falls within the verification window (Jan 2022 to 6 months prior to analysis date). Verified product releases enter under a 60-day reduced verification lag where the §3.9.2 conditions are satisfied.

Rationale for 6-Month Lag:

Purpose: Trades recency for verification quality

Benefits: - Implementation confirmation (not just announcements) - Evidence accumulation period - Third-party validation emergence - Source verification and accuracy validation - Source archiving stability

Trade-offs:

• Excludes events implemented within 6-month verification window
• Cannot track events requiring real-time data
• 6-month delay for new events entering the database (60 days for verified product releases under §3.9.2)

Why This Works:

Gold standard verification requires: 1. Implementation evidence (construction complete, law enacted, system operational) 2. Third-party confirmation (multiple independent sources) 3. Impact assessment (early operational results)

Announcements happen instantly. Implementation takes months. WEO measures reality, not promises.

Industry Standard Alignment:

The 6-month lag aligns with established verification practices: - Financial Infrastructure: Credit ratings require 90-180 days post-implementation; infrastructure bonds require 6-12 months operational history - Physical Infrastructure: Major construction projects verified 6-12 months after handover; data centres report with 3-6 month lag - Policy/Regulatory: Legislative databases use 30-90 days post-enactment; trade agreements use 6-12 months for impact assessment - Academic/Think Tank: OECD indicators use 6-12 month lag; World Bank infrastructure data uses 12-24 month lag

Positioning: The 6-month lag positions WEO between real-time dashboards (immediate, announcement-based) and annual reporting cycles (12-24 month lag, high quality but infrequent), prioritising verification quality over recency.

3.9.1 Clarification: Event Dates vs. Source Dates

Critical Distinction:

The 6-month verification lag applies to event implementation dates, NOT source publication dates. The event’s implementation date is the recorded date value.

Examples:

Rationale:

The lag exists to ensure events have had sufficient time for verified implementation — not to exclude recent reporting about established events. A source published today reporting on infrastructure completed 2 years ago is exactly what the methodology intends: current verification of established reality.

Interaction with Currency Windows (Section 3.4.8):

Both requirements must be satisfied:

1. Event implementation date: Within verification window (Jan 2022 to 6 months prior to analysis)
2. Source publication date: Within currency window for data type:
   • Infrastructure operational status: ≤24 months
   • Policy/regulatory status: ≤12 months
   • Financial data: ≤12 months
   • Technical specifications: ≤36 months

No Conflict: These requirements are complementary. The verification lag ensures events are mature enough to verify. The currency windows ensure evidence is recent enough to be relevant.

3.9.2 Reduced Verification Lag for Verified Product Releases

Corporate events documenting a product release enter the database under a reduced verification lag of 60 days where the four conditions below are satisfied. The 6-month standard remains the default for all other events; a product release failing any condition enters under the standard window. All other requirements of this chapter — source standards (§3.1), currency windows (§3.4.8) — and qualification under Chapter 4 apply unchanged.

Qualifying Conditions (all four required):

1. Event class. The event is a Corporate event qualified under Chapter 4 Part B (Route-Based Assessment) whose implementation is a product release — a model, platform, or equivalent software product.

2. Verified general availability. The product is generally available: publicly accessible within its declared availability footprint. The declared availability footprint is the set of markets and access channels in which the release documentation states the product is available. Limited previews, waitlists, and beta programmes do not qualify; where a limited release precedes general availability, the implementation date is the general availability date.

3. Continuous availability. The product has remained generally available throughout the 60-day period, measured against the declared availability footprint. Continuity is interrupted by a documented change in availability status in any declared market — withdrawal, suspension, or removal, whether developer-initiated or externally directed. The status change must be documented by the developer, a directing authority, or the product’s availability documentation; transient service interruptions without a documented status change do not interrupt continuity. Footprint expansions do not interrupt continuity. A scheduled end-of-availability announcement does not interrupt continuity where the product remains available throughout the period.

4. Maturity re-review. A maturity re-review record is established at initial database entry (§3.15.13), with an eligibility date of the implementation date + 180 days.

Entry Verification: Continuity under Condition 3 is confirmed at entry across the full 60-day period and documented with the sources used.

Interruption Effect: An interruption during the 60-day period forfeits the reduced lag only. The event enters under the standard §3.9 window, which runs from the implementation date as for any event; the implementation date does not reset, and the interruption episode forms part of the record verified at standard entry. Availability changes occurring after database entry are post-entry developments handled under Section 3.15 and verified at the §3.15.13 maturity re-review; they do not affect the entered record’s qualification. A status change occurring within the 60-day period but documented only after entry is handled as a post-entry discovery under Section 3.15 and assessed at the maturity re-review; the entry, made against documentation available at the time, is not retroactively altered. Rollbacks and capability restatements — changes to documented capabilities or performance claims that do not alter availability status — are not interruptions under Condition 3. A documented rollback or capability restatement is a mandatory examination point at the §3.15.13 maturity re-review.

Record Designation: Events entering under this provision carry the genesis designation verificationLag: REDUCED (§3.15.3); events entering under the standard window carry verificationLag: STANDARD.

Rationale for the Reduced Lag:

• Implementation confirmation at entry: General availability is directly observable in primary release documentation and public accessibility. The implementation-confirmation function of the verification lag is satisfied at entry rather than by elapsed time.
• Reversal absorption: A 2022–2026 census of Western and Chinese model releases records all observed integrity incidents — withdrawal, suspension, rollback, capability restatement, availability-affecting regulatory action — within 33 days of general availability. The 60-day period covers the observed range at 1.8× the latest incident.
• Separation from lifecycle retirement: Successor-driven retirements in the same census occupy an 89–177 day band. The 60-day period sits below this band; the continuity condition tests release integrity, not release cadence.
• Deferred functions carried by re-review: Evidence accumulation and third-party validation mature after entry. The §3.15.13 re-review at implementation date + 180 days verifies the record at the point it would have cleared the standard window.

See the Methodology Rationale §3.9.1 for the parameter derivation and validation commitments.

Industry Standard Alignment:

• Index inclusion: Default eligibility periods operate alongside conditioned early-entry pathways where the qualifying fact is directly observable — early inclusion of large IPOs at the tenth trading day (MSCI Global Investable Market Indexes Methodology, Sub-section 3.2.4.1) and fast entry implemented after the close of the fifth trading day (FTSE Global Equity Index Series Ground Rules, Rules 8.1.1–8.1.3).
• Credit ratings: Expected and provisional ratings are assigned ahead of final documentation and convert on verification (Fitch (EXP) suffix; Moody’s (P) designation).
• Regulatory approval: Conditional marketing authorisation pairs earlier availability with mandatory post-authorisation verification obligations (EMA, Regulation (EC) No 507/2006).

Positioning: The reduced lag applies the §3.9 architecture to the event class where implementation is directly observable at entry, pairing earlier entry with a second verification pass: continuity confirmation at entry, and maturity re-review at the standard window’s close.

3.10 Bloc Classification

§3.10 defines two distinct classification processes: macro-level bloc membership (§3.10.1) and event-level bloc attribution for Non-Aligned nations (§3.10.3). These processes serve different analytical purposes, operate at different scales, and use different criteria. Under a two-PAA system, two actors satisfy the PAA qualification threshold (§5.3), producing a two-bloc structure: the Western Bloc (anchored by the United States) and the Eastern Bloc (anchored by China). The methodology accommodates additional blocs forming (§3.10.1.3) without architectural modification.

Macro-level bloc membership determines a nation’s default ecosystem alignment as recorded in the Bloc Membership Register. Event-level bloc attribution determines which bloc a specific event is classified to during event processing. Macro-level membership is structural, slow-moving, and based on technology ecosystem dependencies. Event-level attribution is operational, per-event, and based on measurable partnership characteristics. The two processes use different primary signals because they answer different questions: macro-level classification asks “which ecosystem does this nation’s AI infrastructure structurally depend on?” whilst event-level attribution asks “for this specific event, which bloc’s ecosystem does it operate within?”

Nations classified as Western Bloc or Eastern Bloc at the macro level (§3.10.1) do not undergo per-event attribution — their register classification applies to all events. Only nations classified as Non-Aligned undergo the event-level three-priority hierarchy (§3.10.3).

3.10.1 Macro-Level Bloc Classification

Authoritative Register

The WEO Bloc Membership Register (available on the WEO website) provides the current authoritative classification of nations into Western Bloc, Eastern Bloc, and Non-Aligned. The register is a living document updated through versioned snapshots when geopolitical developments warrant reclassification.

Ecosystem Definition

WEO recognises two AI infrastructure ecosystems, each defined by a Principal AI Actor (§5.3). For bloc classification purposes, a PAA’s ecosystem comprises the full infrastructure stack across which it exercises sovereign capability — chip design, fabrication, semiconductor equipment, compute, frontier models, regulatory authority, and sovereign investment (the seven AI infrastructure dimensions defined in §5.3 and assessed per the qualification principles in §5.3.2). Bloc classification determines which of these two ecosystems a nation’s AI infrastructure primarily operates within.

• Western Bloc — the ecosystem anchored by the United States
• Eastern Bloc — the ecosystem anchored by China

Principal AI Actor designations are assessment-date snapshots, accurate at V1.5 publication. Current designations are documented in the Sovereign Capability Profiles (SCP) Register (§5.3.3). If a third actor were to satisfy the PAA qualification threshold (§5.3), a third bloc would be established with that actor as its anchor. The bloc structure accommodates future PAA changes without architectural modification.

Classification Principle

Bloc membership reflects AI ecosystem alignment — the ecosystem through which a nation’s AI capabilities are developed, deployed, and governed. Classification is determined by assessing observable ecosystem alignment against the category indicators defined below, with documented evidence meeting the source standard defined in §3.10.1.1.

Where political alliance and AI ecosystem alignment diverge, AI ecosystem alignment takes precedence. A nation’s membership of political frameworks (NATO, SCO, BRICS, Non-Aligned Movement) provides supporting context but is not determinative. The classification measures technology dependencies, compute partnerships, governance framework participation, and investment flows — not political statements, UN voting records, or traditional geopolitical alliance frameworks.

Alignment strength correlates with the breadth of a nation’s operational dependency on the bloc’s ecosystem across the seven SCP dimensions. Category placement is determined by indicator-based assessment against the category definitions below. The SCP dimensional framework (§5.3) provides the analytical vocabulary for describing alignment breadth; the category indicators translate this vocabulary into observable, documentable classification criteria at the macro level.

Universal Membership Categories

The following categories apply symmetrically to both the Western Bloc and the Eastern Bloc. Identical definitions, indicators, and distinguishing criteria apply regardless of which bloc is being assessed. A nation’s category within a bloc describes the strength of its alignment with that bloc’s AI infrastructure ecosystem, not its political character, values, or regime type.

The mechanism of alignment — formal agreement, voluntary technology choice, infrastructure lock-in, political alliance, governance framework participation — is recorded as a descriptive attribute within each nation’s register entry, not as a classification criterion. This enables cross-bloc comparison on a common scale of alignment strength.

The categories describe a spectrum from structural permanence to transient fluidity. Core alignment is deeply embedded and historically entrenched — reversal would constitute a geopolitical crisis. Integrated alignment is substantial but contingent on maintained compliance. Engaged alignment is material but voluntary — a nation can diversify without formal consequences. Peripheral alignment is narrow and inherently transient — a single relationship may dissolve or a symmetric counter-relationship may emerge, shifting the nation to Non-Aligned. This gradient of permanence has implications for analytical confidence — higher categories carry greater classification certainty.

Core

Definition: A nation that structurally anchors or is deeply embedded within the bloc’s AI infrastructure ecosystem across multiple dimensions. Core members operate within the Principal AI Actor’s ecosystem as a matter of long-standing strategic orientation, with alignment that is structural rather than transactional. Removal from the ecosystem would require fundamental reorientation of the nation’s technology infrastructure and geopolitical posture.

Indicators: - Long-standing (multi-decade) strategic alignment with the bloc anchor - Operational dependency on the bloc’s AI infrastructure stack across multiple dimensions (chip design, fabrication, equipment, compute, models, regulatory authority, sovereign investment — the seven dimensions of the Sovereign Capability Profiles framework, §5.3) - Membership in the bloc’s primary multilateral technology and governance frameworks - Domestic AI infrastructure substantially built on the bloc’s hardware, software, and standards stack - Formal alliance or treaty relationship with the bloc anchor covering security, trade, or technology

Distinguishing criteria (Core vs Integrated): Core members have structural, multi-dimensional embedding that predates the current AI infrastructure competition. Their alignment is not primarily the result of recent agreements or access frameworks — it reflects decades of integrated supply chains, defence relationships, institutional participation, and regulatory convergence. An Integrated member may have comparable formal commitments but lacks the historical depth and structural lock-in.

Transition logic: Demotion from Core requires a fundamental strategic reorientation — analogous to an exit from a longstanding alliance or the deliberate construction of an alternative technology stack. This is a crisis-driven transition, not a routine reclassification. Promotion to Core from Integrated requires sustained (multi-year) deepening of alignment across additional SCP dimensions, not merely the accumulation of agreements.

Integrated

Definition: A nation that actively participates in the bloc’s AI infrastructure ecosystem through formal agreements, structured technology access frameworks, or significant bilateral partnerships that carry compliance conditions. Integrated members have made deliberate, formalised commitments to the bloc’s ecosystem and receive preferential access or partnership terms in return. Their alignment is substantial, multi-vector, and subject to ongoing conditions.

Indicators: - Formal bilateral or multilateral agreements with the bloc anchor covering AI infrastructure, compute access, or semiconductor supply - Compliance conditions attached to technology access (e.g., export control alignment, end-use restrictions, technology environment governance standards) - Active participation in bloc-specific governance or standards bodies with compliance requirements - Significant bloc-origin compute infrastructure deployed domestically (data centres, cloud regions) under structured access frameworks - Alignment across two or more SCP dimensions with formal documentation

Distinguishing criteria (Integrated vs Core): Integrated members have substantial formal commitments but lack the historical depth and structural lock-in of Core members. Their alignment is the product of recent (post-2020) strategic decisions rather than multi-decade integration. An Integrated member’s alignment could plausibly shift within a 5–10 year horizon through deliberate policy change; a Core member’s could not.

Distinguishing criteria (Integrated vs Engaged): Integrated members have formal, conditional agreements with compliance requirements — their technology access is contingent on continued adherence to specified conditions. Engaged members participate in the ecosystem through de facto technology choices or governance activities without bilateral compliance conditions. The presence or absence of formal compliance conditions is the primary discriminator.

Transition logic: Promotion from Engaged to Integrated is triggered by the formalisation of commitments — signing agreements with compliance conditions, accepting technology access frameworks with end-use restrictions, entering structured partnerships. Demotion from Integrated to Engaged is triggered by the lapse, withdrawal from, or non-compliance with formal agreements. Promotion from Integrated to Core requires sustained multi-dimensional deepening over years, not a single event.

Engaged

Definition: A nation that participates in the bloc’s AI infrastructure ecosystem primarily through de facto technology choices, governance activities, or infrastructure deployment, without formal bilateral compliance conditions. Engaged members are functionally operating within the ecosystem — using the bloc’s hardware, running the bloc’s models, or participating in bloc governance — but without the formalised commitment structure of Integrated members. Their alignment is observable and material but not treaty-bound.

Indicators: - Predominant use of the bloc’s compute hardware in domestic AI infrastructure - Deployment of the bloc’s foundation models in government or major enterprise applications - Participation in bloc governance forums without formal compliance conditions (e.g., non-binding declaration signatories, governance network members, dialogue partners) - Voluntary adoption of the bloc’s AI standards or regulatory frameworks - Commercial relationships with the bloc’s hyperscalers or AI laboratories

Distinguishing criteria (Engaged vs Integrated): Engaged members lack formal, conditional agreements. Their alignment is the product of market choices, voluntary governance participation, or infrastructure deployment decisions rather than negotiated bilateral commitments with compliance requirements. An Engaged member faces no formal consequences for diversifying away from the bloc’s ecosystem.

Distinguishing criteria (Engaged vs Peripheral): Engaged members have observable, material participation in the ecosystem across more than one vector — they are using the bloc’s technology, participating in its governance, and/or hosting its infrastructure in ways that can be documented through public evidence. Peripheral members have only limited, single-vector connections.

Transition logic: Promotion from Peripheral to Engaged is triggered by observable evidence of material ecosystem participation across more than one mechanism. Promotion from Engaged to Integrated is triggered by the formalisation of commitments with compliance conditions. Demotion from Engaged to Peripheral is triggered by diversification away from the bloc’s ecosystem to a level where participation is no longer multi-vector.

Peripheral

Definition: A nation with limited, recent, or single-vector connection to the bloc’s AI infrastructure ecosystem. Peripheral members may have political alignment without deep technology integration, infrastructure dependency in one dimension without governance participation, or governance participation without technology infrastructure. Their connection to the ecosystem is real but narrow, shallow, or nascent.

Indicators: - Political alignment with the bloc anchor (e.g., bilateral security relationships, multilateral framework membership) without corresponding technology ecosystem integration - Single-dimension infrastructure dependency (e.g., reliance on the bloc’s telecommunications equipment without broader AI infrastructure adoption) - Recent entry into bloc governance forums at observer or dialogue level - Limited domestic AI infrastructure with single-source dependency on the bloc

Distinguishing criteria (Peripheral vs Engaged): Peripheral members have only single-vector or shallow connections to the ecosystem. If the connection is political, there is no corresponding technology integration. If the connection is technological, it is limited to one dimension. If the connection is governance, it is at observer level without material technology deployment. The distinction is breadth: Engaged members participate across multiple vectors; Peripheral members participate through one.

Distinguishing criteria (Peripheral vs Non-Aligned): Peripheral members have at least one observable, attributable connection to a specific bloc’s ecosystem that creates a predominant alignment, however narrow. Non-Aligned nations have no predominant connection to either bloc, or have approximately symmetric connections to both.

Transition logic: Promotion from Peripheral to Engaged is triggered by broadening of ecosystem participation beyond a single vector. Demotion from Peripheral to Non-Aligned is triggered by the dissolution of the connecting relationship or the development of approximately symmetric engagement with both blocs. Entry from Non-Aligned to Peripheral is triggered by the emergence of a predominant single-vector connection to one bloc.

Non-Aligned (separate status)

Definition: A nation with no predominant alignment to either the Western or Eastern AI infrastructure ecosystem. Non-Aligned status can reflect genuine strategic neutrality, approximate symmetry of engagement with both blocs, or deliberate multi-alignment strategies. Nations without documented AI-infrastructure engagement across either ecosystem are outside the scope of the Bloc classification system and are not classified as Non-Aligned, Western, or Eastern.

Non-Aligned is a dynamic status determined by the absence of predominant bloc attribution, not a residual classification. A nation claiming non-alignment whilst having deep, multi-dimensional dependency on one bloc is classified within that bloc (as Engaged or Peripheral), not as Non-Aligned.

Indicators: - Approximately symmetric engagement with both blocs’ technology ecosystems (e.g., using both US and Chinese hardware, participating in both blocs’ governance forums) - Deliberate multi-alignment policy (e.g., simultaneous Western GPU procurement and Chinese infrastructure partnerships) - Active pursuit of AI sovereignty initiatives that reduce dependency on both blocs

Identification criteria: See §3.10.2.

Event-level attribution: Non-Aligned nations require per-event bloc attribution using the three-priority hierarchy (§3.10.3). The same Non-Aligned nation may appear in Western Bloc events and Eastern Bloc events depending on the partnership characteristics of each specific event.

Bloc Assignment Gate

The preceding five categories describe the strength of a nation’s alignment within a bloc. This subsection defines the mechanism by which an actor is assigned to a bloc in the first instance — the gate between the general classification principle (“every nation is classified by which ecosystem its AI infrastructure primarily operates within”) and the category assignment within a specific bloc.

Bloc assignment uses a two-track system. Track 1 resolves unambiguous cases through observable infrastructure indicators. Track 2 resolves contested cases through a structured dependency analysis across the seven SCP dimensions (§5.3.2). The two tracks are sequential: Track 2 is applied only when Track 1 does not produce a clear majority.

Track 1 — Observable Infrastructure Alignment (Default)

An actor is assigned to the bloc whose Principal AI Actor’s ecosystem provides the predominant share of the actor’s operational AI infrastructure across three observable indicators:

1. Hardware origin: The ecosystem of origin for the AI accelerator hardware deployed in the actor’s territory (whose chips power the actor’s AI workloads).

2. Compute and model platforms: The primary cloud compute and model development platforms in commercial and governmental use within the actor’s territory (whose cloud infrastructure and foundation models the actor’s institutions operate on).

3. Regulatory alignment: The regulatory framework the actor’s AI governance aligns with or operates under (whose compliance standards, export control regimes, or governance norms the actor’s policy framework references or transposes).

Where two or more indicators point to the same PAA ecosystem, that ecosystem’s bloc is the assignment. No further analysis is required. The actor proceeds to category assignment within that bloc based on the strength of alignment as defined by the five category definitions above.

Track 2 — Seven-Dimension Dependency Direction Analysis (Contested Cases)

Where Track 1 indicators point in different directions — or where all three indicators are ambiguous — the full seven-dimension dependency direction analysis is applied. For each of the seven SCP dimensions defined in §5.3.2, the assessor determines which PAA’s ecosystem the actor’s AI infrastructure draws on for that capability:

• D1 (AI accelerator design): whose accelerator architectures are deployed?
• D2 (Advanced semiconductor fabrication): whose fabrication ecosystem produces the actor’s chips?
• D3 (Semiconductor manufacturing equipment): whose equipment supply chain services the actor’s fabs (if any)?
• D4 (Cloud AI compute services): whose cloud infrastructure hosts the actor’s AI workloads?
• D5 (Frontier AI model development): whose foundation models does the actor’s ecosystem operate on?
• D6 (AI-specific regulatory authority): whose regulatory framework does the actor align with?
• D7 (Sovereign AI infrastructure investment): whose ecosystem does the actor’s sovereign investment programme direct capital towards?

This analysis applies to all seven dimensions, not only those where the actor scores MET under the SCP assessment. An actor scoring 0/7 on its Sovereign Capability Profile still uses hardware designed within one PAA’s ecosystem and may access compute or models provided through the other — the dependency direction across dimensions determines bloc alignment even where the actor holds no sovereign capability of its own.

The PAA ecosystem holding the majority of the seven dimension dependencies determines bloc assignment. The actor proceeds to category assignment within that bloc.

Dead Heat Rule

Where the dimension dependency count is exactly equal across PAA ecosystems (possible under a two-PAA system only if the actor’s seventh dimension draws on a non-PAA or domestically produced input, producing a 3–3 split with one unattributed), the actor is designated Non-Aligned. Event-level bloc attribution for the actor’s events uses the three-priority hierarchy defined in §3.10.3.

An exact split in ecosystem dependency across the SCP dimensions indicates that the actor has genuinely diversified its infrastructure dependencies to the point where it is not structurally embedded in either ecosystem. This is the operational definition of Non-Aligned status: the absence of predominant alignment, demonstrated through infrastructure dependency analysis rather than political declaration.

Where the Dead Heat Rule produces a Non-Aligned designation, the Dimension Durability Tiebreaker (below) does not apply. The Dead Heat Rule takes precedence: an exact split is resolved to Non-Aligned, not overridden by durability weighting.

Near-Dead-Heat Rule

Where the dimension dependency count produces a narrow majority (4–3 split under a two-PAA structure), the majority determines bloc assignment. However, the split dependency constrains the actor’s category within that bloc: an actor with a near-dead-heat dependency profile is assigned to Peripheral or Engaged category rather than Integrated or Core, because the narrow majority indicates weaker structural embedding than a decisive dependency pattern would produce.

The category ceiling (Engaged) may be exceeded only if the actor subsequently develops additional infrastructure commitments that widen the dependency gap beyond the near-dead-heat threshold.

Dimension Durability Tiebreaker

Where Track 2 produces a tied dependency count and no Dead Heat condition exists, the tiebreaker is determined by dimension durability — the switching-cost profile of each dependency type. Under the current two-PAA system, the Dead Heat Rule exhausts the tied-count case; this provision activates if the PAA landscape changes (§3.10.1.3) and provides analytical vocabulary for register narratives.

In the AI infrastructure context as of July 2026, hardware dependencies (particularly at the frontier of semiconductor fabrication and equipment) exhibit the longest documented switching costs and timelines, followed by platform dependencies (cloud and model-ecosystem network effects), followed by governance dependencies (which are most reversible at the programme level but can become durable when embedded in dense economic interdependence).

The default tiebreaker hierarchy is: hardware (D1–D3) > platform (D4–D5) > governance (D6–D7). This hierarchy is calibrated to the 5–10 year assessment horizon and to the current configuration of the AI infrastructure stack, where leading-edge chips, EUV equipment, and CUDA tooling are concentrated in 2–3 actors with documented switching costs exceeding a decade. It is an empirical heuristic, not a theoretical claim about the nature of lock-in.

The analyst must override the default hierarchy when a dependency presents any of the following conditions:

1. Institutional gravity: Governance alignment is embedded in dense economic interdependence (significant trade exposure, customs union membership, integrated regulatory agencies), in which case governance lock-in may equal or exceed hardware lock-in. The analyst should not assume governance is the least durable dependency for actors with deep institutional embedding.

2. Network-effect platform entrenchment: The actor’s AI workloads are deeply integrated with a specific platform’s proprietary services and explicit sovereign displacement efforts have failed over an extended period, in which case platform lock-in should be weighted equally with hardware.

3. Vertically-integrated hardware: A single entity controls both the hardware design and the full software stack, collapsing hardware switching timelines. The default hardware stickiness applies to fragmented stacks with process-design-kit-locked foundry relationships.

4. Commodity-input hardware: The hardware dependency is a commodity chemical, material, or standard component with multiple global suppliers, in which case switching costs may be measured in months rather than years. The default hardware stickiness applies to frontier and chokepoint hardware.

The dimension durability concept mirrors the domain durability concept applied at the event level in §6.3, where hardware-domain events are assessed as more resistant to reversal than platform-domain or governance-domain events. The same analytical principle — that physical infrastructure creates deeper structural lock-in than digital services, which create deeper lock-in than institutional arrangements — operates at the macro actor-assignment level.

3.10.1.1 Evidence Standard for Register Classification Changes

Any reclassification of a nation from one category to another, or from Non-Aligned to a bloc (or vice versa), requires documented evidence meeting the following minimum standard:

Minimum: 1 primary source (Grade 1 or Grade 2 per the source authority hierarchy defined in §5.3.4) + 1 corroborating source (Grade 2 or Grade 3 per §5.3.4).

Source terminology follows the authority hierarchy defined in §5.3.4. Primary sources include government official documents (.gov domains, official gazettes, regulatory filings), multilateral organisation publications, and SEC-equivalent filings. Corroborating sources include major wire services (Reuters, AP, Bloomberg), quality journalism (Financial Times, Wall Street Journal), and peer-reviewed think tank reports (CSIS, Brookings, Chatham House, IISS).

Excluded sources per §3.1: Wikipedia, Reddit, forums, blogs. Encyclopaedias (Britannica, etc.) are tertiary reference works and do not qualify as primary or corroborating sources.

Negative verification: Where a classification depends on the absence of evidence (e.g., confirming a nation has not signed a particular agreement), absence must be demonstrated through at least two independent comprehensive lists or authoritative sources where the nation does not appear.

Reinforcement (no category change): Register reinforcements — where new evidence strengthens an existing classification without changing the category — are documented in the register narrative with source citations but do not require the full 1+1 evidence standard. The existing classification evidence stands; reinforcement evidence is supplementary.

Retrospective audit: Snapshot 2025.12.14-001 predates this evidence standard. Source documentation for that snapshot has been retrospectively supplemented to meet the §3.10.1.1 standard. No classifications were altered.

3.10.1.2 Register Operations

Versioning: Each register update receives a version identifier in the format YYYY.MM.DD-NNN where the date is the publication date and NNN is the sequence number.

Archival: Register snapshots are archived via Internet Archive/Wayback Machine (content preservation) and OpenTimestamps (cryptographic existence proof). Source URLs for classification evidence are archived via Internet Archive/Wayback Machine at the time of snapshot publication.

Update triggers: The register should be assessed for updates when: - A nation signs or withdraws from a bloc-specific technology framework (e.g., Pax Silica, AISI Network, SCO technology cooperation) - A nation receives or loses conditional technology access (e.g., chip export approvals, export control list changes) - A nation’s major AI infrastructure shifts to a different bloc’s technology stack - Significant geopolitical realignment affecting technology relationships occurs

Transition cadence: Register assessments may occur at any time when triggered by the events above. There is no fixed review cycle, but a verification snapshot should be produced at least annually to confirm existing classifications remain current, even if no changes have occurred.

3.10.1.3 Third Bloc Formation — Transitional Classification

If a new Principal AI Actor qualifies under §5.3, a third bloc is established (§3.10.1, Ecosystem Definition). Nations previously classified within an existing bloc may find their ecosystem alignment structurally split across the original and newly formed blocs — for example, continuing to depend on the original bloc’s hardware and compute infrastructure whilst operating under the new bloc’s regulatory authority and investment frameworks. This section provides the transitional classification mechanism for such scenarios.

Split-alignment recognition: If a third bloc forms, nations with demonstrable operational dependency across multiple ecosystems — assessed against the seven SCP dimensions (§5.3.2) — may no longer have a single predominant bloc alignment. A nation that previously held Core status in one bloc may find that its dimensional dependencies are now distributed: some dimensions aligning with the original bloc, others with the newly formed bloc. This is distinct from Non-Aligned status (which reflects strategic choice or genuine neutrality); split-alignment during bloc formation reflects structural transition, not hedging.

Transitional classification mechanism: During the transition period, nations with genuine multi-bloc dimensional dependency are reclassified as Non-Aligned and assessed per-event using the three-priority hierarchy (§3.10.3), even if they were previously Core or Integrated in another bloc. This ensures that each event is attributed to the bloc whose ecosystem capabilities are actually utilised in that specific event, rather than forcing a binary macro-level classification that would misrepresent the structural reality.

Stabilisation criterion: A nation’s ecosystem alignment is considered stabilised — and eligible for reclassification from transitional Non-Aligned to a specific bloc — when its operational dependency across the seven SCP dimensions predominantly aligns with one ecosystem. Predominance is assessed through the standard indicator-based classification process (§3.10.1) at each register snapshot. During the transition period, predominance should be assessed conservatively: a marginal majority (e.g. 4 of 7 dimensions) may not constitute sufficient predominance if the remaining dimensions represent critical infrastructure dependencies. The assessment should consider the structural weight of each dimension, not merely the count.

Category accommodation: During the transition period, the nation is classified as Non-Aligned (per the transitional classification mechanism above). The analyst tracks the nation’s dependency pattern across both blocs to assess when stabilisation occurs. When predominance is established and the nation is reclassified to a specific bloc, the category level (Core/Integrated/Engaged/Peripheral) reflects the strength of that alignment at the point of reclassification. A nation emerging from a transitional period is unlikely to qualify as Core immediately — the expected trajectory is from transitional Non-Aligned to Engaged or Peripheral in the predominant bloc, deepening over subsequent assessment cycles as dependencies consolidate.

3.10.2 Non-Aligned Nation Identification

A nation is classified as Non-Aligned when all five of the following criteria are met:

1. Active security, economic, or technology partnerships with both the Western and Eastern blocs
2. Explicit strategic autonomy, non-alignment, or multi-alignment doctrine (declared or demonstrated through observable policy)
3. Refusal to join exclusive bloc-specific alliances or technology frameworks that would create predominant alignment
4. Sovereign infrastructure development that is not predominantly dependent on either bloc’s ecosystem
5. Observed independence in technology governance and standards participation (not systematically aligned with either bloc’s regulatory framework)

Relationship to register: The five-criteria test determines Non-Aligned eligibility at the macro level. The Bloc Membership Register may additionally list nations undergoing alignment transitions that no longer meet all five criteria but require per-event assessment during the transition period. Such transitional cases are documented in the register with appropriate status indicators.

Declared vs de facto alignment: Non-Aligned status is assessed against both declared policy and observable infrastructure dependency, independently. A nation that declares non-alignment whilst operating predominantly within one bloc’s ecosystem is classified within that bloc, not as Non-Aligned. This dual assessment follows the principle that technology dependencies are the primary classification signal, not political declarations.

3.10.3 Event-Level Bloc Attribution for Non-Aligned Nations

Scope: This section applies exclusively to event-level classification during event processing. It determines which bloc a specific event involving a Non-Aligned nation is attributed to. It does not apply to macro-level register classification decisions (§3.10.1).

Attribution principle: WEO classification methodology requires PAA-ecosystem attribution — each qualifying event is attributed to the bloc anchored by a specific PAA. Events with no bloc dependency are outside documentation scope. The three-priority hierarchy is structurally applicable to any number of PAA-anchored ecosystems. Under the two-PAA structure at V1.5 publication, this produces Western Bloc or Eastern Bloc attribution.

Rationale for scope limitation: Macro-level classification (§3.10.1) and event-level attribution answer different questions at different analytical scales. Macro-level classification asks which ecosystem a nation’s AI infrastructure structurally depends on — technology ecosystem alignment is the right primary determinant because it captures structural lock-in (switching costs measured in years and billions). Event-level attribution asks which bloc’s ecosystem a specific event operates within — financial backing is the right Priority 1 because at the individual event level it provides an objective, measurable, reproducible signal that can be calculated as a percentage. The priority ordering differs between the two processes because they optimise for different analytical requirements: structural accuracy at the macro level, operational reproducibility at the event level.

Classification Process: Three-Priority Hierarchy

For events involving Non-Aligned nations, apply this sequential test to determine bloc classification:

Priority 1 — Financial Backing:

• Test: Of funding provided by WB or EB entities (excluding NA nation domestic funding), does either bloc provide ≥66⅔%?

Calculation: - Denominator = WB funding + EB funding (exclude NA domestic funding) - WB percentage = WB funding ÷ Denominator - EB percentage = EB funding ÷ Denominator

Classification: - If WB percentage ≥66⅔% → Classify as WB event - If EB percentage ≥66⅔% → Classify as EB event - If neither bloc reaches 66⅔% → Proceed to Priority 2

Note: NA nation domestic/sovereign funding does not count towards either bloc’s percentage — it makes Priority 1 inconclusive, requiring progression to Priority 2.

Example: Project with US$700M NA domestic + US$200M WB + US$100M EB funding: - Denominator = US$200M + US$100M = US$300M (bloc funding only) - WB percentage = US$200M ÷ US$300M = 66.7% → Classify as WB event (meets 66⅔% threshold)

Priority 2 — Critical Technology:

• Test: Which bloc provides the core enabling technology?
• Critical technology = technology without which the event cannot achieve its objectives
• If WB provides critical technology → Classify as WB event
• If EB provides critical technology → Classify as EB event
• If unclear or mixed → Proceed to Priority 3

Examples: - Event relies on Western advanced GPU technology as core compute → Western Bloc - Event uses Eastern infrastructure technology as critical backbone → Eastern Bloc - Event uses Western cloud services as platform → Western Bloc

AI Model Events — Clarification:

For AI model events, “critical technology” is determined by base model entity origin (headquarters jurisdiction of the developing entity). Deployment infrastructure (cloud provider, hosting location) is not determinative.

• Base model origin: Headquarters jurisdiction of entity that developed the model weights
• Deployment infrastructure: Where model is hosted or accessed from (not determinative)
• Derivative models: Base model origin takes precedence unless derivative represents substantial transformation (>50% new parameters or fundamental architectural change)

For empirical derivation: See Methodology Rationale, Section 3.12.1.

Priority 3 — Strategic Leadership:

• Test: Which bloc initiated, designed, or leads the strategic direction?
• If WB member leads initiative → Classify as WB event
• If EB member leads framework → Classify as EB event
• If still genuinely ambiguous → Flag for manual review

Examples: - Western Bloc member initiates and leads bilateral partnership → Western Bloc - Eastern Bloc member leads multilateral framework development → Eastern Bloc

Edge Case — Manual Review: - If event remains genuinely 50/50 after all three criteria → Flag for manual review - Document ambiguity and rationale for final classification - Default to technology provider if forced choice required

NA-Only Events: - Events involving ONLY Non-Aligned nations (e.g., bilateral coordination between two Non-Aligned nations) must still pass the three-priority test - If no WB or EB entity provides financial backing, technology, or leadership → Event cannot be classified to either bloc - Result: OMIT from database (event falls outside WB/EB binary classification scope) - Rationale: WEO’s classification methodology requires binary WB/EB attribution; events with no bloc dependency are outside documentation scope

Classification Examples

Note: The following are theoretical examples demonstrating the classification methodology. Actual verified events are documented in the WEO event database.

Example 1: Priority 1 Resolution (Financial Backing)

A Non-Aligned nation establishes a bilateral AI research partnership. A Western Bloc member provides US$400M in co-investment; an Eastern Bloc member provides US$50M in technical advisory funding. The Non-Aligned nation contributes US$300M in domestic sovereign funding.

• Priority 1 (Financial Backing): Denominator = US$400M + US$50M = US$450M (bloc funding only; domestic funding excluded). WB percentage = US$400M ÷ US$450M = 88.9% → exceeds 66⅔% threshold.
• Result: WB event. Resolved at Priority 1; Priorities 2 and 3 not required.

Example 2: Priority 1 → Priority 2 Cascade (Technology Dependency)

A Non-Aligned nation deploys a national AI compute programme with 100% domestic sovereign funding and no foreign financial contributions.

• Priority 1 (Financial Backing): Denominator = US$0 (no bloc funding). Priority 1 inconclusive — proceed to Priority 2.
• Priority 2 (Critical Technology): The programme’s compute infrastructure relies on Western advanced GPU technology as critical processing capacity. Without this technology, the programme’s objectives are unachievable. Critical technology provider is Western Bloc.
• Result: WB event. Despite sovereign funding, critical technology dependency determines bloc classification at Priority 2.

Bloc Attribution

Events classified through this process are attributed 100% to their assigned bloc: - WB events → Western Bloc attribution - EB events → Eastern Bloc attribution - No split attribution between blocs

Principle: Same NA nation may appear in WB events and EB events depending on partnership characteristics in each specific event.

Documentation Requirements

For each event involving NA nations, document:

Classification Determination: - Which Priority (Financial/Technology/Leadership) determined classification - Specific evidence supporting classification (% funding, technology specifications, leadership role) - Bloc assigned (WB or EB) - Rationale if ambiguous or close decision

Classification Principles

WEO prioritises methodological integrity through observable, verifiable criteria rather than political allegiance inference. This approach:

• Eliminates subjective judgement about “true allegiances” that shift over time
• Provides consistent classification across analysts using clear, measurable criteria
• Measures actual partnership structures rather than inferring geopolitical positions
• Maintains neutrality in assessing Non-Aligned strategic autonomy
• Ensures verifiability through financial data, technology specifications, and leadership documentation

3.11 Exclusion Criteria (Automatic Disqualification)

Events are AUTOMATICALLY EXCLUDED if:

✗ Announcement without implementation: Proposals, plans, frameworks without operational evidence
✗ Proposals without legislative passage: Bills that didn’t become law
✗ Pilot programmes without scaling: Small trials not expanded
✗ “Planned” initiatives without budget: Aspirational without resources
✗ Agreements “in principle”: Non-binding expressions of interest
✗ Events outside verification window: Event implementation date before 1st January 2022 or within 6 months of analysis date (insufficient time for verified implementation; verified product releases enter from 60 days under §3.9.2) ✗ State-controlled media requiring confirmation: Sources lacking editorial independence without third-party verification
✗ Single-source events: Cannot verify with second independent source (Exception: Single-source events may be included with editorial approval per Section 3.4.1 verification standards when all exception criteria are met: sufficient importance, demonstrable direct knowledge, established accuracy record, no ulterior motive, identity disclosure to editorial authority, and explicit status notation in event record)
✗ Contradicts verified events: Conflicts with higher-confidence data without explanation

3.12 Revision Policy

When Events Are Revised: - New information contradicts original verification - Source retracted or corrected - Implementation status materially changes

Revision Process: 1. Re-verify with updated sources 2. Update event data and confidence level 3. Document rationale in event version history 4. Note material changes in monthly updates

Transparency: All revisions documented with clear rationale. Material changes noted in methodology updates.

3.13 Phase 1→Phase 2 Handoff Protocol

Purpose: Systematic transition from event verification (Phase 1) to classification (Phase 2).

Required Data Package

Every verified event must include the following at Phase 1 completion:

Core Fields (Phase 1):

• Event ID: Sequential numeric identifier (zero-padded string), recorded as id
• Event Name: Standardised title (60 char max)
• Date Verified: YYYY-MM-DD
• Date Occurred: YYYY-MM-DD
• Operational Status: ACTIVE or TERMINATED

Phase 1 Classification:

• Event Type: Coordination/Infrastructure/Policy/Corporate
• Bloc Attribution: WB/EB (for NA nation events, via Section 3.10)

Verification:

• Source List: All URLs with access dates
• Source Count: Number of Primary + Corroborating sources
• Verification Notes: Sourcing rationale and confidence assessment
• Confidence Level: High (90%+) / Medium (70-90%)

Phase 2 Fields (to be assigned during Classification):

• Tier Classification: 1, 2, or 3 (assigned in Chapter 5)
• Bloc Classification: Cross-Bloc (Tier 1), WB-Led/EB-Led (Tier 2) or WB/EB (Tier 3) (assigned in Chapter 5)
• Fragmentation Type: Buildout/Restriction (Tier 2 only) (assigned in Chapter 5)
• Domain: Technology/Security/Trade/Energy-Infrastructure (assigned in Chapter 6)
• Industry Tag Primary: Primary industry tag (assigned in Chapter 7)
• Industry Tag Secondary: 0–2 secondary tags with mechanism statements (assigned in Chapter 7)
• Environmental Nexus Tags: 0–5 tags with mechanism statements and evidence-basis descriptors (assigned in Chapter 8)

Phase 1 Validation Checklist

Before handoff to Phase 2:

Verification Complete (Phase 1) - [ ] All sources documented with full citations and access dates - [ ] 2+ Primary sources OR 1 Primary + 2 Corroborating sources verified - [ ] Implementation evidence documented (not announcements) - [ ] Confidence level assigned: High (90%+) / Medium (70-90%) - [ ] Event Type assigned (Coordination/Infrastructure/Policy/Corporate) - [ ] Bloc attribution documented for NA nation events (via Section 3.10)

Ready for Phase 2 Classification - [ ] All mandatory Phase 1 fields populated - [ ] Event proceeds to Chapter 4 (Geopolitical Significance Assessment)

Note: Tier Classification, Fragmentation Type, and Domain are assigned during Phase 2 (Chapters 4-6); industry tags are assigned per Chapter 7 rule sets; Environmental Nexus Tags per Chapter 8. See Chapter 5, Section 5.9 for Tier Classification Checklist; Chapter 6 (worked examples following Section 6.6) for Domain Classification illustrations.

Example: Cross-Bloc Technology Framework

Event ID: 901
Event Name: Cross-Bloc AI Safety Framework  
Date Verified: 2023-11-02
Date Occurred: 2023-11-01
Operational Status: ACTIVE

Tier Classification: 1 (Cross-Bloc coordination)
Bloc Classification: Cross-Bloc (Cross-Bloc coordination)
Event Type: Coordination
Fragmentation Type: N/A

Source Count: 3 Primary sources
Verification Notes: "Verified via official government press release, UN documentation, and multilateral organisation records. Implementation confirmed through summit proceedings."
Confidence Level: High

3.14 Event Evolution & Succession Protocol

Purpose: Handle events that transform over time whilst maintaining accurate historical records, preserving analytical continuity, and preventing double-counting.

Core Principle: Events are living records that evolve through version history. New event creation is reserved for genuine transformations where the entity’s fundamental nature changes — not for scaling within the same institutional framework.

3.14.1 The Transformation-Scaling Distinction

The central question for event evolution is not quantitative magnitude but institutional continuity:

Does the change represent transformation (change in kind) or scaling (change in degree)?

Rationale: This distinction aligns with industry practice across infrastructure databases (World Bank PPI, Global Energy Monitor), treaty registries (UN Treaty Collection), and financial platforms (Bloomberg, Refinitiv). The principled boundary is institutional, not quantitative.

Corporate Product Release Supplement

The institutional criteria above — legal instruments, party composition, authorisation, entity continuity — assume event types where those concepts are structurally meaningful: policy instruments with legal bases, coordination frameworks with identifiable parties, and infrastructure projects with regulatory authorisations. For Corporate event type (Section 3.6) product releases — model releases, platform launches, and equivalent software artefacts qualifying through routes specified in Chapter 4 — these institutional indicators are structurally inapplicable. A software model release has no treaty, no sovereign parties, and no regulatory authorisation in the sense the criteria intend.

For corporate product releases, the transformation-scaling distinction applies the same principled boundary — change in kind versus change in degree — through three replacement dimensions:

Dimension A — Product Identity (Screening Gate):

Is the candidate a separately identifiable product release? Assess against:

• Separate release documentation (model card, technical report, release announcement)
• Distinct product name (not a version suffix or checkpoint label on the same product)
• Separate distribution channel (distinct repository, API endpoint, or deployment)

If the candidate is not separately identifiable (e.g., a weight refresh on the same repository, a checkpoint update under the same model card, an incremental version bump without independent documentation) → Rolling Update. No further assessment required.

If the candidate is separately identifiable → proceed to Dimensions B and C.

Dimension B — Technical Independence (Substantive Test):

Does the candidate represent independent technical development or incremental refinement of its predecessor?

Dimension C — Market Relationship (Contextual Modifier):

Does the candidate coexist with its predecessor as a parallel product, or replace it as a successor?

• Coexists: Both products remain available and actively maintained, serving different functions → strengthens transformation signal (parallel products from the same developer warrant separate records regardless of technical delta)
• Replaces: Predecessor deprecated or discontinued, candidate is direct successor → neutral; outcome determined by Dimension B

Decision Logic:

Scope: This supplement applies exclusively to corporate product releases. All other Corporate event subtypes — joint ventures, acquisitions, facility construction decisions, strategic investments — retain the institutional criteria in the §3.14.1 transformation-scaling table, which function as designed for those contexts.

N/A Decision Rule: When institutional criteria are structurally inapplicable to an event type, the corporate product diagnostic replaces them. The determination is not made by defaulting inapplicable criteria to either “same” or “changed.”

Interaction with Coordination Connections: A “new event” determination under this supplement does not preclude a typed relationship between the new event and its predecessor under the Coordination Connections framework (Chapter 9, Section 9.2). Same-developer product succession and relationship documentation are independent assessments — the former determines record architecture, the latter documents evidenced connections between distinct events.

Interaction with Structural Visibility Asymmetry (Section 4.11): Closed-source products where the developer does not publish architecture details may systematically produce Dimension B = Ambiguous outcomes for successor releases. This is an honest result reflecting insufficient public evidence, not a framework deficiency. Such cases flag for human review.

Worked Examples:

Example 1 — New Event:

A leading technology company releases a closed-source large language model (Model A) using a dense Transformer architecture with a 32,000-token context window. Eighteen months later, the same company releases Model B — a Mixture-of-Experts architecture with a 1,000,000-token context window, documented in a separate technical report. Model B replaces Model A as the company’s primary offering.

• Dimension A: MET — separate technical report, separate API identifier, separate release announcement
• Dimension B: Independent — architecture class change (dense → MoE), separate technical report, qualitatively new capability (30× context expansion)
• Dimension C: Replaces
• Determination: New Event (A=MET + B=Independent → New Event regardless of C)

Example 2 — Rolling Update:

The same company subsequently releases Model B Turbo — an optimised variant of Model B with faster inference, reduced pricing, and an updated knowledge cutoff. Model B Turbo uses the same Mixture-of-Experts architecture and is accessed through the same API family with a suffix identifier. No separate technical report is published. Model B Turbo replaces Model B as the default variant.

• Dimension A: MET (weakly — separate announcement, but same API family with suffix, no independent technical documentation)
• Dimension B: Incremental — same architecture, inference optimisation, no independent design
• Dimension C: Replaces
• Determination: Rolling Update (A=MET + B=Incremental + C=Replaces → Rolling Update)

3.14.2 Decision Framework

Three rules determine whether to create new event, update existing via rolling update, or terminate:

Rule 1: Transformation → Create New Event

IF change involves:

• Classification change: Tier, Bloc, Domain, or Event Type classification changes
• Party transformation: Bilateral becomes multilateral, or significant party composition shift
• Legal regime change: New treaty, new authorisation, or fresh consent required
• Entity split or merger: One event becomes multiple, or multiple events consolidate
• Institutional discontinuity: Original framework superseded by fundamentally different structure

THEN:

1. Original event: Set Operational Status = TERMINATED (with termination date)
2. Original event: Add superseded_by relationship to successor event
3. New event: Create with new Event ID
4. New event: Add succeeded_from relationship pointing to original
5. New event: Add Succession Rationale: Explain transformation

Why: Transformations create fundamentally different coordination events. Both realities warrant separate documentation with explicit succession linkage.

Example:

ORIGINAL EVENT:
Event ID: 903
Event Name: "Bilateral AI Partnership"
Tier: 3 (Intra-Bloc WB)
Operational Status: TERMINATED (2024-03-15)
superseded_by: 904
Succession Note: "Expanded to 8-nation consortium with cross-bloc participation"
Historical Period: Active from 2023-11 to 2024-03

SUCCESSOR EVENT:
Event ID: 904
Event Name: "Multilateral AI Consortium"  
Tier: 1 (Cross-Bloc)
succeeded_from: 903
Succession Rationale: "Transformation: bilateral → multilateral, Tier 3 → Tier 1. 
                       New participants from Eastern Bloc required fresh institutional 
                       framework with separate governance structure."
Current Status: Active from 2024-03 onwards

Result: Two events with explicit succession relationship, non-overlapping time periods, accurate historical record, preserved CC provenance.

Rule 2: Scaling → Rolling Update (Section 3.15)

IF development involves:

• Same legal instruments: Original authorisation, award, or treaty covers the expansion
• Same parties: No change in signatories or institutional participants
• Classification stable: Tier, Bloc, Domain, and Event Type unchanged
• Quantitative growth: Budget increase, capacity expansion, timeline extension
• Continuous evolution: Same fundamental coordination activity at larger scale

THEN: Apply Section 3.15 (Rolling Updates) — update existing event with version history

Why: Scaling within the same institutional framework represents continuous evolution of a single coordination event. Version history preserves the complete trajectory whilst maintaining analytical continuity.

Example:

A major semiconductor manufacturing programme receives federal award of $6.6B as part of total $65B project. Subsequently, the private investment component expands to $165B (154% increase) whilst the federal award remains unchanged at $6.6B.

Analysis:

• Same legal instrument? ✓ Original federal award unchanged
• Same parties? ✓ Same government agency, same recipient corporation
• Classification stable? ✓ Still Tier 3 Western, Infrastructure domain
• Fresh authorisation required? ✗ Expansion covered by original award terms

Result: Rolling Update per Section 3.15. Event remains single record with version history documenting scale evolution. Genesis data preserved. CCs maintain provenance.

Rule 3: Withdrawal/Termination → Depends on Impact

Scenario A: Withdrawal Causes Transformation

IF withdrawal causes:

• Classification change (e.g., cross-bloc → single bloc, Tier 1 → Tier 3)
• Framework collapse (all or most parties withdraw)
• Institutional discontinuity

THEN: Apply Rule 1 (Transformation). Original terminated, successor created if framework continues in transformed form.

Scenario B: Withdrawal Without Transformation

IF withdrawal leaves event materially unchanged:

• Still qualifies for same Tier (e.g., 27 of 28 nations remain cross-bloc)
• Core structure and purpose intact
• Classification unchanged

THEN: Apply Section 3.15 (Rolling Update). Event remains active with withdrawal documented in version history.

3.14.3 Numerical Thresholds as Review Triggers

The following thresholds trigger mandatory human review, but do not automatically determine outcome:

Review Process:

1. Threshold breach triggers review assignment
2. Analyst applies transformation-scaling criteria (Section 3.14.1)
3. Decision documented with explicit rationale
4. If scaling → Section 3.15 (Rolling Update)
5. If transformation → Rule 1 (New Event with Succession)

Rationale: Numerical thresholds correlate imperfectly with genuine transformation. They serve as useful flags for human attention but should not mechanically determine record architecture. The institutional criteria in Section 3.14.1 govern the actual decision.

3.14.4 Succession Modelling

When transformation warrants new event creation, explicit succession relationships preserve analytical continuity:

Succession Relationship Types:

Bidirectional Linking:

Succession relationships are always bidirectional. Both the terminated original and the new successor carry explicit cross-references enabling navigation in either direction.

CC Succession Handling:

When events with Coordination Connections undergo succession:

1. CCs on original event remain valid as historical records
2. CCs may optionally carry succession_note indicating relationship continues to successor
3. New CCs verified against successor event are documented as new CC records (not verification_history entries on original CCs)
4. The succession chain is navigable: Original Event → Successor Event → Current CCs

3.14.5 Documentation Requirements

For transformation (new event):

• Succession Rationale: 2-3 sentences explaining why this constitutes transformation
• succeeded_from / superseded_by: Bidirectional cross-references
• Original event: Operational Status = TERMINATED with date
• Review documentation: Evidence that transformation criteria met

For scaling (rolling update):

• Apply Section 3.15 documentation requirements
• If threshold review triggered: Document rationale for scaling determination
• Preserve complete version history

For termination without successor:

• Operational Status = TERMINATED
• Termination Note: Explanation of why event ended
• Termination Evidence: Sources documenting termination

3.14.6 Quality Checklist

Before finalising evolution decision:

• Transformation-scaling criteria applied (Section 3.14.1); if Corporate product release, corporate product diagnostic applied (§3.14.1 supplement)
• Correct rule identified (Transformation / Scaling / Withdrawal)
• If threshold triggered: Review documented with rationale
• If transformation: Succession relationships bidirectional
• If transformation: Original set to TERMINATED with non-overlapping dates
• If scaling: Section 3.15 applied correctly
• No double-counting (verify active periods don’t overlap)
• CC implications assessed

3.15 Post-Qualification Verification (Rolling Updates)

Purpose: Establish methodology for tracking, verifying, and incorporating event developments that occur after initial database qualification.

Core Principle: The same verification standard that governs initial qualification (6 months; 60 days for verified product releases under §3.9.2) applies to all subsequent updates. Post-qualification developments must pass temporal verification before incorporation into qualified event data.

3.15.1 Rationale and Scope

Why Post-Qualification Verification:

Events evolve after initial database entry. Infrastructure projects expand, policy frameworks are amended, corporate initiatives scale. Without systematic tracking, the database becomes a snapshot rather than a living record.

However, unverified updates introduce the same risks that the 6-month lag standard addresses for initial qualification: announcements that do not materialise, figures that change before implementation, and developments that reverse before completion.

Empirical basis: Research on major technology infrastructure announcements documents that 40-60% of large capital projects experience significant delays, modifications, or cancellations. The 6-month window captures immediate failures whilst validating actual implementation.

Scope — This section applies to:

• Capacity or scale changes to existing events (e.g., infrastructure expansion)
• Scope modifications (e.g., additional participants, extended geographic reach)
• Operational updates (e.g., commissioning dates, utilisation milestones)
• Classification-relevant developments (may trigger Section 3.14 transformation)

Scope — This section does NOT apply to:

• Initial event qualification (governed by Sections 3.1-3.14)
• Error corrections (immediate correction permitted with audit trail)
• Source updates without data changes (immediate update permitted)

3.15.2 Two-Tier Data Architecture

Genesis Data

Definition: The original qualified values at time of initial database entry.

Characteristics:

• Immutable historical baseline
• What qualified the event for database inclusion
• Preserved in dedicated genesis block
• Never modified after initial entry

Purpose: Genesis data provides permanent reference for:

• Understanding original qualification basis
• CC verification provenance (which event version a CC was verified against)
• Historical analysis of event evolution
• Audit trail integrity

Current Data

Definition: The latest verified values after Rolling Updates have been incorporated.

Characteristics:

• Mutable through Rolling Updates process
• Reflects current known state of the event
• Main event record fields (investment, description, scope, etc.)
• Changes create new versions (see Section 3.15.7)

Pending Updates

Definition: Source-verified developments awaiting 6-month temporal qualification.

Characteristics:

• Documentary evidence exists (source-verified per Section 3.1)
• Source date < 6 months from current date
• Cannot be incorporated until eligibility date passes
• Must be re-verified before incorporation

Location: Dedicated pendingUpdates array within event record

3.15.3 Event Data Structure

Each event record maintains three data layers:

id: [EVENT_ID]
name: [Event Name]
version: 1.1
versionDate: [YYYY-MM-DD]

CURRENT DATA (mutable via Rolling Updates):
  investment: [Current verified value]
  description: [Current verified description]
  scope: [Current verified scope]
  [other event fields]

GENESIS DATA (immutable):
  genesis:
    version: 1.0
    date: [YYYY-MM-DD]
    investment: [Original qualified value]
    description: [Original qualified description]
    scope: [Original qualified scope]
    qualificationBasis: [Route/criteria that qualified the event]
    verificationLag: [STANDARD | REDUCED (§3.9.2)]

VERSION HISTORY (audit trail):
  versionHistory:
    - version: 1.0
      date: [YYYY-MM-DD]
      description: Initial database entry
      changedFields: []
    - version: 1.1
      date: [YYYY-MM-DD]
      description: Incorporated PU-XX-001: [Update description]
      changedFields: [investment]
      previousValues:
        investment: [Previous value]
      incorporatedUpdate: PU-XX-001

PENDING UPDATES (awaiting verification):
  pendingUpdates: []

3.15.4 Pending Update Data Structure

Each pending update record contains:

id: PU-[EVENT_ID]-[SEQUENCE]

CONTENT:
  headline: [Brief description, max 100 characters]
  description: [Detailed description, max 500 characters]
  affectedFields: [field1, field2]
  proposedValues:
    field1: [New value]
    field2: [New value]

TEMPORAL:
  sourceDate: [YYYY-MM-DD]
  eligibilityDate: [YYYY-MM-DD, sourceDate + 180 days; maturity re-review records: implementationDate + 180 days (§3.15.13)]
  dateAdded: [YYYY-MM-DD]

STATUS:
  status: [Status code]
  statusChangedAt: [YYYY-MM-DD]

SOURCES:
  sources:
    - desc: [Source description]
      url: [URL]
      date: [YYYY-MM-DD]
      type: [PRIMARY | CORROBORATING]

VERIFICATION (populated after review):
  verificationOutcome: [CONFIRMED | MODIFIED | INVALIDATED | INCONCLUSIVE]
  verificationDate: [YYYY-MM-DD]
  verificationNotes: [String]
  verificationEvidence:
    - desc: [...]
      url: [...]

3.15.5 Status Taxonomy

Transition Rules:

• Status changes require documented rationale
• Terminal statuses preserve full audit trail
• EXPIRED triggers escalation notification

3.15.6 Update Lifecycle

Stage 1: Identification

New development identified through:

• Routine monitoring of existing events
• User submission with source documentation
• Systematic audit process

Requirement: Documentary evidence must exist (source-verified per Section 3.1 standards).

Stage 2: Queue Entry

If source-verified evidence exists:

1. Create pending update record
2. Calculate eligibility date (source date + 180 days; implementation date + 180 days for maturity re-review records, §3.15.13)
3. Set status: SUBMITTED
4. Add to master queue document

If insufficient evidence:

• Do not add to queue
• Document rejection rationale if formally submitted

Stage 3: Eligibility

When eligibilityDate is reached:

1. Auto-transition status: SUBMITTED → PENDING_REVIEW
2. Add to verification queue
3. Assign for review

Stage 4: Verification

Materialisation Check:

• Search for confirmation of the development
• Compare original claims to actual outcomes
• Document evidence either way

Decision Matrix:

Stage 5: Incorporation or Archival

If VERIFIED:

1. Update main event record with verified values
2. Increment version number (Section 3.15.7)
3. Check for CC implications (Section 3.15.8)
4. Archive pending update record with INCORPORATED status

If INVALIDATED or REJECTED:

1. Archive pending update record with terminal status
2. Add to invalidation log (Section 3.15.9)
3. Preserve full audit trail

3.15.7 Version Control

Version Numbering Convention:

Error correction (+0.0.1) applies when the edit changes the record’s factual content — a wrong date, wrong figure, wrong actor name, or misattribution. Editorial maintenance does not increment the version number and applies when the factual content a reader would extract is unchanged — prose improvements, formatting changes, field-label standardisation. The boundary is the record’s factual assertions: if the record’s factual content is the same before and after the edit, the change is editorial maintenance.

Version History Structure:

Each event record maintains a versionHistory array documenting all changes:

versionHistory:
  - version: 1.0
    date: [YYYY-MM-DD]
    description: Initial database entry
    changedFields: []
  - version: 1.1
    date: [YYYY-MM-DD]
    description: Incorporated PU-XX-001: [Update description]
    changedFields: [investment, description]
    previousValues:
      investment: [Previous value]
      description: [Previous value]
    incorporatedUpdate: PU-XX-001

Preservation Principle:

Previous values are always preserved in version history. This enables:

• Point-in-time reconstruction of database state
• Audit trail for all changes
• Analysis of how events evolve over time
• CC provenance tracking (which version a CC was verified against)

3.15.8 Coordination Connection Implications

When pending updates are incorporated, assess CC implications following these principles.

Historical Validity of Existing CCs

Core Principle: CCs verified against genesis data remain valid historical records. A CC documents a relationship that existed at verification time; subsequent event updates do not retroactively invalidate the documented connection.

CCs are historical records of verified coordination relationships. If Event A funded Event B at 10% at genesis, that relationship existed and was documented. If Event B later scales such that the original funding represents only 5%, the original CC remains valid — it documents what was true at the time of verification.

Mandatory CC Review Triggers

When incorporating updates, conduct CC review if:

• Scale changes exceed 50% (may enable new Funding Flow pathways)
• New participants added (may enable new connection pathways)
• Scope changes affect domain or geographic reach
• Any change affects fields referenced in existing CCs

CC Review Process:

1. Identify affected CC pathways
2. Re-run CC identification for affected event pairs
3. Verify any candidate connections per Chapter 9 methodology
4. Handle new CCs per rules below
5. Document CC review outcome in incorporation notes

Same-Type CC Reinforcement

Where updated event data enables verification of a CC of the same type between the same events as an existing CC, this is documented as a new entry in the existing CC’s verification_history rather than as a separate CC record.

Rationale: The coordination pathway between two events is a single relationship. It may be verified multiple times as events evolve, but it remains one pathway. This approach:

• Preserves the genesis verification as historical record
• Documents reinforcement of the coordination pathway over time
• Preserves full verification history in the verification_history array

CC Data Structure with Verification History:

connection_id: CC-[SOURCE]-[TARGET]-[TYPE]
source_event_id: [SOURCE_ID]
target_event_id: [TARGET_ID]
connection_type: [TYPE_NUMBER]
connection_type_name: [Type Name]
direction: [source_to_target | bidirectional]

CURRENT STATE (latest verification):
  confidence_level: [CC-V | CC-E | CC-A]
  evidence_summary: [Summary based on latest verification]

VERIFICATION HISTORY (all verifications, genesis first):
  verification_history:
    - version: 1.0
      date: [YYYY-MM-DD]
      sourceEventVersion: 1.0
      targetEventVersion: 1.0
      confidence_level: [CC-V | CC-E | CC-A]
      evidence_summary: [Summary at this verification]
      evidence_detail: [full evidence object]
      genesis: true
    - version: 1.1
      date: [YYYY-MM-DD]
      sourceEventVersion: 1.0
      targetEventVersion: 1.1
      confidence_level: [CC-V | CC-E | CC-A]
      evidence_summary: [Summary at this verification]
      evidence_detail: [full evidence object]
      genesis: false

Different-Type CC Addition

Where updated event data enables a CC of a different type between the same events, this is created as a separate CC record. Different CC types represent distinct coordination mechanisms and warrant independent documentation.

Example: Events 901 and 902 may have both:

• CC-901-902-3 (Funding Flow) — verified at genesis
• CC-901-902-4 (Regulatory Enablement) — verified after v1.1 update

These are separate CCs with separate relationship records, as they document different coordination mechanisms.

New Event Pair CCs

Where updated event data enables a CC between events that had no previous CC, this is created as a standard new CC record per Chapter 9 methodology.

Non-Triggers

The following do not require CC review:

• Minor scale adjustments (<25%)
• Source updates without data changes
• Formatting or description clarifications

Conceptual Architecture: One CC represents one coordination pathway between two events. The pathway may be verified multiple times as events evolve, with each verification recorded in the CC’s verification history. This preserves the genesis verification as historical record whilst documenting reinforcement over time.

3.15.9 Invalidation Tracking

Purpose:

Maintain full records of developments that did not materialise to:

• Build source reliability tracking
• Identify pattern failures by announcement type
• Inform future verification decisions
• Preserve complete audit trail

Invalidation Record Structure:

id: INV-[EVENT_ID]-[SEQUENCE]
originalUpdate: [Full pending update record]
invalidationDate: [YYYY-MM-DD]
invalidationReason: [Reason code]
evidence:
  - desc: [...]
    url: [...]
lessonsLearned: [String, optional]

Reason Codes:

3.15.10 Maintenance Procedures

Master Queue Document

A central document tracks all pending updates across all events:

WEO Pending Updates Queue

Last Updated: [Date]

ELIGIBILITY THIS WEEK:
| Event | Update ID | Headline | Eligibility Date | Status |

ELIGIBILITY NEXT 30 DAYS:
| Event | Update ID | Headline | Eligibility Date | Status |

ALL PENDING UPDATES (by Event):

Event XX: [Event Name]
  - PU-XX-001: [Headline] (eligible: [Date], status: [Status])

Review Workflow

Frequency: Weekly batch review

Process:

1. Scan for items where eligibility date has passed and status = SUBMITTED
2. Transition to PENDING_REVIEW
3. Generate review queue
4. Assign for verification
5. Complete verification within 7 days
6. Escalate if no action within 14 days of eligibility

Alert Schedule:

3.15.11 Quality Checklist

Before adding pending update:

• Source-verified evidence exists per Section 3.1
• Eligibility date correctly calculated (source date + 180 days; implementation date + 180 days for maturity re-review records)
• Affected fields identified
• Proposed values documented

Before incorporating update:

• Eligibility date has passed
• Materialisation verified with documentary evidence
• Version number incremented correctly
• Previous values preserved in version history
• Genesis block unchanged
• CC implications assessed per Section 3.15.8
• Audit trail complete

For CC reinforcement:

• Same CC type between same events as existing CC
• New verification added to verification_history
• Genesis verification preserved with genesis: true
• Current state updated to reflect latest verification

For invalidation:

• Reason code assigned
• Evidence documented
• Full pending update record archived
• Lessons learned captured (if applicable)

3.15.12 Integration with Event Evolution Protocol

Post-qualification verification operates alongside Section 3.14 (Event Evolution & Succession Protocol):

Decision Flow:

Post-qualification development identified
|
v
Is this a Corporate product release? (model, platform, or equivalent software artefact from same developer as existing event)
|
YES --> Apply §3.14.1 corporate product diagnostic (Dimensions A/B/C)
NO  --> Continue with institutional criteria below
|
v
Does it affect Tier, Bloc, Domain, or Event Type classification?
|
YES --> Section 3.14 (Transformation → New Event)
NO  --> Continue assessment
|
v
Does it involve party transformation or legal regime change?
|
YES --> Section 3.14 (Transformation → New Event)
NO  --> Continue assessment
|
v
Does numerical threshold trigger review? (≥100% budget OR ≥50% capacity OR ≥25% participant change — see §3.14.3)
|
YES --> Human review applying Section 3.14.1 criteria
|
Transformation? --> Section 3.14 (New Event)
Scaling? --> Section 3.15 (Rolling Update)
NO  --> Section 3.15 (Rolling Update)

Key Principle: Numerical thresholds trigger review, not automatic record creation. The transformation-scaling distinction in Section 3.14.1 governs the outcome.

3.15.13 Maturity Re-Review Records (Reduced-Lag Entries)

A maturity re-review record is established at initial database entry for every event qualified under the reduced verification lag (§3.9.2).

Record Parameters:

• Structure: Standard pending update record (§3.15.4), with two variations: the eligibility date is calculated as event implementation date + 180 days (not source date + 180 days), and the CONTENT block carries no proposed values at creation — findings are populated at review.
• Identifier: Standard PU-[EVENT_ID]-[SEQUENCE] format; the headline records the scheduled review.
• Lifecycle: The record follows the §3.15.5 status taxonomy and §3.15.6 lifecycle, entering at SUBMITTED and transitioning to PENDING_REVIEW automatically on the eligibility date.

Review Scope: The review verifies the record at the point the event would have cleared the standard §3.9 window:

1. Availability history: whether the product remained generally available within its declared footprint since entry, and whether any withdrawal, suspension, rollback, capability restatement, or availability-affecting regulatory action occurred.
2. Source stability: whether the entry’s primary sources remain live and consistent with the record; archived versions are consulted where originals are unavailable.
3. Record accuracy: whether current data fields remain accurate against post-entry developments.

A documented rollback or capability restatement is a mandatory examination point under item 1, regardless of whether it altered the product’s availability status.

Outcomes: The verification outcome is recorded per the §3.15.4 verification fields. Post-entry developments identified by the review — including scheduled lifecycle retirements — are incorporated through the standard Rolling Updates process where they alter current data. A scheduled lifecycle retirement is not an integrity finding: the event documents an implemented release, and subsequent retirement does not alter the record’s qualification.

Summary

Chapter 3 establishes Gold Standard requirements through which WEO aims to meet the verification rigour of major financial indices. Key principles:

1. Source Hierarchy: Primary → Corroborating → Supplementary sources
2. Verification Protocol: 5-step systematic process for every event
3. Implementation Evidence: Operational proof required, not just announcements
4. Source Requirements by Claim Type: Tiered verification standards (A/B/C) with confidence language
5. Verification Window: 1st January 2022 - 6-month cut-off from current date (lag standard; 60-day reduced lag for verified product releases, §3.9.2)
6. Non-English Events: Enhanced protocols for WEO’s English-language research base
7. Bloc Classification: Cross-Bloc (Tier 1), WB-Led/EB-Led (Tier 2) or WB/EB (Tier 3) with three-priority test for NA nation events
8. Tier System: Three tiers with clear classification guidance
9. Event Types: Four mechanism-based categories
10. Quality Assurance: Comprehensive verification and validation processes
11. Event Evolution: Historical classifications preserved; transformations (change in kind) create new events with succession relationships; scaling (change in degree) handled via rolling updates with version history; corporate product releases assessed via dedicated diagnostic replacing structurally inapplicable institutional criteria
12. Post-Qualification Verification: Rolling Updates system maintaining 6-month lag standard for post-entry developments; genesis data preservation; CC verification history tracking

These standards are NON-NEGOTIABLE. Every event in WEO database meets these requirements without exception. This verification foundation enables WEO’s credibility as the first platform to systematically classify and document AI infrastructure coordination dynamics across geopolitical blocs.

End of Chapter 3: Event Verification

Chapter 4: Geopolitical Significance Assessment

4.1 Purpose and Framework Overview

This chapter establishes Qualification Criterion 4 (QC4) of WEO’s event verification methodology. Events must demonstrate geopolitical significance to qualify for WEO database entry.

Qualification Framework Structure

AI infrastructure coordination includes physical buildouts, software ecosystems, policy frameworks, and multi-nation agreements. These distinct activity types require tailored significance criteria whilst maintaining consistent evidentiary rigour.

Keohane Pre-Filter (Multi-Nation Coordination): Events meeting Keohane coordination criteria (Section 3.7) auto-qualify for geopolitical significance. Multi-nation coordination — whether cross-bloc or intra-bloc — is inherently significant for a coordination index. These events proceed directly to Tier Classification (Chapter 5) without requiring Part A/B/C assessment.

Part A/B/C Assessment (All Other Events): Events not meeting Keohane criteria are assessed through one of three frameworks based on event nature:

Qualification Routing

Event passes Chapter 3 Universal Requirements
(AI Connection, Implementation Evidence, Verification Window, Source Standards)
                            ↓
        ┌───────────────────────────────────────────┐
        │  KEOHANE PRE-FILTER                       │
        │  Does event meet Keohane Type 1, 2, or 3? │
        │  (See Section 3.7 Coordination Criteria)  │
        └───────────────────────────────────────────┘
                            ↓
              YES                        NO
               ↓                          ↓
    ┌─────────────────┐     ┌─────────────────────────────┐
    │  AUTO-QUALIFY   │     │  ROUTE TO PART A/B/C        │
    │  Skip to Tier   │     │  Based on event nature:     │
    │  Classification │     │  • Physical infra → Part A  │
    └─────────────────┘     │  • Software/platform → Part B│
                            │  • Policy/institutional → Part C│
                            └─────────────────────────────┘

Rationale: This structure ensures comprehensive coverage of AI infrastructure coordination activity whilst applying domain-appropriate significance criteria. Multi-nation coordination auto-qualifies because coordination itself demonstrates geopolitical significance. Single-actor events require assessment to distinguish strategically significant activity from routine operations.

Temporal Assessment Principle: All qualification thresholds are assessed at time of implementation, not at time of verification or database entry. Comparative metrics (rankings, market positions, percentile thresholds) reflect the event’s status when it became operational. This preserves historical accuracy as competitive landscapes evolve.

Schema note: The qualifying route — Keohane auto-qualification or the Part A/B/C pathway — is recorded as the event’s qualificationPathway.

4.2 Keohane Pre-Filter: Multi-Nation Coordination

Events meeting Keohane coordination criteria (Type 1: Formal Agreement, Type 2: Institutional Consensus, or Type 3: Demonstrated Convergence) auto-qualify for geopolitical significance without requiring Part A/B/C assessment. The criterion assessment is recorded in the event’s keohane array (per-criterion factor, pass, rationale).

✓ Automatic qualification — Events proceed directly to Tier Classification (Chapter 5)

Multi-nation coordination is inherently significant for a coordination index regardless of whether the coordination is cross-bloc (T1) or intra-bloc (T3).

Note: Events must still meet all Chapter 3 universal requirements (AI Connection Filter, Implementation Evidence, Verification Window, Source Standards). Keohane auto-qualification applies to geopolitical significance assessment only.

For complete Keohane framework specification, evidence requirements, implementation verification standards, and examples, see Chapter 3: Event Verification, Section 3.7.

4.3 Part A: Physical AI Infrastructure (Basel 5-Factor Assessment)

Events not meeting Keohane pre-filter criteria are routed to Part A, B, or C based on event nature. Part A applies to physical AI infrastructure events.

Scope: Single-nation or corporate physical infrastructure events affecting bloc-level dynamics or global AI coordination landscape.

Examples:

• Major economy semiconductor manufacturing incentive programme ($50B+)
• Advanced semiconductor export restrictions affecting global supply chains
• National AI compute infrastructure initiative (10,000+ GPUs/accelerators)
• Major data centre buildout programme

Qualification: Must meet Basel 5-Factor Assessment (2+ of 5 factors required)

Institutional Foundation: Basel Committee on Banking Supervision G-SIB Methodology (2018)

Rationale: The Basel G-SIB methodology represents the most sophisticated institutional framework for assessing “systemic importance” in infrastructure. Used by G20 central banks since 2011, it balances quantitative metrics with multi-dimensional assessment. WEO adapts this proven framework for AI infrastructure significance.

4.4 Basel 5-Factor Assessment Framework

Part A events must demonstrate significance on 2+ of 5 factors to qualify:

Object-of-assessment rule. When the event being assessed is not itself a facility (e.g., a policy instrument, a chip product line, an investment transaction, a procurement contract), the five factors are assessed against the object the event documents, not the instrument or transaction in isolation:

• Factors 1 (Size), 3 (Substitutability), and 4 (Complexity) are assessed against the infrastructure, technology, or material that the event controls, funds, produces, or restricts
• Factors 2 (Interconnectedness) and 5 (Cross-Jurisdictional Activity) are assessed against the event’s cross-border effect — the dependencies, supply-chain impacts, or multi-nation consequences the instrument creates or disrupts

At least one passing factor must rest on evidence specific to the event or entity being assessed, not on characteristics shared by every entity in the same category. The test is substitution: replace the assessed entity with any other entity in the same category; if the factor rationale remains true without changing a word, the factor is class-generic. Class-generic factors count toward the 2+/5 threshold but an event cannot qualify on class-generic factors alone.

Factor 1: Size (Scale/Magnitude)

Assessment Question: Does this represent top-quartile scale globally in AI infrastructure?

Threshold:

• $500M+ capital deployment (adapted from U.S. FHWA “Major Project” definition, 23 U.S.C. 106(h); see Methodology Rationale Document for full precedent analysis), OR

• 5,000+ GPUs or equivalent AI accelerators deployed, OR

• Top 500 supercomputer-class system, OR

• Top 25% globally within category by AI infrastructure scale

  Note on AI Accelerator Equivalence: “Equivalent AI accelerators” includes TPUs, NPUs, and purpose-built AI training/inference processors (e.g., Huawei Ascend, Enflame CloudBlazer, Google TPU, Cambricon MLU) that serve the same computational function as GPUs in AI infrastructure deployments. The threshold measures AI compute infrastructure at scale; chip architectural lineage does not affect qualification.

  Note on “Top 25% Within Category” for AI Accelerator Designers: The category for AI accelerator designer events comprises companies currently designing and producing AI accelerators at scale — shipped to external customers or deployed internally at production scale. Pre-revenue entities and edge-only processors are excluded. The primary evidence of scale is entity AI accelerator revenue. Where the accelerator is not sold commercially and no standalone chip revenue exists, the parent entity’s AI infrastructure segment revenue serves as the evidence basis. The Factor 1 rationale states the metric used and the figure supporting the top-25% determination.

Why this threshold?

• Filters out trivial corporate initiatives ($10M pilot programmes)
• Captures strategically significant infrastructure
• Comparable to national-level initiatives

Note on Event Verification Relationship: This $500M physical infrastructure threshold is higher than Chapter 3: Event Verification, Section 3.7 minimum ($100M) by design. Physical AI infrastructure (semiconductor fabs, data centres, supercomputers) requires capital-intensive deployment at $500M+ scale. Events between $100M-$499M can still qualify for WEO database by demonstrating geopolitical significance via 2+ other Basel factors (Interconnectedness, Substitutability, Complexity, Cross-Jurisdictional Activity). Size is one indicator of significance, not the only pathway.

Examples:

• ✓ Major economy semiconductor manufacturing incentive: $50B+ commitment (qualifies)
• ✓ Non-Aligned nation AI infrastructure initiative: 10,000+ GPUs/accelerators, $1B+ (qualifies)
• ✓ Advanced processor import restriction: Affects $5B+ annual trade value (qualifies)
• ✓ Major semiconductor facility financial award: $5B+ commitment (qualifies)
• ✗ Corporate AI research laboratory: $100M investment (does not qualify on size alone)
• ✗ University research computing cluster: 100 GPUs (below threshold)
• ✓ Globally dominant AI accelerator designer: produced technology deployed at scale exceeding the 5,000-accelerator threshold, with entity AI infrastructure scale top-quartile within the AI accelerator design category
• ✗ AI accelerator designer with entity AI infrastructure scale below top-quartile within the category and produced accelerator deployment below the 5,000-unit threshold: Size requires the entity’s own scale to meet a Factor 1 criterion — aggregate market volumes or domestic deployment base do not substitute

Factor 2: Interconnectedness (Cross-Border Dependencies)

Assessment Question: Does this create dependencies or integrate with other nations’ AI systems?

Criteria:

• Creates or restricts critical dependencies across multiple nations, OR
• Enables/restricts other nations’ AI development, OR
• Creates supply chain dependencies, OR
• Establishes standards other nations adopt, OR
• Creates network effects across borders

Examples:

• ✓ Advanced semiconductor fabrication facility: Critical node in global supply chain
• ✓ Advanced technology export controls: Restricts competing bloc’s access to critical inputs
• ✓ Critical minerals export restrictions: Creates cross-border dependencies
• ✓ International AI governance standard: Multiple nations adopt framework
• ✗ Domestic cloud computing region: Serves local market only, no cross-border dependency
• ✗ Domestic data centre with no foreign connections: Isolated infrastructure

Note on Factor Attribution: Where cross-border dependency arises from the geographic concentration of a supplier’s jurisdiction rather than from the infrastructure’s functional integration with other nations’ systems, the dependency is assessed under Factor 5 (Cross-Jurisdictional Activity), not Factor 2.

Factor 3: Substitutability (Uniqueness/Concentration)

Assessment Question: Can this infrastructure be easily replaced by alternatives?

Criteria:

• Affects concentrated/irreplaceable capabilities, OR

• Only provider of this infrastructure type in region/bloc, OR

• Specialised capability not available elsewhere, OR

• Removal would create significant gap, OR

• One of few global suppliers (high concentration)

  Note on Strategic Concentration: Where documented export controls, trade restrictions, or equivalent regulatory instruments constrain an ecosystem’s access to alternative suppliers or technologies, the “Removal would create significant gap” and “One of few global suppliers” criteria assess substitutability against the constrained market’s available alternatives, not the unconstrained global market. The evidence requirement is documented demand-supply imbalance within the constrained ecosystem — evidence that the ecosystem cannot practically access alternatives that exist globally. An ecosystem subject to trade restrictions where the restricted entity’s products remain commodity-replaceable from accessible alternative suppliers does not qualify under this provision; the discriminating factor is documented constraint on access to alternatives, not the existence of regulatory instruments affecting the market.

Examples:

• ✓ Extreme ultraviolet lithography equipment restrictions: Single supplier with 100% market share, zero substitutes
• ✓ Leading AI accelerator export restrictions: Dominant platform with limited substitutes
• ✓ Advanced semiconductor manufacturing nodes: Few alternatives globally
• ✓ National AI safety institute: Only government AI safety body in major economy
• ✗ Generic data centre infrastructure build: Commodity technology, many substitutes exist
• ✗ Generic cloud computing capacity: Many substitutes available
• ✓ AI accelerator designer serving an ecosystem where documented export controls restrict access to alternative suppliers: The entity’s removal would create a significant gap because the constrained ecosystem cannot practically access global alternatives — substitutability assessed against the constrained market’s available alternatives, not unconstrained global availability
• ✗ AI accelerator designer whose products are commodity-replaceable within the ecosystem it serves: Alternative architectures and suppliers are accessible without regulatory constraint on access — product-level replaceability assessed against the market the entity’s ecosystem can actually access

Factor 4: Complexity (Cutting-Edge Tech/Long Lead Times)

Assessment Question: Does this involve sophisticated, multi-stage processes or specialised components?

Criteria:

• Involves cutting-edge capabilities OR multi-year development cycles requiring specialised inputs or processes, OR
• Cutting-edge technology deployment, OR
• Multi-year construction with specialised inputs, OR
• Requires rare expertise or materials, OR
• Long lead times (2+ years) with complex supply chains

Examples:

• ✓ Advanced semiconductor manufacturing facilities: 3-5 year build cycle, extreme technical complexity
• ✓ Frontier AI model training infrastructure: Cutting-edge AI capability
• ✓ Exascale-class supercomputing systems: Cutting-edge technical integration
• ✗ Standard information technology infrastructure: Commodity technology, rapid deployment
• ✗ Standard enterprise AI deployment: Routine technology
• ✓ Restriction or control instrument targeting advanced semiconductor equipment or high-purity specialised materials: controlled technology involves multi-year development cycles, extreme-purity processing, or specialised synthesis equipment — complexity assessed against the controlled technology per the object-of-assessment rule
• ✗ Restriction or control instrument targeting commodity technology or widely available materials with short procurement lead times and multiple established suppliers: controlled technology does not exhibit cutting-edge complexity regardless of the instrument’s regulatory sophistication

Factor 5: Cross-Jurisdictional Activity (Multi-Nation Impact)

Assessment Question: Does this affect multiple nations’ AI capabilities or strategic positioning?

Criteria:

• Affects coordination dynamics across multiple nations, OR
• Affects entire bloc’s AI sovereignty/capability, OR
• Sets precedent for other bloc members, OR
• Strengthens/weakens bloc’s global AI position, OR
• Shifts inter-bloc AI dynamics

Examples:

• ✓ Critical materials export restrictions: Affects global supply chains across multiple nations
• ✓ Regional data protection regulation: Affects cross-border data flows, creates regulatory friction
• ✓ Regional bloc AI regulation: Affects all member states with extraterritorial reach
• ✓ Non-Aligned nation AI capability initiative: Strengthens bloc coordination capacity
• ✗ Domestic market regulation: Affects only single nation’s internal market
• ✗ Municipal-level AI pilot programme: Purely domestic implementation

Bloc-capability contribution by a domestic facility satisfies Factor 5 only where the record documents (a) participation by entities from other jurisdictions in the deployment — through technology partnership, joint venture, or cross-border supply arrangement extending beyond ordinary equipment procurement, or (b) explicit strategic-programme embedding with cross-bloc effect stated in primary sources. Domestic facilities contributing to national AI capability without documented cross-border participation do not satisfy Factor 5 regardless of scale.

• ✓ Domestic AI compute facility deployed through multinational technology partnership or cross-border supply arrangement: documented participation from entities in other jurisdictions establishes cross-jurisdictional activity through the cross-border participation itself, not inference from strategic significance
• ✗ Domestically funded and equipped AI compute facility serving domestic users: strategic significance to national or bloc-level AI capability does not satisfy Factor 5 without documented cross-border participation or explicit cross-bloc effect in primary sources, regardless of facility scale

4.5 Qualification Threshold

Part A events must demonstrate significance on 2+ of 5 factors (as defined in Section 4.4). This multi-factor requirement prevents single-dimension outliers and aligns with Basel G-SIB methodology.

4.6 Worked Examples

Worked Example 1: QUALIFIES (5/5 factors)

Major Economy Advanced Technology Export Controls

Basel 5-Factor Assessment:

• ✓ Factor 1 (Size): Affects $5B+ trade annually
• ✓ Factor 2 (Interconnectedness): Disrupts competing bloc supply chain dependencies
• ✓ Factor 3 (Substitutability): Affects irreplaceable advanced node capabilities
• ✓ Factor 4 (Complexity): Controlled technology involves extreme technical complexity — advanced-node semiconductor manufacturing requires multi-year development cycles, specialised lithographic equipment, and sub-10nm process engineering
• ✓ Factor 5 (Cross-jurisdictional): Affects coordination across multiple nations and blocs

FACTORS MET: 5/5
QUALIFICATION: ✓ Part A event (High Confidence)

Geopolitical Significance: Export controls represent coordinated effort to restrict competing bloc’s access to advanced semiconductor capabilities, fundamentally reshaping global AI supply chains and accelerating reduced technological interdependence between blocs.

Worked Example 2: DOES NOT QUALIFY (1/5 factors)

Corporate AI Research Partnership Announcement

Basel 5-Factor Assessment:

• ✓ Factor 1 (Size): $1B partnership value
• ✗ Factor 2 (Interconnectedness): No cross-border dependencies created
• ✗ Factor 3 (Substitutability): Not unique (many similar partnerships exist)
• ✗ Factor 4 (Complexity): Not cutting-edge (standard collaboration model)
• ✗ Factor 5 (Cross-jurisdictional): Bilateral corporate arrangement only, no broader coordination impact

FACTORS MET: 1/5
QUALIFICATION: ✗ Does NOT qualify - Insufficient geopolitical significance

Rationale for Exclusion: Whilst large in scale, this partnership creates no strategic dependencies, represents commodity collaboration, and has no measurable impact on bloc-level AI coordination dynamics or observable fragmentation patterns.

4.7 Documentation Requirements (Part A Events)

For each Part A event that qualifies via Basel 5-Factor Assessment:

Required in Database:

1. Basel factor assessment (which factors met, with evidence) — recorded in the event’s basel5 array (per-factor factor, pass, rationale)
2. Justification for 2+ factors (specific metrics/examples)
3. Confidence level for each factor (High/Medium/Low)
4. Cross-reference to primary sources supporting factor assessment

Format Template:

BASEL 5-FACTOR ASSESSMENT (Part A - Physical Infrastructure):

Factor 1 (Size): ✓/✗ [One sentence justification with metric]
Factor 2 (Interconnectedness): ✓/✗ [One sentence justification]
Factor 3 (Substitutability): ✓/✗ [One sentence justification]
Factor 4 (Complexity): ✓/✗ [One sentence justification]
Factor 5 (Cross-jurisdictional): ✓/✗ [One sentence justification]

FACTORS MET: X/5
QUALIFICATION: ✓/✗ Part A event (meets 2+ factors)

GEOPOLITICAL SIGNIFICANCE JUSTIFICATION:
[2-3 sentences explaining bloc-level impact and global coordination dynamics]

Quality Check:

• All Part A events MUST have Basel assessment documented
• Events failing Basel (0-1 factors) MUST be excluded (with reason noted)
• Basel assessment MUST be verifiable by independent analyst

4.8 Part B: Software/Platform Infrastructure (Route-Based Assessment)

Software and platform infrastructure qualifies via any ONE of four routes; the assessment is recorded in the event’s routeBased array (per-route factor, pass, rationale):

ROUTE 1: Official Critical Infrastructure Designation

Definition: Platform designated by authoritative governmental or international regulatory body as critical infrastructure.

Recognised Authorities:

United States: - CISA Systemically Important Entities (SIEs): Designated under National Security Memorandum 22 - CISA Critical Software: Software on CISA’s authoritative list per Executive Order 14028

European Union: - Digital Markets Act (DMA) Gatekeepers: Platforms meeting cumulative criteria (€7.5B turnover OR €75B market cap, 45M monthly users AND 10K yearly business users, sustained 3 years) - NIS2 Directive Essential Entities: Critical infrastructure operators designated by EU member states - DORA Critical ICT Providers: ICT service providers designated critical by European Supervisory Authorities

The designation frameworks listed above constitute the recognised authorities for Route 1; additions require a methodology version amendment.

Evidence Required: - Official designation letter or published list entry - Current status (not expired/revoked) - Specific services/platforms designated (not just parent company)

For empirical derivation: See Methodology Rationale, Section 4.4.

Route 1: Applicability by Jurisdiction

Methodology: Route 1 qualification relies on publicly documented official critical infrastructure designations.

Western Bloc jurisdictions: US CISA Systemically Important Entities (SIE) and EU Digital Markets Act Gatekeeper designations provide publicly accessible official classification.

Eastern Bloc jurisdictions: Comparable official designations exist in regulatory frameworks (such as PRC Critical Information Infrastructure Operator/CIIO classification), but specific entity lists are not publicly accessible. Where official designation lists are not publicly available, Route 1 qualification cannot be verified through WEO’s evidence-only methodology.

Implication: Eastern Bloc software platforms qualify for WEO database via Routes 2, 3, or 4. Route 1 qualification requires publicly verifiable official designation.

Methodological note: This constraint reflects variations in public disclosure regimes across jurisdictions and does not constitute an assessment of underlying governance quality or regulatory effectiveness. WEO’s evidence-only standard requires publicly verifiable documentation; where such documentation is unavailable, alternative verification routes apply.

For empirical derivation: See Methodology Rationale, Section 4.4.

ROUTE 2: Investment-Based Infrastructure Scale

Definition: Platform demonstrates capital intensity characteristic of infrastructure assets through documented investment.

Bloc Neutrality: Investment includes private venture capital, corporate investment, AND government/state investment programmes. State investment sources include: CHIPS Act allocations, Made in China 2025 initiative funding, In-Q-Tel investments, sovereign wealth fund allocations, national development bank financing, and equivalent state-backed capital deployment mechanisms. This ensures Route 2 captures both Western private-capital platforms and Eastern state-backed platforms equivalently.

Two-Tier Threshold System:

Tier A: $100M+ (Automatic Qualification) - ≥$100M total capital invested (equity + debt), OR - ≥$100M annual recurring revenue (ARR) - Precedent: Institutional infrastructure fund minimum deal sizes (Blackstone, Brookfield, KKR, sovereign wealth funds)

Tier B: $50M-$99M (Requires Supporting Criterion) - ≥$50M total capital invested (equity + debt), OR - ≥$50M annual recurring revenue (ARR) - PLUS must meet 1+ Route 3 criterion (below)

Criterion 3C does not satisfy this requirement as the sole supporting criterion; 3C requires an additional Route 3 criterion, and that constraint applies when 3C serves as Route 2B support. - Precedent: Government infrastructure programmes (Canadian NRCan, EU Cohesion Policy, US DOD) - Rationale: Captures emerging platforms whilst maintaining rigour through multi-criteria requirement

Evidence Required: - SEC filings showing total funding raised - Verified Crunchbase/PitchBook investment records - Public company financial statements (market cap, revenue) - Analyst reports (Gartner, IDC) validating ARR - Platform-specific investment (not parent company conglomerate totals)

Open Source / Hybrid Platforms: For platforms without traditional investment data: - Foundation funding (Linux Foundation, CNCF, Apache Software Foundation) - Corporate engineering investment (FTE developers × time × engineer compensation) - Combined ecosystem investment across contributing companies - However: Open source primarily qualifies via Route 3 (dependencies)

Note: For threshold relationships between software and physical infrastructure qualification, see Section 3.7 (Coordination Criteria and Verification Thresholds), specifically the ‘Note on Threshold Relationships’ subsection.

For empirical derivation: See Methodology Rationale, Section 4.4.

ROUTE 3: Multi-Criteria Assessment (2+ Required)

Definition: Platform demonstrates systemic essentiality through MULTIPLE characteristics (any 2+ qualifies):

Criterion 3A: Technical Dependencies (≥10,000 Dependents) - ≥10,000 documented packages/projects directly dependent on software

Precedent: - npm registry empirical analysis: 10,000 dependents = top 0.1-1% of 1.5M packages, natural distributional gap separating infrastructure from libraries - PyPI top 1% downloads designation (≈3,500 critical packages requiring mandatory 2FA) - Linux Foundation CII Census II top 200-500 packages per ecosystem

Measurement Sources: - npm: Package page dependent counts or libraries.io API - PyPI: Top 1% downloads percentile - GitHub: Dependency insights graph (limitation: excludes private repos) - Other ecosystems: Package manager statistics or libraries.io cross-ecosystem data

For empirical derivation: See Methodology Rationale, Section 4.4.

Criterion 3B: Market Concentration (≥50% Market Share) - ≥50% market share in clearly defined relevant market, sustained 2-3 years

Precedent: - US Sherman Act Section 2: <50% typically no monopoly power; ≥50% raises concern - EU Article 102 TFEU: <40% dominance unlikely; ≥50% rebuttable presumption; ≥70% super-dominance - Precedent cases: US v. Microsoft (>90% PC OS), US v. Google (90-95% search)

Market Definition Requirements: - Narrow, function-specific markets (e.g., “mobile operating systems” not “computing devices”) - Geographic scope specified (global, US, EU, or defined market) - Two-sided market considerations (assess concentration on relevant side) - Avoid overly broad definitions artificially reducing calculated share

Evidence Required: - Third-party market research (Gartner, IDC, Statista) - Regulatory filings with market share disclosures - Government competition authority reports (FTC, DOJ, European Commission) - Court findings in antitrust proceedings - Transparent methodology (revenue-based, unit-based, user-based)

For empirical derivation: See Methodology Rationale, Section 4.4.

Criterion 3C: Organisational Dependencies (≥10,000 Organisations)

• ≥10,000 documented organisations critically dependent on platform, OR
• Platform serves ≥10% of entities in defined critical infrastructure sector

Precedent: Limited explicit precedent. Adapts EU Digital Markets Act 10,000 yearly active business users threshold by analogy.

Evidence Required: - Documented customer counts (company disclosures, analyst reports) - Enterprise customer lists, government contracts - Marketplace statistics indicating organisational integration - Evidence must show critical dependency (core operational integration), not casual usage

LIMITATION ACKNOWLEDGED: This criterion has weakest authoritative precedent of all WEO infrastructure qualification criteria. Therefore, WEO requires organisational dependency PLUS at least one additional Route 3 criterion (minimum 2 total criteria).

Criterion 3D: Official Technical Designation - Designated “critical” or “core infrastructure” by authoritative technical body

Qualifying Designations: - Linux Foundation Core Infrastructure Initiative (CII) Census II inclusion - Open Source Security Foundation (OpenSSF) Securing Critical Projects designation - PyPI Critical Packages (top 1% downloads, ≈3,500 packages requiring mandatory 2FA) - GitHub Advisory Database critical package designation

Evidence Required: - Official inclusion on recognised lists with documentation - CII Best Practices Badge (Passing/Silver/Gold) plus Census II inclusion - OpenSSF designation letter - PyPI critical package list verification - Current designation (not revoked)

Multi-Criteria Rationale: Requiring 2+ criteria prevents single-dimension outliers from misclassification: - Utility library with 15,000 dependencies but low strategic impact fails organisational test - Platform with 40% market share + strong organisational dependencies qualifies despite missing 50% threshold - New critical package with 8,000 dependents but PyPI critical designation + emerging market concentration qualifies

Precedent: EU DMA requires cumulative satisfaction of revenue AND user AND duration criteria. OpenSSF Criticality Score weights 10 factors rather than single metric.

For empirical derivation: See Methodology Rationale, Section 4.4.

Routes 1–3 Summary Table

Qualification Logic: Platform/model must satisfy Route 1, Route 2, Route 3 (with 2+ criteria), OR Route 4 (any one criterion). Routes are independent — any ONE qualifies.

Route 3: Eastern Bloc Platform Examples

The following Eastern Bloc platforms qualify via Route 3 criteria:

Gitee (码云): - PRC equivalent to GitHub - Qualifies via: 3A (dependencies — primary code hosting for PRC open-source ecosystem) + 3B (market concentration — dominant position in PRC developer market) - Measurement source: Gitee public statistics, CNCF China ecosystem reports

ModelScope (魔搭): - Alibaba Cloud AI model platform - Qualifies via: 3A (dependencies — 1,000+ hosted models with downstream integrations) + 3C (organisational dependencies — enterprise adoption across PRC AI ecosystem) - Measurement source: ModelScope platform statistics, Alibaba Cloud disclosures

cnpm (China npm mirror): - npm registry mirror for PRC developer ecosystem - Qualifies via: 3A (dependencies — serves as primary npm access point for PRC developers) - Note: Requires additional Route 3 criterion for qualification; typically paired with 3C (organisational dependencies across PRC enterprises) - Measurement source: cnpm registry statistics, Alibaba open-source reports

Hugging Face China Mirror: - Model hub mirror serving PRC AI ecosystem - Qualifies via: 3A (dependencies — derivative models and fine-tunes) + 3C (organisational dependencies — PRC enterprise and research institution usage) - Measurement source: Mirror access statistics where available

For empirical derivation: See Methodology Rationale, Section 4.4.

ROUTE 4: Open-Source AI Model Distribution

Route 4 accommodates both open-source models (weights publicly available) and closed-source models (API-only access). Each accessibility type has four parallel qualification criteria (4A-4D for open-source, 4A-CS to 4D-CS for closed-source). Determine accessibility classification first (see “Accessibility Classification” below), then apply the relevant criteria set.

Definition: AI model distributed under open-source or open-weight licensing demonstrating significant adoption and coordination impact.

Qualification Logic: Any ONE of four criteria (4A-4D) qualifies.

Criterion 4A: Download Threshold

Threshold: - ≥100M cumulative downloads, OR - ≥10M downloads per month sustained over 3+ months

Precedent: - EU Digital Markets Act: 45M monthly active users threshold for gatekeeper designation - WEO applies ≈2× multiplier (100M) for AI-specific context where downloads ≠ active users - Sustained monthly threshold (10M/month × 3 months) captures rapid adoption patterns

Measurement Sources: - Hugging Face download statistics (primary) - GitHub release download counts - PyPI/npm package download statistics for model wrappers - Papers with Code model tracking

Criterion 4B: Geographic Reach

Threshold: - Documented adoption across BOTH Western Bloc AND Eastern Bloc jurisdictions, OR - Deployment evidence in ≥20 countries across ≥3 continents

Precedent: Geographic bifurcation patterns indicate cross-bloc coordination significance. Models deployed across bloc boundaries create coordination dynamics regardless of download volume.

Measurement Sources: - Hugging Face geographic statistics (where available) - Enterprise customer disclosures - Government procurement records - Academic citation geographic distribution

Evidence Required: - Geographic download/deployment statistics from measurement sources - Government/institutional adoption across jurisdictions - Language localisation patterns indicating multi-bloc targeting

Criterion 4C: Ecosystem Integration

Threshold: - ≥10,000 documented derivatives, fine-tunes, or dependent models, OR - Demonstrable institutional integration (≥100 enterprises OR ≥50 government/research institutions)

Precedent: - Route 3A dependency threshold (≥10,000 dependents) applied to AI model ecosystem - Institutional threshold adapted from DMA business user criteria

Measurement Sources (derivatives): - Hugging Face model cards (base_model field) - Papers with Code derivative tracking - GitHub repository forks and adaptations

Evidence Required (institutional integration): - Enterprise integration announcements or case studies - Academic paper citations using model as foundation

Criterion 4D: Institutional Adoption

Threshold: - Documented deployment by ≥3 government agencies or critical infrastructure operators across ≥2 countries, OR - Adoption by ≥10 Fortune Global 500 companies

Precedent: Institutional adoption signals coordination significance beyond consumer usage. Government and enterprise deployments create durable dependencies.

Measurement Sources: - Government procurement databases (SAM.gov, TED) - SEC filings and earnings transcripts - Industry analyst reports (Gartner, Forrester, IDC)

Evidence Required: - Official government procurement or deployment announcements - Enterprise earnings call mentions or annual report disclosures - Regulatory filings indicating model integration

ACCESSIBILITY CLASSIFICATION

Purpose: Determine whether a qualified AI model event follows open-source or closed-source treatment for magnitude calculation.

Decision Tree:

Is model architecture/weights publicly available for download?
    │
    ├─ YES: Are weights available under recognised open-source 
    │       or open-weight licence?
    │       │
    │       ├─ YES → OPEN-SOURCE TREATMENT
    │       │        (Apply Route 4 open-source criteria: 4A-4D)
    │       │
    │       └─ NO (weights available but restrictive licence)
    │            → OPEN-SOURCE TREATMENT with licence notation
    │
    └─ NO: Is model accessible only via API?
            │
            ├─ YES → CLOSED-SOURCE TREATMENT
            │        (Apply Route 4 closed-source criteria: 4A-CS to 4D-CS)
            │
            └─ Model not publicly accessible
                 → Does not qualify for WEO database

Open-Source Indicators: - Model weights downloadable from Hugging Face, GitHub, or equivalent - Licence permits inspection, modification, or redistribution (MIT, Apache 2.0, Llama 2 Community, etc.) - Community fine-tuning and derivative creation observable

Closed-Source Indicators: - API-only access (no weight distribution) - Proprietary architecture with no public documentation - Terms of service prohibit reverse engineering or extraction

Hybrid Cases: - Models with “open weights” but restrictive commercial terms → Open-source treatment (weights are observable) - Models with partial open-sourcing (base open, fine-tunes closed) → Classify by primary distribution model - Research-only releases with no publicly accessible weights or API → Does not qualify (no public access pathway; the decision tree terminal exclusion applies)

ROUTE 4: Closed-Source AI Equivalents (4A-CS to 4D-CS)

Definition: Closed-source AI models accessible only via API, demonstrating equivalent coordination significance to open-source models.

Qualification Logic: Any ONE of four criteria qualifies.

Criterion 4A-CS: User Base

Threshold: - >100M monthly active users (MAU) → Automatic qualification - 50M-100M MAU → Qualifies with 4B-CS OR 4C-CS

Precedent: - EU Digital Markets Act: 45M monthly end users threshold - WEO applies ≈2× multiplier (100M) for automatic qualification - 50M-100M range requires supporting criterion to prevent borderline misclassification

Measurement Sources: - Similarweb traffic estimates - data.ai (formerly App Annie) mobile app statistics - Company earnings disclosures - Third-party analyst reports (Sensor Tower, Statista)

Criterion 4B-CS: Geographic Reach

Threshold: - Available in ≥150 countries, OR - Available in ALL G7 nations + documented Eastern Bloc presence (PRC, Russia)

Precedent: Geographic availability indicates cross-bloc coordination significance. The G7 + Eastern Bloc test captures strategic positioning even for models with restricted geographic access.

Evidence Required: - Official availability statements - Documented geographic restrictions (app store, API terms of service) - Evidence of Eastern Bloc availability (API access from PRC, Russia, etc.)

Criterion 4C-CS: Enterprise Integration

Threshold: - Composite assessment across three dimensions: 1. Fortune 500 enterprise adoption (≥50 documented customers) 2. Government/defence contracts (≥3 agencies across ≥2 countries) 3. API ecosystem (≥1,000 registered developers OR ≥100 published integrations)

All three dimensions must be met.

LIMITATION ACKNOWLEDGED: Closed-source enterprise integration is less observable than open-source metrics. Composite assessment prevents single-dimension gaming whilst maintaining rigour.

Evidence Required: - SEC filings and earnings call transcripts - Government procurement databases (SAM.gov, TED) - Platform developer documentation - Industry analyst enterprise surveys (Gartner Magic Quadrant, Forrester Wave)

Criterion 4D-CS: Capability Threshold

Threshold: - ≥1B parameters (documented or credibly estimated), AND - Frontier performance on recognised benchmarks (top 10 on MMLU, HumanEval, or equivalent)

Precedent: Capability threshold captures models with significant coordination impact regardless of commercial adoption metrics. Parameter count + benchmark performance provides observable proxy for frontier status.

Measurement Sources: - Model cards and technical documentation - Academic papers and preprints - Benchmark leaderboards (Hugging Face Open LLM Leaderboard, Papers with Code)

Evidence Required: - Parameter count from official documentation or credible estimate - Benchmark scores from recognised evaluation frameworks - Publication date to establish frontier status at time of release

Route 4 Summary Table

Qualification Logic: Any ONE criterion qualifies. Criteria are independent pathways.

For empirical derivation: See Methodology Rationale, Sections 4.4-4.5.

4.9 Part C: Policy and Institutional Events (PISA-5 Assessment)

Purpose and Scope

PISA-5 (Policy and Institutional Significance Assessment) provides a 5-factor qualification framework for determining whether single-jurisdiction AI policy and institutional events warrant inclusion in WEO’s measurement indices.

Gap Addressed: Single-jurisdiction AI policy and institutional events that: - Pass the Two-Stage AI Connection Filter - Have NO physical infrastructure nexus (Basel inapplicable) - Do NOT involve software/model release (Software Routes inapplicable) - Are single-jurisdiction (Keohane Pre-Filter multi-nation inapplicable)

Event Types Covered: - National AI regulatory frameworks - National AI safety institutions - Comprehensive AI governance legislation - AI-specific regulatory authorities

Rationale: Framework design adapts established precedents from international law (Vienna Convention binding/voluntary distinctions), regulatory analysis (GDPR extraterritoriality model), and institutional assessment methodologies (FSB financial centre classifications). See Methodology Rationale Document for detailed empirical grounding.

Pre-Filter Triage

Before applying PISA-5, confirm event routing:

1. Confirm event passes Two-Stage AI Connection Filter
2. Is this a multi-nation coordination event? 
   → YES: Route to Keohane Pre-Filter (auto-qualify) → Skip to Tier Classification
   → NO: Continue
3. Does this involve significant physical infrastructure?
   → YES: Route to Part A (Basel 5-Factor)
   → NO: Continue
4. Is this a software/model release?
   → YES: Route to Part B (Software Routes)
   → NO: Continue
5. Is this a single-jurisdiction policy or institutional event?
   → YES: Route to Part C (PISA-5)
   → NO: Route to editorial review — assess via most
         applicable Part A/B/C framework on a case-by-case basis

The Five Factors

Factor 1: Jurisdictional Significance (F1)

Definition: The originating jurisdiction possesses sufficient economic weight, technological leadership, or geopolitical standing to render its AI governance policies inherently significant at the global level.

J-Tier Structure:

J-Tier A Jurisdictions (explicit): - G7 members: United States, United Kingdom, France, Germany, Italy, Canada, Japan - China - European Union (for EU-level regulations distinct from member state policies)

J-Tier B Jurisdictions (G20 excluding J-Tier A): - India, Brazil, Australia, South Korea, Mexico, Indonesia, Turkey, Saudi Arabia, Argentina, South Africa, Russia

J-Tier C Criteria (AND logic — BOTH required): - GDP >$500B (nominal, World Bank/IMF data), AND - Top-20 AI developer status per Stanford HAI Global Vibrancy Tool

AI Developer Metric: - Primary source: Stanford HAI Global Vibrancy Tool (default weights) - Supplementary source: Tortoise Global AI Index (for jurisdictions outside Stanford’s 36-country coverage) - Threshold: Positions 1-20 in the primary source (Tortoise consulted only for jurisdictions outside Stanford’s 36-country coverage)

Excluded: - Sub-national jurisdictions (regardless of economic size) - International organisations without legislative/regulatory authority

The African Union is assessed at J-Tier E. Although the AU holds G20 membership, it does not exercise binding legislative or regulatory authority over member states’ AI governance and is subject to the international-organisation exclusion. The EU’s J-Tier A listing reflects its binding legislative authority, not G20 membership alone.

Evidence Required: - GDP data: World Bank or IMF most recent publication - AI ranking: Stanford HAI most recent edition (or Tortoise for jurisdictions outside Stanford’s coverage), with specific ranking position cited

Factor 2: Regulatory Scope and Binding Authority (F2)

Definition: The policy creates legally binding obligations with credible enforcement mechanisms affecting a substantial portion of the AI ecosystem within its jurisdiction.

Threshold (BOTH conditions required):

Condition A — Binding Status: - Policy contains mandatory language (“shall,” “must,” “required”) - AND specifies enforcement mechanisms (monetary penalties, licence revocation, prohibitions, or criminal sanctions)

Condition B — Scope:

• Policy applies across multiple AI system categories (not single sector)
• OR establishes new regulatory authority/mandatory registration regime

Evidence Required: - Legislative/regulatory text showing: (1) mandatory language in operative provisions, (2) penalty amounts or enforcement authority designation, (3) scope/applicability clauses

Note on assessment object for non-regulatory events: Condition A (binding status) assesses whether the policy creates binding obligations on parties within the AI ecosystem — companies, developers, operators, or deployers. An executive order, appropriation act, or ministerial directive that is binding on a government agency does not satisfy Condition A unless the resulting obligations extend to AI ecosystem participants. Programme-execution evidence — contracts signed, joint ventures constituted, administrative facilitation — does not satisfy binding-status requirements; these are implementation activities, not binding obligations on regulated parties. Spending commitments and investment programmes that create no mandatory compliance obligations on AI ecosystem participants fail Condition A regardless of programme scale; the designed pathway for such events is the tiebreaker (TB1–TB5).

Examples: - ✓ PASS: Cross-sectoral AI regulation with €35M+ penalties - ✓ PASS: Generative AI measures with mandatory registration and enforcement authority - ✗ FAIL: Voluntary ethics guidelines (no penalties) - ✗ FAIL: Advisory AI safety institution (no regulatory authority)

Factor 3: AI Centrality (F3) — MANDATORY GATING FACTOR

Definition: AI is the primary subject of the policy rather than an incidental mention within broader legislation.

CRITICAL: Failing Factor 3 results in automatic disqualification regardless of other factors.

Threshold (EITHER structural indicator sufficient):

Structural Indicator A — Title/Definitions: - “Artificial intelligence,” “AI system,” “machine learning,” or equivalent term appears in policy title - OR policy establishes AI-specific definitions in dedicated definitions section

Structural Indicator B — Dedicated AI Requirements: - Policy creates AI-specific obligations (risk assessment, transparency, testing, incident reporting) - OR creates AI-specific institutional structure (board, registry, authority, sandbox)

Evidence Required: - Policy title, table of contents, definitions section, and substantive provisions from official legislative text

Examples: - ✓ PASS: “Artificial Intelligence Act” with AI-specific risk classification - ✓ PASS: “Generative AI Measures” with AI-specific content labelling requirements - ✗ FAIL: Data protection regulation with automated decision-making provision (AI not primary subject) - ✗ FAIL: Copyright directive with single AI/text-mining exception (AI incidental)

Coverage note: Application-agnostic Policy instruments controlling physical materials or technology products under general-purpose regulatory frameworks — export controls, materials restrictions, technology licensing regimes — will typically fail F3 because the instrument’s primary subject is the controlled material or technology, not AI. This pattern applies across both blocs for the upstream supply chain instrument class: Chinese critical materials controls, US BIS specification-based semiconductor controls, and EU Critical Raw Materials Act provisions all exhibit the same application-agnostic design. Where such events reach QC4 via PIET (§3.5.1), they route to Part A (Basel 5-Factor), not PISA-5. See §4.11: Structural Visibility Asymmetry.

Pathway exemption. Events qualifying through AI Connection pathways that establish AI infrastructure relevance through pathway-specific evidence requirements — Option F (Defence Appropriation Evidence, §3.5) and Option G (Supply-Chain Response Evidence, §3.5) — satisfy F3 by virtue of the pathway’s evidence. Each pathway requires documentary demonstration that the event’s AI infrastructure relevance is real and evidenced to primary source standard; this pathway-specific evidence is functionally equivalent to the AI centrality assessment F3 performs. F3 is not separately assessed for events qualifying through these pathways.

This exemption reflects a structural feature of the event classes these pathways serve: defence appropriations and supply-chain response instruments are inherently application-agnostic — the instrument text addresses the programme or the material, not the downstream application. F3’s structural indicators (AI in title, AI-specific definitions, AI-specific obligations) will systematically fail for these event classes regardless of the events’ genuine AI infrastructure significance. The pathway-specific evidence requirements prevent this structural mismatch from excluding documented AI infrastructure coordination dynamics.

Pass logic for F3-exempt events: For events exempt from F3 via this provision, PISA-5 is assessed on the remaining four factors (F1, F2, F4, F5). The pass logic for exempt events is:

The F1+F2 double-fail exclusion rule operates independently of the ≤1/4 exclusion rule. Both may apply simultaneously (e.g., an event passing only F4 triggers both ≤1/4 and, if F1 also fails, F1+F2 double-fail). Both rules are assessed; the outcome is exclusion regardless of which rule applies first.

The tiebreaker mechanism (TB1–TB5) applies to marginal cases under the same criteria as standard PISA-5. Tiebreaker outcomes are recorded in the event’s tiebreaker object (triggered, triggerReason, assessment, result).

Factor 4: Enforcement and Accountability (F4)

Definition: The policy contains credible mechanisms to ensure compliance and impose consequences for non-compliance.

Threshold (ANY ONE sufficient): - Specific penalty provisions with quantified amounts (monetary fines, percentage of turnover) - Named regulatory authority with explicit investigative/enforcement powers - Mandatory reporting, auditing, or certification requirements with specified deadlines - Private right of action for affected parties

Evidence Required: - Penalty articles, regulatory authority designation clauses, compliance timeline provisions, or standing/remedies provisions from official text

Note on assessment object for non-regulatory events: F4 assesses enforcement mechanisms over external parties — companies, developers, operators, or deployers — not internal programme governance. Budget authority, procurement mandates, staffing authority, and internal programme management powers are characteristics of institutional operation, not enforcement mechanisms over the AI ecosystem. Internal military or ministerial command authority does not satisfy F4 unless the institution holds enforcement jurisdiction over parties outside the establishing ministry or agency.

Examples: - ✓ PASS: €35M/7% turnover penalties with designated enforcement authority - ✓ PASS: Administrative enforcement with service suspension powers - ✗ FAIL: International AI principles (no enforcement mechanism) - ✗ FAIL: Advisory institution (no sanctions)

Factor 5: International Relevance (F5)

Definition: The policy has documented cross-border implications or triggers international coordination mechanisms.

Threshold (ANY ONE sufficient):

• Explicit extraterritorial provisions (affects foreign entities placing products/services in jurisdiction)
• Cross-border data, model, or compute flow restrictions
• Mutual recognition, equivalence, or adequacy decision framework for third countries
• Formal initiation of bilateral/multilateral coordination mechanism with another major AI jurisdiction
• Explicit implementation of international AI standard or agreement

Evidence Required:

• Extraterritoriality provisions, cross-border transfer rules, adequacy clauses, or official announcements of coordination mechanisms

Examples: - ✓ PASS: Regulation applying to providers outside jurisdiction placing on domestic market - ✓ PASS: AI safety institution with bilateral agreements and multilateral coordination role - ✗ FAIL: Regulatory measures with primarily domestic application - ✗ FAIL: Domestic-only voluntary guidelines

Pass/Fail Logic

Automatic Qualification (QUALIFY)

An event qualifies if EITHER: 1. ≥4 of 5 factors pass, OR 2. Factors 1, 2, and 3 ALL pass (regardless of F4/F5)

Automatic Disqualification (EXCLUDE)

An event is excluded if EITHER: 1. Factor 3 fails (AI Centrality — mandatory gate), OR 2. Both Factors 1 AND 2 fail (neither significant jurisdiction nor regulatory scope)

Exception: Events qualifying through Option F (Defence Appropriation Evidence) or Option G (Supply-Chain Response Evidence) are exempt from F3 per the pathway exemption (§4.9). For these events, the pass logic in the pathway exemption provision governs — see §4.9, Factor 3.

Marginal Cases (HUMAN REVIEW)

Events passing exactly 3 factors (including F3) but NOT meeting automatic qualification routes to Human Review.

Decision Summary:

F3 pathway exemption: For events qualifying through Option F or Option G (§3.5), F3 is not separately assessed. These events use the adjusted pass logic defined in §4.9, Factor 3 (pathway exemption), which assesses four factors (F1, F2, F4, F5) with ≥3/4 required for qualification.

PISA-5 Assessment by Event Subtype

The following examples illustrate how F2 (Regulatory Scope and Binding Authority) and F4 (Enforcement and Accountability) apply across four event subtypes. The tiebreaker (TB1–TB5) routes non-regulatory events that fail F2 and F4 to assessment on resource commitment, institutional permanence, and international relevance rather than regulatory character.

Subtype 1 — Regulatory instrument:

Regulatory instruments with mandatory language, specified penalties, and designated enforcement authority satisfy F2 and F4 through their operative text. F2 and F4 definitions are written for this class.

• ✓ Cross-sectoral AI regulation with mandatory compliance obligations, quantified penalties, and designated enforcement authority with investigative powers

Subtype 2 — Institution:

Institutions are assessed on the obligations they create for AI ecosystem participants, not the legal character of the establishing instrument.

• ✓ Institution with statutory authority to impose binding requirements on AI developers — mandatory pre-market testing, registration obligations, or conformity assessment with designated enforcement powers over non-compliant parties
• ✗ Advisory institution with voluntary participation arrangements — the establishing instrument may be binding on the creating government agency, but no binding obligations extend to AI ecosystem participants. Correct pathway: 3/5 marginal → tiebreaker (TB1–TB5)

Subtype 3 — Spending/investment programme:

Spending commitments and investment programmes are assessed on whether they create mandatory compliance obligations on AI ecosystem participants, not on programme-execution activities.

• ✗ National AI compute investment programme creating no mandatory compliance obligations — contracts, joint ventures, and procurement are programme execution, not F2/F4 satisfaction. Correct pathway: 3/5 marginal → tiebreaker (TB1–TB5)

The tiebreaker is the designed pathway for significant spending programmes that lack regulatory character. TB1 (Resource Commitment) and TB2 (Institutional Permanence) assess the dimensions most relevant to this event class.

Subtype 4 — Defence programme:

Defence institutions and programmes are assessed on the same F2/F4 criteria as civilian events — enforcement jurisdiction over external parties, not intra-ministry command authority.

• ✗ Defence AI programme operating within a single ministry’s command structure with no enforcement jurisdiction over external parties — internal procurement mandates and budget authority do not satisfy F4. Correct pathway: 3/5 marginal → tiebreaker (TB1–TB5)

Defence programmes of high strategic significance that fail F2/F4 route to the tiebreaker, where TB1 (Resource Commitment) and TB2 (Institutional Permanence) are designed to capture them.

AI Hub Exception (J-Tier D)

Purpose: Accommodates AI-significant jurisdictions that do not meet standard J-Tier A/B/C thresholds but have demonstrated importance to global AI development.

Qualification Criteria (≥2 of 4 required):

Administration: - WEO maintains published list of Designated AI Hubs, updated annually - Designation valid for 24 months; requires requalification - Changes announced 6 months before implementation

Human Review Framework

Trigger

Event passes exactly 3/5 factors (including mandatory F3) but does not meet automatic qualification (≥4/5 or F1+F2+F3).

For F3-exempt events (Option F or Option G qualification, §4.9): the marginal trigger is exactly 2/4 factors passed with F1+F2 not both failing. The same tiebreaker checklist (TB1–TB5) applies.

Tiebreaker Checklist (TB1-TB5)

CRITICAL DISTINCTION FOR TB1: The $15M threshold is for annual operating budget (recurring yearly expenditure), NOT one-time capital investment. This differs from Part A Basel Factor 1 ($500M+) and Chapter 3: Event Verification, Section 3.7 ($100M), which apply to capital investment in infrastructure projects.

Rationale: The $15M annual operating budget threshold is derived from analysis of AI governance institution budgets, validated against established infrastructure classification frameworks. See Methodology Rationale Document for detailed empirical grounding.

Decision Rule

• ≥3/5 tiebreaker criteria met → QUALIFY
• ≤2/5 tiebreaker criteria met → REJECT
• Exactly 3/5 with reviewer uncertainty → ESCALATE to senior reviewer

Dual Reviewer Requirement

1. Lead analyst completes initial assessment with full checklist
2. Independent second analyst reviews without knowledge of initial decision
3. Concordant decisions: Final
4. Discordant decisions: Escalate to senior reviewer

Temporal Safeguards

• Seasoning requirement: Policy changes require 6+ months operational evidence before qualification
• Cooling-off period: Rejected events ineligible for reassessment for 12 months absent material change

Worked Examples

Note: The following are theoretical examples demonstrating the PISA-5 qualification methodology. Actual verified events are documented in the WEO Events Database with full assessments.

Worked Example 1: Major Western Bloc Regional AI Framework

Result: 5/5 → QUALIFIES

Worked Example 2: Major Eastern Bloc Economy Generative AI Measures

Result: 4/5 → QUALIFIES

Worked Example 3: G7 Nation AI Safety Institution

Result: 3/5 (including F3, but not F1+F2+F3) → HUMAN REVIEW

Tiebreaker Assessment:

Tiebreaker: 5/5 → QUALIFIES

Worked Example 4: Small Nation Voluntary AI Ethics Guideline

Result: F1+F2 both FAIL → EXCLUDED (automatic disqualification)

Worked Example 5: Sub-National AI Legislation

Result: EXCLUDED (sub-national jurisdictions do not enter PISA-5)

Rationale: Sub-national policies do not represent sovereign-level bloc coordination dynamics measurable by WEO’s methodology.

Documentation Requirements (PISA-5 Events)

The factor assessment is recorded in the event’s pisa5 array (per-factor factor, pass, rationale).

For each event assessed via PISA-5:

Required in Database:

1. Five-factor assessment (F1-F5 with PASS/FAIL for each)
2. Evidence citations for each factor determination
3. J-Tier classification (A/B/C/D/E) with supporting data
4. Confidence level (HIGH/MEDIUM)
5. For marginal cases: Complete tiebreaker checklist (TB1-TB5)

Format Template:

PISA-5 ASSESSMENT (Part C - Policy/Institutional Event):

Factor 1 (Jurisdictional): ✓/✗ [J-Tier X — One sentence justification]
Factor 2 (Regulatory Scope): ✓/✗ [One sentence justification]
Factor 3 (AI Centrality): ✓/✗ [One sentence justification]
Factor 4 (Enforcement): ✓/✗ [One sentence justification]
Factor 5 (International): ✓/✗ [One sentence justification]

FACTORS PASSED: X/5
QUALIFICATION: ✓/✗/⚠️ [Qualifies / Excluded / Human Review]

If Human Review triggered:
TIEBREAKER ASSESSMENT: [TB1-TB5 results]
FINAL DETERMINATION: [Qualifies / Rejected]

GEOPOLITICAL SIGNIFICANCE JUSTIFICATION:
[2-3 sentences explaining policy/institutional impact on AI coordination dynamics]

Part C Summary: PISA-5 Qualification

Purpose: Qualify single-jurisdiction AI policy and institutional events for WEO database

Five Factors: - F1: Jurisdictional Significance (J-Tier A/B/C/D/E) - F2: Regulatory Scope and Binding Authority - F3: AI Centrality (MANDATORY GATE — exempt for Option F/G events per §4.9) - F4: Enforcement and Accountability - F5: International Relevance

Qualification Logic: - ≥4/5 factors OR F1+F2+F3 → QUALIFIES - F3 fails OR F1+F2 both fail → EXCLUDED - Exactly 3/5 (incl. F3) → HUMAN REVIEW - F3-exempt events (Option F/G): ≥3/4 factors → QUALIFIES; 2/4 marginal → HUMAN REVIEW (see §4.9)

Critical Principle: All events in WEO database have passed Qualification Criterion 4 (QC4). PISA-5 ensures policy and institutional events meet the same geopolitical significance standard as physical infrastructure (Part A) and software/platform (Part B) events.

4.10 Qualification Criterion 4 Summary

Keohane Pre-Filter (Multi-Nation Coordination):

• ✓ Automatic qualification
• No Part A/B/C assessment required
• Events proceed directly to Tier Classification
• Examples: Multilateral AI safety declarations, bilateral technology partnerships, ISO/IEC standards, regional governance frameworks

Rationale: Multi-nation coordination auto-qualifies because the coordination itself demonstrates geopolitical significance — two or more sovereign entities making observable policy adjustments through mutual accommodation inherently signals strategic importance for a coordination index.

Part A — Physical AI Infrastructure (Basel 5-Factor):

• ✓ Must pass Basel 2+ factors
• Requires documented assessment
• Examples: Major economy semiconductor incentive programmes, national AI compute initiatives, advanced technology export controls

Part B — Software/Platform Infrastructure (Route-Based):

• ✓ Must meet one of four routes
• Route-specific criteria apply
• Examples: Foundation models, critical software platforms, AI APIs with significant adoption

Part C — Policy and Institutional Events (PISA-5):

• ✓ Must pass 4/5 factors OR F1+F2+F3
• ✓ F3-exempt events (Option F/G, §4.9): must pass 3/4 factors (F1, F2, F4, F5)
• Single-jurisdiction policy/institutional events
• Examples: National AI regulatory frameworks, AI safety institutions, comprehensive AI governance legislation

Critical Principle: All events in WEO database have passed Qualification Criterion 4 (QC4) — geopolitically significant. Events that fail assessment are excluded during verification, not included as “low significance” events.

4.11 Structural Visibility Asymmetry

Structural Description

WEO’s qualification framework requires verifiable evidence from official primary source documentation. This standard is appropriate, reproducible, and applied consistently across all blocs. It produces asymmetric coverage in practice — but the asymmetry is more nuanced than a simple East-West divide. Three distinct sources operate independently.

Instrument design. Materials controls, export licensing regimes, and dual-use technology restrictions are application-agnostic by regulatory convention — across both blocs. Chinese critical materials controls (MOFCOM Announcement No. 23/2023, gallium/germanium; No. 33/2024, antimony) list controlled items by HS code without specifying downstream applications. Western upstream instruments exhibit the same pattern: US BIS semiconductor controls (October 2022) define controlled items by technical specification thresholds without AI-specific operative provisions; the EU Critical Raw Materials Act sets extraction and recycling benchmarks without specifying AI as an end-use; US Defense Production Act mineral invocations reference energy and defence applications with no AI language. Where an instrument is application-agnostic by design, Stage 2 Options A, B, and C cannot be satisfied from documentary sources alone — regardless of issuing bloc. This is a structural feature of the upstream supply chain instrument class, not of either bloc’s disclosure regime.

AI governance instruments, by contrast, name AI explicitly in their titles, definitions, and operative provisions — in both blocs. China’s CAC Interim Measures for Generative AI Services, Deep Synthesis Provisions, and Algorithm Recommendation Regulations all carry AI-specific titles, definitions, and substantive provisions. Western equivalents (EU AI Act, US Executive Orders on AI) do the same, though with substantially denser documentation ecosystems — impact assessments, published consultation records, and institutional commentary that Chinese regulatory architecture does not produce in comparable volume.

Documentation landscape beyond the current verification approach. A documentation layer exists within Chinese-language databases, government portals, and platform-integrated channels that is beyond the reach of WEO’s current verification protocols (§3.3): academic analysis on CNKI, legal commentary on PKU Law/北大法宝, government procurement records on ccgp.gov.cn, provincial implementation details, think tank reports from CAICT and CCID, and regulatory intelligence via platform channels such as WeChat public accounts. Established translation intermediaries — DigiChina (Stanford), CSET (Georgetown), China Law Translate, ChinAI Newsletter — provide partial English-language coverage of this material. WEO’s verification approach employs advanced translation systems and region-specialist research tools to extend reach into non-English documentation, but full access to this layer requires native-language proficiency, platform integration, and familiarity with the Chinese regulatory information ecosystem — capabilities that these tools do not fully replicate. This is most significant for AI infrastructure events, where provincial-level documentation contains granular AI-specific evidence including intelligent computing centre designations, hardware procurement specifications, and computing power subsidy programmes.

Regulatory process architecture. Chinese regulatory architecture produces structurally less public documentation than Western equivalents as a systemic feature: no published regulatory impact assessments, no published consultation responses, shorter operative texts, and less institutional commentary infrastructure. These categories of documentation are absent because they are not produced — not because they exist in Chinese and are inaccessible. This reduces documentation density for Chinese AI governance instruments compared to Western counterparts, even when Chinese-language sources are fully accounted for.

A subset of regulatory instruments within jurisdictions exhibiting this regulatory process architecture is issued as internal administrative guidance or communicated through informal regulatory channels and produces no publicly accessible instrument text. In these cases the instrument exists but is unpublished — a distinct condition from documentation categories that are not produced.

Consequence for Database Coverage

The combined effect of these three sources produces directional under-representation of Eastern Bloc events, with the composition varying by instrument class.

For materials and export control events, the primary source of under-representation is instrument design: the documentation required for Stage 2 qualification does not exist in the operative text, in any language, in either bloc. PIET (§3.5.1) was designed specifically for this instrument class.

For AI infrastructure events, the primary source of under-representation is the documentation landscape beyond the current verification approach: AI-specific documentation — including MIIT intelligent computing centre designations and provincial deployment records — exists within Chinese-language databases and government portals that WEO’s current verification protocols do not fully reach.

For AI governance events, under-representation is modest. Chinese AI governance instruments carry explicit AI-specific language that satisfies Stage 2 qualification. The remaining gap reflects thinner regulatory process documentation — fewer impact assessments, less published consultation — which affects the depth of verification context but not Stage 2 qualification itself. For the unpublished-instrument subset documented above, neither §3.1 verification nor documentary Stage 2 qualification is available from official sources.

Users interpreting WEO data should treat Eastern Bloc event coverage as a conservative lower bound on actual Eastern Bloc AI infrastructure activity — verified coverage rather than estimated coverage. This is a deliberate analytical choice. Every event in the WEO database meets WEO’s evidentiary standard. The directional under-representation reflects the combined effect of instrument design conventions, the current reach of WEO’s verification approach, and regulatory process differences — not a data quality issue.

Methodology Response

WEO addresses the asymmetry through mechanisms corresponding to each source.

Instrument design (Stage 2 qualification pathways):

PIET — Post-Implementation Evidence Track (§3.5.1) establishes AI connection at Stage 2 for Policy restriction events on physical AI-critical materials or physical technology products, via post-implementation empirical evidence — trade flow disruption, commodity price movement, government policy responses, and named entity corporate disclosures — where official primary documentation contains no AI-specific language. PIET is scope-bounded: it applies to physical materials and physical technology products with HS-code-trackable trade flows only.

OEP — Operational Evidence Protocol (§3.5 Option D) establishes AI connection at Stage 2 for Infrastructure events where official documentation is absent, generic, or application-agnostic, via technical output analysis, product-type designation, or hardware deployment evidence. OEP is scope-bounded: it applies to Infrastructure events only and is not available to Policy, Coordination, or Corporate events.

Option F — Defence Appropriation Evidence (§3.5, Option F) establishes AI connection at Stage 2 for Policy events where binding defence appropriation documents contain explicit AI designations with stated monetary values. Option F addresses the structural condition where post-implementation operational detail moves behind classification barriers but the upstream financial commitment is public. Option F is scope-bounded: it applies to Policy events only and requires both explicit AI designation and a quantified financial commitment in the appropriation instrument.

Option G — Supply-Chain Response Evidence (§3.5, Option G) establishes AI connection at Stage 2 for Policy events where the instrument controls, secures, subsidises, or stockpiles a material that is a documented input to AI infrastructure manufacturing or operation, and Options A, B, and C fail because the instrument text addresses the material rather than AI. Option G addresses the symmetric counterpart to PIET: where PIET qualifies restriction events through post-implementation trade flow evidence, Option G qualifies response events (minerals strategies, subsidy frameworks, stockpile legislation) through pre-existing materials science and supply-chain documentation. Option G is scope-bounded: it applies to Policy events only and requires documented AI infrastructure relevance at primary source standard.

Documentation landscape (verification protocols):

Enhanced non-English verification protocols (§3.3) specify minimum evidence standards, third-party confirmation requirements, and confidence scoring for events where primary sources are not in English. WEO’s verification approach employs advanced translation systems and region-specialist research tools alongside established translation intermediaries to extend verification reach into non-English documentation ecosystems. The methodology also incorporates Chinese regulatory architecture directly — including the MIIT tripartite classification framework (§3.5, OEP Pathway C), Chinese authority hierarchy and linguistic markers for Coordination Connection classification (§9.5), and non-Western standards pathway validation for Framework Family connections (§9.2.1).

Regulatory process architecture (accepted limitation):

The structurally thinner documentation produced by regulatory processes that do not generate published impact assessments or consultation records — currently documented for Chinese regulatory architecture — is a permanent feature of the affected jurisdictions’ documentation landscapes that the methodology accepts. If additional jurisdictions exhibit structurally similar regulatory process architecture, the same accepted limitation applies.

Regulatory process architecture (convergent implementation evidence accommodation):

Where the regulatory process architecture gap extends to unpublished instruments — issued as internal administrative guidance or communicated through informal regulatory channels — standard §3.1 sources cannot verify the affected events because the issuing authority produces no publicly accessible documentation of them. Where no state media report meeting the state media accommodation’s conditions is available, a second accommodation addresses this evidence configuration.

This accommodation applies to Policy events where all five of the following conditions are met:

1. The issuing jurisdiction exhibits the regulatory process architecture documented in the Structural Description above, including the unpublished-instrument condition.

2. A documented search of the issuing jurisdiction’s official gazettes, government portals, and legal databases has not located a published instrument text. The search and its findings are recorded in the event’s verification documentation.

3. Implementation is confirmed by qualifying sources from three or more source categories. Qualifying categories: regulated financial disclosures, wire service reports citing named sources, government-affiliated think tank analysis, official trade data, customs enforcement actions, and industry trade publications. The category count is met only by sources institutionally independent of one another — sources from the same outlet, or from outlets owned by the same parent organisation, contribute to the category count once. Official trade data and customs enforcement actions, classified as supplementary sources under §3.1, are accepted in the corroborating source role within this accommodation.

4. At least one source is an accountability-bearing disclosure — a regulated financial filing subject to securities law (the regulated financial disclosure categories enumerated at §3.5 Option E) or an audited corporate report subject to securities regulation. The accountability-bearing disclosure must confirm the event’s existence and must characterise the event in terms that would satisfy the AI Connection Filter (Options A, B, or C) if the same language appeared in the instrument’s operative text. The accountability-bearing disclosure functions as the primary source for §3.1 purposes; the remaining convergent sources function as corroborating sources under the standard §3.1 source quality hierarchy.

5. Observable effects reported across the qualifying sources are mutually consistent. No contradictory evidence exists regarding the event’s existence, scope, or AI infrastructure relevance.

Dual-purpose evidence: Convergent evidence satisfying conditions 3–5 simultaneously satisfies §3.1 event verification and establishes AI connection at Stage 2 (Substantive AI Connection, §3.5) — confirming both the event’s existence and implementation (§3.1) and its AI infrastructure relevance through the condition 4 disclosure language. See §3.4.11 for confidence assessment guidance.

This accommodation is available only after standard §3.1 sources, the state media accommodation, PIET (§3.5.1), and all Stage 2 Options (A through G) have been assessed and found inapplicable, with documented rationale for each. The assessment and its findings are recorded in verification documentation.

Remaining coverage gap. Policy events in categories excluded from PIET (investment screening, data governance, security technology controls, researcher mobility restrictions) represent the primary source evidence boundary of the documentation-based methodology. These exclusions are correct: for these event classes, the evidence required for qualification does not exist in publicly verifiable form, except where the convergent implementation evidence accommodation’s conditions are met.

WEO documents what has verified primary source evidence. Where such evidence does not exist, the correct outcome is exclusion — not inference.

Relationship to Event Verification

The source accommodations documented in this section modify what constitutes a qualifying primary source for §3.1 event verification purposes.

State media accommodation. For events where structurally thinner regulatory process architecture in the issuing jurisdiction produces insufficient documentation for Tier A claims under §3.1, state media with official documentary function is accepted as primary evidence under the following conditions:

• The outlet operates with documented state editorial oversight in the issuing jurisdiction (e.g., Xinhua, China Daily, Global Times in the Chinese regulatory context, or equivalent outlets in other jurisdictions)
• The report attributes a specific statement to a named official at an identified central government ministry or equivalent authority
• The attribution is verifiable — the report identifies the official by name and institutional role

General editorial content, commentary, or unattributed reporting from these outlets does not qualify. This accommodation is specific to the documentary function role and does not elevate all content from qualifying outlets to primary status.

Convergent implementation evidence accommodation. For Policy events where the instrument is unpublished and no state media report meets the conditions above, convergent evidence from independent sources, including an accountability-bearing disclosure, is accepted as primary evidence under the five conditions specified in the Methodology Response above. The convergent evidence simultaneously establishes event existence (§3.1) and AI infrastructure relevance at Stage 2 (Substantive AI Connection, §3.5). This accommodation is available only after standard §3.1 sources, the state media accommodation, PIET (§3.5.1), and all Stage 2 Options (A through G) have been assessed and found inapplicable, with documented rationale for each.

Where §4.11-accommodated sources are the sole or principal basis for Tier A claims, the verification assessment should record this and specify which accommodation type applies. See §3.4.11 for confidence term guidance.

Cross-reference: §2.8 (Explicit Limitations) for the broader set of scope limitations accepted by the documentation-based methodology. §3.1 (Source Accommodations) for the summary pointer. §3.3 (Non-English Source Verification Protocol) for verification approach. §3.4.11 (Verification Assessment for Accommodated Sources) for consolidated confidence guidance. §3.5.1 (PIET), §3.5 Option D (OEP), §3.5 Option F (Defence Appropriation Evidence), and §3.5 Option G (Supply-Chain Response Evidence) for the Stage 2 qualification pathways.

End of Chapter 4: Geopolitical Significance Assessment

Chapter 5: Tier Classification

5.1 Purpose

This chapter provides the framework for classifying verified events into one of three tiers based on coordination scale: cross-bloc coordination (Tier 1), between-bloc fragmentation (Tier 2), and intra-bloc coordination (Tier 3).

5.2 Three-Tier Architecture

Tier Definitions

Methodology Scope Note: At V1.5 publication, tier classification implements a binary bloc structure (Western Bloc and Eastern Bloc), with Non-Aligned nations classified to either bloc per event based on dominant partnership characteristics. The underlying tier architecture — Cross-Bloc (T1), Between-Bloc (T2), and Intra-Bloc (T3) — is designed to accommodate future bloc formations as power structures evolve. Corporate blocs, regional blocs, infrastructural blocs, or hybrid formations could be incorporated through methodology extension without requiring fundamental architectural changes. This design prioritises methodological durability over current-state specificity.

5.3 Principal AI Actors

Definition

A principal AI actor (PAA) is a nation or supranational entity that satisfies three independent conditions:

1. Capability breadth (Gate 1) — the actor demonstrates dominant or independently significant capability across three or more of the seven AI infrastructure dimensions defined below.
2. Ecosystem independence (Gate 2) — the actor can sustain its met dimensions without access to any single PAA’s ecosystem inputs, as assessed through the severance test defined in §5.3.1.
3. Sustainable platform provision (Gate 3) — the actor holds at least one platform dimension (D4 Cloud AI Compute or D5 Frontier AI Model Development) that would remain at its qualifying level under the per-PAA severance scenarios assessed in Gate 2.

All three conditions are necessary. An actor meeting the capability threshold but failing the ecosystem independence or sustainable platform tests receives a different designation under the Actor Designation Framework defined below. The three-gate structure and its four resulting designations are specified in full in §5.3.1.

The seven AI infrastructure dimensions assessed under Gate 1 are:

1. AI accelerator design (merchant training-relevant silicon)
2. Advanced semiconductor fabrication (≤7nm production nodes)
3. Semiconductor manufacturing equipment (lithography, deposition, etching, metrology)
4. Cloud AI compute services (hyperscale data centre clusters for AI training and inference)
5. Frontier AI model development (state-of-the-art foundation models with general applicability)
6. AI-specific regulatory authority with extraterritorial reach (enforceable compliance frameworks governing AI systems across jurisdictions)
7. Sovereign AI infrastructure investment at scale (national programmes directing capital towards AI compute, fabrication, or infrastructure capacity)

Any combination of three or more dimensions satisfies Gate 1. The per-dimension qualification principles, including specific boundary conditions, control tests, and edge-case resolution, are defined in §5.3.2.

Actor Designation Framework

Actors assessed against the seven dimensions are classified through the three-gate designation structure defined in §5.3.1:

• Principal AI Actor (PAA) — ecosystem anchor: ≥3 dimensions met, per-PAA severance test passed, and at least one sustainable platform dimension (D4 or D5)
• AI Infrastructure Keystone (AIK) — structural chokepoint leverage within an ecosystem without providing the ecosystem itself: ≥3 dimensions met, per-PAA severance test passed, no sustainable platform dimension
• Advanced Capability State (ACS) — significant sovereign capabilities that the actor cannot sustain autonomously under withdrawal of a PAA’s ecosystem inputs: ≥3 dimensions met, per-PAA severance test failed
• Participant — actors scoring fewer than 3 dimensions, operating within ecosystems shaped by PAAs and AIKs

The Actor Designation Framework distinguishes actors that anchor AI infrastructure ecosystems (PAAs) from actors that hold structural leverage within those ecosystems (AIKs), actors with significant but dependent capabilities (ACSs), and actors operating within the ecosystem landscape (Participants). The distinction between PAA and AIK is analytically significant: an AIK’s withdrawal would disrupt a PAA’s supply chain, but would not create an alternative ecosystem.

Current actor designations, dimension scores, and the full Sovereign Capability Profiles Register are published as versioned snapshots per the register process defined in §5.3.3. The current determination reflects assessed capability as of July 2026.

Relationship to Sovereign Capability Profiles

The PAA designation and the Sovereign Capability Profiles are actor-level data layers. They are analytically related to, but independent of, the event-level classifications (Tier, Bloc, Event Type, Domain) documented in Chapters 3–5. An actor’s capability score does not determine the tier or bloc classification of events in its territory. A Participant scoring 0/7 may host T2 events of high structural significance; a PAA scoring 6/7 may host routine T3 events. The two layers operate at different units of analysis and answer different questions:

• Events answer: what is occurring in the AI infrastructure coordination landscape?
• Sovereign Capability Profiles answer: what does each actor independently control?

The T1 Cross-Bloc Coordination gate (§5.4) continues to require verified adoption or implementation by the principal AI actor of each of at least two distinct ecosystems. Only actors holding the full PAA designation (all three gates satisfied) qualify as “principal AI actors” for T1 classification purposes. AI Infrastructure Keystones and Advanced Capability States do not satisfy this requirement.

Application to Tier Classification

T1 Cross-Bloc Coordination requires verified adoption or implementation by the principal AI actor of each of at least two distinct ecosystems. The following Keohane Type 2 (Institutional Consensus Standard) example illustrates the verification process; the same principal actor requirement applies uniformly across all Keohane types and event types.

Development participation in international bodies — including P-member voting in standards organisations — constitutes evidence of engagement but does not alone satisfy the adoption or implementation requirement. National adoption, verified through national standards databases or equivalent documentation, is required.

For Keohane Type 2 events, the relevant verification is whether the standard has been adopted as a national standard by the principal AI actor of each of at least two distinct ecosystems:

• US-centred ecosystem: Adoption by the United States or verification that the standard is implemented within the US-centred ecosystem through national standards body adoption or operational certification schemes
• China-centred ecosystem: Adoption as a Chinese national standard (GB or GB/T, verified through openstd.samr.gov.cn) or verified operational implementation within the China-centred ecosystem

Where a standard is developed with cross-bloc participation but adopted only within one ecosystem, the event is classified at the tier appropriate to its actual adoption footprint — typically T3 with the implementing bloc.

The principal actor verification applies uniformly across all event types and Keohane types. For Keohane Type 1 (formal agreements, bilateral partnerships, institutional establishments), the test assesses whether the principal AI actors of at least two distinct ecosystems have verified adoption or implementation through direct participation — institutional membership by non-principal members does not substitute for principal actor engagement. This uniform application ensures that “cross-bloc” carries the same analytical meaning regardless of the coordination mechanism through which it is achieved.

Event type eligibility: The principal actor requirement applies to tier classification, not event type determination. All event types other than Policy events are structurally eligible for T1 classification provided the T1 three-criterion test is met with verified adoption or implementation by the principal AI actor of each of at least two distinct ecosystems. Policy events cannot satisfy Criterion 1 because their unilateral mechanism (§3.6) precludes cross-bloc participation.

Relationship to qualification pathways: Qualification pathway (Keohane, Basel, Route-Based, PISA-5) and tier classification are independent, sequential assessments. The principal actor requirement is a tier classification criterion, not a qualification criterion. However, the T1 three-criterion test (cross-bloc participation, binding status, material integration) is functionally coordination-equivalent — any event meeting all three criteria inherently possesses coordination characteristics regardless of its qualification pathway.

T2 scope. The principal actor requirement does not extend to T2 Between-Bloc Fragmentation. T1 measures ecosystem-level integration, requiring engagement by the principal AI actor of each of at least two distinct ecosystems. T2 measures structural separation between blocs, where significance is determined by the structural effect rather than the identity of the actor creating it. Structural separation can originate from any actor with sufficient supply-chain leverage, regulatory reach, or infrastructure capacity — including actors designated below PAA level (AIK, ACS, or Participant). The T2 qualification frameworks (Basel 5-Factor thresholds, PIET impact evidence, Mandatory Standard enforcement test) directly measure structural significance, making a principal actor gate redundant for T2 classification. The theoretical basis for this T1/T2 asymmetry is documented in the Methodology Rationale (§5.4, T2 Scope).

Review Mechanism

Reassessment of Principal AI Actor designations and Sovereign Capability Profiles follows the register process defined in §5.3.3. The assessment methodology — seven-dimension framework with Gate 1 capability threshold, three-gate designation structure, and per-dimension qualification principles — remains stable across assessment cycles; the actor designations and dimension scores reflect assessed capability at each assessment point. Per-dimension qualification principles, including quantitative thresholds, are subject to research-based recalibration at methodology version milestones to maintain analytical discrimination as the global AI infrastructure landscape evolves.

The methodology accommodates bloc formation from within existing blocs. The event classification permanence rule preserves the historical alignment record: events retain their original bloc classification permanently. Where a transition occurs, Coordination Connections can document the pathway — recording, for example, how regulatory capacity preceded and enabled hardware independence through applicable connection types (e.g., CC Type 4 Regulatory Enablement, CC Type 6 Framework Family, CC Type 3 Funding Flow).

5.3.1 Principal AI Actor Designation: Three-Gate Structure

The Principal AI Actor (PAA) designation requires satisfaction of three independent gates:

Terminology note: “Ecosystem inputs” (defined below under Severance Test Criteria) is a technical term denoting the specific inputs a PAA provides to actors within its ecosystem and can deny through sovereign jurisdiction or extraterritorial regulatory instruments. “Ecosystem” used without “inputs” in this section refers to the general AI infrastructure ecosystem concept — the full technology landscape anchored by a PAA.

The three gates in this designation structure (Gate 1, Gate 2, Gate 3) are distinct from and unrelated to the three-tier event classification system (T1, T2, T3) defined in §5.2.

Gate 1 — Capability threshold. The actor meets ≥3 of the 7 dimensions defined in §5.3, as assessed through the qualification principles in §5.3.2.

Gate 2 — Ecosystem independence (severance test). The actor can sustain its met dimensions without access to any single PAA’s ecosystem inputs (as defined below).

Gate 3 — Sustainable platform dimension. The actor holds at least one sustainable platform dimension (D4 or D5) — a dimension that provides the ecosystem substrate upon which other actors’ AI capabilities operate. A dimension is “sustainable” for Gate 3 purposes if it would remain at its qualifying level — as defined by the dimension-specific qualification principle in §5.3.2 — under each per-PAA severance scenario tested in Gate 2. A dimension that is currently met but would degrade below its qualification threshold under withdrawal of a PAA’s ecosystem inputs does not satisfy Gate 3.

Example: An actor meeting D4 through compute clusters built with foreign-designed accelerators holds D4 at the assessment date. However, if the PAA’s ecosystem inputs — including the accelerator supplier’s products — were withdrawn, the actor could not refresh or expand its compute infrastructure to maintain frontier training capability within the severance window. D4 is met for Gate 1 but is not sustainable for Gate 3.

All three gates are necessary for PAA designation. The three-gate structure produces a four-designation classification:

• An actor scoring ≥3, passing the per-PAA severance test, AND holding a sustainable platform dimension is classified as a Principal AI Actor (PAA) — an ecosystem anchor.
• An actor scoring ≥3, passing the per-PAA severance test, but holding NO sustainable platform dimension is classified as an AI Infrastructure Keystone (AIK) — an actor with structural chokepoint leverage within an ecosystem without providing the ecosystem itself (note: “keystone” follows Paine’s (1966) ecological usage — disproportionate systemic impact relative to abundance — not Iansiti & Levien’s (2004) business-strategy usage, which describes platform hub orchestrators). AIKs hold leverage over the AI supply chain (through equipment monopolies, fabrication capacity, or governance authority) but do not host the compute or model development platforms that define an ecosystem.
• An actor scoring ≥3 but FAILING the per-PAA severance test is classified as an Advanced Capability State (ACS) — an actor with significant sovereign capabilities that nonetheless operates within an ecosystem anchored by a Principal AI Actor.
• An actor scoring fewer than 3 dimensions is classified as a Participant — an actor operating within ecosystem(s) shaped by PAAs and AIKs. The dimension profile (which specific dimensions are met) carries the analytical detail for Participant-designated actors; no further subdivision is applied because the structural distinctions below the ≥3 threshold are better captured by per-dimension data than by additional designation categories.

Severance Test Criteria

The severance test is applied against each existing PAA individually. For each actor scoring ≥3 on the capability threshold, the test asks:

If access to this PAA’s ecosystem inputs were withdrawn, would the actor retain ≥3 met dimensions spanning ≥2 of the three capability categories (hardware, platform, governance) within a 24–36 month assessment window?

The actor must pass the test against each existing PAA independently. An actor that fails against any single PAA does not pass Gate 2. The test is applied separately against each PAA’s ecosystem inputs, beginning with the PAA whose ecosystem inputs the actor has the greatest structural dependency on (typically the PAA in whose bloc the actor is classified — the most challenging scenario), then against remaining PAAs. Each test is documented independently.

Ecosystem inputs defined. A PAA’s ecosystem inputs comprise: (a) goods, services, and intellectual property directly produced or controlled by entities under the PAA’s sovereign jurisdiction; and (b) goods, services, and intellectual property produced by entities outside the PAA’s jurisdiction but subject to denial through the PAA’s extraterritorial regulatory instruments (e.g., the United States Foreign Direct Product Rule, or inputs subject to direct Export Administration Regulations jurisdiction from US-based design or manufacturing activity). Inputs produced by non-PAA actors that are not subject to the withdrawing PAA’s extraterritorial controls remain available to the actor under test. The severance test withdraws ecosystem inputs as defined above; it does not withdraw all inputs originating from actors aligned to the PAA’s geopolitical bloc. These inputs constitute the underlying resources — materials, technologies, services, and legal permissions — upon which an actor’s met dimensions depend.

Dimension sustainability classifications. For each met dimension under each per-PAA severance scenario, the assessor classifies the dimension’s sustainability as one of: sustainable (no material dependency on the withdrawn PAA’s ecosystem inputs), sustained under stress (dependency exists but deterrence or domestic alternatives preserve the dimension at its qualifying level), sustained under stress with multi-vector exposure (as above, but the PAA holds multiple independent leverage points weakening the deterrence calculus), degraded-but-sustained (capability degrades under severance but remains above the qualification threshold defined in §5.3.2), or at structural risk (capability would fall below the qualification threshold). Only dimensions classified as sustainable, sustained under stress, sustained under stress with multi-vector exposure, or degraded-but-sustained count towards the ≥3 threshold in criterion 1 below. Dimensions classified as at structural risk do not count.

Deterrence principle. Where the withdrawn PAA holds sovereign jurisdiction over a subsidiary or facility of an entity headquartered in the actor under test, and the PAA’s denial of that facility’s output would materially degrade the PAA’s own access to the parent entity’s products, a mutual deterrence condition exists. Under mutual deterrence, the dependency is classified as “sustained under stress” rather than “collapsed” for severance test purposes. Each deterrence assessment must document: (a) the specific subsidiary or facility at risk, identifying its location and the PAA’s jurisdictional basis for denial; (b) the mechanism by which the PAA could deny the facility’s output (export controls, operational directives, asset freezing, or other sovereign instruments); and (c) the specific and material cost to the PAA of exercising that denial, demonstrating that the denial would be operationally self-destructive for the PAA’s own AI infrastructure capability. Where multiple independent leverage points exist for a single dependency, the assessor must evaluate whether the PAA could achieve its objectives through targeted action on any single secondary vector without triggering the self-harming consequences of disrupting the primary entity. If targeted action on a secondary vector could materially degrade the entity’s products without collapsing the PAA’s own access, the deterrence argument is weakened for that vector and the dimension should be classified as “sustained under stress with multi-vector exposure” rather than plain “sustained under stress.” The assessor must document each leverage point and its individual deterrence calculus. Where the actor under test is a supranational entity, the deterrence assessment requires that the supranational entity — not merely an individual member state — holds direct sovereign jurisdiction over the parent entity sufficient to ensure the entity’s continued operation under PAA pressure. Deterrence based on a member state’s sovereign leverage over a headquartered entity does not automatically transfer to the supranational level; the supranational entity must demonstrate its own enforceable authority over the entity’s operational decisions.

For each assessment cycle, “existing PAAs” refers to the designations from the most recent published SCP register. Current PAAs are assessed first to confirm continued qualification; remaining actors are then assessed against the confirmed PAAs’ ecosystem inputs. The PAA list is updated at the conclusion of each full assessment cycle, not during individual actor assessments.

An actor passes the severance test if:

1. At least 3 of its currently met dimensions would remain at their qualifying level — as assessed against the dimension-specific qualification principles in §5.3.2 — within 24–36 months using only domestically controlled inputs or inputs sourced from non-PAA actors whose own supply chains would remain functional under the specific PAA withdrawal being tested, AND
2. The sustainable dimensions span at least 2 of the 3 capability categories: hardware (Dimensions 1–3), platform (Dimensions 4–5), and governance (Dimensions 6–7)

Cascade analysis boundary. Cascade analysis extends one level. For each met dimension, the assessor determines whether the actor’s primary capability-sustaining entities (the entities whose capabilities form the documented basis for the dimension’s “met” assessment) directly depend on the withdrawn PAA’s ecosystem inputs (as defined above, including inputs reachable through the PAA’s extraterritorial regulatory instruments and inputs subject to direct regulatory jurisdiction from PAA-based design or manufacturing activity). Sub-tier supply chain dependencies (dependencies below the primary entity level — e.g., a primary entity’s component suppliers and their suppliers) are documented as constraints where identified but do not determine the severance verdict. Where sub-tier regulatory exposure is plausible for a capability-sustaining entity but has not been assessed, this is recorded as a documented constraint in the Sovereign Capability Profiles Register with a review trigger for future methodology versions. The single-level boundary applies equivalently when assessing whether non-PAA actors’ supply chains would remain functional under criterion 1: the assessor checks whether the non-PAA actor’s primary capability-sustaining entities directly depend on the withdrawn PAA’s ecosystem inputs, without tracing sub-tier dependencies within those entities.

The second criterion prevents an actor from qualifying as a PAA on the basis of governance and platform dimensions alone whilst possessing zero hardware independence — because hardware is the physical substrate without which platform and governance capabilities are operationally hollow in the AI infrastructure context.

The severance test is applied using the dependency documentation produced during the per-dimension capability assessment. Each dimension assessed as “met” includes documented constraints and dependencies. The severance test synthesises these dependencies to determine whether a structural collapse would occur upon withdrawal of a specific PAA’s ecosystem inputs.

Actor Classification Hierarchy

Actor designations are assessment-date snapshots of current capabilities. They are not retrospective assessments of capabilities at the time each event in the database occurred. Bloc classifications for individual events were assigned under the methodology version current at the time of entry. The Actor Designation Framework does not retroactively alter event-level classifications made under prior methodology versions.

The AIK classification is analytically significant because it identifies actors with bargaining power derived from chokepoint position rather than ecosystem provision — an AIK’s leverage operates within an ecosystem it does not anchor.

The ACS classification is informative for risk assessment: an advanced capability state faces higher “supply-chain permission risk” than a PAA or AIK, because its capability stack is structurally dependent on a relationship it does not control.

5.3.2 Dimension Qualification Principles

Epistemic Register

Principal AI Actor scoring is an analytical assessment — a structured evaluation of sovereign capability against defined criteria — rather than an event verification, which documents observable occurrences through primary source evidence. Both are rigorous and evidence-based, but they differ in kind:

• Event verification (Chapters 3–4) asks: did this occur? The answer is grounded in documented, source-verified facts.
• Capability assessment (§5.3) asks: does this actor independently control this capability? The answer requires interpretive judgement applied to verified evidence.

This distinction is acknowledged because WEO’s broader methodology prioritises epistemic transparency. A dimension assessment of “met” within a Sovereign Capability Profile represents a documented analytical judgement, supported by primary sources, not an algorithmically derived data point.

General Principles

Binary assessment. Each dimension is assessed as met or not met. There is no partial credit. Where a capability exists but is constrained or dependent on another actor, the dimension is assessed as met with the constraint documented in the actor’s profile. A constrained capability is still a capability; the constraint is analytical context, not a disqualifier for the capability assessment. Documented constraints are operative inputs to the severance test (§5.3.1), where they determine whether met dimensions would survive withdrawal of a PAA’s ecosystem inputs.

Operational, not aspirational. Dimensions are assessed against demonstrated, current, operational capability — not announced plans, signed memoranda of intent, or projected timelines. An actor that has committed investment to semiconductor fabrication but has not yet commenced volume manufacturing at ≤7nm does not meet Dimension 2. The assessment reflects the state of the world at the assessment date.

Sovereign control principle (governing rule). The control test applied to each dimension reflects the structural nature of the capability being assessed. Physical infrastructure dimensions (D2 fabrication, D4 compute) are assessed by territorial presence — the sovereign territory where infrastructure physically operates has effective control, because immovable assets cannot be relocated and the host state has jurisdiction, taxation, and nationalisation authority. Corporate capability dimensions (D1 accelerator design, D5 model development) are assessed by ownership chain — the corporate parent’s territory has effective control through strategic direction and IP ownership. D3 (equipment) applies both tests: the entity must be headquartered in the actor’s territory AND control the qualifying technology. D6–D7 (governance) are inherently sovereign. Foreign-controlled subsidiaries in ownership-chain dimensions are assessed under the parent entity’s territory unless the subsidiary demonstrably operates with strategic autonomy in the relevant dimension.

Subsidiary and acquisition clause. Where a designing, manufacturing, or operating entity is a subsidiary of a parent headquartered in another territory, or has been acquired by a foreign-headquartered parent, the dimension is assessed for the parent’s territory unless the subsidiary retains demonstrated strategic autonomy over the relevant capability direction and the core intellectual property or operational control cannot be unilaterally transferred or encumbered by the parent without host-territory regulatory approval. This clause applies to corporate capability dimensions (Dimensions 1, 3, and 5) and to the corporate capability aspects of Dimension 4 (strategic direction, IP) without overriding the D4 territorial compute requirement. Dimensions 2 and 4 use territorial presence as the primary test (see sovereign control principle above). Dimensions 6 and 7 assess sovereign governmental actions where the clause is inapplicable.

Dimension-Specific Qualification Principles

Dimension 1 — AI accelerator design. The actor hosts an entity that designs and commercially markets AI training-relevant accelerators (GPUs, TPUs, NPUs, or equivalent processors designed primarily for machine learning training workloads) as a primary product line, where the core microarchitectural design intellectual property is domestically controlled. Architecture licensing (providing foundational instruction set architectures that others use to build accelerators) does not constitute accelerator design unless the licensor also produces and markets finished training-relevant accelerators. “Commercially markets” requires the accelerator to be available for purchase or lease by third-party customers at commercially relevant quantities at the assessment date; a design that cannot be manufactured or delivered does not independently satisfy this dimension. Mobile, edge, or inference-only processors do not qualify unless they are also deployed at scale for data centre AI training. The subsidiary and acquisition clause (above) applies.

Dimension 2 — Advanced semiconductor fabrication (≤7nm). The actor operates production-capable semiconductor fabrication facilities at process nodes of 7nm or below, where production-capable means active volume manufacturing rather than research, pilot, or demonstration lines. The capability is assessed based on operational status at the assessment date. Reliance on imported equipment (including the distinction between DUV and EUV lithography) does not prevent a dimension from being met, but the dependency is documented as a constraint in the actor’s profile. Contract fabrication for foreign-designed chips qualifies — the dimension tests manufacturing capability, not chip design ownership. A fabrication facility physically located within the actor’s territory and engaged in active volume manufacturing qualifies for that territory regardless of the operating entity’s corporate domicile; where the facility is foreign-owned, the foreign ownership and any associated strategic dependencies are documented as constraints.

Dimension 3 — Semiconductor manufacturing equipment. The actor hosts entities that design and manufacture critical semiconductor production equipment — or sole-sourced subsystems and components essential to the functioning of such equipment — used in advanced (≤7nm) fabrication processes globally. The relevant equipment categories include lithography systems, thin-film deposition tools, plasma etching systems, metrology and inspection equipment, and critical optical, mechanical, or electronic subsystems thereof. A supplier is globally essential if it has no readily substitutable alternative supplier from another actor’s territory for a specific equipment function required in ≤7nm process flows. The substitutability test applies at the level of specific equipment functions essential to advanced fabrication, not at the broad category level: an actor meets this dimension if its supplier performs a function for which no alternative from another territory could substitute without significant process redesign, capability loss, or multi-year qualification delay. The subsidiary and acquisition clause applies.

Dimension 4 — Cloud AI compute services. The actor hosts hyperscale cloud providers that operate AI training and inference infrastructure as a commercially available service, where operational compute is physically present on the actor’s territory or under the actor’s direct sovereign jurisdiction. “Domestically controlled” in D4 requires operational compute on the actor’s territory, not merely corporate domicile of the parent entity. Corporate ownership of compute infrastructure entirely abroad does not satisfy D4 — the dimension tests territorial compute presence, consistent with the sovereign control principle for physical infrastructure dimensions. For this dimension, “hyperscale” means the provider operates AI compute clusters sufficient to independently train a current-generation frontier foundation model. Providers whose accelerator capacity is primarily suited to inference, fine-tuning, or small-to-medium training runs do not meet the hyperscale threshold. Operational control means the provider can independently make decisions about infrastructure deployment, customer access, and capacity allocation without contractual veto rights held by a foreign technology partner. Where a hyperscale provider is foreign-owned but operates qualifying compute on the actor’s territory, the territorial compute satisfies D4 for the host territory; the foreign ownership and any associated strategic dependencies are documented as constraints, following the same logic applied to foreign-owned fabrication facilities in D2. Cloud providers with a primarily domestic customer base qualify, but the scope limitation is noted. The subsidiary and acquisition clause applies to the corporate capability aspects (strategic direction, IP) but does not override the territorial compute requirement.

Dimension 5 — Frontier AI model development. The actor’s territory hosts organisations that develop state-of-the-art foundation models with general applicability, where the research direction, training decisions, and model intellectual property are primarily controlled from this territory. A model is “competitive with the current global frontier” if, at the assessment date, it performs within the top tier on at least three broadly recognised evaluation benchmarks spanning different capability domains (e.g., reasoning, coding, knowledge, instruction-following). “General applicability” excludes narrow, domain-specific models. Compute infrastructure dependency on another actor does not prevent the dimension from being met; the dimension tests intellectual control over model development — research direction, architecture decisions, and training methodology — not infrastructure self-sufficiency, which is assessed under Dimensions 2 and 4. The assessment notes whether frontier capability depends on compute infrastructure controlled by another actor. A model that was frontier-competitive at release but has fallen significantly behind the current frontier at the assessment date does not meet this threshold. The subsidiary and acquisition clause applies: where a model developer is a subsidiary of a parent headquartered in another territory, the dimension is assessed for the parent’s territory unless the subsidiary demonstrates strategic autonomy over model development.

Dimension 6 — AI-specific regulatory authority with extraterritorial reach. The actor enforces AI-relevant compliance frameworks that create binding obligations for entities outside its own jurisdiction, either through direct legal applicability to foreign actors (e.g., regulations that apply to any entity serving the actor’s market regardless of where that entity is based) or through export control regimes with documented extraterritorial enforcement. The dimension covers both AI-specific legislation and general-purpose regulatory or trade control frameworks whose primary documented application targets AI systems, AI compute hardware, AI models, or AI-relevant manufacturing equipment. Domestic-only AI regulation does not meet this dimension regardless of its stringency. Voluntary frameworks, non-binding guidelines, and participation in international AI governance dialogues do not qualify. The test is demonstrated enforcement capacity beyond the actor’s borders, not merely legislative ambition. Supranational entities (e.g., the European Union) are assessed as a single actor for this dimension when the regulatory framework is enacted at the supranational level with binding legal force for member states and extraterritorial applicability to foreign entities. Enforcement capacity may be evidenced by the entity’s demonstrated track record with analogous cross-border regulatory frameworks.

Dimension 7 — Sovereign AI infrastructure investment at scale. The actor operates a national or supranational programme directing significant public capital towards AI compute infrastructure, semiconductor fabrication capacity, or AI-specific physical infrastructure. “At scale” means the programme represents a nationally transformative commitment that materially affects either the global AI infrastructure landscape or the actor’s own structural position within it. The threshold is deliberately qualitative rather than a fixed monetary amount, because sovereign investment significance is relative to the actor’s economy and the programme’s structural intent. Investment channelled entirely through foreign-ecosystem partnerships — where the infrastructure is operated by, and serves the strategic interests of, a foreign actor — does not demonstrate sovereign infrastructure capability; it demonstrates ecosystem participation, which is analytically distinct. Where a national programme includes both sovereign-capability-building components and foreign-ecosystem facilitation components, the dimension is assessed based on whether the sovereign-capability-building components, taken independently, meet the “nationally transformative” threshold. Foreign-ecosystem components are documented but do not count towards the sovereignty assessment. Procurement of foreign-manufactured hardware for domestically-controlled and domestically-operated infrastructure constitutes sovereign investment; the foreign-ecosystem exclusion applies only where operational control, data governance, or strategic direction of the infrastructure rests with a foreign actor.

Cross-Dimensional Consistency Note

The “domestic control” test operates differently across dimensions by design, reflecting what each dimension structurally measures:

This variation is deliberate: a uniform “domestic control” standard applied across all dimensions would either over-credit territorial presence (treating a TSMC fab in Arizona as equivalent to American fabrication capability for all purposes) or under-credit it (denying Arizona-based fabrication capacity because the corporate parent is Taiwanese). The dimension-specific tests reflect the structural reality of how each capability type operates in the global AI infrastructure landscape. The sovereign control principle unifies these tests: physical infrastructure follows territorial sovereignty; corporate capability follows the ownership chain.

Supranational Capability Aggregation

Where a supranational actor is assessed alongside its constituent member states, a member state’s qualifying entity may also credit the supranational actor’s dimension assessment when the supranational level holds direct, enforceable jurisdiction over the qualifying entity’s relevant commercial or regulatory decisions — such as export-control authority, binding trade-policy competence, or regulatory compliance mandates exercised at the supranational level. The jurisdictional basis is documented on both entries: the member-state register entry identifies the qualifying entity as also crediting the supranational actor, and the supranational entry identifies the member-state origin of each aggregated capability. This note is symmetric with the subsidiary and acquisition clause: the subsidiary clause traces capability through the corporate ownership chain; the aggregation note traces capability through the jurisdictional chain. A single entity crediting both a member state and a supranational actor reflects nested sovereignty — the member state controls the entity’s domestic operations; the supranational level controls the regulatory or trade-policy environment governing the entity’s external market access. The aggregation rule does not create independent capability where none exists; it documents that a single qualifying entity operates under two layers of sovereign authority, each with distinct enforcement instruments and severance profiles.

5.3.3 Sovereign Capability Profiles Register

Assessments are published as a versioned register, analogous to the WEO Bloc Membership Register. Each register version includes:

• Assessment date
• Register version identifier (format: SCP-REG-NNN)
• Per-actor assessment across all seven dimensions, with source citations for each dimension assessed as met
• Documented constraints and dependencies per met dimension
• Severance test result (for actors scoring ≥3)
• Actor classification (PAA, AIK, ACS, or Participant)
• Sensitivity notes for gate-decisive sustainability classifications (see below)
• Dimension 5 benchmark declaration for the assessment cycle (see below)
• Change log from previous register version (dimensions gained or lost, with the Capability Shift Event reference where applicable)

The register is reassessed at methodology version milestones. Between scheduled reassessments, dimension changes may be recorded when a verified WEO event provides evidence that an actor has gained or lost a capability. Such interim changes are logged with the triggering event reference and incorporated into the next full register version.

Gate-decisive sensitivity notes. Wherever a Gate 2 or Gate 3 verdict depends on a single dimension’s sustainability classification — that is, where reclassifying that one dimension would change the actor’s designation — the register entry must carry an explicit sensitivity note stating: (a) the dimension concerned; (b) its current sustainability classification; (c) the classification that would flip the verdict; and (d) the monitored conditions bearing on the classification. The note is maintained at every register touch until the dependency dissolves.

Any gate-decisive sustainability classification additionally requires an explicit evidence-against-interpretation write-up — the documented evidence on each side of the classification boundary and the reasoning for the classification adopted. The boundary between adjacent sustainability classes is where analyst discretion is highest and designation consequence greatest; the write-up requirement ensures the judgement is auditable at precisely that point.

Dimension 5 benchmark declaration. Each register version must declare, as mandatory register metadata, the evaluation basis for that cycle’s Dimension 5 verdicts: the specific evaluation instruments used, their versions, and the frontier reference scores against which “top tier” was assessed. The declaration converts “broadly recognised evaluation benchmarks” into a declared, versioned basket for each cycle without freezing the methodology to instruments that will be obsolete by the next version. Where the instruments available at an assessment date cannot clearly separate top-tier models from the broader field, the reduced-confidence flag applies per the Dimension 5 qualification principle. Escalation rule: if two consecutive assessment cycles carry the reduced-confidence flag, the phrase “broadly recognised evaluation benchmarks” in the Dimension 5 qualification principle is replaced at the next methodology version with an explicit rolling-basket mechanism specifying how instruments enter and exit the qualifying basket.

Actors are eligible for inclusion in the register when at least one verified WEO event is attributable to the actor as a sovereign, or when they meet ≥1 of the seven AI infrastructure dimensions defined in §5.3.2. Attribution follows the sovereign that controls or originates the event — the national government, the supranational joint undertaking, or the convening standards body’s own institutional identity — not the physical venue: an event filed from an actor’s territory because an international body is headquartered there, or because supranational infrastructure is physically sited there, does not confer eligibility on the host nation. Eligibility permits assessment; it does not oblige it. Actors are selected for assessment batches on strategic salience, and eligible actors may remain unassessed without prejudice. This prerequisite ensures the register tracks actors within WEO’s observational scope rather than producing a comprehensive global assessment.

5.3.4 Evidence Standard for Dimension Qualification

Each dimension assessed as “met” in a Sovereign Capability Profile must be supported by verifiable source evidence meeting the minimum standard defined below. This standard ensures that dimension qualifications carry the same evidentiary rigour as WEO event verifications and coordination connection assessments, adapted to the structural nature of capability claims.

Base Standard

Minimum: 1 primary source (Grade 1 or Grade 2) + 1 corroborating source (Grade 2 or Grade 3). The corroborating source must be editorially independent of the primary source (i.e., not derived from or published by the same institution).

Source Authority Hierarchy

Grade 1 (Canonical primary instrument). National statute or regulation; official gazette entry; signed treaty; court ruling; direct benchmark output (TOP500, MLPerf); audited financial filing (SEC/EDGAR, annual report with auditor sign-off).

Grade 2 (Standardised institutional dataset or verified industry benchmark). IMF, World Bank, ITU, OECD dataset; SEMI Fab Forecast; TechInsights market share report; peer-reviewed academic publication; company investor presentation or press release with specific verifiable claims.

Grade 3 (Recognised analytical or journalistic source). IISS, Belfer, Freedom House, CSIS assessment; law-firm regulatory tracker (White & Case, Baker McKenzie, Cooley); major wire-service or financial journalism (Reuters, AP, FT, Bloomberg).

Trade press without named authorship, content aggregators, forums, and Wikipedia do not qualify at any tier. Self-reported benchmark scores without independent verification are noted as such in the source descriptor and do not satisfy the primary source requirement for Dimension 5.

Escalation Triggers

The base standard (1+1) escalates to 1+2 (1 primary + 2 corroborating) when any of the following conditions apply:

1. Opaque-regime self-reporting. The primary source is a government or state-affiliated entity from a jurisdiction with documented constraints on independent verification (press freedom indices, transparency ratings). The additional corroboration must include at least one non-government-affiliated source.
2. Contested claim. Credible published sources dispute the capability claim. The additional corroboration must address the specific point of contestation.
3. Unaudited vendor disclosure. The primary evidence is a corporate disclosure that has not been subjected to independent audit or regulatory review (e.g., self-reported benchmark results, unaudited capacity claims). The additional corroboration must include at least one source that independently verifies the specific claim.
4. No canonical instrument available. No Grade 1 source exists for the claim (common in emerging capability areas). Two Grade 2 sources, or one Grade 2 and one Grade 3, substitute for the 1+1 base.

Mandatory Source Descriptors

Each source cited in a dimension assessment must include:

• Source type (Grade 1, 2, or 3)
• Publisher/institution
• Publication date
• Specific claim supported
• Any credibility caveats (e.g., “self-reported,” “industry estimate,” “government source in opaque jurisdiction”)

This asymmetry between the event evidence standard (2+ primary, or 1 primary + 2 corroborating, per §3.1) and the dimension evidence standard (1+1 base with escalation) is deliberate. Structural capability assessments are evidenced by fewer, higher-authority sources than discrete event claims. The combination of source quantity (1+1) + authority hierarchy (Grade 1/2/3) + mandatory descriptors provides a more defensible evidence architecture than a count of three sources with no quality framework.

5.4 Tier 1: Cross-Bloc Coordination

Qualifying Criteria (ALL Three Required)

Criterion 1: Cross-Bloc Adoption or Implementation

Test: Does the event involve verified adoption or implementation by the principal AI actor of each of at least two distinct ecosystems?

Western Bloc and Eastern Bloc: See the WEO Bloc Membership Register on the WEO website for current membership. Section 3.10 documents the classification methodology for Non-Aligned nations.

Evidence Required: - Official membership lists - Participant rosters - Documented adoption or implementation by the principal AI actor of each of at least two distinct ecosystems

Example (Hypothetical):

• ✓ International AI safety treaty with 45 signatories including US, EU members, China, and Russia
• ✗ Western-aligned multilateral framework with 38 member countries (no Eastern Bloc participation)

Criterion 2: Binding or Implemented

Test: Is the coordination more than just memoranda of understanding (MOUs) or voluntary frameworks?

Must be either: - Actual commitments with adoption mechanisms, OR - Operational systems with implementation evidence, OR - Standards with formal certification schemes

Evidence Required: - Published standards/regulations - Adoption documentation - Certification bodies - Implementation records

Example (Hypothetical): - ✓ International technical standard adopted by national standards bodies across at least two distinct AI ecosystems - ✗ Voluntary AI ethics dialogue with no formal adoption mechanisms

Criterion 3: Material Integration

Test: Does the coordination create shared infrastructure, mutual vulnerability, or enforceable agreements?

Forms of Material Integration: - Shared technical specifications used across blocs - Certification schemes recognised internationally - Interoperable systems requiring cross-border coordination - Supply chain integration through common standards - Mutual recognition agreements

Evidence Required: - Cross-border implementation - Mutual recognition documentation - Shared infrastructure usage - Certification schemes operating across blocs

Example (Hypothetical): - ✓ Global AI safety certification scheme where certifications issued in Western countries are recognised in Eastern countries and vice versa - ✗ Policy dialogue producing only non-binding recommendations

Classification Guidance

Many initiatives that initially appear cross-bloc do not meet all three Tier 1 criteria:

Common Failures: - Western-only organisations lack Eastern Bloc participation - Voluntary dialogue frameworks lack binding implementation - Observer status ≠ formal participation (must have voting/decision rights)

Note: Framework withdrawals, breakdowns, or disbanding do not qualify as T1 events. If such breakdowns produce structural separation (parallel buildout, export restrictions), they may qualify as T2 fragmentation events. T1 captures coordination formation; T2 captures structural separation.

5.5 Tier 2: Between-Bloc Fragmentation

Fragmentation Types

Type: Restriction

Barriers limiting cross-bloc flows:

• Export controls (technology, equipment, materials)
• Investment restrictions (FDI screening, ownership limits)
• Technology bans
• Data localisation requirements
• Regulatory fragmentation

Type: Buildout

Parallel infrastructure development creating separate systems: - Semiconductor fabrication facilities - Data centre networks - GPU/compute clusters - Competing technical standards - Alternative governance frameworks

Tier 2 Classification Tests

Events that are not Tier 1 must be tested for Tier 2 qualification. Apply the corresponding Tier 2 test based on the event’s observable action.

T2 Restriction Test

Question: Does official policy documentation explicitly restrict other-bloc actor’s: - Access to domestic market? - Access to technology/inputs? - Investment/ownership rights? - Operations in specific jurisdictions?

Explicit Naming Requirement

Acceptable naming: - Country names: “China,” “Russia,” “United States” - Geographic references: “certain countries of concern” (if context clear) - Specific entities: Named companies or organisations - Entity list classifications: “foreign adversaries” (if defined)

NOT acceptable: - Generic: “foreign entities” (without specificity) - “National security” alone (without geographic targeting) - Implicit understanding (unstated)

Worked Example: Export Controls Classification

Event: Country A announces export controls on advanced semiconductor equipment

Document excerpt: “Export licences required for advanced lithography equipment to Country B and Country C”

Analysis: - Explicit restriction? YES (export licensing) - Named other-bloc entities? YES (Countries B and C explicitly named) - Classification: TIER 2 (Restriction)

T2 Restriction Test Logic

Explicit restriction on other-bloc actor?
  YES → Named other-bloc entity in official documentation?
    YES → TIER 2 (Restriction — Explicit-Targeting)
    NO → Policy restriction event?
      YES → See Impact-Demonstrated Pathway (below)
      NO → TIER 3 (not a Policy restriction)
  NO → TIER 3 (no explicit restriction)

T2 Restriction Test: Impact-Demonstrated Pathway

When the Explicit-Targeting test fails, T2 Restriction classification may be supported on an Impact-Demonstrated basis where cross-bloc fragmentation impact is demonstrated through other-bloc government policy responses.

Criteria — all required: - Event type is Policy restriction - T2 Restriction Explicit-Targeting test fails — no named other-bloc entity in primary official documentation - ≥2 other-bloc government primary-source policy responses within 18 months of implementation

T2 Impact-Demonstrated Test Logic

Explicit-Targeting test passed?
  YES → T2 Restriction (Explicit-Targeting) applies — stop
  NO → Event type is Policy restriction?
    YES → ≥2 other-bloc government primary-source policy responses
          within 18 months of implementation?
      YES → TIER 2 (Restriction — Impact-Demonstrated)
      NO → T2 Impact-Demonstrated fails
    NO → Impact-Demonstrated unavailable — stop

Evidence standard: Official government publications only. Each response must be contemporaneously documented as responsive to the restriction event — analyst inference from timing alone does not qualify. Qualifying response types: executive orders, official strategy documents, legislative proposals with government sponsorship, regulatory actions, official gazette publications, budget appropriations, enacted legislation. See §3.5.1, Gate 3 for additional specification.

This pathway is available to any Policy restriction event regardless of Stage 2 route. For PIET-qualified events, Gate 3 clearance produces T2 Impact-Demonstrated as a natural byproduct of qualification; the basis is recorded without requiring a separate Chapter 5 determination. For non-PIET events, T2 Impact-Demonstrated is assessed as a standalone Chapter 5 determination applying the same evidence standard.

T2 Buildout Test

Four-Criteria Framework

Meeting ONE OR MORE criteria classifies the event as Tier 2. All four need not be met.

Criterion 1: Dependency Reduction Language

Test: Explicit statement of reducing dependency on NAMED other-bloc country/region/technology.

Required elements: - Dependency/reliance reduction language - Named specific other-bloc entity - Official policy documentation

Example (Hypothetical): - ✓ “Reduce dependence on semiconductor manufacturing capacity in Country X” - ✗ “Enhance domestic semiconductor capacity” (no named entity)

Criterion 2: National Security + Other-Bloc Co-Mention

Test: “National security” (or equivalent) appears in same paragraph/section with explicit reference to NAMED other-bloc entity.

Co-location definitions: - Strongest: Same sentence - Strong: Same paragraph (3-5 sentences) - Acceptable: Same subsection (clearly related) - Too weak: Different sections

Example (Hypothetical): - ✓ “These investments are critical to national security, particularly given vulnerabilities from dependence on manufacturing capacity in Country X” - ✗ National security in Section 1, Country X in Section 5 (no co-location)

Criterion 3: Operating Restrictions on Funded Entities

Test: Funded entities explicitly prohibited or restricted from operating in or transferring technology to NAMED other-bloc jurisdiction.

Evidence required: - Prohibition or restriction (not “encouraged to avoid”) - Named specific other-bloc country/region - Binding funding terms/legislation

Example (Hypothetical): - ✓ “Recipients may not engage in significant transactions involving expansion of manufacturing capacity in Country X” - ✗ “Recipients encouraged to prioritise domestic investment” (not prohibited)

Note: This is the STRONGEST criterion - creates direct legal obligation tying funding to geographic restrictions.

Criterion 4: Supply Chain Resilience + Geographic Specificity

Test: “Supply chain resilience” (or equivalent) co-located with explicit reference to NAMED other-bloc entity creating the resilience concern.

Evidence required: - Supply chain resilience language - Named other-bloc country/region - Co-location (same paragraph/section)

Why this is WEAKEST criterion: - “Resilience” can mean many things (disasters, pandemics, logistics) - Often uses euphemistic language - May lack clear causal connection

Example (Hypothetical): - ✓ “Strengthen supply chain resilience against disruptions from geographically concentrated suppliers in Country X” - ✗ “Improve supply chain resilience” (no geographic targeting)

T2 Buildout Test Logic

Check Criterion 1: Dependency reduction + named other-bloc?
  YES → TIER 2 (stop)
  NO → Continue

Check Criterion 2: National security + co-mention?
  YES → TIER 2 (stop)
  NO → Continue

Check Criterion 3: Operating restrictions?
  YES → TIER 2 (stop)
  NO → Continue

Check Criterion 4: Supply chain resilience + named other-bloc?
  YES → TIER 2
  NO → TIER 3

Only ONE criterion needed for Tier 2.

T2 Mandatory Standard Test

Two-Condition Framework

BOTH conditions must be met for Tier 2 classification.

Condition 1: Mandatory Language

Test: Official documentation contains mandatory language: “shall,” “must,” “required,” or equivalent.

Mandatory examples: - “Organisations shall implement…” - “Entities must comply with…” - “Required for all providers…”

Voluntary examples (NOT mandatory): - “Organisations should consider…” - “Recommended best practices…” - “Encouraged to adopt…”

Condition 2: Enforcement Mechanisms

Test: Documented enforcement including fines, penalties, market access restrictions, or consequences.

Acceptable enforcement: - Specific financial penalties - Market access prohibition - Licensing revocation - Criminal penalties

Weak enforcement (may not qualify): - Reputational consequences only - Industry self-regulation - Voluntary reporting

T2 Mandatory Standard Test Logic

Check Condition 1: Mandatory language present?
  NO → TIER 3 (stop)
  YES → Continue

Check Condition 2: Enforcement mechanisms documented?
  NO → TIER 3
  YES → TIER 2

BOTH required. If either absent → Tier 3.

Fragmentation Type: Events qualifying via T2 Mandatory Standard Test are classified as Restriction (mandatory compliance requirements create barriers to non-conforming entities).

Chinese Standard Decision Rule

For events involving Chinese national standards:

GB (without /T) = Mandatory → Test for Tier 2
GB/T (with /T) = Voluntary → Automatic Tier 3

This rule applies to all Chinese standards: GB designation indicates mandatory compliance; GB/T indicates recommended guidance.

5.6 Tier 3: Intra-Bloc Coordination

Definition

Coordination occurring entirely within Western Bloc or Eastern Bloc, with no cross-bloc participation. Strengthens internal cohesion.

Qualifying Criteria

Western Bloc (WB) Tier 3: - Involves ONLY WB members - No China, Russia, or Eastern Bloc participation - May include Non-Aligned if WB-dominated partnership

Eastern Bloc (EB) Tier 3: - Involves ONLY EB members - No US, EU, or Western Bloc participation - Multilateral Eastern Bloc frameworks typically qualify as EB (major EB economies leading) - May include Non-Aligned if EB-dominated partnership

Borderline Case Verification

Critical verification step for major infrastructure, alliance, or industrial policy events:

Large-scale internal coordination initiatives may have strategic implications that create ambiguity between Tier 2 (between-bloc fragmentation) and Tier 3 (intra-bloc coordination). Before classifying such events as Tier 3, rigorously verify that they do not meet Tier 2 classification criteria.

Verification protocol:

STEP 1: Check all four Tier 2-B Buildout criteria (only ONE required for Tier 2): 1. Dependency reduction language + named other-bloc entity 2. National security + other-bloc co-mention (same paragraph/section)
3. Operating restrictions on funded entities (strongest criterion) 4. Supply chain resilience + geographic specificity

STEP 2: Check Tier 2-R Restriction criteria: - Explicit restriction + named other-bloc entity

STEP 3: Check Tier 2 Mandatory Standard criteria:

• Mandatory language (“shall,” “must,” “required”) + documented enforcement mechanisms

If ANY criterion met with verifiable evidence → Classify as Tier 2
If NO criteria met → Classify as Tier 3

Examples requiring rigorous verification:

• Infrastructure programmes with strategic or security framing
• Defence alliance deepening with strategic framing
• Technology/industrial policy initiatives mentioning national security
• Economic integration programmes referencing supply chain vulnerabilities

Classification principle:

Events qualify as Tier 2 if they meet any T2 classification test: explicit cross-bloc targeting (Restriction), demonstrated cross-bloc impact through other-bloc government responses (Impact-Demonstrated), documented dependency reduction, national security, or resilience language referencing named other-bloc entities (Buildout), or mandatory compliance requirements with enforcement mechanisms (Mandatory Standard). Only events meeting no T2 test remain Tier 3.

5.7 Classification Decision Framework

Step-by-Step Process

STEP 1: Check Tier 1 First

Cross-bloc participation (the principal AI actor of each of ≥2 distinct ecosystems)?
  NO → Step 2
  YES → Check binding + material integration
    BOTH YES → TIER 1 (stop)
    Otherwise → Step 2

STEP 2: Identify Applicable Tier 2 Test

STEP 3: Apply Tier 2 Test

• T2 Restriction Test (Section 5.5)

• T2 Buildout Test (Section 5.5)

• T2 Mandatory Standard Test (Section 5.5)

  If T2 criteria met → TIER 2

  If T2 criteria NOT met → TIER 3

  Note: For Policy restriction events failing the T2 Restriction Explicit-Targeting test, check the T2 Impact-Demonstrated Pathway (Section 5.5) before classifying as Tier 3.

STEP 4: Assign Bloc Classification

• Tier 1: Cross-Bloc
• Tier 2: WB-Led or EB-Led (based on which bloc initiated the action)
• Tier 3: WB or EB (based on bloc membership)

5.8 Non-Aligned Nation Allocation

Non-Aligned (NA) nations are classified to the current blocs (Western Bloc or Eastern Bloc) based on dominant partnership characteristics in each specific event. Apply the three-priority hierarchy defined in Section 3.10: Non-Aligned Nations - Bloc Classification:

1. Financial Backing (≥66⅔% from either bloc)
2. Critical Technology (which bloc provides core technology)
3. Strategic Leadership (which bloc initiated/leads)

AI Model Events: For technology priority, base model entity origin (headquarters jurisdiction) determines bloc classification, not deployment infrastructure. See Section 3.10 for full methodology and worked examples.

Key Principle: Same NA nation may appear in WB events, EB events, or sovereign events depending on specific partnership context.

5.9 Tier Classification Checklist

Before finalising tier classification, verify:

Tier Assignment

• Tier 1 criteria checked first (cross-bloc + binding + material integration)
• Tier assigned correctly:
  • T1: Cross-Bloc Coordination (all three Tier 1 criteria met)
  • T2: Between-Bloc Fragmentation (T2 Restriction, Buildout, or Mandatory Standard test met per §5.5)
  • T3: Intra-Bloc Coordination (no cross-bloc participation or targeting)
• If Tier 2: Fragmentation Type assigned (Buildout or Restriction; Mandatory Standard routes to Restriction per §5.5)
• Tier 3 borderline case verification completed (Section 5.6)

Evidence Documentation

• For Tier 1: Evidence documented for all 3 criteria (cross-bloc participation with principal actor verification per §5.3, binding/implemented status, material integration)
• For Tier 2 (Restritcion): Verbatim quote showing explicit other-bloc targeting
• For Tier 2 (Impact-Demonstrated): ≥2 other-bloc government primary-source policy responses documented with linkage evidence per §5.5
• For Tier 2 (Buildout): At least one of four buildout criteria documented with named other-bloc evidence per §5.5
• For Tier 2 (Mandatory Standard): Both conditions documented (mandatory language + enforcement mechanisms) per §5.5
• For Tier 3: Rationale documented for why Tier 1/2 criteria not met

Bloc Classification

• Bloc classification assigned (Cross-Bloc for Tier 1; WB-Led/EB-Led for Tier 2; WB/EB for Tier 3)
• Bloc verification timestamp recorded (bloc_at_verification)
• Bloc register version recorded (bloc_register_version)

Confidence Level - [ ] Confidence level assigned (HIGH/MEDIUM) - [ ] LOW confidence events excluded from the database

5.10 Quick Reference

Decision Tree

1. Check TIER 1 first:
   Cross-bloc (the principal AI actor of each of ≥2 distinct ecosystems) + Binding + Material Integration?
     ALL YES → TIER 1 (stop)
     Otherwise → Continue

2. Route to applicable Tier 2 test(s) based on event characteristics:
   Restriction action (export controls, bans, sanctions, market access) → T2 Restriction Test
   Infrastructure buildout with explicit cross-bloc targeting → T2 Buildout Test
   Binding standard or mandatory regulation with enforcement → T2 Mandatory Standard Test
   
   Where an event's characteristics match multiple tests,
   apply all matching tests. Any single T2 pass is sufficient.

3. Apply Tier 2 Test:
   T2 Restriction: Explicit restriction on other-bloc actor?
     YES → Named other-bloc entity?
       YES → TIER 2 (Restriction — Explicit-Targeting)
       NO → Policy restriction event?
         YES → ≥2 other-bloc government responses within 18 months?
           YES → TIER 2 (Restriction — Impact-Demonstrated)
           NO → TIER 3 (threshold not met)
         NO → TIER 3 (pathway unavailable)
     NO → TIER 3 (no explicit restriction)
   
   T2 Buildout: ONE OR MORE of 4 criteria met? (each requires named other-bloc)
     YES → TIER 2 (Buildout)
     NO → TIER 3
   
   T2 Mandatory Standard: Mandatory language + enforcement?
     YES → TIER 2 (Restriction)
     NO → TIER 3

4. Assign Bloc Classification:
   T1 → Cross-Bloc
   T2 → WB-Led or EB-Led
   T3 → WB or EB

5. Assign Confidence:
   HIGH / MEDIUM

Key Decision Rules

Chinese Standards: - GB = Mandatory → Test for Tier 2 - GB/T = Voluntary → Automatic Tier 3

Non-Aligned Nations: - Primary partner test: Financial (≥66⅔%) → Technology → Leadership - 50/50 edge case = Manual review

Tier 2 Buildout: - ONE criterion sufficient (not all 4) - Criterion 3 (operating restrictions) strongest - Criterion 4 (supply chain resilience) weakest

Tier 2 Mandatory Standard: - BOTH conditions required (mandatory AND enforcement) - If either missing → Tier 3

Tier 1: - ALL 3 criteria required (participation + binding + integration) - Cross-bloc participation must include formal roles (not observers)

For empirical derivation of tier classification criteria: See Methodology Rationale, Section 5.

End of Chapter 5: Tier Classification

Chapter 6: Domain Classification

6.1 Overview

Domain classification categorises each verified event by its primary subject matter — the thematic arena within which the event takes place. The assigned domain is recorded as domain.

The Four Domains

Why classification matters: Domain categorises the primary subject matter of each event, enabling thematic analysis across the database and providing data granularity for users seeking events within specific subject areas.

Scope Note: This guide focuses exclusively on domain assignment — determining WHAT each event is primarily about. Domain classification is independent of Event Type classification (which determines HOW the event occurred).

6.2 Domains vs Event Types

Domain classification (subject matter) is independent of Event Type classification (mechanism). See Section 2.4 for the relationship between WEO’s three classification systems (Event Type, Tier, Domain).

Infrastructure Terminology Clarification

“Infrastructure” appears in both classification systems with distinct meanings:

Classification Independence

Event Type and Domain are orthogonal classification systems:

Any combination is possible. An Infrastructure event (Event Type) can belong to any Domain; a Technology domain event can have any Event Type.

For detailed derivation: See Methodology Rationale, Section 6.

6.3 The Four Domains: Quick Reference

1. Energy/Infrastructure Domain

Key question: Is this primarily about physical capacity and buildout?

Includes: - Physical data centre construction - Chip fabrication facility construction - Power grid capacity and modernisation - Energy sourcing and access - Infrastructure siting and permitting - Compute capacity buildouts - Physical supply chain infrastructure

Excludes: Algorithm/software development

Examples:

• ✓ Major semiconductor fabrication facility construction
• ✓ Hyperscaler data centre investment programmes
• ✓ National AI infrastructure acceleration policies
• ✓ Domestic semiconductor manufacturing capacity buildouts
• ✓ National data centre strategies
• ✓ Power grid modernisation for AI workloads
• ✗ Semiconductor R&D funding programmes (that’s Technology)

2. Security Domain

Key question: Is this primarily about defence, military, or national security?

Includes: - Military AI applications - Defence partnerships and cooperation - Security-motivated restrictions - Dual-use technology controls (if security is PRIMARY motivation) - Intelligence sharing on AI - Military-civil fusion programmes

Excludes: Economic trade restrictions (unless security-motivated)

Examples: - ✓ Multilateral defence technology cooperation framework - ✓ Defence ministry AI procurement programmes - ✓ Military-civil integration AI initiatives - ✓ Intelligence alliance AI information sharing - ✓ Security-motivated chip export controls - ✗ General trade restrictions (that’s Trade domain)

3. Technology Domain

Key question: Is this primarily about computational/algorithmic capability?

Includes: - AI model development and releases - Algorithm innovations - Technical standards and protocols - Software platforms and APIs - Research collaborations on AI capabilities - Chip DESIGN and architecture (not manufacturing)

Excludes: Physical manufacturing, data centre construction

Examples: - ✓ Advanced GPU chip design and algorithm optimisation - ✓ Large language model releases - ✓ International AI technical standards - ✓ Open-source AI collaborations - ✗ Semiconductor fab construction (that’s Energy/Infrastructure) - ✗ Data centre buildouts (that’s Energy/Infrastructure)

AI Event Domain Assignment

AI-related events require explicit domain classification based on event type:

Significance: This distinction is material for analysis. Physical AI infrastructure events represent longer-term structural commitments than software events due to the durability and capital intensity of physical assets.

Decision Rule: Classify by PRIMARY activity: - Model release (major AI model releases) → Technology - Data centre construction (major cloud provider facility) → Energy/Infrastructure - Chip fabrication facility (major semiconductor fab construction) → Energy/Infrastructure - Chip design announcement (major chip architecture announcement) → Technology - AI regulatory framework → Technology unless primarily affecting physical infrastructure siting/construction

4. Trade Domain

Key question: Is this primarily about economic exchange, investment, or market access?

Includes: - Trade agreements with AI provisions - Investment treaties and flows - Market access regulations - Tariff structures - Economic partnerships - FDI screening (if economically motivated) - Cross-border service trade

Excludes: Security-motivated trade restrictions

Examples: - ✓ Bilateral trade and technology councils - ✓ Regional economic partnerships (if includes AI provisions) - ✓ Bilateral investment treaties - ✓ Cross-border AI service agreements - ✗ Security-motivated export controls (that’s Security domain)

6.4 Classification Decision Tree

Use this flowchart for each event:

START: What is this event primarily about?

├─ Physical construction/buildout? (fabs, data centres, grids)
│  └─ YES → ENERGY/INFRASTRUCTURE
│
├─ Defence, military, national security?
│  └─ YES → SECURITY
│
├─ Algorithms, models, software, technical standards?
│  └─ YES → TECHNOLOGY
│
└─ Economic exchange, investment, market access?
   └─ YES → TRADE

6.5 Common Classification Challenges

Challenge 1: Manufacturing Incentive Programme-type Policies

Question: Technology funding that enables infrastructure?

Decision rule: - If event funds R&D, design, algorithms → Technology - If event funds specific construction projects → Energy/Infrastructure

Example: - Major semiconductor incentive programme = Technology (funds R&D broadly) - Specific fab construction project = Energy/Infrastructure (specific large-scale construction)

Note on Hybrid Announcements (CapEx/OpEx Decomposition):

Announcements that bundle physical infrastructure and software components in a single headline figure (e.g., “Company X announces $20B AI investment”) require event decomposition during classification. The classification process isolates the capitalised (CapEx) portion — typically physical infrastructure, data centres, hardware procurement — from expensed (OpEx) components such as R&D and software development.

Decomposition Decision Rule: - Data centre construction, server hardware, networking equipment, power infrastructure, cooling systems → Energy/Infrastructure (CapEx) - Software development, algorithm R&D, model training costs → Technology (typically OpEx, not capitalised)

Practical Guidance: When a single announcement combines both components without breakdown, classify based on the PRIMARY announced activity. If the announcement emphasises physical buildout (e.g., “new data centre campus”), classify as Energy/Infrastructure. If the announcement emphasises capability development (e.g., “AI research initiative”), classify as Technology. Document the decomposition rationale in the event record.

Challenge 2: Export controls

Question: Trade restriction or security policy?

Decision rule: What’s the PRIMARY stated justification? - If national security → Security - If economic protection/competitiveness → Trade - If technology supply chain → Technology

Example: - AI chip export controls between blocs = Technology (primary effect is supply chain fragmentation) - But if explicitly security-motivated = Security

Challenge 3: Multi-domain events

Question: Event clearly spans 2-3 domains?

Decision rule: Identify the PRIMARY impact — the domain where the event has its greatest effect — and classify by that domain alone. Multi-domain character is acknowledged in the classification rationale where relevant.

For cases where primary impact cannot be determined, apply the tiebreaker hierarchy in Section 6.7.

Example:

• National infrastructure acceleration policy
  • CLASSIFY AS: Energy/Infrastructure (primary impact: physical buildout; the economic-competitiveness dimension is acknowledged in the classification rationale)

6.6 Domain-Typical Durability Ranges

Note: Technology domain uses 2-5 year range for classification reflecting typical algorithm and standards lifecycles. AI Software events specifically may extend to 2-7 years due to model and platform variability. Foundational protocols (e.g., TCP/IP) represent edge cases achieving 40+ years through network effects, but such durability is not observable at implementation.

Ordering Note: Technology appears above Trade despite shorter durability because the domain hierarchy reflects coordination lock-in potential, not durability alone. Technology exhibits stronger path dependence and network effects than trade agreements. See Section 6.7 for full rationale.

Durability in WEO Methodology

Durability appears in event classification:

Purpose: Determine domain assignment Key distinction: High-durability (Energy/Infrastructure, 20-60 years) vs Low-durability (Technology, 2-5 years)

This distinction is material for analysis. Physical AI infrastructure events represent longer-term structural commitments than software events due to the durability and capital intensity of physical assets.

Empirical Basis

Category: Empirically grounded (HIGH confidence for Energy/Infrastructure and Security; MEDIUM for others)

Key insight: High-durability domains (Energy/Infrastructure, Security) create structural lock-in persisting across policy cycles. Lower-durability domains (Technology, Trade) have shorter asset lifespans, though lock-in mechanisms vary — see Section 6.7 for ordering rationale.

For detailed derivation: See Methodology Rationale, Section 6.

Worked Example 1: Advanced AI Chip Export Controls

Event: Major economy implements comprehensive export controls restricting advanced AI chip sales to another bloc

Classification process:

Primary focus check: - Physical construction? ✗ No - Algorithms/software? ✓ Maybe (affects chip supply) - Defence/security? ✓ Yes (national security justification) - Economic/trade? ✓ Yes (restricts trade)

Decision tree analysis: - Event is explicitly defence/security motivated - Primary stated justification: national security - Secondary effect: trade restriction - Tertiary effect: technology supply chain

Domain classification: Security

Rationale: Primary motivation is national security (defence-related technology control), despite significant trade and technology supply chain effects.

Confidence: High

Worked Example 2: Major Semiconductor Manufacturing Incentive Programme

Event: Major economy implements comprehensive semiconductor manufacturing incentive programme allocating significant funding for R&D and production

Classification process:

Primary focus check: - Physical construction? ✓ Yes (but not primary) - Algorithms/software? ✓ Yes (R&D funding) - Defence/security? ✗ No direct defence focus - Economic/trade? ✓ Yes (competitiveness)

Decision tree analysis: - Event primarily funds R&D, design, innovation - Manufacturing incentives are secondary - Focus is technological capability development - Economic competitiveness through technology leadership

Domain classification: Technology

Rationale: Primary focus is R&D and design capability development. Whilst manufacturing incentives exist, the programme emphasises technological innovation and capability.

Confidence: Medium-High (slight ambiguity on R&D vs manufacturing balance)

Worked Example 3: Major Semiconductor Fabrication Facility Construction

Event: Major semiconductor manufacturer breaks ground on large-scale advanced chip fabrication facility in strategically important location

Classification process:

Primary focus check: - Physical construction? ✓ YES (primary) - Algorithms/software? ✗ No - Defence/security? ✗ Not primary - Economic/trade? ✓ Yes (but secondary)

Decision tree analysis: - Event is physical construction project - Specific large-scale infrastructure buildout - Creates manufacturing capacity - Economic and security benefits are outcomes, not primary activity

Domain classification: Energy/Infrastructure

Rationale: This is physical infrastructure construction. The fact that it has technology, economic, and security implications doesn’t change that the event itself is a buildout activity.

Confidence: High

Worked Example 4: International AI Safety Framework

Event: Multiple countries sign comprehensive international declaration on AI safety establishing shared principles and coordination mechanisms

Classification process:

Primary focus check: - Physical construction? ✗ No - Algorithms/software? ✓ Yes (AI safety principles) - Defence/security? ✓ Yes (safety as security) - Economic/trade? ✗ Not primary

Decision tree analysis: - Event establishes principles for AI development - Focuses on technical safety standards - International coordination on AI governance - Security dimension present but secondary

Domain classification: Technology

Rationale: Primary focus is technical standards and principles for AI development and safety. Security considerations are present but the mechanism is technical governance.

Confidence: High

6.7 Ambiguous Cases: Decision Framework

If event genuinely spans two domains equally (rare), use this tiebreaker hierarchy:

Tiebreaker priority: 1. Energy/Infrastructure — If ANY significant physical buildout component 2. Security — If ANY significant defence/national security component 3. Technology — If algorithmic/capability component 4. Trade — If economic exchange component

Ordering Principle

This hierarchy reflects coordination lock-in potential rather than strict durability ordering:

Energy/Infrastructure and Security rank highest because their events create the most persistent coordination requirements through physical and institutional lock-in.

Technology ranks above Trade despite shorter durability based on mechanism analysis. Technology standards and capability events exhibit stronger path dependence and network effects than trade agreements (Arthur, 1989; David, 1985). Technology choices create self-reinforcing lock-in through increasing returns and switching costs. Trade agreements, by contrast, include explicit modification provisions (e.g., WTO TBT Article 2.3) and demonstrate higher practical reversibility.

This ordering also reflects analytical practice at major technology policy institutions (CSET, RAND, Brookings), which implicitly treat technology capability as foundational whilst treating trade policy as instrumental to technology goals.

Derivation: This hierarchy synthesises Domain Durability Ranges (Section 6.6) with mechanism analysis from path dependence literature. The Technology/Trade ordering specifically reflects coordination lock-in assessment rather than pure durability.

Application

Example: Event is 50% Technology (algorithm) and 50% Security (defence application) - Tiebreaker: Security (higher priority) - Document Technology as strong secondary

Operational Note: In practice, domain classification ambiguity is rare. If the primary focus question (Section 6.2) produces a clear answer with one domain representing majority (>50%) impact, no tiebreaker is required. The tiebreaker hierarchy applies only when an analyst cannot determine majority impact for any single domain after systematically applying the decision tree. Such cases require explicit documentation of the ambiguity rationale and tiebreaker application.

6.8 Pre-Database Entry Quality Gate

Before including any event in WEO database, confirm completion of all stage checkpoints:

Phase 1: Qualification

• Stage 1: Event Verification — Section 3.13 Phase 1 Validation Checklist complete
• Stage 2: Geopolitical Significance Assessment — Chapter 4 pathway documented (Keohane/Basel/Routes/PISA-5)

Phase 2: Classification

• Stage 3: Tier Classification — Section 5.9 checklist complete
• Stage 4: Domain Classification — Domain classification documented per Section 6.6 worked examples
• Industry Tags — Primary industry tag assigned per Chapter 7 rule sets; secondary tags (0–2) documented with mechanism statements; any [REVIEW] or [VERIFY-INVESTMENT] flags resolved

Phase 3: Relationship Mapping (if applicable)

• Stage 5: Coordination Connections — Section 9.6.2 checklist complete for each connection

Database Entry Authorisation - [ ] All applicable stage checklists verified - [ ] No outstanding LOW confidence flags - [ ] Event record ready for database entry

End of Chapter 6: Domain Classification

Chapter 7: Industry Tags

7.1 Purpose

This chapter introduces industry tags — a distinct analytical layer applied during Phase 2, after domain classification (Stage 4) and before coordination connections (Chapter 9). Where domain classification identifies what subject matter an event concerns (Energy/Infrastructure, Security, Technology, Trade), industry tags identify which specific industry the event’s documented provisions most directly address (e.g. Semiconductors & Equipment, Defence & Aerospace).

Pipeline position. Industry tags depend on all four upstream stages. Events reaching this operation have already passed gold-standard verification (Stage 1), geopolitical significance assessment (Stage 2), tier classification (Stage 3), and domain classification (Stage 4). Industry tags inherit the evidentiary assurance of this upstream pipeline — no independent verification is performed at this stage.

Scope. This chapter covers the methodology for understanding and applying industry tags: the governing principle, the 11-category taxonomy, the rule-based assignment logic, override and tiebreaker mechanisms, secondary tag rules, and quality standards. Complete keyword vocabularies, tested examples with specific event identifiers, and other reference material are maintained in the companion Industry Tagging Reference document.

7.2 Industry Tagging Principle

Governing Standard

Each qualified WEO event is tagged with the industry whose operational landscape the event’s documented provisions most directly address.

Operational landscape encompasses an industry’s operations, supply chain relationships, market access, competitive dynamics, and regulatory environment.

This is an identification task, not an impact claim. The event’s documented provisions are assessed to identify which industry they address — not what effect the event has on that industry. No downstream impact assessment is required or produced.

Tagging vs Classification

Industry tags are conceptually distinct from WEO’s three classification systems (Event Type, Tier, Domain). Classification assigns intrinsic properties to events — the event IS Tier 1; the event IS Energy/Infrastructure. An industry tag identifies an external relationship — for example, the event’s provisions ADDRESS the semiconductor industry. The event does not belong to the industry; the industry is identified as the one the event’s provisions most directly address. This directional distinction is why industry identification is treated as tagging rather than classification.

Industry tags do not modify the “three phases containing five stages” processing architecture documented in §2.1, nor add a fourth classification system to the three documented in §2.4. They are a distinct analytical layer applied during Phase 2 — see §2.5 for their architectural position.

Revenue and Demand Distinction

An industry that receives more work or more revenue from an event is not the same as an industry whose operational landscape is directly addressed by the event’s provisions. The industry tag identifies the industry the event’s provisions address, not necessarily the industry that benefits. A sovereign compute programme that procures dedicated power generation for data centre facilities generates significant revenue for energy infrastructure firms — but the programme’s documented provisions address sovereign cloud infrastructure deployment, not energy industry operations. Primary tag: Cloud, Data Centres & Connectivity Infrastructure. Energy & Power Infrastructure receives a secondary tag where the programme’s provisions specify dedicated power procurement, directly addressing energy infrastructure operations. A differently structured sovereign compute programme — one whose provisions address energy grid management via AI-driven infrastructure — could route Energy & Power Infrastructure as primary. Each event is assessed on the basis of its own documented provisions, not by programme category.

7.3 The 11-Category Taxonomy

Category Definitions

Design Principles

The taxonomy captures industries whose operational landscapes are most directly addressed by WEO-qualifying AI infrastructure events. Categories are defined by distinct supply chains, distinct competitive landscapes, and distinct strategic players — not by activity type or revenue flow. The taxonomy adapts the Global Industry Classification Standard (GICS, maintained by S&P/MSCI since 1999) as its primary institutional reference, supplemented with NAICS/ICB where GICS does not capture Eastern Bloc industries adequately.

GICS mapping for each category, where applicable, is provided in the taxonomy table above. A complete GICS-to-WEO correspondence table is maintained in the companion Industry Tagging Reference.

For empirical derivation and category design rationale: See Methodology Rationale.

Category: Adapted from established classification standards (HIGH confidence). The adaptation gap — classifying geopolitical events by addressed industry rather than classifying enterprises by principal activity — is real and documented.

Key Structural Decisions

Subsea cables sit within Cloud, Data Centres & Connectivity Infrastructure because hyperscalers now own or fund the majority of new submarine cable builds and account for the majority of subsea capacity usage. Within WEO’s AI infrastructure scope, subsea cable events are functionally cloud/data centre enablement events with converging strategic players.

Telecoms is structural secondary only because terrestrial telecoms carriers retain distinct strategic positioning in last-mile access networks, spectrum, and regulatory relationships — but within WEO’s scope, AI infrastructure events do not address telecoms competitive dynamics as their primary subject. Secondary tags capture the identifiable pathways from event provisions to telecoms carrier operations. If keyword routing produces a Telecoms primary match, the event is flagged [REVIEW] and assessed under the Industry Tagging Principle for reassignment.

Quantum Computing Infrastructure is a separate category because quantum has distinct supply chains (cryogenics, novel materials), a distinct competitive landscape (quantum modality competition), a distinct export control regime, and distinct sovereign programmes across multiple jurisdictions. Events whose provisions address quantum computing do not tag cleanly under existing categories.

Insurance and risk assessment is captured within Financial Services & Investment. Government and public sector is excluded because the majority of WEO events are government-originated, creating circularity if Government were a tagging category.

Flat tagging with primary/secondary designation is used — not hierarchical.

MONITOR Candidate: Robotics & Physical AI Infrastructure

Robotics & Physical AI Infrastructure is not included in the taxonomy. Events whose provisions address robotics receive primary tags under Semiconductors & Equipment, Automotive & Manufacturing, or AI Software & Platforms depending on which industry their provisions most directly address. Re-assessment criteria are documented in the companion Industry Tagging Reference.

7.4 Primary Tag Assignment

Primary tags are assigned through deterministic mappings, keyword routing, and content analysis. The assigned category is recorded as industryPrimary.

For empirical derivation: See Methodology Rationale.

Category: Standard practice in professional classification (HIGH confidence). Deterministic rule-based assignment from structured metadata is established across clinical coding (CMS DRG Grouper), news classification, and statistical coding. The technique is standard; only the specific mapping rules (domain × event type → primary tag) are WEO-specific.

7.4.1 Rule Set A: Deterministic Mapping

Three domain × event type combinations produce deterministic primary tags without keyword routing:

All other 13 domain × event type combinations (of 16 total) route through keyword-based rule sets (B, C, or D) for primary tag assignment.

Override guidance. Rule Set A deterministic mappings are subject to Industry Tagging Principle review when the event contains significant secondary provisions that would, standing alone, route to a different industry. Such events are flagged [REVIEW] and assessed under the override mechanism (§7.8). The export control routing principle (§7.5.3) applies across all rule sets including Rule Set A.

7.4.2 Rule Sets B, C, and D: Keyword Routing

Rule Set B covers all Energy/Infrastructure events, plus Technology + Policy, Technology + Infrastructure, Technology + Corporate, Trade + Infrastructure, and Trade + Corporate. Keywords are checked in priority order against the event’s name, brief description, and scope.

Rule Set C covers Security + Policy events, with a priority structure optimised for the Security domain’s policy landscape (investment screening, mining controls, AI governance, military, trade).

Rule Set D covers Security + Coordination, Security + Infrastructure, and Security + Corporate events.

All three keyword-based rule sets use a priority group structure:

Complete keyword vocabularies are maintained in the companion Industry Tagging Reference. The representative keywords above illustrate the priority logic; they are not exhaustive.

Keyword matching implementation. Matching is applied to the event’s name, brief description, and scope. All matching is case-insensitive with word-boundary enforcement, optional plural trailing ‘s’, and hyphen/space interchangeability. Keywords of five characters or fewer require strict word-boundary matching to prevent substring false positives.

Priority resolution. When an event matches keywords from multiple categories, the priority group structure governs. Priority Group 1 wins over Priority Group 2. Within a priority group, the first match by category table ordering wins. The contested keyword resolution table (§7.6) provides explicit priority for keywords that span multiple categories.

7.5 Special Routing Rules

Three routing principles apply across the rule sets to handle categories of events that require special treatment.

7.5.1 Supercomputer/HPC Routing

Supercomputer, HPC, and exascale events require special handling because their primary significance varies between compute capacity deployment and processor architecture validation.

Rule: If the event deploys a non-standard or alternative processor architecture → Semiconductors & Equipment. Otherwise → Cloud, Data Centres & Connectivity Infrastructure (default).

Non-standard architecture is identified through content analysis of the event description. The distinguishing signal is an architecture that departs from commercially dominant configurations — such as wafer-scale processors, sovereign processor designs, or non-incumbent instruction set architectures deployed at HPC scale. Established semiconductor competitors deploying their standard product lines in HPC are identified as standard hardware because the deployment uses commercially available configurations rather than validating an alternative architecture.

The Industry Tagging Principle (§7.2) and override mechanism (§7.8) apply where this routing does not reflect the event’s documented provisions.

Worked example (anonymised). A regional bloc deploys a sovereign exascale system using a domestically designed processor architecture distinct from commercially dominant configurations. Primary tag: Semiconductors & Equipment — provisions address validation of alternative processor architecture. Contrast: a sovereign supercomputer deployed using standard GPU compute from established vendors. Primary tag: Cloud, Data Centres & Connectivity Infrastructure — standard hardware, compute capacity deployment.

7.5.2 Investment Vehicle Principle

The investment vehicle principle applies after keyword routing completes. When keyword routing assigns Financial Services & Investment to a fund, investment vehicle, or financing mechanism, the following verification applies: Do this event’s documented provisions most directly address financial services industry dynamics, or the funded industry’s operational landscape?

Decision framework:

1. Does the fund’s structure, scale, or design directly address how AI infrastructure investment operates? → Financial Services & Investment primary.
2. Do the fund’s documented provisions most directly address a specific industry’s operational landscape? → That industry primary; Financial Services & Investment secondary.

Events matching financial keywords (sovereign wealth fund, venture capital, private equity, infrastructure fund, investment fund, capital raise) are marked [VERIFY-INVESTMENT] for content review. This requires content analysis, not keyword rules alone.

Worked example (anonymised). A major economy establishes a $100B+ sovereign fund explicitly designed to reshape how sovereign AI investment is structured, with novel co-investment architecture and first-loss capital provisions. Primary tag: Financial Services & Investment — the fund’s existence directly addresses sovereign AI investment vehicle design. Contrast: a major economy establishes a $47B+ national fund with documented allocations to semiconductor fabrication capacity. Primary tag: Semiconductors & Equipment — provisions address semiconductor manufacturing, not financial services dynamics; Financial Services & Investment receives secondary tag.

7.5.3 Export Control Routing

Export control events route to the industry whose supply chain is directly targeted by the control, not to Trade & Logistics by default.

Rule. When export control terminology (export control, export licensing, export ban, restriction, sanctions, entity list, Foreign Direct Product Rule, AI Diffusion Rule) appears alongside industry-specific keywords, the event routes to the controlled industry:

Trade & Logistics receives a secondary tag when the event creates new trade compliance architecture, regardless of where the primary tag routes.

Scope: all rule sets. The export control routing principle applies across all rule sets, including Rule Set A deterministic mappings. Where a Rule Set A deterministic mapping produces Trade & Logistics for an export control event that targets a specific industry’s supply chain, the event is flagged [REVIEW] and the export control routing principle applied under the override mechanism (§7.8).

7.6 Contested Keyword Resolution

Some keywords appear in multiple categories’ vocabularies. The contested keyword resolution table establishes default priority routing with context-dependent overrides. The Industry Tagging Principle applies: route to the industry whose operational landscape is most directly addressed.

Representative entries from the full 35-keyword table (maintained in the companion Industry Tagging Reference):

Note on “artificial intelligence.” This is a low-priority catch-all. It triggers AI Software & Platforms tagging only when no other category-specific keywords match within the same event.

7.7 Secondary Tag Assignment

7.7.1 Governing Standard

After primary tag assignment, 0–2 secondary tags are applied. Each secondary tag requires a one-sentence source-verifiable mechanism statement explaining how the event’s documented provisions address that secondary industry’s operations. Secondary tags are recorded in the event’s industrySecondary array; each entry carries the category as tag and the statement as mechanism. The primary/secondary tag structure adapts principal/secondary activity classification (ISIC Rev. 4, ICD-10).

Category: Adapted from established classification standards (MEDIUM-HIGH confidence). The primary/secondary structure adapts principal/secondary activity classification. The 2-secondary cap lacks direct precedent in comparable systems — most use uncapped secondary codes — but is a deliberate design constraint enforcing prioritisation.

A secondary tag is justified if and only if: the event’s documented provisions address the secondary industry’s operations, supply chain, or market access — not merely generate activity, revenue, or demand for that industry.

The mechanism statement is mandatory. If the mechanism cannot be stated in one sentence with a specific, source-verifiable pathway from the event’s provisions to the secondary industry, the tag is not justified.

7.7.2 Mechanism Statement Standard

The mechanism statement identifies a document-verifiable pathway — specific content within the event’s provisions that is directed at the secondary industry’s operations. The statement describes what the provisions contain and which industry’s operations that content addresses, not what effect the provisions produce.

Formula: “[Specific provision/content] addresses [specific aspect of secondary industry’s operations]” — where both the provision and the aspect can be verified from the event documentation.

Format illustrations:

For an export control event with military end-use provisions (primary: Semiconductors & Equipment; secondary: Defence & Aerospace): “Provisions specify military end-use as a licensing criterion, directly addressing defence procurement supply chains.”

For a sovereign compute programme with dedicated power infrastructure (primary: Cloud, Data Centres & Connectivity Infrastructure; secondary: Energy & Power Infrastructure): “Programme provisions specify dedicated power procurement for data centre facilities, directly addressing energy infrastructure operations.”

Each statement identifies specific documented content and names the secondary industry’s operations that content addresses, consistent with the justification standard in §7.7.1. Full worked examples demonstrating mechanism statements within complete routing workflows are provided in §7.10.

Category: Adapted from established classification standards with novel elements (MEDIUM-HIGH confidence). The requirement adapts justification practices from clinical coding and intelligence analysis. The universal application — every secondary tag, every time — is more demanding than most established systems, which require justification only for ambiguous cases.

7.7.3 ALWAYS Rules

Two secondary tag assignments are structurally reliable and apply without case-by-case assessment, provided the mechanism statement standard (§7.7.2) is satisfied. Where no truthful mechanism statement can be written for a specific event, the tag is not applied and the inapplicability is recorded in the tagging rationale:

7.7.4 Key Conditional Rules

The complete conditional rules table is maintained in the companion Industry Tagging Reference. The governing standard (§7.7.1) can justify secondary tags even when no specific conditional rule fires, provided a mechanism statement can be documented.

7.8 Override Constraints and Tiebreaker

Override Mechanism

When the Industry Tagging Principle conflicts with rule set output, the principle governs — but the override requires all four of the following:

1. [REVIEW] flag — the event is flagged for manual review.
2. Written rationale — citing specific evidence from the event documentation that justifies the override. Must reference documented provisions, scope, scale, or targeting — not predicted impact.
3. Structured assessment — identify all industries matched by rules, state which industry is most directly addressed by the event’s documented provisions, and explain why the rule output is inadequate.
4. Audit trail — override decisions are logged and subject to periodic consistency review against prior override decisions.

If the four requirements cannot be satisfied, the rule set output stands.

This aligns with the discipline of domain tiebreaker application (§6.7), which requires explicit documentation of the ambiguity rationale and tiebreaker application.

Tiebreaker Principle

Where two or more industries have comparable claims to primary tagging and the Industry Tagging Principle does not resolve the ambiguity, priority follows a principle-based approach with partial supply chain ordering.

Where a supply chain relationship exists between competing industries, upstream position is the primary indicator. The upstream industry is more directly addressed by provisions that target the supply chain itself, whilst downstream effects are derivative:

Mining & Critical Minerals (most upstream) → Semiconductors & Equipment → Energy & Power Infrastructure (cross-cutting enabler) → Cloud, Data Centres & Connectivity → AI Software & Platforms (most downstream)

The supply chain ordering applies when competing industries are both on the chain and the event concerns the chain relationship itself.

Where no supply chain relationship exists between competing industries, priority follows the industry whose operations, market access, or own supply chain receive the most substantive documented treatment (measured by provision scope, financial allocation, or regulatory specificity). Industries outside the core AI infrastructure supply chain ordering above — Financial Services & Investment, Defence & Aerospace, Automotive & Manufacturing, Trade & Logistics, Quantum Computing Infrastructure, Telecoms — are assessed on substantive documented treatment directly.

Documentation requirement. When the tiebreaker is applied, the following are documented: (a) which industries were competing for primary tagging, (b) the supply chain relationship between them (if any), (c) the evidence for which industry is most directly addressed, and (d) the final tagging decision with rationale.

7.9 Quality Standards

Primary Tag Verification

After deterministic rules assign a primary tag, verify: “Do this event’s documented provisions most directly address this industry’s operational landscape? If the event were described to a professional in this industry, would they immediately recognise its relevance to their work?” If no, override per §7.8.

Category: Standard practice in professional classification (HIGH confidence). The domain-professional verification test adapts face validity methodology (Mosier 1947; TREC relevance assessment). Adversarial testing of classification outputs against domain expertise is established across information retrieval, medical coding, and survey instrument design.

For empirical derivation: See Methodology Rationale.

Secondary Tag Verification

Each secondary tag must satisfy the mechanism statement standard documented in §7.7.1–7.7.2.

Tagging Assurance

Keyword matching is a proxy for industry identification, not a proof that the event’s provisions address that industry. The priority group ordering and content analysis are designed to prevent incidental industry mentions from displacing the event’s primary industry tag. The governing reproducibility standard applies: two independent analysts, given identical event documentation and methodology, should reach the same industry tag.

Evidentiary indicators for edge cases. For events where deterministic rules and keyword routing do not produce a clear result, “most directly addresses” is assessed per the governing standard (§7.2) and tiebreaker measurement criteria (§7.8), with the additional requirement that the industry is specifically named or identifiable from the event’s documentation — not inferred from downstream effects. These indicators are assessed against official documentation only. Projected, anticipated, or speculative relevance is outside scope.

Where industry-tag changes affect events with existing Parallel Policy connections, a downstream re-verification obligation applies to Criterion 2 assessments on those connections (§9.4.3).

7.10 Worked Examples

The following examples demonstrate primary tag routing, secondary tag mechanism statements, and the output format. Each example uses a simplified event summary for illustration. In practice, mechanism statements are derived from the full event documentation obtained during verification (Stage 1), which typically comprises multiple source documents with substantially more detail than presented here.

Example 1: Export Control Event

A major economy restricts export of advanced semiconductor manufacturing equipment to rival bloc nations. Provisions specify licensing requirements for lithography systems, deposition equipment, and metrology tools. Scale: significant (covering $10B+ annual trade). Domain: Security. Event Type: Policy.

Routing: Rule Set A: Security + Policy → Rule Set C. Keyword matches: “export control” + “semiconductor” + “lithography” → export control routing principle applies → Semiconductors & Equipment.

Primary tag: Semiconductors & Equipment — provisions directly address semiconductor manufacturing equipment supply chains.

Secondary tag: Defence & Aerospace — mechanism: “Export control provisions specify military end-use as a licensing criterion, directly addressing defence procurement supply chains.”

Secondary tag: Trade & Logistics — mechanism: “Provisions establish new export licensing architecture for controlled items, directly addressing trade compliance operations.”

Example 2: Sovereign Compute Programme

A major economy announces a multi-billion-dollar sovereign compute programme. Documented provisions address data centre construction, GPU procurement, cloud certification, and domestic AI model training capacity. Domain: Energy/Infrastructure. Event Type: Infrastructure.

Routing: Rule Set A → Rule Set B. Keywords: “data centre,” “sovereign compute,” “GPU cluster” → Cloud, Data Centres & Connectivity Infrastructure.

Primary tag: Cloud, Data Centres & Connectivity Infrastructure — provisions directly address sovereign cloud infrastructure deployment.

Secondary tag: Energy & Power Infrastructure — mechanism: “Programme provisions specify dedicated power procurement and grid interconnection for data centre facilities, directly addressing energy infrastructure operations.” (Cloud → Energy conditional met: physical data centre construction involved.)

Secondary tag: AI Software & Platforms — mechanism: “Programme provisions allocate compute credits for domestic foundation model training, directly addressing AI platform operations.”

Example 3: Investment Vehicle

A consortium of sovereign wealth funds establishes a $100B+ fund explicitly designed to reshape how AI infrastructure investment is structured, with novel co-investment architecture and multi-jurisdictional deployment provisions. Domain: Trade. Event Type: Corporate.

Routing: Rule Set A: Trade + Corporate → Rule Set B. Keywords: “sovereign wealth fund,” “investment fund” → Financial Services & Investment. [VERIFY-INVESTMENT] flag applied.

Investment vehicle principle check: Do the fund’s documented provisions primarily address financial services dynamics? The fund’s structural design — novel co-investment architecture, first-loss capital provisions, multi-jurisdictional compliance — directly addresses how sovereign AI investment operates. Financial Services & Investment primary confirmed.

Primary tag: Financial Services & Investment — fund’s design directly addresses sovereign AI investment vehicle architecture.

Secondary tag: Cloud, Data Centres & Connectivity Infrastructure — mechanism: “Fund’s deployment provisions specify data centre infrastructure as a primary investment target, directly addressing cloud infrastructure capital access.”

End of Chapter 7: Industry Tags

Chapter 8: Environmental Nexus Tags

8.1 Purpose

This chapter introduces Environmental Nexus Tags (ENTs) — a distinct analytical layer applied during Phase 2, after industry tags (Chapter 7) and before coordination connections (Chapter 9). Where industry tags identify which specific industry an event’s documented provisions most directly address, Environmental Nexus Tags identify which environmental dynamics an event intersects — resource demand, environmental enablement, environmental consequence, environmental dependency, or environmental governance.

Pipeline position. ENTs depend on all four upstream stages. Events reaching this operation have already passed gold-standard verification (Stage 1), geopolitical significance assessment (Stage 2), tier classification (Stage 3), and domain classification (Stage 4). ENTs inherit the evidentiary assurance of this upstream pipeline. ENT assessment may reference industry tag assignments. Industry tags (Chapter 7) are assessed before ENTs; ENTs are assessed before coordination connections (Chapter 9).

Scope. This chapter covers the methodology for understanding and applying Environmental Nexus Tags: the governing principle, the five-type taxonomy, qualifying thresholds and evidence standards, the Warmth Engine Ratio (WER), and architectural guardrails. For empirical derivations, confidence assessments, and calibration justifications: see Methodology Rationale.

8.2 ENT Tagging Principle

Governing Standard

Each qualified WEO event is assessed for environmental intersections across five tag types. A tag is applied when the event meets the qualifying threshold for that type.

ENTs identify the existence of environmental intersections, not their magnitude. Each tag is binary — applied or not applied. The mechanism statement provides a one-sentence document-verifiable description of how the environmental intersection manifests. ENTs are a data enrichment layer that identifies where environmental intersections exist across the database; they do not quantify those intersections.

Tagging vs Classification

Environmental Nexus Tags are conceptually distinct from WEO’s three classification systems (Event Type, Tier, Domain). Classification assigns intrinsic properties — the event IS Tier 1; the event IS Energy/Infrastructure. An ENT identifies an external intersection — for example, the event INTERSECTS WITH documented resource demand. The event does not belong to the environmental intersection; the intersection is identified as a documented relationship between the event and environmental systems. This directional distinction is why environmental intersection identification is treated as tagging rather than classification.

Category: Adapted from established classification frameworks (HIGH confidence). The classify-first-enrich-second pattern directly adapts the Basel Committee on Banking Supervision’s treatment of climate-related financial risks as a cross-cutting overlay on existing risk categories.

ENTs follow the same architectural pattern as industry tags (§2.5): a post-classification enrichment layer that inherits upstream pipeline assurance and produces metadata consumed by downstream analysis. ENTs do not modify the “three phases containing five stages” processing architecture documented in §2.1, nor add a fourth classification system to the three documented in §2.4. They are a separate analytical layer parallel to industry tags. ENT assignment does not affect domain classification — the four-domain system and the ENT system operate on different analytical axes and are orthogonal. ENT tags are assigned before Stage 5 (Coordination Connections) and are visible to analysts during CC analysis, but do not affect CC identification, classification, or confidence levels.

Confidence Architecture

ENTs use binary qualification: a tag is either applied or not applied, based on meeting the qualifying threshold for that type. Each applied ENT carries:

• Tag type (ENT-1 through ENT-5) — recorded as type
• Mechanism statement — one-sentence document-verifiable description of how the environmental intersection manifests — recorded as mechanism
• Evidence — source documentation supporting the tag assignment — recorded in the tag’s sources array (citation, type, url per entry)
• Evidence basis — recorded as evidenceBasis: “Documented” (qualifying evidence appears in the event’s own source documentation or primary regulatory sources) or “Assessed” (analyst assessment based on authoritative third-party data applied to documented event characteristics)

Schema note: ENT assessments are recorded in the event’s environmentalNexusTags array; each tag additionally carries its type name as name, and ENT-5 tags carry the qualifying pathway.

The “Documented/Assessed” distinction captures meaningful evidence quality variation without introducing the full CC confidence architecture (CC-V/CC-E/CC-A, documented in Chapter 9). Both values may rely on primary-quality sources — the distinction is about where the evidence comes from, not about its quality. This evidence-basis descriptor is specific to ENT assessment and is distinct from the confidence language hierarchy documented in §3.4.

For rationale on the binary qualification model and evidence-basis descriptor: See Methodology Rationale.

Architectural Guardrails

Four guardrails prevent ENTs from functioning as a competing classification system:

1. Read-only dependency. ENTs consume upstream classification but never modify it. An event’s tier, domain, event type, and industry tags remain unchanged regardless of ENT assignment.
2. Independent removability. The entire ENT layer could be removed without affecting any core classification, verification, or coordination connection. This tests whether the layer is truly supplementary.
3. No primary aggregation by ENT. Events are never primarily grouped or filtered by ENT tag type as a substitute for domain grouping. ENTs inform analysis within domains, not across them as a competing organisational principle.
4. Explicit documentation of layer role. ENTs are an analytical enrichment layer parallel to industry tags — cross-cutting metadata, not a categorical classification.

An event may carry multiple ENT tags of different types (0 to 5 tags per event, non-exclusive). An event may not carry multiple tags of the same type — each type is binary per event.

For rationale and institutional precedents for the four-guardrail architecture: See Methodology Rationale.

8.3 The Five-Type Taxonomy

Taxonomy Overview

Category: WEO synthesis (MEDIUM-HIGH confidence). Faceted classification theory and mixed-property architecture draw on established information science; the specific five-type taxonomy design is the novel element.

The five types capture three directional relationships: AI infrastructure’s active footprint on the environment (ENT-1, ENT-3); environmental conditions constraining AI infrastructure operations (ENT-4); and governance mediating between AI infrastructure and environmental systems (ENT-2 intent, ENT-5 operationalisation).

For rationale on the five-type taxonomy structure and directional coherence: See Methodology Rationale.

8.3.1 ENT-1: Resource Demand

Definition: Event implementation creates documented demand on environmental resources — energy at hyperscale capacity, or water, land, or critical minerals where resource requirements are the subject of dedicated environmental documentation.

Category: Empirically grounded (HIGH confidence). The ≥100MW energy threshold derives from convergent institutional classification across IEA, US Congressional Research Service, and industry analysts.

Qualifying Threshold:

The event must demonstrate documented resource demand through at least one of:

• Energy: Documented dedicated power capacity ≥100MW, OR documented grid impact assessment attributable to the event, OR documented power purchase agreement for ≥100MW dedicated capacity for the facility
• Water: Documented water consumption or cooling requirements that are the subject of dedicated environmental documentation — environmental permits, utility filings, or environmental impact assessments specific to the facility’s water demand. Standard municipal water connection does not qualify.
• Land: Documented land conversion for facility construction that is the subject of dedicated planning or environmental documentation — land use permits, environmental impact assessments, or zoning filings specifying the facility footprint. Standard commercial lot development does not qualify.
• Minerals: Documented critical minerals extraction requirements with environmental impact identified in source documentation

The ≥100MW energy threshold exists because without it, virtually every physical AI infrastructure event would qualify (they all use electricity), making the tag trivially universal. The water, land, and minerals vectors are binary documentation tests — the tag is applied when dedicated environmental documentation specifies the resource requirement. These vectors do not need numerical thresholds because specific, quantified water, land, and mineral requirements appearing in dedicated environmental documentation are substantially less common than energy capacity figures — energy capacity is typically the headline specification, whilst water consumption, land conversion, and mineral requirements are often disclosed through environmental permits and impact assessments rather than in the headline documentation that typically forms the event’s primary source set.

Capacity figures must match the event’s scope. Cluster- or hub-level supply infrastructure qualifies only where the event is the cluster or hub; a facility event within a cluster requires facility-attributable dedicated capacity, a facility grid impact assessment, or a facility PPA.

Where an event’s scope is a programme rather than a single facility, capacity targets, mandated minimum-capacity criteria, or deployment figures ≥100MW in the programme’s official documentation satisfy the threshold.

Evidence Standard: Facility specifications, environmental impact assessments, power purchase agreements, utility filings, or government environmental documentation. Corporate sustainability reports qualify as corroborating (not primary) evidence.

Key Exclusion: General industry averages do not qualify. The specific facility or programme’s resource demands must be documented, not inferred from sector-level data.

Evidence Basis: Typically “Documented” — energy capacity data usually appears in the event’s own source documentation. Water, land, and mineral evidence may require sources outside the primary source set (environmental permits, impact assessments, utility filings).

For rationale on the ≥100MW threshold and multi-vector architecture: See Methodology Rationale.

8.3.2 ENT-2: Environmental Enablement

Definition: The event’s stated rationale, legally binding text, or official sovereign funding documentation explicitly references environmental objectives — including energy efficiency, emissions reduction, renewable energy requirements, environmental footprint minimisation, or ecological protection — as an explicitly stated justification, enabling condition, or documented co-benefit of the AI infrastructure action.

Category: WEO-original with non-Western validation (CATEGORY CREATOR). The four-criteria linguistic threshold is WEO-original; cross-jurisdictional validation across five regulatory architectures confirms the operative provisions test produces correct results globally.

Qualifying Threshold:

All four criteria must be met:

1. Explicit. Environmental objectives must be explicitly stated, not implied.
2. Primary source. Environmental language must appear in primary legal, regulatory, or sovereign funding documentation — not solely in press releases, marketing materials, or corporate sustainability reports.
3. Operative provisions. Environmental language must appear in operative provisions of the document (legislative articles, binding conditions, funding criteria) — not solely in preambles, recitals, or aspirational statements.
4. AI infrastructure directed. Environmental objectives must be specifically directed at the AI infrastructure action documented in the event, not generic corporate sustainability commitments that incidentally cover AI infrastructure operations.

Evidence Standard: Direct quotation or paraphrase from primary legal, regulatory, or sovereign funding text identifying the environmental nexus. Voluntary corporate ESG reports, Carbon Disclosure Project submissions, and similar market-driven compliance mechanisms do not qualify unless they implement binding sovereign mandates.

Key Exclusion: Physical geographic proximity to renewable energy sources does not qualify. A facility sited near a hydroelectric dam for commercial power access, without a sovereign mandate requiring clean energy, does not meet the ENT-2 threshold. This boundary separates ENT-2 (policy intent) from ENT-4 (environmental dependency) and prevents overlap with ENT-1 (resource demand).

The qualifying environmental language must be attributable to the event: in the event’s own primary documentation, or in sovereign regulatory/approval instruments that designate or condition the specific event (approval conditions, designation-linked mandatory standards). Instruments belonging to a different private actor (host facilities, landlords, suppliers) do not satisfy the test for the event, regardless of operational inheritance. Voluntary corporate environmental goals do not qualify even where implemented through binding private contracts — the sovereign-mandate exclusion applies to the origin of the obligation, not the bindingness of the implementing instrument.

Tenant or colocation deployments at a host facility share the host’s environmental infrastructure operationally but do not inherit the host’s environmental documentation for ENT-2 purposes. The host facility’s environmental permits, regulatory conditions, and sustainability commitments are documentation attributable to the host’s event, not the tenant’s.

Strategy actions, summit declarations, and positioning statements are not operative provisions. Where a strategy directs binding implementation, cite the implementing instrument (cascade model).

Cascade model application. Where governance instruments use directional language at the national level but gain operative force through mandatory national standards and provincial implementation, the “operative provisions” test applies to the implementing instrument where binding language appears — consistent with the principle that EU directives require member-state transposition before creating binding obligations.

Evidence Basis: Typically “Documented” — the qualifying evidence is text within the event’s primary documentation.

ENT-2/ENT-5 Boundary. ENT-2 marks the presence of environmental intent in governance instruments. ENT-5 marks the operationalisation of that intent into binding requirements or dedicated infrastructure. An event may carry both tags when environmental language (ENT-2) generates binding operational constraints (ENT-5). The dual-tag is informative, not redundant — it marks different positions on a governance maturity spectrum: aspiration versus obligation.

For rationale on the four-criteria linguistic threshold, cascade model, and governance maturity spectrum: See Methodology Rationale.

8.3.3 ENT-3: Environmental Consequence

Definition: Event implementation has produced documented, measured environmental outcomes — positive or negative — verified through independent monitoring, regulatory filings, or official environmental reporting.

Qualifying Threshold:

The event must demonstrate documented environmental outcomes through at least one of:

• Documented emissions impact (increase or decrease) attributed to the specific event in official reporting
• Documented environmental incident or regulatory enforcement action linked to the facility or policy
• Documented environmental monitoring data showing measurable change attributable to the event
• Formal regulatory proceedings (e.g., environmental agency rulings, notices of intent to sue under environmental statutes) directly linked to the event’s environmental impacts

Evidence Standard: Environmental regulatory filings, audited corporate sustainability reports with facility-level data, government environmental monitoring, independent environmental assessment, or regulatory enforcement documentation.

Key Exclusion: Projected, estimated, or modelled impacts do not qualify. Only documented, measured outcomes meet the threshold. This is consistent with WEO’s evidence-only observation standard (Chapter 1, Core Principles).

Evidence Basis: “Documented” for consequences with regulatory enforcement evidence. “Assessed” where measurement relies on independent monitoring data not produced by the event’s implementing entities.

Activation Conditions

ENT-3 distinguishes between two categories of environmental consequence, each with distinct activation conditions:

Acute Operational Consequences are taggable immediately upon qualifying evidence. These are localised environmental disruptions from facilities in active operation: air quality violations from onsite power generation, documented thermal pollution of local waterways, immediate aquifer drawdowns, or grid reliability events caused by facility power demand. The activation criterion is regulatory enforcement action, formal notice of intent to sue under environmental statute, or verified independent monitoring data.

Cumulative Lifecycle Impacts are activated when reporting data matures — specifically, 24 months post-commencement of high-volume operations at the respective facility (as determined by the operational status documented during event verification), OR when facility-level environmental reporting instruments (e.g., EU EED Article 12 reporting, Germany EnEfG Energy Efficiency Register) have generated at least two full reporting cycles of comparable data, whichever occurs first. This window allows collection of verifiable operational data including municipal water discharge records, emissions inventory reporting, and stable grid load assessments.

Scope limitation on governance instruments. The reporting cycle trigger references instruments producing facility-level environmental operational data, not model-level energy documentation (e.g., EU AI Act Annex XI). The AI Act documents model training energy consumption — significant for ENT-5 assessment but not the data source for measuring cumulative environmental consequences of a specific physical facility.

For rationale on the activation model and 24-month calibration: See Methodology Rationale.

8.3.4 ENT-4: Environmental Dependency

Definition: Authoritative environmental risk data documents a specific risk to the event’s facility, location, supply chain, or operational conditions. ENT-4 is applied when recognised external indices or official risk assessments flag a documented environmental vulnerability — WEO is checking whether authoritative data identifies a risk, not making its own risk determination.

Qualifying Threshold:

The event must demonstrate documented environmental dependency through at least one of:

• Water-stress dependency (both conditions required):
  • Water stress. Facility located in a documented water-stress zone. For the WRI Aqueduct 4.0 default source, qualifying Baseline Water Stress classes are Medium-High (20–40%), High (40–80%), Extremely High (>80%), and Arid and Low Water Use. Low (<10%) and Low-Medium (10–20%) do not qualify. For designated complementary national sources, qualifying classifications are those the issuing authority defines as stress, scarcity, over-exploitation, or equivalent (e.g. CGWB “Over-exploited” or “Critical”; Environment Agency “serious water stress”); descriptive scarcity statistics without an authoritative classification do not satisfy this condition.
  • Consumptive process. The facility’s documented cooling or process-water architecture includes a consumptive stage: evaporative cooling towers or adiabatic/evaporative-assisted heat rejection; once-through withdrawal; or ultrapure/process water consumption. The test applies at the heat-rejection terminus and across the process chain: any documented consumptive stage qualifies, including secondary loops (e.g. liquid-cooled plates with evaporative heat rejection). Closed-loop systems rejecting heat without consumptive water use — dry coolers, free cooling, warm-water direct liquid cooling with non-evaporative rejection — do not satisfy this condition. Where the cooling or process-water architecture is not documented, the condition is not met: absence of the tag is the correct default (§8.6).
• Facility located in a documented extreme weather or climate risk zone AND environmental risk is acknowledged in planning documentation or independently assessable from authoritative risk indices Country-level indices (e.g. ND-GAIN) do not alone satisfy the weather/climate requirement; they must be paired with facility-specific risk documentation or documented realised events affecting the facility or its documented dependencies.
• Supply chain dependency on critical minerals whose extraction is subject to documented environmental constraints or geographic monopolisation with environmental vulnerability
• Operational dependency on environmental conditions (e.g., stable grid supply, cooling water temperature) where those conditions are subject to documented degradation trends The dependency must be on an environmental or climatic condition whose degradation is documented in authoritative environmental data; infrastructure capacity constraints (grid-connection queues, transmission availability) do not qualify absent documented climate-driven risk to the relevant assets.

Authoritative Indices

Three global indices are designated as default sources for ENT-4 assessment:

• WRI Aqueduct Water Risk Atlas (Version 4.0) — freely accessible, updated periodically, recognised by financial regulators and rating agencies, provides facility-level water stress classification
• ND-GAIN Country Index — Notre Dame Global Adaptation Initiative; freely accessible, annually updated, provides country-level climate vulnerability and readiness assessment
• Munich Re NatCatSERVICE — natural catastrophe loss database; industry-standard for physical climate risk assessment

Designated complementary national sources. Where national environmental data sources provide demonstrably superior resolution for a specific jurisdiction, they are designated as complementary sources alongside the three global defaults. Complementary sources supplement the global baseline for facility-level precision; they do not replace it. Designated complementary-source equivalence mappings include: CGWB “Over-exploited” or “Critical” (India); Environment Agency “serious water stress” (England); EEA WEI+ >40% (European coverage).

Strong recommendation (five sources): J-SHIS (Japan — seismic hazard, 250m mesh, NIED); CGWB NAQUIM (India — groundwater, 1:50,000 scale); CCRS V3 (Singapore — climate projections, 2024); PUB (Singapore — water security, coastal risk); BNPB InaRISK (Indonesia — multi-hazard, regency-level).

Recommendation (Chinese national sources): Ministry of Water Resources (水利部) basin-level hydrological data (1km resolution); First National Disaster Risk Census (第一次全国自然灾害综合风险普查) outputs (county-level multi-hazard, Ministry of Emergency Management); National Surface Water Automatic Monitoring System (real-time, Ministry of Ecology and Environment).

Additional complementary sources may be designated as the database expands to new jurisdictions, provided they meet WEO source quality requirements (§3.1, or equivalent recognised institutional publication) and offer meaningfully higher resolution than the global defaults for the specific jurisdiction.

Key Exclusion: Generalised global climate risk does not qualify. The environmental dependency must be specific to the event’s documented facility, location, or supply chain — not inferred from broad regional or global trends.

Evidence Basis: Typically “Assessed” — environmental dependency requires applying authoritative third-party risk data to the event’s documented facility characteristics, rather than being visible in the event’s own primary sources.

For rationale on the coupled gate architecture, water-stress band floor, consumptive-process floor, index designation, and non-Western validation of complementary sources: See Methodology Rationale, Section 8.8.

8.3.5 ENT-5: Environmental Coordination

Definition: Event creates explicit, documented environmental operational requirements on AI infrastructure — including binding reporting obligations, mandatory efficiency standards, renewable energy conditions, or capacity-gated environmental criteria — OR deploys dedicated AI/compute infrastructure specifically for environmental monitoring, prediction, or management at sovereign or multilateral scale.

Category: WEO-original for scope selection (CATEGORY CREATOR); adapted for Pathway A evidence architecture (HIGH confidence). The medium scope boundary definition is grounded in empirical population analysis.

Qualifying Threshold:

The event must demonstrate environmental governance through at least one of:

Pathway A — Binding Environmental Governance:

• Legally binding or contractually enforceable environmental requirement that creates operational constraints on AI infrastructure operators or providers
• Environmental requirement documented in primary legislative, regulatory, or contractual text
• Requirement must create binding environmental operational requirements on AI infrastructure — the test is whether the instrument creates such requirements, not whether the instrument’s primary legislative purpose is AI infrastructure regulation

Pathway B — Dedicated Environmental Infrastructure:

• Dedicated AI/compute infrastructure allocation or deployment decision with environmental monitoring, prediction, or management as the explicit primary purpose
• Purpose documented in official programme documentation
• Sovereign or multilateral scale, not purely corporate

Evidence Standard (Pathway A): Primary legislative or regulatory text establishing binding environmental requirements. Voluntary frameworks, non-binding pledges, and aspirational commitments do not qualify.

Evidence Standard (Pathway B): Official programme documentation from sovereign or multilateral implementing entities, meeting WEO’s standard primary source requirements (§3.1).

Cross-cutting capture. Validation across eight jurisdictions confirms that cross-cutting environmental instruments — climate legislation, energy conservation acts, building efficiency codes — are the dominant global regulatory model for data centre environmental governance. Energy conservation acts imposing mandatory PUE reporting on data centres as a designated industry class, climate laws with binding greenhouse gas obligations capturing data centres within scope, and mandatory national standards establishing binding energy efficiency grades for data centres all qualify under the Pathway A test. General environmental regulation that incidentally applies to data centres through its application to all commercial buildings or all energy consumers, without any data-centre-specific provision, does not qualify — the instrument must identify or designate data centres (or computing facilities, or equivalent) as a regulated category within its scope.

Key Exclusion: ENT-5 distinguishes between events that constitute environmental governance targeting AI infrastructure as a regulated category (qualifying) and events that are AI infrastructure actions with environmental provisions (captured by ENT-2, not ENT-5). A sovereign compute initiative with environmental efficiency provisions is an AI infrastructure event with environmental characteristics — qualifying for ENT-2 where criteria are met, but not for ENT-5. ENT-5 applies only where the event itself constitutes binding environmental governance specifically targeting AI infrastructure (Pathway A), or dedicated AI infrastructure deployed for environmental purposes at sovereign or multilateral scale (Pathway B).

Institutional coordination machinery — councils, task forces, delivery units, inter-ministerial bodies — does not satisfy Pathway A absent binding environmental requirements the instrument itself creates. Institutional discussion of environmental governance is not environmental governance.

Evidence Basis: “Documented” for both pathways — the qualifying evidence is primary legal/regulatory text (Pathway A) or official programme documentation (Pathway B).

For rationale on the medium scope definition, dual-pathway architecture, and non-Western validation: See Methodology Rationale.

8.4 Evidence Architecture

Source Universe

ENT evidence may come from sources outside the event’s Stage 1 source set. This is a deliberate architectural choice:

Source Quality Requirements

ENT-specific sources must meet the same quality hierarchy as WEO primary and corroborating sources (§3.1, or equivalent recognised institutional publications). Authoritative environmental risk indices (WRI Aqueduct, ND-GAIN, Munich Re NatCatSERVICE) qualify as corroborating sources as equivalent recognised institutional publications (§3.1).

Designated complementary national sources (§8.3.4) qualify where they meet WEO source quality requirements and offer meaningfully higher resolution than the global defaults for the specific jurisdiction.

8.5 Warmth Engine Ratio

Definition

Warmth Engine Ratio (WER) = ENT-1 count ÷ ENT-5 count

The Warmth Engine Ratio measures the balance between documented environmental resource demand (ENT-1) and documented environmental governance (ENT-5).

What WER Expresses

WER expresses the ratio between documented environmental resource demand (ENT-1) and documented environmental governance (ENT-5) within the WEO event corpus. Changes in the ratio across processing loops reflect changes in the documented balance between demand-side and governance-side events as the corpus grows.

Operationalisation

WER is reportable whenever ENT-5 count ≥ 1. If ENT-5 = 0, report as “No documented environmental governance events” rather than computing an undefined ratio. WER is reported with its component counts: “WER [value] (n: [ENT-1 count]/[ENT-5 count])”.

WER is reported as provisional while ENT-5 count < 10.

Interpretive Context

WER measures documented events in the WEO database, not the totality of global AI-environment activity. The ratio should be interpreted as a measure of the observable landscape, with appropriate caveats about database scope and representativeness.

The denominator counts environmental-governance instruments that qualify as WEO events; instruments outside the event corpus are outside the ratio.

For rationale on WER operationalisation: See Methodology Rationale, §8.5 (ENT-1), §8.9 (ENT-5), §8.13 (positioning and novelty), and §8.14 (provisionality, n-disclosure, and corpus scope).

8.6 ENT Quality Standards

Pre-assignment verification:

• ✓ Event has completed all upstream pipeline stages (Stages 1–4) and industry tag assignment
• ✓ Each applied ENT meets its qualifying threshold as documented in §8.3
• ✓ Each applied ENT includes a mechanism statement (one-sentence document-verifiable description)
• ✓ Each applied ENT includes evidence citation(s) from sources meeting §3.1 quality requirements
• ✓ Evidence basis correctly designated as “Documented” or “Assessed” per §8.2 criteria
• ✓ No ENT tag applied without meeting qualifying threshold — absence of a tag is the correct default

Post-assignment verification:

• ✓ Mechanism statements are document-verifiable — an independent analyst could locate the cited evidence and confirm the stated intersection
• ✓ All five ENT types assessed — confirm each type was considered, not just the obvious ones
• ✓ ENT-2/ENT-5 boundary correctly applied where both tags are present — verify the governance maturity spectrum distinction

8.7 Limitations

ENT assessment is subject to the same Structural Visibility Asymmetry documented in §4.11 — events in jurisdictions with thinner regulatory process architecture may carry fewer ENT tags regardless of their actual environmental intersection. ENTs measure only documented environmental intersections; environmental dynamics operating below documentation thresholds are outside ENT scope, consistent with WEO’s evidence-only observation standard. ENT-2 and ENT-5 assignment requires analyst judgement about whether environmental language meets the “operative provisions” and “binding constraint” thresholds respectively — qualifying criteria are designed for reproducibility, but borderline cases will arise and rationale for all judgement calls should be documented. Edge-case guidance will be developed as the processed event population provides empirical boundary cases to codify.

End of Chapter 8: Environmental Nexus Tags

Chapter 9: Coordination Connections

9.1 Purpose and Scope

9.1.1 What This Chapter Covers

This methodology defines how the Warmth Engine Observatory identifies, classifies, and documents relationships between verified events in the WEO database. These relationships — called “Coordination Connections” (CC) — capture how events influence, enable, or respond to one another across the AI infrastructure coordination landscape.

9.1.2 Core Principle

A Coordination Connection exists when evidence establishes the relationship between two verified events. For Types 1–6, documentary evidence is required — temporal proximity alone, thematic similarity, or unsupported analytical inference do not constitute valid connections. Parallel Policy (Type 7) is the sole analytical CC type, assessed at CC-A confidence through the four-criterion similarity rubric (§9.4.3) rather than documentary evidence.

9.1.3 Relationship to WEO Methodology

Coordination Connections operate as a supplementary layer on top of WEO’s verified event database. Events must first pass WEO’s standard verification process (Chapter 3) before connections can be documented between them.

Processing Sequence:

Event A (Verified) ←→ Connection ←→ Event B (Verified)
                          ↓
              Connection Type + Confidence Level (CC-V/CC-E/CC-A)          

Event Lifecycle: For CC handling when events undergo succession (termination, transformation, or merger), see Section 3.14.4 (CC Succession Handling) and Section 3.15.8 (Coordination Connection Implications).

Infrastructure Threads (Chapter 10) form a second supplementary layer, recording documented material facts; the distinction from Coordination Connections is set out at §10.4.

9.1.4 Multiple Connections Between Events

Two events may have multiple valid connections of different types. Each connection pathway is documented as a separate record with its own evidence.

Example: CHIPS Act (Policy) → Intel Fab Award (Infrastructure)

• Funding Flow: CHIPS Act appropriates funds received by Intel
• Regulatory Enablement: CHIPS Act creates legal authority exercised in the award

Each connection type requires independent evidence meeting its minimum confidence level. The existence of one connection type does not automatically establish another.

9.1.5 Use Cases (Priority Order)

9.1.6 Distinct Actor Requirement

Coordination Connections document relationships between events involving distinct actors — separate sovereign entities, separate corporate entities, or separate institutional bodies. Events involving the same actor (e.g., successive policy instruments issued by the same government ministry, or sequential product releases by the same corporation) do not constitute coordination between actors and are outside CC scope. Where the same actor appears in both events, the relationship is internal sequencing, not inter-actor coordination.

This requirement applies to all seven CC types. Model family lineage (successive versions of the same AI model by the same developer), corporate product roadmap execution, and intra-governmental policy cascades within a single ministry are documented through event metadata (versioning, succession) rather than Coordination Connections.

Structural co-membership. Framework Family (Type 6) documents structural co-membership within a designated programme or institutional framework — a relationship that is bidirectional and non-causal, distinct from the sequential and causal patterns described above. Where two events share a common implementing entity, the distinct actor test applies as follows:

Where the distinct actor test produces a FAIL for a candidate Framework Family CC, the structural relationship between the events is recorded through event metadata (shared programme attribution, parent framework identification) rather than through a Coordination Connection.

The distinct actor test is assessed at the entity level: a subsidiary and its parent company are the same actor for CC purposes unless the subsidiary operates with documented strategic autonomy in the relevant domain, consistent with the subsidiary clause applied in the SCP framework (§5.3.2). Separate legal entities under common control — including entities controlled by the same natural person — are likewise the same actor for CC purposes where documented resource sharing ties their operations, with the same strategic-autonomy exception.

9.1.7 Independent Adoption Check

Before classifying any CC at Types 1–6, the analyst considers whether both events may have arisen independently in response to common conditions rather than through a direct inter-event relationship. Where independent adoption cannot be ruled out and no documentary evidence establishes the inter-event connection, the relationship is assessed under Type 7 (Parallel Policy) rather than a documentary type. Where documentary coordination evidence exists between the actors but does not establish the specific inter-event connection, the routing rule at §9.4.3 applies.

9.1.8 Corporate Product Release Scope Limitation

Corporate product releases — including AI model launches, software platform deployments, and hardware product announcements — are market actions, not coordination mechanisms. Product releases are outside the scope of Coordination Connection assessment across all seven CC types.

Corporate instruments — power purchase agreements, infrastructure buildout programmes, procurement contracts, strategic investments — remain assessable where they satisfy the applicable CC type definition and evidence requirements.

Where coordination occurs in temporal proximity to a product release, the coordination is captured through the events that document the coordinating instruments, not through the release itself.

9.2 Connection Type Taxonomy

9.2.1 Connection Types

Type 1: Policy Cascade

Definition: A higher-authority event mandates, directs, or creates implementation requirements for a lower-level event.

Direction: Parent → Child (hierarchical)

Evidence Requirements (any single route is sufficient):

• Child event explicitly cites parent event as legal/policy basis
• Parent event issues directive requiring child event’s actions
• Implementation relationship documented in official sources

The three evidence routes are operationally equal — each independently establishes the cascade relationship. Where evidence is found through any route, the confidence level is determined by the evidence’s documentary character: direct citation by instrument number or title supports CC-V; evidence requiring interpretation of official sources (e.g. directive language in the parent instrument referencing national implementation without naming the specific child event) supports CC-E.

Confidence levels: CC-V and CC-E. Policy Cascade is a documentary CC type; CC-A (analytical) is not available.

Example Patterns:

• Central government framework → Ministry implementation plan
• Enabling legislation → Regulatory rule
• International agreement → National implementation

Linguistic Markers:

• English: “pursuant to,” “in accordance with,” “implementing,” “as required by”

• Chinese: 落实 (luòshí), 贯彻 (guànchè)

  Note: 根据 (gēnjù, “pursuant to / based on”) and 依照 (yīzhào, “in accordance with”) are context-dependent — each may indicate Policy Cascade or Regulatory Enablement depending on the Authority Level relationship. Apply the Authority Hierarchy decision rules to resolve. For 根据 chains exceeding the standard temporal window, the §9.4.1 accommodation applies to Regulatory Enablement connections.

Type 2: Joint Issuance

Definition: Multiple distinct entities publish a single unified document that constitutes one coordinated policy act.

Direction: Bidirectional (co-equal parties)

Evidence Requirements:

• Single document with multiple issuing authorities
• Shared document number/reference
• Coordinated publication date

Example Patterns:

• Inter-ministerial joint regulation
• Bilateral MOU with mutual commitments
• Multi-agency enforcement guidance

Distinction from Parallel Policy: Joint Issuance = One document, multiple signatories Parallel Policy = Multiple similar documents, separate issuers

Type 3: Funding Flow

Definition: Event A provides financial resources that directly enable or support Event B.

Direction: Funder → Recipient

Evidence Requirements:

• Budget allocation document specifying recipient
• Grant award citing funding source
• Contract/procurement record linking events
• Minimum attribution: 10% of Event B’s funding traceable to Event A

Example Patterns:

• Appropriations bill → Infrastructure project
• Investment programme → Corporate buildout
• Research grant → Technology development

Threshold Rationale: 10% minimum prevents trivial linkages whilst capturing meaningful dependencies. Derived from OECD “contributes to” standard, supported by convergent international regulatory precedent (see Methodology Rationale, Section 9.4.2).

Type 4: Regulatory Enablement

Definition: Event A creates the legal, regulatory, or procedural basis that makes Event B possible.

Direction: Enabler → Enabled

Evidence Requirements:

• Event B cites Event A as enabling authority
• Event A creates permissions/authorities exercised in Event B
• Regulatory pathway established by Event A, utilised by Event B

Example Patterns:

• Export control exemption → Technology transfer
• Licensing framework → Permitted activity
• Standards adoption → Conformant products

Distinction from Policy Cascade:

• Policy Cascade: Higher authority directs lower-level implementation (mandatory compliance)
• Regulatory Enablement: Creates possibility/permission that recipient chooses to exercise (enabling but not mandating)

Authority Hierarchy for Policy Cascade vs Regulatory Enablement

Decision Principle: Policy Cascade applies where the source instrument directs or mandates the target; Regulatory Enablement applies where it creates permissions the target chooses to exercise. Authority Levels (AL-1 to AL-6) support the determination where source language is indeterminate.

Authority Hierarchy (Descending):

Authority Levels (AL-1 to AL-6) classify the binding force of source documents.

Decision Rules:

1. Language character governs: Where the source instrument directs, mandates, or requires implementation → Policy Cascade. Where it enables, authorises, appropriates, or creates permissions exercised by the target → Regulatory Enablement. Language character governs regardless of Authority Level difference.

   • Example: Primary legislation (AL-3) → Agency implementation rule (AL-5) = Policy Cascade where the legislation mandates; Regulatory Enablement where the legislation appropriates

2. Adjacent Levels (1 AL difference): Examine language

   • If Target Event uses mandatory implementation language (“pursuant to,” “implementing,” 落实) → Policy Cascade
   • If Target Event uses permissive language (“authorised under,” “enabled by,” 依照) → Regulatory Enablement

3. Same Level: Default to Regulatory Enablement unless explicit hierarchical language present

4. Cross-Jurisdictional: International agreements (AL-1) creating national implementation (AL-3 to AL-5) = Policy Cascade

Chinese Framework Equivalent:

Document Type Hierarchy: 法律 (Law) > 法规 (Regulation) > 规章 (Rule) > 通知 (Notice) > 意见 (Opinion)

Ambiguous Hierarchy: If hierarchy remains unclear after applying these rules, classify as Regulatory Enablement.

Type 5: Response

Definition: Event B is a direct, deliberate reaction to Event A, taken with intent to counter, signal, or impose costs.

Direction: Trigger → Response

Evidence Requirements:

• Official statement explicitly identifies Event A as trigger
• Response timing within applicable Response Band (see §9.4.1)
• Response entity has documented awareness of trigger event

Example Patterns:

• Export control → Retaliatory restriction
• Sanctions designation → Counter-sanctions
• Standard exclusion → Alternative standard creation

Temporal Window: Response timing is governed by Response Bands calibrated to the response evidence type. See Section 9.4.1 for Response Band definitions and application.

“Official Statement” Evidence Standard:

For Response connections, “official statement explicitly identifies Event A as trigger” requires:

Qualifying Sources (in priority order):

1. Government press release from official .gov/.gov.xx domain
2. Official gazette or register publication
3. Regulatory filing preamble or explanatory memorandum
4. Official spokesperson attribution in verified news sources (named spokesperson, official capacity)
5. Verified official social media account (ministry-level or above)

Non-Qualifying Sources:

• Unnamed government sources
• Leaked documents
• Think tank analysis or academic inference
• News media characterisation without official attribution
• Personal social media accounts (even of officials)

“Explicit Identification” Standard:

The official statement must identify the trigger event through ONE of:

Insufficient Identification:

If the official statement uses euphemistic or generic language without sufficient specificity to uniquely identify the trigger event, no Response connection is documented.

Examples of insufficient identification: - “In response to certain foreign measures” - “Responding to discriminatory trade practices” - “In light of recent international developments”

If explicit identification emerges in subsequent official statements, the connection may be added at that time.

Type 6: Framework Family

Definition: Events are formally part of the same standards suite, regulatory family, or institutional framework.

Direction: Bidirectional (sibling relationship) or Parent → Member (where the parent framework document is itself a WEO event)

Sibling↔︎sibling applies where two events are co-members of a framework and neither event is the parent framework document (e.g., two standards within a numbered series, two awards under a subsidy programme).

Parent→member applies where one event is the parent framework document and the other is a designated component (e.g., a national infrastructure programme designating specific facilities as programme components, where the programme document establishes membership without providing direct funding or regulatory authority). Parent→member Framework Family CCs capture programmatic designation — the formal identification of an event as a component of a defined programme or framework — where that designation is the substantive inter-event connection. Parent→member CCs use direction: "source_to_target" with the parent event as source.

Redundancy rule: Where a parent↔︎member relationship is already documented through another CC type (Policy Cascade, Funding Flow, or Regulatory Enablement) between the same event pair, a Framework Family CC is redundant and is not created. Framework Family parent→member CCs document structural programme membership where no other CC type captures the relationship.

Evidence Requirements (any one of the following suffices, provided it meets CC-V formal designation standard):

• Common numbering/naming convention: Standards sharing a designated number range that constitutes a recognised series (e.g., ISO 42001, ISO 42002, ISO 42005, ISO 42006 within the “42000-series”). Standards with different numbering under the same committee (e.g., ISO/IEC 5338, ISO/IEC 8183, ISO/IEC 23894 — all under SC 42 but with distinct numbering) do not qualify via this pathway alone.

• Explicit cross-reference in standards body documentation: For ISO/IEC standards, this means citation in the Normative References section (Section 2 / Clause 2), where “some or all of [the referenced document’s] content constitutes requirements of this document” (ISO/IEC Directives, Part 2). For Chinese national standards (GB/T series) under SAC/TC260, the equivalent is the 规范性引用文件 (Normative Reference Documents) section, which uses functionally equivalent binding language: “构成…必不可少的条款” (“constitutes an indispensable clause”). The same evidence standard applies: only references in the normative section qualify; body-text mentions, informative annexes, bibliography entries, and introduction footnotes do not constitute “explicit cross-reference.”

• Parent framework document identifies both as family members: A governing document that explicitly designates both events as components of a defined framework or programme. For legislative/regulatory contexts: the enabling legislation or regulation itself. For institutional contexts: a formal founding document or charter that names member entities. A standards body committee’s administrative portfolio catalogue does not constitute a “parent framework document” — it indicates administrative co-location within a committee’s governance, not formal framework membership.

Example Patterns:

• ISO/IEC AI standards series (42000-range shared numbering, or normative Section 2 cross-references)
• Chinese GB/T AI standards under TC260 (connected via 规范性引用文件 normative references; decentralised cluster topology rather than single hub)
• EU AI Act + implementing regulations (legislation as parent framework)
• Chinese 1+N framework components (State Council document as parent framework, where “N” documents cite the directive by document number in operative provisions)
• Multilateral AI safety institute network (founding declaration as institutional framework)
• National semiconductor subsidy act + individual awards (legislation as parent framework)

For empirical derivation: See Methodology Rationale, Section 9.2.

Type 7: Parallel Policy

Definition: Similar events occur in different jurisdictions without formal coordination.

“Different jurisdictions” means different sovereign entities or, for non-governmental bodies, different institutional entities. Events produced by the same standards body, regulatory agency, or institutional framework are within the same institutional jurisdiction for Parallel Policy purposes. Same-body events that lack Framework Family evidence are classified as having no qualifying connection (DNQ) rather than being assessed under Parallel Policy. Similarly, events funded by the same legislative programme are same-jurisdiction — they should be assessed under Framework Family (with the legislation as parent framework document) rather than Parallel Policy.

Direction: Bidirectional or unidirectional (depending on evidence)

Evidence Requirements:

• Substantive similarity in policy design, scope, or targets
• Temporal proximity (within window specific to the event’s WEO Domain — see Section 9.4.1)
• No evidence of explicit coordination between the two events (domain-level coordination evidence between the actors is recorded as analytical context — see §9.4.3)

Confidence Level: CC-A (Analytical) — floor and ceiling. Parallel Policy is the sole analytical CC type; the CC-A level is the logically entailed confidence for a determination based on structural similarity rather than documentary proof (§9.3.2). Where coordination evidence exists between the actors, the routing rule at §9.4.3 applies.

Similarity Assessment Criteria:

• Mechanism similarity (same policy tool type — mandatory gate)
• Industry similarity (same industry per industry tagging system, Chapter 7)
• Scope similarity (comparable geographic/sectoral reach)
• Timing overlap (within domain-specific temporal window — see Section 9.4.1)

Minimum Threshold: Criterion 1 (Mechanism Similarity) must be met. Of the remaining three criteria, at least two must be met (minimum 3 of 4 total).

For empirical derivation: See Methodology Rationale, Section 9.2.

Synthesis Sources

Category: WEO-original synthesis (verified novel IP)

The seven CC types were synthesised from multiple independent source frameworks, with each type validated across 3+ systems:

Novelty Status: A systematic novelty review (December 2025) verified CC as the first typed event-to-event relationship taxonomy applied to AI infrastructure coordination. No existing platform (GDELT, ICEWS, ACLED, Stratfor, Eurasia Group, etc.) implements comparable typed event-to-event relationship categories.

For detailed IP analysis: See Methodology Rationale, Section 9.

9.3 Confidence Levels

9.3.1 Confidence Level Definitions

Coordination Connections use a distinct confidence classification to avoid confusion with WEO’s event verification Tier A/B/C system:

CC-A Evidence Requirements for Parallel Policy (Type 7):

For Parallel Policy connections, CC-A confidence requires: - Primary source documentation for each connected event (minimum 1 per event) - Documented criteria assessment across all 4 similarity dimensions (mechanism, industry, scope, timing) - Explicit rationale for each criterion determination, including the sub-category characteristic(s) identified for Criterion 1 and the shared industry tag(s) for Criterion 2 - Criterion 1 (Mechanism Similarity) met as mandatory gate - Total criteria score ≥3/4, with Criterion 1 always among the met criteria

Terminology Note: CC-V/CC-E/CC-A are used exclusively for connection confidence to distinguish from event verification Tiers (A/B/C) and strategic significance Tiers (1/2/3).

Where §9.2.1 provides a type-specific confidence determination method, that method governs. The §9.3.1 source requirements are the default for CC types without type-specific provisions.

9.3.2 Minimum Confidence by Connection Type