Static snapshot. This site serves two different things: 1,853 data centres reported by OpenStreetMap contributors nationwide, and 13 sites Helios infers from Arizona parcel records, exported on July 29, 2026. The first is a map of what has been recorded; the second is an argued hypothesis with an evidence chain. This is a point-in-time export, not a live view. See meta.json or the methodology.

Methodology and limitations

Helios publishes two datasets built by entirely different methods. The national observatory counts what has been mapped and divides up a reported national total. The Arizona study argues, from primary records, where a facility is probably being built. Neither method is used to support the other's claims. If you have not read the basics, start there.

The national observatory

Four stages, no database

The whole pipeline runs from committed CSVs with no server and no database, so a contributor can rebuild every figure on the site from a clean checkout. One command, make poll, runs it end to end and prints what changed.

  1. Snapshot. A tiled Overpass query pulls every US element tagged telecom=data_center, building=data_center or industrial=data_centre, with its geometry. Building outlines are converted to area on the WGS-84 ellipsoid, not by treating degrees as metres, and each element is reduced to a centroid, a footprint and its tags.
  2. History. The ohsome API replays OpenStreetMap's full edit history and reports the moment each element began — or stopped — matching that filter. This is the only defensible source for the time axis: an element's original creation date is when it was first drawn as anything, which is often years before it became a data centre.
  3. Placement. Each facility is matched to a US county by point-in-polygon against Census TIGER boundaries, indexed with an R-tree. The boundary vintage is recorded, because county codes do change.
  4. Allocation. LBNL's reported national electricity and water totals are divided across facilities in proportion to mapped building floor area, then summed into counties and states. Only facilities mapped as buildings take part: a campus mapped as a land parcel and a site mapped as under construction are counted and measured, but receive no share.

Re-running the pipeline with no upstream change produces no diff at all. The CSVs are written deterministically — stable sort, fixed precision — so that git diff between two polls is itself an honest change log.

The power and water model, and its weakest link

The allocation is conservative by construction: every facility receives its footprint's share of the national figure, so the state shares re-sum to the published total exactly. A test asserts this, because the property is the entire justification for the method.

What the model assumes is that power density per square metre is uniform across facilities. It is not. A dense multi-storey hall draws far more per square metre of ground than a single-storey shed, so tall sites are under-weighted and flat ones over-weighted.

What that weakest link turned out to be. This model used to allocate Virginia about 2,255 MW, against roughly 4,100 MW that Virginia's own legislative commission attributes to Northern Virginia alone — an under-read of about half in the densest region in the country. The cause was not the density assumption above. It was that “footprint” pooled three different things: a building's floor plate, the boundary of the land a campus sits on, and a site still under construction. Weighting by the pooled figure sent 82% of a measured national total to geometry that is not a building, and a single 3.1 km² parcel in Racine County, Wisconsin drew 598 MW while every mapped building in Loudoun County together drew 1,020 MW.

Weighting building floor area alone moves Loudoun County to 3,034 MW and Virginia to 4,972 MW, which is consistent with that independent figure where the old result was not. The correction cuts both ways and is not a claim of accuracy: the discarded parcels are real facilities whose load is now attributed to buildings elsewhere, so regions mapped campus-first are understated, and each such region says so on its own page. The density assumption above is unaffected and remains.

What the observatory cannot see

  • Construction dates. Not one facility in the dataset carries one, because OpenStreetMap does not record them. Every date here describes an edit to the map.
  • Coverage. There is no authoritative public count of US data centres, so what fraction of reality these 1,853 represent is anyone's guess, including ours.
  • Pre-2017 history. The tagging convention was barely used before then. That stretch of the curve is drawn hatched because it describes the tag, not the country.
  • Whether a removal was a demolition. An element leaves the dataset when it stops matching the filter, which a retag does as readily as a teardown.
  • 203 facilities' arrival. They were mapped before the retained history begins, so they appear in the counts but in no curve. Each region page states its own gap rather than hiding it.

The Arizona site model

How Helios reaches a conclusion

Data flows in one direction, and every step is reversible for audit:

  1. A connector fetches bytes from a declared public source. The payload is hashed with SHA-256 and stored under a key derived from that hash, so a key cannot be reused for different content and re-fetching identical bytes is a no-op.
  2. A parser reads structured records out of the payload without interpreting them.
  3. A normalizer maps source-native fields onto Helios concepts, converts units, and applies the privacy policy. Each distinct assertion becomes its own evidence record with its own date.
  4. Parcels are clustered into sites by spatial adjacency and shared ownership. Either signal alone produces bad clusters.
  5. A weighted rule set scores each site, and every point of the score is recorded as a separate explanation row pointing at one evidence record.

The confidence model

Each evidence record maps to at most one rule and contributes base weight × extraction confidence × recency. The sum is squashed into 0–100 by a saturating function so that accumulating weak signals cannot imitate a strong one.

Three mechanisms deliberately hold scores down:

  • Diversity capping. A site supported by one kind of evidence cannot exceed 45% however much of it exists. Ten permits from one office are one fact observed ten times.
  • Saturation. Contributions have diminishing returns.
  • Staleness. Event evidence that stops progressing decays and eventually scores negative. Standing conditions — statements about the present, such as the county’s current use classification — are exempt, because a facility does not become less likely to exist as its purchase deed ages.

Weights are domain-reasoned starting points taken from the project specification. They are not fitted to outcomes, and calibration is deliberately deferred until a historical backtest exists to calibrate against. Tuning weights now would produce numbers that look authoritative and mean nothing.

Privacy

County assessor records name private homeowners. Helios classifies every owner name during ingestion and suppresses those identified as natural persons or as trusts bearing an individual’s name — before anything is written to the database, not as a display filter. No organization record is created for a private individual, because storing a redacted placeholder would still disclose that a person owns a particular parcel.

The classifier is biased toward redaction: an unclassifiable name is treated as personal. A company wrongly redacted costs a little recall; a homeowner wrongly published is a serious harm. The connector also declines to request owner mailing street addresses at all, so that data never reaches Helios.

Known limitations of the site model

  • Early-stage coverage is still uneven. ACC eDocket transmission and substation filings are parsed from recorded fixtures only — Helios does not scrape the live ASP.NET search. Municipal planning agenda PDFs are not yet automated. Mesa commercial building permits and EPA air facilities improve construction and generator recall, but coverage can still concentrate at Stage 7 when the assessor’s DATA CENTERS label is the dominant signal.
  • Ownership history is truncated. The assessor exposes only the most recent deed per parcel, so Helios observes a single transfer rather than a chain. Multi-year land assembly by successive entities is invisible.
  • Score semantics are conflated. One number currently blends “is this a data centre?” with “how far along is it?”. A county-confirmed operating facility scores moderately rather than highly, because the model was designed for detecting emerging projects. Separating the two is a calibration task for the backtesting phase.
  • Transmission-line distances are approximate. The Overpass query returns a centroid per circuit rather than a polyline, so distances are measured to a midpoint and treated as an upper bound.
  • OpenStreetMap coverage is contributor-dependent. The absence of a substation in OSM is not evidence that none exists, and Helios draws no negative inference from it.
  • No satellite analysis. No imagery credentials are configured, so no satellite observations exist. Nothing in the interface derives from remote sensing.
  • No historical backtest yet. Until the replay harness runs, Helios has published no measured precision, recall, or lead time, and none should be inferred from the confidence figures.

What Helios will not do

  • Name an operator without a direct filing. Circumstantial strength — a single-purpose LLC, an out-of-state mailing address, a nearby substation — never promotes to an attribution.
  • Bypass authentication, CAPTCHAs, or any technical access control.
  • Publish exact water or power consumption without a reported figure.
  • Present scenario output as measurement.