AI Ledger
Hepburn Advisory
Hepburn Advisory
AI Ledger
Hepburn Advisory
Hepburn Advisory
The Ledger reconciles each AI layer to customer-paid revenue because that is the clearest denominator: money customers actually paid. Capital is split between annual spend on the Overview and cumulative stock on the Capital Ledger. Usage is notional at list price. Compute is realised provider revenue. Power is shown both as a dollarised operating layer and as a physical GW constraint. Every multiple on the site is [layer] ÷ $24B.
The Overview reconciliation starts with customer-paid AI revenue because it is the cash line the rest of the system must ultimately justify. Capital is investment committed before revenue arrives. Usage is activity, some paid and some not. Compute is supplier-side revenue earned from serving demand. Power is the physical and dollar constraint required to deliver it. The spine compares annual 2025 layers against the same revenue baseline; Capital separately retains a cumulative stock view because infrastructure is a balance-sheet asset, not only a one-year flow.
How we build the numbers, where they come from, and how confident we are.
Projections are directional arithmetic, not forecasts. Benchmarks are dated and sourced. Each derived metric defaults to a documented method; every assumption is editable. Where a number appears on a Ledger page, that page is the canonical source. This page describes how those numbers are built, not what they are at any given moment.
The AI Ledger tracks the AI industry through five interlocking ledgers. The Capital Ledger follows how much is being spent to build AI infrastructure — semiconductors, data centres, networking. The Revenue Ledger tracks what comes back — who earns what from selling AI products and services. The Compute Ledger follows who sells AI compute and what it earns. The Usage Ledger estimates actual consumption — tokens processed, models served, inference volume. The Power Ledger accounts for the electricity required to serve it all. Together they answer: how much is going in, how much is coming out, who provides the compute, how much is being used, and can the grid supply it?
Anchored from NVIDIA Data Centre revenue (Tier 1A), which sets the silicon floor. Cross-checked against MSFT, GOOG, META, and AMZN 10-K capital expenditure filings. Silicon represents approximately 55% of total CapEx; the remainder covers power, construction, and networking. Current total system CapEx is published on the Capital Ledger.
Entity-by-entity rollup sourced from earnings calls, SEC filings, and investor presentations. Revenue uses collected-revenue methodology. Never run-rated or exit-ARR. Consumer vs. enterprise split informed by The Information reporting and company segment disclosures. Each entity carries its own provenance tier; current quarterly aggregate is on the Revenue Ledger.
Hyperscaler AI cloud + neocloud + Oracle OCI revenue, published both gross-disclosed and net of model-lab pass-through per the principal/agent verification gate described below. Direct frontier-API revenue (OpenAI / Anthropic API direct) stays on the Revenue Ledger; only the cloud-margin leg is in Compute. Each provider's disclosed figures are held with their filing reference and re-read each reporting cycle. Current quarterly aggregate is on the Compute Ledger.
Multi-model consensus methodology tracking 14 providers. Primary anchors: OpenRouter public throughput statistics and NVIDIA inference throughput disclosures. China accounts for approximately 50% of global volume. No single provider discloses full usage data, so all figures are Med or Low confidence. Current daily-volume range is published on the Usage Ledger.
Forward demand triangulated across three independent methods: anchored projection from third-party 2026 baselines (~76 GW), silicon-shipments bottom-up, and operational tokens × FLOPs. Variance across methods is published as a health metric rather than hidden. Supply is built up from interconnection-queue data and named projects with per-row provenance. The demand model, the supply stack and the named-project list are all published in the underlying dataset. Current curves and the supply gap are on the Power Ledger.
The Compute Ledger decomposes hyperscaler + neocloud AI revenue into three segments so the page can publish the right number for the right question. Headline aggregates are post-Copilot. Copilot-class revenue is per-seat productivity SaaS, scoped to a future Apps Ledger.
Pass-through rule. Pass-through is the lab rev-share applied to Hosted model APIs, not to total AI revenue. An earlier version of this page applied the pass-through percentage to gross AI revenue and reported ~$11.5B for 2025. That overstated it by roughly 10×. Most hyperscaler AI revenue is direct compute spend (Frontier lab and AI workload) rather than token-API resale. Corrected pass-through is ~$1B for 2025, and corrected net ~$44.5B, on the sum-of-quarterlies post-Copilot basis with the segment sizing set out below.
Copilot scope-out rule. M365 Copilot, GitHub Copilot, Copilot Studio (MSFT); Gemini-in-Workspace SKUs (GOOGL); equivalent embedded-AI-feature productivity lines elsewhere. These are per-seat SaaS, not Compute. They are deducted from each provider's disclosed AI line, and the deduction is published alongside it. They flow to a future Apps Ledger when that is built; until then they are tracked but not published on the Compute page. AWS does not have a named productivity Copilot line; default deduction is 0 unless a specific embedded-AI line is identifiable in the 10-Q. Scope-out uses MS-declared values (not TAIL-derived) so the deduction matches what is in the reported AI run-rate.
Principal/agent verification gate. Before publication, the revenue recognition policy notes from the most recent 10-K are read for AWS, MSFT (Azure), GOOGL (Cloud), and ORCL (OCI). For each, principal (gross) vs. agent (net) treatment under ASC 606 is confirmed. All four reviewed entities use principal treatment for AI reseller arrangements (verified 06/05/2026, and recorded beside the published figures). Treatment is re-verified each cycle as 10-Ks are refiled.
Direct frontier-API revenue sits outside Compute. When Bedrock resells Claude, AWS keeps the cloud margin (Compute, Hosted model APIs net); Anthropic gets the rest (Model revenue). When a customer calls Anthropic directly, 100% is Model revenue with the underlying compute showing on AWS/GCP P&Ls as Frontier lab compute. This avoids ecosystem-level double-counting between Compute and Apps/Model Revenue.
Sizing was previously done with editorial AI-share weights — AWS AI taken as 15% of AWS revenue, and so on. Since 06/05/2026 each provider's AI line has been built bottom-up from its own segments instead. Approach by provider:
The Anthropic equity gain on Alphabet's Q1 2026 P&L ($36.9B) is investment income, not Cloud operating revenue (per Fortune, 30/04/2026), and does not inflate the GCP AI line. The CoreWeave figure includes ~$3.8B of Microsoft-sub-rented capacity that is also recognised as AWS / Azure compute revenue elsewhere; under each entity's revenue-recognition policy both legs are real revenue lines on each company's P&L, so the ecosystem total is gross of that overlap by definition. We surface it separately rather than try to net it out at the Compute layer.
For each provider, the 2025 calendar AI line is published on a sum-of-quarterlies basis — the four reported (or derived) 2025 quarterly AI revenues summed. We chose this over the alternative annualised run-rate basis (year-end exit run-rate × 4), even where the run-rate number is the figure CEOs prefer to disclose. Why: in a year of accelerating growth, sum-of-Q is materially smaller than annualised. Microsoft's 2025 calendar AI is $25.25B sum-of-Q against $28B annualised exit, a gap of about 10%; Amazon and Google sum-of-Q ≈ annualised because their growth shape doesn't diverge as much. If the trajectory chart anchored Q1 2026 at $9.25B (= disclosed $37B run-rate ÷ 4) but forced the four 2025 quarters to sum to $28B, Q4 2025 would have to balloon above $9.25B, producing a visible quarter-on-quarter drop into Q1 2026 that contradicts the +123% year-on-year growth.
On this basis every major provider's quarterly trajectory rises into Q1 2026 without a false dip. The annualised run-rate figure is not lost. It is kept beside each provider as context. The layer stack and the trajectory chart both use the sum of the four quarters.
The Layer Stack visual on /compute publishes cohort Apps Revenue (the Revenue Ledger's total customer revenue, ~$17.36B as at 06/05/2026), not an editorially-extended ecosystem total. An earlier version used a Tier 2A 5× multiplier ($17.4B → $100B) to bridge the cohort to "enterprise SaaS AI ARR". That multiplier had no provenance trail, and the ratio swung ±25% on a single editorial constant. The corrected page shows the cohort number as-is and flags the cohort-vs-ecosystem gap as a future-Apps-Ledger scope. All four Layer Stack layers are on lookback 2025 actuals on the same time-basis (sum-of-quarterlies for compute, FY26 calendar 2025 for silicon) so the multipliers between layers are apples-to-apples.
The Revenue Ledger Sankey routes per-entity revenue across channels (Model Subs / Model API / Hyperscalers / AI Native Apps / Trad. SaaS) and into buyer segments (Consumer / AI Natives / Enterprises & Govs / VC-Investors). Until 06/05/2026 the routing applied a flat 70/30 Model API / Hyperscalers split to every provider's API revenue. That weighting is roughly right for enterprise customers (who buy Bedrock / Azure OpenAI / Vertex for compliance and procurement) but wrong for AI Natives. Cursor, Glean, Perplexity and Harvey go ~95% direct to OpenAI or Anthropic, for cost and latency. Because the cohort is mostly AI Natives, the flat 30% Hyperscalers weight inflated the Hyperscalers channel to $3.63B. The flat split was replaced on 06/05/2026 with per-archetype weights, so each entity now routes through the channels its real customers use.
Every entity in the cohort is tagged with one archetype. The taxonomy:
| Archetype | What it covers | API share to Hyperscalers | Enterprise share to Hyperscalers | API share to AI Natives |
|---|---|---|---|---|
| Frontier lab | Foundation-model labs (OpenAI, Anthropic, Google/Gemini, Mistral, xAI, Cohere, DeepSeek, etc.) | 5% | 50% | 70% |
| AI native | AI-native scale-ups built on frontier APIs (Cursor, Glean, Perplexity, Harvey, ElevenLabs, Suno, Runway, Midjourney, etc.) | 10% | 20% | 30% |
| Enterprise SaaS | Traditional SaaS layering AI features (Salesforce, ServiceNow, Adobe, Notion, Microsoft Copilot, Databricks, etc.) | 50% | 60% | 0% |
| Hyperscaler | Cloud providers (AWS, Azure, GCP) and neoclouds (CoreWeave, Lambda, Crusoe, Nebius) — Sankey treats these as compute providers, not buyers | — | — | — |
| Infrastructure as a service | Token-API aggregators / inference infra (Together, Fireworks, Groq, Replicate, Modal, OpenRouter) | 0% | 50% (default) | 50% |
| Consumer app | Pure consumer chat surfaces. Rare as a standalone; usually rolled under Frontier lab via the subscription share | 0% | 50% (default) | 50% |
The channel weights and the buyer-segment weights are both published in the underlying dataset. Each provider is tagged with its archetype, and the routing applies the matching weights. An untagged entity falls through to a conservative default of 15% Hyperscalers and 85% Model API on the API leg, and 50/50 on the enterprise leg. Under-counting the Hyperscalers channel is editorially safer than over-counting it.
Buyer relabel. The Who-Pays column previously showed Consumer / SME / Enterprise. SME conflated AI-native scale-ups (heavy API consumption, light headcount, no traditional SaaS revenue) with small businesses; the new buckets — Consumer / AI Natives / Enterprises & Govs / VC-Investors — name what sits on the demand side of the AI economy. Subscription revenue routes to Consumer; API revenue splits between AI Natives and Enterprises & Govs per archetype; enterprise contracts route to Enterprises & Govs.
Reconciliation against the Compute Ledger. On these weights the Revenue Ledger Hyperscalers channel lands at ~$1.7B (gross). After the 20% hyperscaler take-rate, that implies ~$1.36B of cohort lab revenue passing through Hyperscaler resale. That is comparable to the Compute Ledger Hosted-model-APIs pass-through (~$1B) within tier 2A noise. The remaining ecosystem Hosted-model-APIs gross (~$4.35B) covers non-cohort enterprise spend (Fortune 500 buying Bedrock / Azure OpenAI outside the 9-source cohort) and is documented on the Compute Ledger but out of scope for the Revenue Ledger cohort.
Since 06/05/2026 any aggregate published on the site must be checked against the parallel figure on adjacent Ledgers. Where the two differ, the gap is closed by showing the bridge between them, never by quietly re-tuning a number. The three reconciliations below are published in full, so a reader can check each pair without working the bridge out for themselves.
The Compute Ledger trajectory chart shows realised quarterly compute revenue (e.g. MSFT $9.25B in Q1 2026 — $37B run-rate ÷ 4). The Compute Ledger now also surfaces a separate Forward commitments block that reports the multi-year contracted order book — Google's RPO ($242.8B → $467.8B Q4 25 to Q1 26, +$225B QoQ), Anthropic's $200B five-year deal with Google, and the ~$718B Anthropic and OpenAI have together committed to the three largest hyperscalers (Microsoft, Amazon and Google). These two views describe overlapping economic reality on different time bases. Bridge: contracted dollars convert into realised quarterly compute revenue over the contract life of each booking (typically 1–8 years); they are not Q1 26 revenue and would double-count if mixed into the trajectory bars. The trajectory chart and the forward-commitments block are reconciled by being kept on separate surfaces with the relationship explicit.
The Capital Ledger shows realised hyperscaler capex (cumulative 2023–25 ~$745B; 2025 calendar ~$380B). The Compute Ledger forward-commitments block also tracks hyperscaler→lab equity investment — Google→Anthropic cumulative ~$43B, Amazon→Anthropic cumulative ~$33B (incl. contingent), AWS→OpenAI Feb 2026 $13B + up-to $20B more. These dollars are not additive to capex: most of the equity round flows back to the same hyperscaler as compute commitment (Anthropic-Google $200B/5yr is funded in part by Google's equity into Anthropic). Bridge: equity investment is a separate balance-sheet line from PP&E capex and we do not add the two figures. The circular flow (hyperscaler equity into a lab, the lab's compute commitment back to the hyperscaler, and the capex realised over time) is reconciled by tagging each leg separately rather than presenting a single "AI investment" total.
M365 Copilot's published 2025 number on TAIL was previously $5.4B ARR (15M paid seats × $30/mo × 12). The Azure billing leak reported by Zitron on 06/05/2026 put actual revenue an order of magnitude lower. On 07/05/2026 the published M365 Copilot number was restated as a three-band structure:
| Band | 2025 USD | Basis | Tier |
|---|---|---|---|
| List billings | $7.2B | 20M paid seats × $30/mo × 12 (post-Q1 FY26 seat refresh) | 1A |
| Bundling-adjusted incremental | $2.5–3.5B | Net of Copilot pricing absorbed into existing E5 / SKU bundles | 2A |
| Leaked actual (PRIMARY) | $1.2–1.5B (midpoint $1.35B) | Leaked Azure billing per Zitron, 06/05/2026 (Q2 FY25 $367M, Q3 FY25 $300M) | 1B |
The published value on TAIL is $1.35B (leaked-actual midpoint), with list and bundling-adjusted bands carried as comparison context. Bridge to the Compute Ledger. The Compute Ledger's Copilot scope-out for 2025 ($6.67B) is Microsoft's own declared exclusion (what Microsoft leaves out of the Azure AI revenue line) and is on a different basis (list-billings level, includes M365 Copilot ~$5.4–7.2B + GitHub Copilot ~$1.65B + Studio/Sales/Service residual). The Trad. SaaS Apps Ledger view uses leaked actuals; the Compute Ledger uses MSFT's own scope-out. The two are not the same number and are no longer presented as though they were. The full bridge is published with the Compute Ledger's disclosures.
Why this matters. Before the restatement, the M365 Copilot $5.4B figure flowed through to the layer stack and to the Apps Revenue-to-Compute multiplier. The leaked-actual restatement reduces the published Copilot line by ~75% and increases the apparent spread between announced AI-product revenue and economically-realised AI-product revenue across the enterprise SaaS stack. That spread is now visible by design.
The Power Ledger publishes a forward demand curve from 2026 to 2030 and a supply pipeline of named, dated builds. The demand curve is the part that needs methodology, because no single source measures global AI power demand directly. It has to be inferred. Three independent methods are run side-by-side, and the variance between them is published as a health metric rather than hidden.
The 2026 baseline is set from third-party published anchors (IEA Energy & AI, BloombergNEF and SemiAnalysis) at ~76 GW of AI-attributable data-centre IT load, with a range of ~64–88 GW. The published anchor is Tier 2B because it is a triangulation of independent measured estimates rather than a single first-party disclosure. Anchor sources are surfaced inline on the Power Ledger page; the full list is published with the demand model in the underlying dataset.
From the 2026 anchor, demand for each forward year grows along compute-spend growth divided by efficiency gain:
demandT = anchor2026 × (computeT / compute2026) × (efficiency2026 / efficiencyT)
The compute-spend track comes from the Compute Ledger (sum-of-quarterlies basis, post-Copilot). The efficiency track decomposes into hardware FLOPS-per-watt gains (Tier 2B, anchored on observed accelerator generation cadence) and software efficiency gains (Tier 2B–3A, modelled on observed tokens-per-FLOP improvements at the frontier-model level). The anchor is the absolute level; the chain provides relative growth. There is no tuning constant. The anchor ratios (Compute/Apps net, Compute/Apps gross, Silicon/Compute) are published with the demand model, together with the utilisation assumption and the power-overhead factor (PUE), which is the ratio of total facility power to the power reaching the servers.
Independent of apps revenue. The silicon base is merchant silicon (NVIDIA Data Centre + AMD Instinct + custom AI ASIC + AI networking, ~$224B 2025, Tier 1A) uplifted by ~50% for hyperscaler internal accelerator fleets (Google TPU, AWS Trainium, Meta MTIA, Microsoft Maia — Tier 2B because internal fleet sizes are not publicly disclosed). Silicon dollars convert to GPU-equivalents using fleet average dollar-per-GPU, retire over a five-year asset life, then multiply by watts per GPU × power-usage-effectiveness × utilisation, and divide by the combined hardware-plus-software efficiency curve. The derived series is published with the demand model.
This method captures the silicon-attributable share of AI power. It deliberately under-counts ecosystem-wide AI power because it excludes data-centre overhead beyond that factor, ad-platform AI workloads not riding on merchant accelerators, and inference run on CPU-class hardware.
The industry token aggregate (~310 trillion tokens per day in 2025, Tier 1B from OpenRouter throughput plus NVIDIA inference disclosures) multiplied by FLOPs per token and divided by FLOPs per watt yields the inference-power line. Training compute adds ~30% on top (Tier 2B; training is FLOPS-saturated, so only hardware efficiency applies; software-efficiency gains help inference, not training). Forward growth tracks apps revenue rather than the compute-spend chain because token volume scales with end-user usage, not the infrastructure build-out. The inference and training splits are published separately.
The three methods describe overlapping reality on different definitional scopes:
Variance across the three methods is published on the Power Ledger as a health metric, stated as variance against the median of the three. The gap is a cohort-versus-ecosystem definitional gap, not a model error. Shrinking it by quietly re-tuning one method to hit the others would defeat the point of running them independently.
Demand is one half; supply is the other. The interconnection-queue data, lead times, and named-project tables on the Power Ledger come from primary grid-operator and operator disclosures — EirGrid (Ireland), EMA (Singapore), AEMO (Australia), ERCOT (Texas), CAISO (California), and equivalents in Japan, Germany, the UK, the Netherlands, and the UAE. Every row in the queue, lead-time and announced-project tables carries its own provenance tier and retrieval date. The cumulative supply curve on the chart is built by stacking deployed capacity, projects under construction, announced projects, and queued projects, in that confidence order. The gap between supply and demand is the published page's headline finding rather than something the methodology smooths over.
The Ledger surfaces two distinct revenue measures for AI providers, and they are not interchangeable. Mixing them is the most common mistake when reading frontier-AI financials.
| Measure | Definition | Where it surfaces | Time orientation |
|---|---|---|---|
| ARR (run-rate) | Trailing-quarter revenue × 4. Forward-looking proxy for the next 12 months at the current pace. | Usage Ledger hero stat ("Combined Provider ARR"), the per-provider chart bars, and the revenue figure on each provider tile. | Forward-looking |
| Collected revenue (audited) | GAAP-style revenue booked over a fiscal year. Backward-looking, audit-grade. | Home page headline ("$24B of customer-paid AI revenue, 2025") and Revenue Ledger sankey; per-provider year-keyed entries on /timeline. | Backward-looking |
The two measures typically diverge by 5–6× for frontier model providers because ARR captures the latest quarter annualised (currently growing rapidly) while collected revenue captures the audited annual figure (which lags). For example, OpenAI's reported ARR was around $25B (Q1 2026 run-rate) while its 2025 collected revenue was around $4.3B. The same company, two different numbers, both correct for what they measure. The Ledger keeps both and labels each surface explicitly.
Year-keyed audited revenue (Anthropic's 2026 collected revenue at $6B, for example) surfaces in the timeline's FY revenue section rather than on the dashboard tile. That is an editorial choice. The dashboard tile carries run-rate only, because the dashboard answers "current state at run-rate". Audited year figures belong on the timeline, where the time orientation is explicit.
A company appears on one of three surfaces depending on what kind of company it is, because the same twelve columns cannot describe an AI application, a frontier lab and a GPU cloud. Each surface reads the same vault and each states its own basis.
| Surface | Who is on it | What it measures | How it is shaped |
|---|---|---|---|
| Applications | The application layer, in three bands: AI-native companies, established software companies selling AI, and comparison classes. | Run-rate revenue on a net basis, funding, pricing model, repricing exposure and evidenced regional presence. | Table. A band switch changes the row set, the headline figure and the category lens together; each band totals on its own basis and only the AI-native band feeds the index headline. |
| Model providers | Frontier labs. A profile requires a run-rate backed by a dated, graded claim; the rest are listed as a roster. | Run-rate and collected revenue, operating loss and burn, funding chain, valuation basis, compute commitments and related-party flows. | One profile per company, not a table. A lab's record is cost structure and commitments, which a row of columns flattens into nothing. |
| Compute providers | Hyperscalers, neoclouds, token factories and bare-metal GPU providers — the same set the Compute Ledger reports. | Gross disclosed revenue and revenue net of the apps carve-out, as two figures; backlog, capacity and evidence grade. | Table, quarter-based. The gross and net figures are never collapsed into one, and the gap between them is its own column. |
Both provider surfaces publish a figure that sits alongside one the Revenue Ledger already publishes, and each states its bridge on the page rather than leaving a reader to reconcile two numbers:
A figure held in our records is not the same as a figure we can publish. Where a company's revenue is not traceable to a dated, named source, the company still appears, in a roster or with an explicit blank, and the reason is stated. A blank is a finding about the record, not a zero, and it is never filled with an estimate to complete a column. Where a company sells no such product at all, that is said plainly rather than rendered as $0.
Every datapoint carries a single confidence value (High, Med or Low) and is rendered as one pill in the colour grammar shared with the Hepburn Advisory site.
| Confidence in data | Pill rendered as | Colour |
|---|---|---|
| High | T1 High | Green |
| Med | T2 Med | Amber |
| Low | T3 Low | Violet |
This is a simplified surface signal. The richer provenance taxonomy below (1A through 4) is the underlying classification framework. Every datapoint is classified against that detailed scheme, then mapped down to the High / Med / Low pill that ships on the page. Splitting the two axes (provenance separate from confidence) is V1.1 work, deferred.
Every data point in the AI Ledger carries a provenance tier. This is the underlying classification. It tells you where the number came from and how much weight to give it. The single-axis pill above is derived from this.
| Tier | Label | Definition |
|---|---|---|
| 1A | Authoritative | First-party disclosure — earnings report, regulatory filing, official press release |
| 1B | Corroborated | Two or more independent reporting sources agreeing within ~15% |
| 2A | Derived | Deterministic calculation from Tier 1 inputs (e.g. subtracting known segments from a reported total) |
| 2B | Triangulated | Value squeezed by multiple Tier 1 anchors setting upper and lower bounds |
| 3A | Anchored projection | Trend extrapolation from a Tier 1 or Tier 2 base point |
| 3B | Interpolated | Curve fit between two Tier 1 anchor points |
| 3C | Scenario assumption | Hand-picked rate or ratio — an explicit editorial choice, documented |
| 4 | Editorial | Round-number guess, carried only until better data arrives |
Primary sources used to construct the ledgers. Each source is classified by category, update frequency, and provenance tier.
| Source | Category | Frequency | Tier |
|---|---|---|---|
| NVIDIA 10-Q / earnings | CapEx anchor (DC revenue) | Quarterly | 1A |
| MSFT/GOOG/META/AMZN 10-K | CapEx cross-check | Annual | 1B |
| MSFT Copilot ARR disclosure | Revenue | Quarterly | 1A |
| OpenAI investor disclosures | Revenue | Irregular | 1B |
| Salesforce Agentforce ARR | Revenue | Quarterly | 1A |
| OpenRouter API | Token throughput | Daily | 2A |
| Epoch AI GPU tracking | China GPU estimates | Periodic | 3C |
| SEC filings (various) | Revenue, CapEx splits | Quarterly | 1A |
| The Information / WSJ | Revenue leaks, ARR estimates | Irregular | 1B |
| CoreWeave S-1 | Utilisation, pricing | One-time | 2A |
Transparency about our limits is part of the methodology. These are known gaps that we track but do not claim to have resolved: