# R3CKON: complete documentation --- --- Generated from the same sources as https://r3ckon.com/docs and /methodology. --- --- # Overview R3CKON is a ledger for the environmental footprint of AI usage. It does three things, every month, for every account: 1. **Meters** your AI usage from metadata alone (models, token counts, regions). 2. **Estimates** the usage-phase water, carbon, and energy cost of that usage with a public, versioned methodology, always shown with its uncertainty range. 3. **Retires** third-party-issued environmental certificates against the conservative end of that estimate, and issues a certificate documenting exactly what was funded and what you may say about it. The product is deliberately not a neutrality badge. The footprint is an estimate with a wide, honestly stated range; the retirements are exact, documented instruments. The ledger keeps the two sides related but never equated, and every claim the platform supports is an activity claim: what was estimated, what was funded, identified by project and vintage. ## Who it is for - **Individuals** who use AI heavily and want a real record rather than a feeling (Personal tier, self-report or API connections). - **Teams and AI-native products** with API usage and, increasingly, customers or boards asking about AI's environmental cost (Team and Business tiers, managed provider connections). - **Enterprises** with reporting obligations, negotiated volume, and audit support needs. ## The loop, in one pass - Usage arrives from managed provider connections (Anthropic, OpenAI, Google), from the metering API, or from self-report in the console. All three paths carry token metadata only; content-shaped payloads are rejected at the API boundary. - The methodology converts usage into water (gallons), carbon (kg CO2e), and energy (kWh) estimates. Every figure carries a 90 percent plausible range, and every estimate stores the exact coefficient values used, so historical numbers stay reproducible forever. - At each monthly close, the obligation accrues at the 90th percentile of the estimate range (P90) and whole registry units are retired against it: Water Restoration Certificates, carbon credits, and Renewable Energy Certificates. Buffer inventory is drawn first; supplier orders cover any shortfall. - A four-section certificate documents confirmed retirements, the estimate that sized them, required disclosures, and the exact statements the record supports. ## Glossary - **Billable tokens**: fresh input + output + 10 percent of cached input. Reasoning tokens are a subset of output, so they are never counted twice. Tier caps count billable tokens, so cache-heavy workloads are not overcharged. This is a fixed billing rule, deliberately separate from the estimation methodology. - **P50 / P90 / the range**: the methodology outputs a probability distribution, not a number. P50 is the median (central estimate). P90 is the retirement accrual basis: nine tenths of the probability sits below it. The whisker on every chart spans P05 to P95, the 90 percent plausible range. - **Retirement**: permanently taking a registry instrument out of circulation, on your behalf. Retirements are whole units only; fractional obligations carry forward. - **Confirmed vs pending**: a funded supplier order awaiting registry confirmation is pending. Certificates report confirmed retirements only; pending orders never support any public statement. - **Buffer**: company-owned retired inventory drawn on before new supplier orders. Customers are never billed for buffer fills. - **Certificate-share floor**: at least 50 percent of subscription revenue to date is spent acquiring certificates, measured cumulatively at actual supplier cost, trued up at each monthly close, and disclosed on the certificate. - **Usage-phase footprint**: the metric covers inference only. Model training, hardware manufacturing beyond an amortized embodied-carbon adder, network transport, and end-user devices are out of scope and disclosed as such. ## What this is not - **Not a neutrality claim.** An estimate this uncertain cannot honestly be declared settled, so the platform never says it is, and the Terms license customers to say only what the record supports. - **Not a measurement.** Providers do not disclose per-token energy or water. Figures are modeled estimates with stated ranges, per the [methodology](/methodology). - **Not always local.** Projects live where they live. Restoring one watershed does not un-consume water in another, and certificates state project geography rather than implying it away. ## Where to go next - [Quickstart](/docs/quickstart): a working ledger in ten minutes. - [Connecting usage](/docs/connecting-usage): the three ingestion paths. - [Metering API](/docs/metering-api): the developer reference. - [Methodology](/methodology): every constant, formula, and source. --- # Quickstart From zero to a working ledger in about ten minutes. > Checkout is not yet open: the steps below describe how the product works > at launch. Today, the [demo console](/demo) is the way to explore. ## 1. Create an account Pick a tier on the [pricing page](/pricing) and complete checkout. Tiers are priced on billable tokens per month, never on footprint, and certificate retirements are bundled: there are no per-credit charges. After payment you land on a welcome page that shows your **console key exactly once**. Copy it somewhere safe immediately: only a hash is stored, so it cannot be shown again. If it is lost, write to info@tahosasystems.com from your billing email and it will be rotated. ## 2. Sign in to the console Open the [console](/console) and paste your key. Everything in the console is scoped to your account: charts, certificates, connections, invoices, and the full connection setup guide. ## 3. Get usage flowing Three paths, in order of preference (details in [Connecting usage](/docs/connecting-usage)): 1. **Managed connection** (best): in the Managed connections card, choose Anthropic, OpenAI, or Google, paste a read-only admin credential, and press Sync window for your first pull. After that, a daily sync runs automatically. 2. **Metering API**: push daily aggregates from your own infrastructure with one authenticated call. See the [metering API reference](/docs/metering-api). 3. **Self-report**: enter monthly token totals from your provider's usage dashboard in the Report usage card. No code, no credentials. ## 4. Read your dashboard Footprint bars rise to P90, the retirement accrual basis; the shade change marks the median, and whiskers span the 90 percent plausible range. The retirement strip below shows whole units retired per month, kept deliberately separate from the estimates. See [Reading the console](/docs/console). ## 5. What happens automatically - Managed connections re-sync daily (a trailing three-day window, replaced idempotently, so provider reporting lag is absorbed). - At each monthly close, the period's obligation accrues at P90, whole units are retired (buffer first, supplier orders for shortfall), your certificate is issued, and your subscription covers it all. At least half of the subscription is spent acquiring certificates, and the achieved share is printed on the certificate. - Billing is managed by your Stripe subscription; the Manage billing button in the console opens the customer portal for card changes or cancellation. ## If something looks wrong - A connection showing `error` displays the provider's message in the Connections card; re-adding with the same label rotates the credential. - Estimation never blocks your AI usage: the platform holds no proxy position in your traffic, so a lapsed sync or subscription affects your ledger, never your tools. --- # Connecting usage The ledger needs one thing from you: token metadata. Model names, token counts, regions, timestamps. Never prompts, never completions; anything content-shaped is rejected at the API boundary (see [Security](/docs/security)). There are three ways in, in order of preference. Exact credential walkthroughs live inside the console (every tier, including preview accounts, sees them); this page tells you what each path needs and what it pulls. ## 1. Managed provider connections (preferred) Paste one read-only credential per provider and the platform pulls daily token aggregates automatically. Up to 50 distinct connections per account; contact us beyond that. A daily auto-sync re-pulls a trailing three-day window for every connection, replacing the window idempotently so provider reporting lag never duplicates events. ### Anthropic (available) - **Credential**: organization Admin API key (`sk-ant-admin…`), read-only, scoped to usage reporting. - **What we pull**: daily tokens by model and service tier, with cache reads split out and counted at the cached-input discount. Extended thinking is billed inside output tokens by Anthropic, so nothing is hidden and no conservative multiplier fires. - **Plans**: API organizations connect; Claude Pro or Max (consumer) has no usage API, so individuals self-report. ### OpenAI (available) - **Credential**: organization Admin key (`sk-admin…`), read-only. - **What we pull**: daily tokens by model, cached input reported separately, Batch API traffic mapped to the batch service tier. o-series reasoning is billed inside output tokens. - **Plans**: API organizations connect; ChatGPT Plus or Pro has no usage API, so individuals self-report. ### Google (available) - **Credential**: a service account JSON key holding only `roles/monitoring.viewer` on the Cloud project. Paste the whole file. - **What we pull**: daily Vertex AI / Gemini token counts by model and region from Cloud Monitoring. This metric does not split out context cache reads or thinking tokens, so both are recorded as unreported, which fails toward conservatism in the estimate and the billable-token count rather than pretending they are zero. - **Plans**: Cloud projects connect; the Gemini consumer app has no usage API, so individuals self-report. ### Rotation and removal Re-adding a connection with the same label replaces its credential. Removing a connection deletes the encrypted credential; usage already ingested for closed periods is retained, because it is the billing and estimate record. ## 2. The metering API Push daily aggregates from your own gateway or infrastructure (OpenRouter, LiteLLM, Bedrock, self-hosted models) with one authenticated call. Include cached and reasoning token counts when you have them; omitted fields are treated as unreported, never as zero. Full request and response shapes: [metering API reference](/docs/metering-api). ## 3. Self-report in the console No code, no credentials: enter monthly token totals straight from your provider's usage dashboard or billing page. This is the right path for individuals on consumer plans and for anyone evaluating before wiring a connection. It is deliberately the least preferred source: connected data is fresher, more granular, and harder to mistype. Self-reported figures are recorded as customer-supplied, and the certificate states the token basis of every period. ## Which path am I? - **Personal**: usually self-report (consumer plans expose no usage APIs); the metering API if you build with API keys. - **Team and Business**: managed connections for each API organization, the metering API for gateways and self-hosted models, self-report to fill gaps. - **Enterprise**: managed connections plus a reviewed ingest plan across providers, gateways, and regions. --- # Metering API reference Base URL: `https://r3ckon.com` The metering API accepts usage **metadata** and nothing else. It exists so gateways, self-hosted stacks, and internal pipelines can feed the ledger without a managed provider connection. ## Authentication Every request carries a bearer key: ``` Authorization: Bearer aiok_ingest_… ``` Keys are account-scoped and role-scoped: - `aiok_admin_…`: full console access plus every API below. This is the key revealed once at signup. - `aiok_ingest_…`: may push usage (both ingest endpoints) but cannot read the console or manage the account. - `aiok_sdk_…`: may push to the SDK feed only. Only a SHA-256 hash of each key is stored. Rotation is currently by request (info@tahosasystems.com) after billing-email verification. ## POST /api/v1/ingest/authoritative The billing-grade feed: daily (or coarser) aggregates that estimates, retirements, and invoices are computed from. ```bash curl -X POST https://r3ckon.com/api/v1/ingest/authoritative \ -H "Authorization: Bearer $R3CKON_KEY" \ -H "Content-Type: application/json" \ -d '{ "events": [{ "apiConnection": "anthropic", "model": "claude-sonnet-5", "region": "us-east-1", "inputTokens": 18400000, "cachedInputTokens": 12100000, "outputTokens": 2300000, "reasoningTokens": 410000, "serviceTier": "standard", "timestamp": "2026-08-04T00:00:00Z" }] }' ``` Response: `{ "accepted": 1 }` ### Event fields | Field | Type | Required | Notes | |---|---|---|---| | `model` | string (1..200) | yes | The provider's model identifier, verbatim. Unknown models estimate under the registry's most conservative class. | | `inputTokens` | integer >= 0 | yes | The FULL input stream, including any cached portion. | | `outputTokens` | integer >= 0 | yes | Completion tokens. | | `region` | string (1..64) | yes | Cloud region code when known (e.g. `us-east-1`). Unrecognized values estimate under conservative unknown-facility parameters. A recognized code selects that cloud's published facility profile, which can lower the estimate relative to the unknown default, so report the region truthfully; region values are recorded with the event and are auditable. | | `timestamp` | ISO 8601 datetime with offset | yes | The period the aggregate covers (use the day start for daily buckets). | | `cachedInputTokens` | integer >= 0 | no | The cached SUBSET of `inputTokens`. Omitted means unreported, not zero. | | `reasoningTokens` | integer >= 0 | no | The reasoning SUBSET of `outputTokens`, where the provider reports it (never billed twice). Omitted means unreported; for reasoning-class models that triggers the methodology's conservative hidden-reasoning multiplier. | | `serviceTier` | `standard` \| `batch` \| `priority` | no | Batch and priority tiers carry their own energy multipliers. | | `apiConnection` | string (1..64) | no | Which source produced this usage; groups the console's per-API filters. Accounts support up to 50 distinct connections. | | `endUserPseudoId` | string (<=128) | no | An opaque pseudonymous id if you segment end users. Never send anything identifying. | ### The content boundary (HTTP 422) Every payload is deep-scanned before parsing. If any key anywhere in the JSON matches a content-shaped name (`prompt`, `completion`, `content`, `messages`, `message`, `text`, `input`, `output`, `system`, `body`, `response`, `query`, `answer`, `transcript`), the request is rejected with `422` and nothing is stored: ```json { "error": "Ingest rejected: payload contains content-shaped key \"prompt\". This platform is metadata-only and must never receive prompt or completion content." } ``` This is an architectural invariant, enforced by tests, not a policy. ### Idempotency and re-submission Managed connections replace their (connection, window) slice atomically on every sync. For your own pushes, the same practice applies: if you need to restate a day, re-push the whole day's aggregates for that `apiConnection` after deleting nothing; duplicate submission of the same window will double-count, so push each window once or contact us to reset a window. ### Errors | Status | Meaning | |---|---| | `400` | Malformed JSON, missing `events` array, or field validation failure (message says which). | | `401` | Missing or unknown bearer key, or a role without ingest rights. | | `422` | Content boundary violation (see above). | ## POST /api/v1/usage-events The SDK feed: identical body and validation, accepted from `sdk`, `ingest`, or `admin` keys. It powers live views and is **never billed from**; billing and retirement always come from the authoritative feed. ## Account APIs The console is built on account-scoped APIs authenticated with your `aiok_admin_…` key. The stable, supported surface today: - `GET /api/admin/overview`: everything the dashboard shows, as JSON: monthly footprint with P05/P50/P90/P95 per category, retirements, credit position, invoices, certificates, connections, filters. - `GET /api/admin/connections` / `POST` (create) / `DELETE /api/admin/connections/{id}` / `POST /api/admin/connections/{id}/sync` with `{ "periodStart": "YYYY-MM-DD", "periodEnd": "YYYY-MM-DD" }`. - `GET /api/admin/certificates/{id}/pdf`: the certificate PDF. - `GET /api/admin/exports/{name}`: reporting CSVs (water restoration summary, CDP Water and ESRS E3 inputs). - `POST /api/admin/billing-portal`: a Stripe customer portal session URL. These return JSON errors in the same `{ "error": "…" }` shape. Endpoints not listed here (reconcile, seeding) are operator-only and may change. --- # Reading the console Everything on the dashboard exists to keep two different kinds of facts honest at once: modeled estimates (with uncertainty) and exact retirements (without any). This page explains each element. A public, read-only [demo console](/demo) shows all of it with synthetic data. ## Monthly usage-phase footprint Three charts: Water (gallons), Carbon (kg CO2e), Energy (kWh), one bar per month. - **The bar rises to P90**, the retirement accrual basis for every account. - **The shade change** inside the bar marks P50, the central estimate. The lighter segment above it is deliberate conservatism headroom, not a higher belief about the footprint. - **The whisker** spans P05 to P95, the 90 percent plausible range. It ships with every figure; hovering a bar shows the numeric range with both ends in the same unit scale. - The estimates credit cache reads at the methodology's cached-input coefficient and apply conservative treatment where providers hide reasoning tokens; banner notices appear when the model-registry disclosure threshold (over 15 percent unclassified tokens) or the hidden-reasoning multiplier fired. ## Filters The API multi-select and date range filter every figure on the page at once. The cap readout shows billable tokens against your tier cap (billable = fresh input + output + 10 percent of cached input; reasoning tokens are a subset of output, never double-counted). ## Retirement history Whole registry units retired per month, one panel per category. Solid bars are confirmed retirements, the only kind certificates report; dashed outlines are funded orders awaiting supplier confirmation. This strip is deliberately separate from the estimate charts: retirements are exact instruments, estimates are modeled, and the two are never overlaid. ## Credit position Per category: units retired to date, pending fulfillment, buffer coverage, and the carryover obligation (fractions below a whole unit roll forward to the next close). Categories never mix; there is no combined score. ## Invoices One local invoice per closed period, mirroring your Stripe subscription charge. Self-serve accounts are charged by the subscription itself, never twice. The Manage billing button opens the Stripe customer portal for card changes, invoice history, and cancellation. ## Certificates Each closed period's four-section certificate, downloadable as PDF and JSON. See [Certificates](/docs/certificates) for the anatomy. ## Managed connections and Report usage Add provider connections (Anthropic, OpenAI, Google), trigger a manual sync for any window, remove or rotate credentials, or self-report monthly totals. The full setup guide renders below these cards inside the console. ## Close a billing period Operator tooling for the monthly close: aggregate the period, accrue at P90, retire (buffer first, then supplier orders), enforce the certificate-share floor, issue the certificate, and invoice. Every step is journaled and idempotent; re-running a closed period changes nothing. --- # Certificates Each monthly close issues one certificate per account: a PDF for humans and a byte-for-byte equivalent JSON document (schema 2.0.0) for systems. It is an activity record with exactly four sections, and it is engineered so the strong assertion (what was retired) is never blurred with the modeled one (what was estimated). ## Section A: Retirements Confirmed retirements only, grouped by category, each with the approved statement, project attribution as the supplier presents it (project name, registry code, vintage), and the supplier reference. Water, carbon, and renewable energy never share a block, no cross-category totals exist, and RECs are never presented as carbon credits. A funded order awaiting supplier confirmation appears in the console as pending but **never on a certificate**. When it confirms, the period's certificate regenerates to include it. ## Section B: Basis of quantity What sized the retirements: the methodology version (pinned), the period's token counts by model class, and the three estimates with their central values and 90 percent ranges. The estimate disclaimer and the usage-phase scope note are required adjacencies: the software cannot render a figure without them, and CI fails if it could. Methodology notices (unclassified model share over 15 percent, hidden-reasoning multiplier) appear here when they fired. ## Section C: Required disclosures Standing disclosures the record depends on, rendered from the same configuration the software enforces: - Water geography: restoration occurs in the project watershed identified in Section A, which may differ from the watersheds where AI infrastructure consumes water. - REC resource type and the supplier's certification disclosure status. - The FTC two-year timing disclosure, when a funded reduction occurs two or more years after purchase. - The certificate-share floor line: what percent of the account's subscription revenue to date has been spent acquiring certificates (measured cumulatively at actual supplier cost), against the 50 percent commitment. - That the certificate is not an audit and not a verification of the footprint estimate. ## Section D: Permitted use A plain statement of what the record supports: activity claims using the approved language in Schedule A of the [Terms](/terms), with filled examples. Statements outside the schedule are outside the license. See the [claims playbook](/docs/claims). ## Verifying a retirement 1. Take the supplier reference from Section A. 2. Contact the supplier (for water and RECs today, Bonneville Environmental Foundation) or the underlying registry with that reference; the retirement is recorded in the supplier's or registry's books in R3CKON's name, for your account's benefit. 3. Compare the project attribution and vintage on the certificate against the registry record. Customers do not take title to instruments; R3CKON purchases and retires in its own name for the customer's benefit, and whether the supplier names the customer as beneficiary of record is stated per supplier relationship. ## The JSON document The JSON mirrors the PDF field for field: `schemaVersion`, `issuer`, `accountName`, `periodStart`, `periodEnd`, and the four sections (`sectionA_retirements` with per-category entries and supplier references, `sectionB_basisOfQuantity` with figures, disclaimers, token classes and notes, `sectionC_requiredDisclosures` as a string list, and `sectionD_permittedUse`). Fetch it from the console or via `GET /api/admin/overview` (the `certificates` array), and the PDF via `GET /api/admin/certificates/{id}/pdf`. --- # Claims playbook This page is for the person who will write the blog post, the ESG slide, or the footer badge. The short version: **say what was done, never what it cancels.** Every approved statement is an activity claim, and the platform is built so the approved language is the same language the software enforces; the schedules in the [Terms](/terms) render from the same configuration file the code runs. ## The three approved statement families Filled examples of the templates (your certificate carries your period's exact versions): - **Water**: "Retired 25 Water Restoration Certificates, representing 25,000 gallons of water restoration as documented by Bonneville Environmental Foundation." Always accompanied by the geography disclosure: restoration occurs in the project watershed identified on the certificate, which may differ from the watersheds where AI infrastructure consumes water. - **Carbon**: "Retired 12 carbon credits (12 tCO2e), Jordan River Restoration Project, Utah (ACR212) Vintage 2024." Project identity is mandatory; a carbon quantity with no project behind it is outside the license. - **Renewable energy**: "Purchased and retired 31 Renewable Energy Certificates (31 MWh) from wind generation, vintage July 2026." Resource type and the supplier's certification disclosure ride along, and REC figures never sit in the same block as carbon figures. Estimates may be quoted only as estimates, with the range: "Our AI usage this quarter is estimated at 41,000 gallons of water (90 percent plausible range 9,000 to 210,000), per R3CKON methodology 1.0.0." ## Why the banned list exists The software scans every buyer-facing surface for banned phrases, and the claim license excludes them for customers. The categories, and the reason each fails: - **Status and neutrality vocabulary**: any phrasing that assigns your footprint a settled status (neutral-style, net-style, zero-style, or positivity claims about water). They assert an equation the evidence cannot support: the footprint is an estimate with a range that can span an order of magnitude, while the retirements are exact. Equating them is exactly the claim regulators and courts have been dismantling. - **Verbs of cancellation and compensation**: any verb that says the retirement undoes, erases, or balances away the footprint. Same equation, verb form. Also, "offset" applied to water or RECs is categorically wrong: WRCs restore water somewhere, they do not un-consume yours, and a REC is a renewable generation attribute, not a carbon instrument. - **Unqualified evaluatives**: broad feel-good labels attached to AI (green-, clean-, eco-styled adjectives). Unfalsifiable, and the FTC Green Guides treat unqualified general environmental benefit claims as deceptive. - **Precision overclaims**: any language presenting the figures as measured, actual, or exact. Nobody outside the providers can measure this; claiming precision the methodology does not have would poison the honest parts of the record too. ## Required adjacencies Some statements are licensed only with a companion, and the renderer throws rather than emit one without the other: | Figure | Must appear with | |---|---| | Any estimate | Its 90 percent range and the modeled-estimate disclaimer with methodology version | | Water retirement | The watershed geography disclosure | | REC retirement | Resource type and supplier certification status; never in a carbon block | | Carbon retirement | Project identity (registry, project, vintage) | | Reduction two or more years out | The FTC timing disclosure | ## The regulatory backdrop, in one paragraph The FTC Green Guides (16 CFR Part 260) treat unqualified environmental benefit claims and unsubstantiated offset claims as deceptive. California AB 1305 requires public disclosures from sellers of voluntary carbon offsets and from companies making certain climate claims; R3CKON publishes its seller [disclosures](/disclosures) and generates the records customers need. The EU's Directive 2024/825 restricts generic environmental claims and claims that a product has neutral, reduced, or positive environmental impact based on offsetting. Activity claims with named projects, quantities, vintages, and stated uncertainty are the form designed to survive all three. ## Quick dos and don'ts - Do: "This month we funded the retirement of 40 carbon credits (Project X, Vintage 2024) against our estimated AI footprint." - Do: publish the certificate itself; it is written to be quoted. - Don't: put any statement about your AI being neutral, matched, or compensated anywhere near these records. - Don't: total water, carbon, and energy into one number, or describe RECs as reducing emissions. - Don't: drop the range when quoting an estimate. --- # Billing One flat monthly subscription per tier. No per-credit charges, no top-up lines, no surprises indexed to estimate size. Pricing is deliberately thin: a small line item next to your AI bill, with at least half of subscription revenue to date spent on the certificates themselves. > Checkout is not yet open; these are the planned launch tiers and they may > change before launch. ## Tiers | Tier | Price | Billable tokens / month | Retirements | |---|---|---|---| | Free | $0 | 10M | Estimates only | | Personal | $12/mo | 25M | Bundled, accrued at P90 | | Team | $55/mo | 100M | Bundled, accrued at P90 | | Business | $435/mo | 1B | Bundled, accrued at P90 | | Enterprise | Custom | Above 1B | Negotiated volume, named projects | ## Billable tokens Tier caps count billable tokens, not raw tokens: ``` billable = fresh input + output + 10% x cached input ``` Cache reads cost providers about a tenth of the compute, and counting them like fresh tokens would overcharge exactly the teams that engineered their usage well. The 10 percent rate is a fixed billing rule, deliberately separate from the estimation methodology: revising a methodology coefficient can change an estimate, never your bill. **Cache-heavy example**: 4,000M tokens tracked, 93 percent cache reads. Billable = 280M fresh and output + 372M (10 percent of 3,720M cached) = 652M, which fits the Business tier despite four billion raw tokens. **Reasoning-heavy example**: 60M input + 30M output (of which 25M are reasoning tokens), no caching. Billable = 90M, which fits the Team tier. Reasoning tokens are a reported subset of output tokens, so they are already inside the output count and are never added again; they matter to the footprint estimate, not to the bill. ## Why tokens, never footprint Your bill depends only on token counts you can audit from your provider's own reporting. No coefficient in the methodology can influence revenue, so the estimates stay honest and so does the price. ## The certificate-share floor At least 50 percent of your subscription revenue to date must have been spent acquiring environmental certificates: retired for your benefit, or purchased into retirement buffer inventory when your usage needed less than the floor. The share is measured cumulatively on a cash basis at actual supplier cost (never a price table), and any shortfall is trued up with an additional purchase at each monthly close, rounding up to whole units so the floor is met rather than approached. The cumulative achieved share is recorded at every close and printed on your certificate. It is a spending commitment on the subscription price, not a representation about footprint coverage, which is governed by the estimate basis stated on the certificate. ## At the cap Estimation continues past the cap; nothing is gated or interrupted. Retirements accrue up to the cap, and sustained billable usage above it moves you to the next tier at the following billing period, with notice. The certificate always states the token volume the period's retirements were accrued against. ## Managing the subscription The Manage billing button in the console opens the Stripe customer portal: card changes, invoice history, and cancellation. If service lapses, your AI tools are unaffected (the platform never touches your traffic); the ledger simply stops accruing retirements, and your history and certificates remain accessible. ## Annual billing Annual billing with two months free is available on Team and Business; write to info@tahosasystems.com. --- # Security and data handling The security story is unusually short because the architecture refuses most of the data other tools hold. ## Metadata only, by construction The platform ingests model names, token counts, regions, and timestamps. It never proxies your AI traffic, never sits between you and your provider, and never receives prompt or completion content. Every inbound payload is deep-scanned before parsing: any key anywhere in the JSON with a content-shaped name (`prompt`, `messages`, `text`, `response`, and the rest of the list in the [metering API reference](/docs/metering-api)) is rejected with HTTP 422 and nothing is stored. The usage-events table has no content columns, and a test asserts its exact column list, so the invariant cannot erode quietly. Two practical consequences: - A breach of this platform cannot leak your prompts; they were never here. - An outage of this platform cannot interrupt your AI usage; it holds no position in your request path. ## Credentials Managed-connection credentials (provider admin keys, Google service account keys) are encrypted at rest with AES-256-GCM. The encryption key lives only in the application environment, never in the database, so the database alone cannot decrypt a credential. Credentials are write-only through the API: they are never returned, and removal deletes the ciphertext. Only read-only, usage-scoped credentials are requested in the first place (Anthropic and OpenAI admin usage keys; Google `roles/monitoring.viewer`). Console keys are stored as SHA-256 hashes. The one-time signup reveal stores the key encrypted only until you view it, then clears it. ## Payment data Card details go directly to Stripe and never touch this platform; the database stores Stripe token references only. Subscriptions, card changes, and cancellation run through Stripe's hosted surfaces. ## Data layer Postgres (Supabase) with row-level security enabled on every table and policies scoped to a dedicated application role; the public PostgREST roles have no policies and no access. Certificates, estimates, and the double-entry ledger are append-oriented: every credit movement is recorded as balanced postings, and reconcile asserts the ledger balances on every run. ## Subprocessors - **Vercel**: application hosting. - **Supabase**: Postgres database. - **Stripe**: payments, invoices, tax. - Certificate suppliers (Bonneville Environmental Foundation) receive purchase orders, not your usage data. ## Retention Usage metadata, estimates, ledger entries, and certificates are retained as the account's permanent record: they are the substantiation for published claims and stay reproducible under the methodology version that produced them. Connection credentials are deleted on removal. Account deletion requests: info@tahosasystems.com (billing-email verified). ## Reporting a vulnerability security@tahosasystems.com (or info@tahosasystems.com). Please include reproduction steps; we commit to acknowledging within two business days. --- # Footprint Estimation Methodology **Version:** `1.1.0` **Published at:** https://r3ckon.com/methodology **Basis:** METHODOLOGY-AND-CLAIMS-SPEC v1.0 (2026-08-05). Constants and their provenance live in `src/core/methodology/configV1.ts`; every value carries a central estimate, a 90 percent plausible range (P05 to P95), a system boundary, a source, and a confidence grade. This methodology is intended to be revised continually as better public data becomes available. Every revision is versioned: a historical estimate always remains reproducible under the version that produced it, and prior versions remain published here. ## Metric The **usage-phase (inference) footprint** of AI API traffic, estimated from metadata only (model identifier, token counts, region, timestamp). This is a bounded metric, not a cradle-to-grave one. **In scope:** accelerator and server energy, idle and reserve serving capacity, facility overhead (PUE), on-site cooling water, off-site water embedded in electricity generation, operational carbon at location-based grid intensity, and an amortized embodied-carbon adder for hardware manufacturing. **Out of scope, disclosed:** model training (see below), hardware lifecycle beyond the adder, network transport (under roughly 5 percent), and end-user devices. Training is excluded because per-token amortization for heavily served models is small, the denominator (lifetime inference tokens) is unknowable from outside[5], and public calibration data covers a single model[6]. The metric is therefore named usage-phase footprint everywhere, never "the footprint of AI." ## Pipeline ``` classify model (pinned registry) -> model class (provider prefixes normalized) resolve coefficients (with boundaries) -> per-token Wh, uplifts, PUE, WUE, grid zone token accounting -> fresh + cached input, output (reasoning is a reported subset of output, never re-added) IT energy (accelerator boundary) -> token terms summed, residual per-class spread shared factors (applied exactly once) -> x evidence-family factor (fully correlated across classes) x idle/reserve uplift boundary normalization -> x PUE (IT -> facility) water -> on-site: IT-boundary kWh x WUE (Green Grid definition) off-site: facility kWh x grid water intensity carbon -> facility kWh x (per-zone grid intensity + embodied adder) uncertainty -> closed-form lognormal propagation, P05/P50/P95 persist -> estimate + every resolved coefficient + version ``` Estimates are pure functions of (metadata, version). Every stored estimate persists the resolved coefficients actually used, so any historical number is reproducible by reading, not re-deriving. ## Uncertainty Two families of evidence for per-token energy disagree by roughly an order of magnitude: top-down provider disclosures (Google's published median Gemini prompt figures[1]; Epoch AI's GPT-4o estimate[2]; Mistral's lifecycle report[4]) imply low values, while parametric per-token fits (EcoLogits-style[3]) imply high ones. Batching, hardware generation, and mixture-of-experts serving explain most of the gap, but it is unresolved. Centrals sit nearer the top-down family; P95 reaches the parametric family. Because that family-level disagreement affects every model class the same way, it is carried by a single shared evidence-family factor (central 1.0, 90 percent range 0.45 to 2.2) applied exactly once per estimate, fully correlated across classes; each per-token coefficient contributes only its residual, class-specific spread. Without this factoring, summing classes would treat the shared dispersion as independent noise and understate the tails. As measured on the 1.1.0 estimator, composed 90 percent intervals span roughly 10 to 12 fold for energy and carbon and roughly 20 to 27 fold for water (which stacks WUE and grid-water uncertainty on top). Every displayed figure carries its range. All coefficients are modeled lognormal. Products propagate exactly; sums use Fenton-Wilkinson moment matching[8]. A customer's monthly total is aggregated by summing token counts per coefficient group first and applying coefficient uncertainty once, because coefficient error is fully correlated across a customer's events and does not average out. Retirement obligations accrue at the 90th percentile of the modeled parameter distribution (P90) for every account: at credit prices this costs little and it buys deliberate conservatism headroom over the central estimate. The interval covers the methodology's stated parameter uncertainty only; structural uncertainty (model form, tokenizer differences, the treated-as-independent PUE/WUE pair, unregistered models, and the excluded scope) sits outside it by construction, which is why P90 accrual is described as a quantile of the modeled range and never as guaranteed coverage. There is no lower election. Under token-tier pricing with retirements bundled, a lower quantile would not change the subscription price; it would only reduce the quantity retired and weaken the statement the certificate supports, so the option does not exist. The console's footprint bars rise to P90, the accrual basis, with a shade change marking the median (P50). Accrual at P90 is labeled as retiring against a quantile of the estimate range, never as guaranteed coverage. Subscription pricing keys on billable tokens (fresh input + output + 10 percent of cached input; reasoning is a subset of output and never counted twice), never on footprint magnitude. The 10 percent cached rate is a fixed billing rule defined in pricing, deliberately distinct from this methodology's cached-input coefficient, so no coefficient here can influence revenue. ## Calculation For a usage event with fresh input tokens i, cached input tokens c, and output tokens o (reported reasoning tokens are a subset of o and never add a separate term), in model class m on facility profile f: ``` E_raw = i·e_in(m) + c·e_in(m)·k_cache + o·e_out(m)·[k_hidden if reasoning-class and reasoning unreported] E_raw = E_raw · k_tier (batch or priority service tier, if any) per-class coefficients enter as residuals; the shared evidence-family factor F_family and the idle/reserve uplift then apply exactly once: E_IT = E_raw · F_family · U_idle (accelerator -> IT-equipment boundary) E_fac = E_IT · PUE(f) (IT -> facility boundary) Water = E_IT[kWh] · WUE(f) + E_fac[kWh] · W_grid (liters; reported in mL) Carbon = E_fac[kWh] · ( I_grid(zone) + A_embodied ) (gCO2e, location-based; embodied is an adder in gCO2e/kWh, not a multiplier) Energy = E_fac (Wh, facility boundary) ``` Every symbol is a lognormal coefficient from the tables below except token counts, which are metered and exact. Uncertainty propagates in closed form: ``` fit: mu = ln(central) sigma = ( ln(p95/central) + ln(central/p05) ) / 2 / 1.6449 (balanced two-sided) if a physical floor exists: sigma = min( sigma, (mu - ln(floor)) / 1.6449 ) residual: for per-class coefficients, sigma_residual = sqrt( max(sigma^2 - sigma_family^2, 0) ) product: mu = sum(mu_i) sigma = sqrt( sum(sigma_i^2) ) sum: Fenton-Wilkinson moment matching: S_mean = sum(exp(mu_j + sigma_j^2/2)) S_var = sum((exp(sigma_j^2) - 1) · exp(2·mu_j + sigma_j^2)) sigma_S = sqrt( ln(1 + S_var/S_mean^2) ) mu_S = ln(S_mean) - sigma_S^2/2 quantile: P_q = exp( mu + z_q·sigma ) (z_0.05 = -1.6449, z_0.5 = 0, z_0.9 = 1.2816, z_0.95 = 1.6449) ``` Monthly totals sum token counts per coefficient group first and apply coefficient uncertainty once (full correlation across a customer's events), then combine groups with Fenton-Wilkinson[8]. ## Constants Generated from `src/core/methodology/configV1.ts` (methodology 1.1.0). Every value is a lognormal coefficient; the table shows the MODELED quantiles (the median and the 90 percent range the estimator actually integrates over, after the balanced two-sided fit and any physical floor). Boundary states what the value already includes (accelerator, server, or facility) so uplifts are applied exactly once. Full source citations accompany each value in the config file. ### Per-token IT energy (accelerator boundary) | Model class | P05 | Central | P95 | Unit | Boundary | Confidence | |---|---|---|---|---|---|---| | frontier, input | 0.0000586 | 0.0002 | 0.000683 | Wh/token | accelerator | low | | frontier, output | 0.000465 | 0.0018 | 0.00697 | Wh/token | accelerator | medium | | frontier-reasoning, input | 0.0000586 | 0.0002 | 0.000683 | Wh/token | accelerator | low | | frontier-reasoning, output | 0.000568 | 0.0022 | 0.00852 | Wh/token | accelerator | low | | mid, input | 0.0000187 | 0.00007 | 0.000262 | Wh/token | accelerator | low | | mid, output | 0.000161 | 0.0006 | 0.00224 | Wh/token | accelerator | medium | | small, input | 0.00000516 | 0.00002 | 0.0000775 | Wh/token | accelerator | low | | small, output | 0.000045 | 0.00018 | 0.00072 | Wh/token | accelerator | medium | | unclassified, input | 0.000101 | 0.00035 | 0.00121 | Wh/token | accelerator | low | | unclassified, output | 0.00101 | 0.0035 | 0.0121 | Wh/token | accelerator | low | The unclassified class is deliberately the most conservative row: unknown models route there, and above 15 percent unclassified tokens in a period the certificate carries a disclosure. ### Shared factors, uplifts, and token accounting | Constant | P05 | Central | P95 | Unit | Boundary | Confidence | |---|---|---|---|---|---|---| | Evidence-family dispersion (shared, applied once) | 0.452 | 1 | 2.21 | multiplier | accelerator | low | | Idle/reserve uplift (server folded in) | 1.13 | 1.57 | 2.18 | multiplier | accelerator | medium | | Embodied carbon adder (carbon only) | 20.4 | 50 | 122 | gCO2e/kWh facility | facility | low | | Cached-input fraction | 0.0447 | 0.1 | 0.224 | of input coeff. | accelerator | low | | Batch service tier | 0.437 | 0.6 | 0.825 | multiplier | accelerator | low | | Priority service tier | 1 | 1.15 | 1.32 | multiplier | accelerator | low | | Hidden-reasoning multiplier | 1.1 | 4 | 14.6 | on output tokens | accelerator | low | The evidence-family factor carries the shared top-down vs parametric dispersion and is applied exactly once per estimate, fully correlated across model classes; per-class coefficients contribute their residual spread. The hidden-reasoning multiplier applies to reasoning-class models whose APIs do not report reasoning token counts; the measured evidence is bimodal (roughly 1.5 to 2.6x on ordinary chat, roughly 11 to 13x on hard reasoning workloads), the single central sits between the modes because aggregate feeds cannot observe the mode, and it never defaults to 1.0. The embodied term is an ADDER in gCO2e per facility kWh, not a multiplier, because embodied share and grid intensity are anti-correlated. ### Facility profiles (PUE and on-site WUE) | Profile | PUE P05 | PUE central | PUE P95 | WUE P05 | WUE central | WUE P95 (L/kWh IT) | |---|---|---|---|---|---|---| | google-cloud | 1.03 | 1.1 | 1.17 | 0.704 | 1.15 | 1.88 | | azure | 1.04 | 1.14 | 1.25 | 0.0341 | 0.3 | 2.64 | | aws | 1.04 | 1.15 | 1.27 | 0.0194 | 0.15 | 1.16 | | direct-api | 1.08 | 1.3 | 1.57 | 0.206 | 0.9 | 3.92 | | unknown | 1.19 | 1.45 | 1.76 | 0.337 | 1.2 | 4.27 | A request whose region is not a recognizable cloud region code uses the direct-api or unknown profile; a customer-supplied region can never reduce the obligation below what a recognized mapping would produce for that location. ### Water and carbon intensity | Constant | P05 | Central | P95 | Unit | Boundary | Confidence | |---|---|---|---|---|---|---| | Off-site (grid) water intensity | 0.759 | 2.4 | 7.59 | L/kWh facility | facility | low | | Grid carbon intensity (unknown-region default) | 269 | 450 | 753 | gCO2e/kWh | facility | low | ### Grid carbon by zone (location-based annual average) | Zone | Mapped regions | P05 | Central | P95 | Vintage | Basis | |---|---|---|---|---|---|---| | eGRID:NWPP | us-west-2 | 248 | 288 | 335 | 2023 | EPA eGRID2023 rev.2 (CO2e, generation) | | eGRID:CAMX | us-west-1 | 162 | 195 | 235 | 2023 | EPA eGRID2023 rev.2 (CO2e, generation) | | eGRID:SRVC | us-east-1 | 233 | 271 | 315 | 2023 | EPA eGRID2023 rev.2 (CO2e, generation) | | eGRID:RFCW | us-east-2 | 357 | 416 | 484 | 2023 | EPA eGRID2023 rev.2 (CO2e, generation) | | EM:IE | eu-west-1 | 215 | 256 | 305 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:DE | eu-central-1 | 277 | 330 | 393 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:GB | eu-west-2 | 182 | 217 | 259 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:FR | eu-west-3 | 33.2 | 42 | 53.1 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:SE | eu-north-1 | 29.2 | 35 | 41.9 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:IN | ap-south-1 | 563 | 671 | 800 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:SG | ap-southeast-1 | 417 | 497 | 592 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:JP | ap-northeast-1 | 400 | 477 | 569 | 2025 | Ember 2025 (CO2 only, generation; range widened) | | EM:AU-NSW | ap-southeast-2 | 407 | 525 | 678 | 2025 | Ember 2025 (CO2 only, generation; range widened) | Basis note: eGRID zones are CO2e; Ember zones are CO2 only (understates CO2e by low single-digit percent, reflected in widened upper bounds), and both are generation-based direct emissions, not lifecycle. Deliberately unmapped pending primary zone data (conservative default applies): EM:CA-QC. ### Provenance Per-token energy centrals sit nearer the top-down disclosures[1][2][4], with P95 reaching the parametric family[3]. Facility PUE and on-site WUE come from the operators' own fleet reporting[9][10][11], applied under The Green Grid's WUE definition[12]. Off-site water uses generation water-intensity factors[13], with the on-site plus off-site framing following the AI water-footprint literature[14]. The embodied-carbon adder is grounded in architectural embodied-carbon accounting[15], accelerator product carbon footprints[16], and the Boavizta database[17]. Per-zone grid carbon values come from EPA eGRID subregion CO2e rates (US)[18] and Ember national generation CO2 (elsewhere)[19]. The hidden-reasoning multiplier's range reflects measured bimodality in reasoning-model output volume[7]. ## Choices - **Location-based, not market-based, grid carbon** (GHG Protocol Scope 2 vocabulary[20]): market-based figures would let provider REC matching drive obligations toward zero; location-based is more physically defensible. - **Average, not marginal, grid intensity:** the metric attributes responsibility for existing load, it does not optimize placement. The Green Software Foundation SCI specification (v1.1) permits short-run marginal, long-run marginal, or average grid intensity while excluding market-based measures; this methodology's location-based annual-average choice is consistent with that allowance[21]. - **Grid carbon values, per zone since 1.1.0:** mapped regions use primary-source annual averages with pinned vintages: EPA eGRID[18] subregion CO2e rates for US zones, and Ember[19] national generation CO2 for non-US zones. The two bases differ: eGRID is CO2e; Ember is CO2 only (missing CH4 and N2O understates CO2e by low single-digit percent, reflected in widened upper bounds), and both are generation-based direct emissions, not lifecycle. Regions without a primary-source zone value (including hydro-heavy Quebec, where a defensible zone-level figure is not yet publicly pinned) deliberately stay on the conservative unknown-region default (central 450, range 250 to 700 gCO2e per kWh) rather than borrow a flattering national average. - **Unclassified models are estimated with the most conservative class** in the table, because unknown models skew toward new frontier and reasoning models. Above 15 percent unclassified tokens in a period, certificates carry a disclosure and the console alerts. - **Hidden reasoning tokens:** for reasoning-class models whose APIs do not report reasoning token counts, output tokens are scaled by a multiplier (central 4.0, modeled 90 percent range 1.1 to 14.6, with a physical floor of 1.0 since hidden reasoning cannot reduce compute). The underlying evidence is bimodal: measured ratios cluster around 1.5 to 2.6x for ordinary chat traffic and around 11 to 13x for hard reasoning workloads[7]. Aggregate metering cannot observe which mode a given account's traffic is in, so the single central sits between the modes and the wide interval says so honestly. - **Tokenizer differences across providers (roughly 20 percent for English prose) are not normalized:** each provider's coefficients apply to that provider's own counts; the effect is second order against the coefficient interval. - **PUE and WUE are negatively correlated** (air cooling trades water for energy); they are treated as independent, which widens rather than narrows the interval, because a sourced joint distribution does not exist. - **Region honesty:** requests whose region is not a recognizable cloud region code are estimated under conservative unknown-facility parameters. A customer-supplied region can never reduce an obligation unless it maps to a known code. ## Standards This methodology **does not claim conformance** to any standard. It is informed by: the Green Software Foundation SCI shape (ISO/IEC 21031:2024)[21], including its embodied term, while deliberately diverging on marginal intensity; the GHG Protocol Scope 2 Guidance for the location-based method[20]; and The Green Grid's WUE definition[12]. It does not meet ISO 14067 or the GHG Protocol Product Standard (cradle-to-grave) and does not reference them as a basis. ISO 14064-3 third-party review is the intended path before any strengthened claim. ## Unknowables Stated plainly because every competitor faces the same wall: 1. Active parameter counts, serving hardware, and datacenter regions for closed frontier models are undisclosed; those estimates carry the full interval width. 2. Hidden reasoning token volume where APIs do not report it. 3. Site-level WUE and grid mix for unidentifiable datacenters, which is most direct API traffic. 4. Whether the top-down or parametric energy evidence family is closer to right. Only direct measurement on open-weight models will narrow it. 5. Whether restoration in one basin meaningfully addresses water consumed in another. This is a scientific and ethical question accounting cannot resolve; water claims stay activity-framed and geographically qualified. ## Changelog | Version | Date | Change | |---|---|---| | 1.1.0 | 2026-08-06 | Correlation and coefficient rebuild after independent review: shared evidence-family factor applied once per estimate (fixes P90 understatement from treating family-level dispersion as independent per class); balanced two-sided lognormal fit with physical floors; reasoning tokens treated as a reported subset of output (no separate energy or billing term); embodied carbon changed from multiplier to gCO2e/kWh adder anchored on accelerator product carbon footprints; idle/reserve uplift corrected to 1.571 [1.25, 2.4] per the fleet-level Google accounting; per-zone grid carbon from EPA eGRID2023 (US, CO2e) and Ember 2025 (non-US, CO2-only with widened bounds), unknown default widened to [250, 700]; Google WUE raised to 1.15 (fleet, not the efficient-sites subset); AWS WUE 0.15 (2024 disclosure); hidden-reasoning multiplier floored at 1.0 with bimodality disclosed; published constants table now shows modeled quantiles. | | 1.0.0 | 2026-08-05 | First reviewed methodology: coefficient provenance with boundaries, lognormal uncertainty propagation, model registry with conservative unclassified class, hidden-reasoning multiplier, WUE on IT-boundary energy, location-based grid carbon, embodied-carbon uplift, correlated monthly aggregation. | | 0.1.0-placeholder | 2026-07-29 | Prototype placeholders. Retained only to reproduce estimates recorded under that version. | ## Related - Claim language and required disclosures: `src/core/config/claims.ts`, docs/TOS-SCHEDULES.md - Known overlap disclosure: if a customer's model provider reports its market-based emissions as zero through annual REC matching and the customer separately retires RECs here, the same megawatt-hour is arguably claimed twice. The Terms require customers to disclose provider-level claims, and this document discloses the overlap. ## References 1. Elsworth et al. (Google), 2025. Measuring the environmental impact of delivering AI at Google: median Gemini Apps text prompt at 0.24 Wh comprehensive versus 0.10 Wh accelerator-only, the anchor of the top-down evidence family. arXiv:2508.15734. https://arxiv.org/abs/2508.15734 2. Epoch AI, 2025. How much energy does ChatGPT use? Independent estimate of roughly 0.3 Wh for a typical GPT-4o query, corroborating the top-down family. https://epoch.ai/gradient-updates/how-much-energy-does-chatgpt-use 3. EcoLogits (GenAI Impact). Open parametric methodology estimating per-request LLM energy from modeled parameter counts and serving hardware; the high (parametric) evidence family in the per-token energy range. https://ecologits.ai 4. Mistral AI, 2025. Lifecycle analysis of Mistral Large 2 (with Carbone 4 and ADEME): a provider-published per-response footprint used to sanity-check the evidence families. https://mistral.ai/news/our-contribution-to-a-global-environmental-standard-for-ai 5. Patterson et al., 2022. The Carbon Footprint of Machine Learning Training Will Plateau, Then Shrink: source of the operational split between inference and training for heavily served models, and why per-token training amortization is small. arXiv:2204.05149. https://arxiv.org/abs/2204.05149 6. Luccioni et al., 2022. Estimating the Carbon Footprint of BLOOM: the only full public lifecycle calibration of a large model, and the reason training amortization is treated as uncalibratable from outside. arXiv:2211.02001. https://arxiv.org/abs/2211.02001 7. ML.ENERGY / Chung et al., 2025. The ML.ENERGY measurements behind the hidden-reasoning multiplier: reasoning models emit roughly 1.5 to 2.6x a non-reasoning model's output tokens on ordinary chat and roughly 11 to 13x on hard reasoning workloads, the bimodality the multiplier's wide interval reflects. arXiv:2505.06371. https://arxiv.org/abs/2505.06371 8. Fenton, 1960. The Sum of Log-Normal Probability Distributions in Scatter Transmission Systems (IRE Transactions on Communications): the moment-matching approximation used to combine lognormal terms. https://doi.org/10.1109/TCOM.1960.1097606 9. Google data center efficiency reporting. Fleet-wide trailing PUE reporting (about 1.10), the basis of the google-cloud facility profile. https://www.google.com/about/datacenters/efficiency/ 10. Microsoft datacenter sustainability reporting. Regional fleet PUE and WUE fact sheets, the basis of the azure facility profile. https://datacenters.microsoft.com/globe/fact-sheets/ 11. AWS sustainability reporting. Fleet water use efficiency reporting (about 0.18 L per kWh), the basis of the aws facility profile. https://sustainability.aboutamazon.com/natural-resources/water 12. The Green Grid, 2011. Water Usage Effectiveness (WUE): the metric definition this methodology follows, applied to IT-boundary energy. https://www.thegreengrid.org/ 13. Macknick et al. (NREL), 2011. A Review of Operational Water Consumption and Withdrawal Factors for Electricity Generating Technologies, NREL/TP-6A20-50900: the basis of off-site (grid) water intensity. https://docs.nrel.gov/docs/fy11osti/50900.pdf 14. Li et al., 2023. Making AI Less Thirsty: Uncovering and Addressing the Secret Water Footprint of AI Models: the framing for combining on-site cooling water with off-site electricity-embedded water. arXiv:2304.03271. https://arxiv.org/abs/2304.03271 15. Gupta et al., 2021-2022. Chasing Carbon (HPCA 2021) and ACT (ISCA 2022): architectural embodied-carbon accounting, the basis of the amortized embodied adder. https://arxiv.org/abs/2201.10036 16. NVIDIA, 2024. HGX H100 product carbon footprint summary: manufacturing emissions for the dominant serving accelerator, the anchor of the embodied adder range. https://images.nvidia.com/aem-dam/Solutions/documents/HGX-H100-PCF-Summary.pdf 17. Boavizta. Open database and methodology for ICT hardware embodied impacts, cross-checking the embodied adder. https://boavizta.org 18. EPA eGRID. US subregion grid emission factors (eGRID2023 rev.2, CO2e output rates): the pinned-vintage source for US zone carbon intensities since methodology 1.1.0. https://www.epa.gov/egrid 19. Ember. National generation CO2 intensities (Ember Yearly Electricity Data, 2025 release): the pinned-vintage source for non-US zones since methodology 1.1.0. CO2-only, generation-based; the methodology widens upper bounds to reflect the missing CH4/N2O and lifecycle terms. https://ember-energy.org/data/yearly-electricity-data/ 20. GHG Protocol, 2015. Scope 2 Guidance: the location-based accounting method this methodology follows for grid carbon. https://ghgprotocol.org/scope-2-guidance 21. Green Software Foundation. Software Carbon Intensity specification (ISO/IEC 21031:2024): the metric shape this methodology is informed by, while deliberately diverging on marginal versus average intensity. https://sci.greensoftware.foundation