The build-out has a footprint too. Here's ours.
Watermark exists to put a compute build-out on the public record. Running the platform is itself compute — servers, storage, and a working set of AI models that read documents so you don't have to. We hold ourselves to the same standard we ask of the sites we track: the numbers below are published as a lead, not a verdict, and every one is labeled with how it was derived.
Built to do less, by default
Most of what cuts our footprint isn't a program — it's an architecture decision made once and inherited by every page after. In order of how much they save:
A record's structured read is computed once, at corroboration time — not re-derived every time a page is opened. Every later visit is a cache hit, not a new inference.
Pages are mostly static HTML built from the corroborated record. No client bundles re-fetching and re-rendering state on every load.
Extraction and classification run on small, task-tuned models. Large frontier models are reserved for the handful of steps that need judgment.
Document ingestion runs on a schedule against off-peak grid windows, in batches — not triggered per visitor request.
No analytics scripts, ad pixels, or session replay. Less fetched and less run, on every single page view.
Sites still in early tracking phases sit in cheaper, lower-power storage tiers until they're active investigations.
Where models touch the record
Models are scoped narrowly — to reading, not to deciding. We don't run recommendation engines, engagement scoring, or ad targeting. Four jobs, each sized to the smallest model that does it well:
Turns a scanned permit or filing into typed fields — dates, parties, figures — the record can display and cite.
Surfaces candidate sources that might confirm or contradict an open lead. Never confirms one on its own.
Answers a question against the corpus and returns it with citations back to source pages.
Turns dense source excerpts into a readable summary for a profile or timeline entry, held for editorial review.
Compute, AI, electricity & water
These magnitudes are a sample, not our footprint. The usage exports behind them are committed fixtures rather than a live pull from our cloud, CI and model providers — the derivation, the factors and the provenance are real, the quantities are placeholders. This banner disappears on its own once the provider pulls are wired: each export records whether it came from a real fetch, and the page reads that rather than being told.
vCPU-hours are the infrastructure we rent — hosting, search, CI. Model inference runs on the provider's accelerators and bills as tokens, not hours, so it appears in none of these bars; its energy is in the electricity panel's scope split.
- Structured extraction 767
- Search & Ask 418
- Corroboration assist 140
- Drafting summaries 70
Structured extraction — turning a filing into typed fields — is most of the volume; drafting is the smallest and most closely reviewed.
- Infrastructure — instances & CI · 0.0535 MWh · 97.1%
- Model inference · 0.0016 MWh · 2.9%
Inference runs on the provider's accelerators and bills as tokens, never as energy — so it is priced from published per-token measurements rather than a meter, and reported here instead of being left out of the total. Plausible range 0.0006–0.016MWh.
- Grid (regional mix) · 0.0496 MWh · 90.0%
- Matched renewable (RECs) · 0.0055 MWh · 10.0%
- Direct — on-site cooling · 1.5 gal · 5.2%
- Upstream — water to generate the power · 27.6 gal · 94.8%
We run no data center. The cooling figure is our provider's, attributed to us by the IT load we bill; the upstream figure is the water consumed generating the power delivered. The two are on composable bases, so the total is a source-basis figure — not two different measures added together.
- Location-based · our model [inference] 0.0149 MTCO2e (0.00428–0.0366)
- Location-based · provider estimate [reference] 0.045 MTCO2e
- Market-based · provider estimate [reference] 0.018 MTCO2e
Grid intensity 596.33 lb CO2e/MWh · eGRID subregion SRVC
Derived ~0.0149 MTCO2e (electricity x 596.326 lb/MWh, SRVC) vs AWS's own estimate — 0.045 MTCO2e location-based, 0.018 MTCO2e market-based. Ours is ~33% of the location-based figure. They differ by scope: our model covers billed instance compute plus model inference, whereas AWS's estimate spans every service it bills (storage, transfer, managed-service and idle-capacity overhead) and none of our inference. The market-based figure is lower because it prices AWS's contracted renewable procurement, not the physical grid — it is reported alongside the location-based one, never instead of it.
AWS Cost Explorer instance-hours (by service, folded into platform functions) converted to vCPU-hours by instance size, plus GitHub Actions minutes converted by runner core count. We run no GPU instances: model inference happens on the provider's accelerators and appears on no bill of ours as energy, only as tokens — so it is priced separately below rather than counted here.
Infrastructure: vCPU-hours x 7 W per allocated vCPU (range 2.1-12, an average-operational assumption folding utilization) x PUE 1.2 (range 1.14-1.56). Inference: output tokens x a published per-model-class Wh/1k-output-token coefficient x PUE. Each fleet's electricity is priced at its own eGRID subregion's CO2e output rate — SRVC (6,366 vCPU-hrs); the model provider does not disclose a serving region, so inference energy is attributed to the primary subregion. Every headline figure carries the band its coefficients imply. Derived ~0.0149 MTCO2e (electricity x 596.326 lb/MWh, SRVC) vs AWS's own estimate — 0.045 MTCO2e location-based, 0.018 MTCO2e market-based. Ours is ~33% of the location-based figure. They differ by scope: our model covers billed instance compute plus model inference, whereas AWS's estimate spans every service it bills (storage, transfer, managed-service and idle-capacity overhead) and none of our inference. The market-based figure is lower because it prices AWS's contracted renewable procurement, not the physical grid — it is reported alongside the location-based one, never instead of it.
We operate no data center. The cooling water below is our cloud provider's, attributed to us by billed IT load using its own published site WUE (liters per kWh of IT load — so the figure divides PUE back out rather than applying an IT-load benchmark to a facility-load number). Added to it is the upstream increment: the water consumed generating each kWh actually delivered to the facility. Site plus upstream is the source-basis total by definition; a site-basis and an already-source-basis benchmark are never summed, and the derivation refuses a benchmark row whose basis would make that happen.
The Anthropic Admin API exposes token aggregates only, so the call count is total tokens / 4000 avg tokens/call (a stated assumption), and the by-task split is modeled until the per-task workspace keys (#1080) are named so the by-workspace usage can be labeled and metered by task. The energy those calls drew is priced against OUTPUT tokens, not this count and not the input+output total: decode dominates inference energy, prefill is far cheaper per token, and no provider publishes a per-token figure — so the coefficients are third-party published estimates, banded across roughly an order of magnitude because that is the spread of what has been measured.
sources · AWS Cost Explorer + Sustainability (Jul 2025-Jun 2026) · GitHub Actions/storage billing (Jul 2025-Jun 2026) · Anthropic Admin usage + cost (Jul 2025-Jun 2026) · EPA eGRID2023 subregion SRVC factors · WUE benchmarks (AWS 2025 / EPRI 2024 / Uptime Institute 2023 / Macknick et al. 2012) · inference-energy coefficients (Epoch AI 2025-02 / Jegham et al. 2025-05 / Google 2025-08)
Same rule as everywhere else on Watermark: every figure links to a correction.
maintained by the record team · data catalog · about