It started with what should have been a simple question.
Cyril, our Director of Market Development, wanted to know which demand response programs were available to electric co-ops. Which utilities had programs? What kinds of devices could participate? Were they built for thermostats, EV chargers, batteries, or something else? What were the terms?
The answers were public. That wasn't the problem.
One co-op described its program on a page buried three levels deep in its website. Another put the details in a PDF. Another had a program that appeared in a regulatory filing but nowhere else. Each piece was available if you already knew where to look, but no one had assembled the pieces into a useful whole.
So we started doing it ourselves.
Today, we're opening that work to everyone. It's called CommonGrid: a public, editable, community-maintained registry of U.S. energy infrastructure.
******
Public doesn't always mean usable
There is an enormous amount of public information about the electric grid. The federal government publishes data about utilities and power plants. Grid operators publish market information. State commissions hold utility filings. Public maps contain transmission lines and service territories. Charging networks and federal databases list EV stations.
But finding a fact is only the beginning. Before you can use it, you have to download the file, understand somebody else's schema, clean the fields, reconcile the identifiers, remove duplicates, connect it to other sources, and decide which source wins when they disagree.
Then you have to do it all over again when the sources change.
Researchers, utilities, startups, government agencies – they’re all paying this tax, over and over again.
What the grid is missing is a single model that everyone can use and anyone can keep up to date.
That is the problem CommonGrid is meant to solve.
An editable, connected, open grid model
Once we had assembled the demand response programs, the next question was obvious: what other useful grid data was public but unnecessarily difficult to explore?
There are already many worthwhile efforts to open pieces of the grid. Map Your Grid, OpenGridWorks, and gridstatus library just to name a few. Each are elegant solutions to real grid information problems, but none were able to solve for the fragmentation we were running into. We still found ourselves having to reconcile schemas and build data connections ourselves.
CommonGrid is meant to be the place where those pieces come together: a shared registry with a connected data model, open APIs, source-level provenance, contribution history, and moderation. The goal isn't simply to publish another slice of the grid, but to create a foundation where many slices can become one useful, continuously improving picture.
We mapped utilities and their service territories. We mapped grid operators, power plants, transmission lines, substations, rates, wholesale pricing nodes, and public EV charging stations. We input customer counts, sales, and capacity.
Individually, each dataset was valuable. Connected, they became much more interesting.
A demand response program belongs to a utility. That utility serves a territory. The territory sits within a balancing authority or market. Power plants, transmission infrastructure, rates, and charging stations all exist within the same physical and institutional landscape. CommonGrid models those relationships instead of handing you a folder full of unrelated spreadsheets.
You can start with a utility, a ZIP code, a power plant, or a point on the map and move outward through the surrounding grid. You can explore it visually at commongrid.info, query it through the API, or download the data and use it somewhere else.
We decided to open source it
At Texture, we needed this context for our own platform. We could have normalized the data, copied it into our private systems, and treated the result as proprietary.
That would have been the conventional choice, and it would have ensured that everyone else was stuck repeating the same work.
But we're a software company through and through, and software has taught us a unique lesson: some of the most important infrastructure gets better when everyone can use it, inspect it, and contribute to it.
OpenStreetMap turned contributions from people around the world into a map used for navigation, logistics, research, city planning, and disaster response. Wikipedia and Wikidata created a shared layer of human and machine-readable knowledge that shows up almost everywhere, whether people recognize the source or not. MusicBrainz applied the same idea to music metadata, giving people and software a common way to identify artists, recordings, and releases.
No one is about to argue that Wikipedia and OpenStreetMap are consolation prizes from a failed attempt at monetization. On the contrary, they’re durable infrastructure we’ve all grown to rely on. Companies build products on them, researchers study them, public institutions use them, and contributors improve them because everyone benefits from a stronger common foundation.
That's the model that felt natural to us. The useful business isn't charging every company to rediscover which utility serves which county or cleaning up the same federal spreadsheet again. A shared foundation lets everyone, including Texture, spend more time building the things that actually move the grid forward.
In fact, Texture itself consumes CommonGrid. When we display public transmission infrastructure, power plants, or other CommonGrid data inside Texture, we use the same API we're making available to everyone else. That forces a useful kind of discipline: the public CommonGrid can't be an abandoned export or a marketing side project. It has to be dependable enough for us to build on, too.
The normalized data is released under the Open Database License, the same license used by OpenStreetMap. You can read it, download it, build commercial products with it, modify it, and redistribute it. Attribute the source, and share public derivative databases under the same terms so improvements remain part of the commons.
Built like a wiki, because it will never be finished
We know CommonGrid isn't complete, and some of the records are wrong.
The U.S. grid is too large, too distributed, and too changeable for any one company to maintain a perfect private model of it. Utilities launch programs. Rates change. Assets are decommissioned and retired. Territory boundaries get corrected. Public agencies revise their source files. A useful registry needs a way to absorb those changes without asking users to trust silent edits from an invisible data team.
So we built CommonGrid for correction rather than completeness, inspired by Wikipedia’s moderation and editing model. Anyone can propose a change, and each change retains its version history. Accuracy comes from the people who know their piece of the grid better than we do. Every accepted edit retains its author, source, timestamp, and permanent diff, and each record can be inspected.
Provenance matters here. If a service territory changes or a program's eligibility rules are updated, you should be able to see what changed, who changed it, and what evidence supported the decision. If an edit turns out to be wrong, it can be reversed without erasing the record of how it happened.
Over time, we want the people closest to the data to maintain it. When a co-op launches a new demand response program, someone at that co-op should be able to add it directly. Researchers should be able to contribute corrections they uncover. People who spend their careers working with a particular region or class of infrastructure should be able to help moderate it.
Texture seeded CommonGrid and funds the infrastructure, but the goal is a registry maintained by the community that uses it. We welcome contributions.
Explore and build on the data
The map is the easiest way to understand CommonGrid, but it's not just a map.
The REST API covers utilities, territories, grid operators, programs, rates, power plants, transmission lines, substations, EV charging stations, and pricing nodes. Geographic endpoints support questions such as which utility serves a coordinate, while vector tiles make it possible to add CommonGrid layers to other maps. Every edit is available through the changelog, and weekly database and GeoJSON snapshots make bulk analysis possible.
You can make 60 API requests per hour without creating an account. A free API key raises that to 5,000 requests per hour, and you can create separate keys for different projects. The point of registration isn't to put the data behind a gate; it gives us enough traceability to operate the service responsibly and a way to build a relationship with the people using it.
The API documentation and examples are available from the CommonGrid developer page.
Help us make it better
CommonGrid is available now at commongrid.info.
Explore the map, query the API, download a snapshot, and if you find a gap, tell us. Better yet, contribute a correction! If you know this data well and want to help review contributions, we'd love to hear from you about becoming a moderator.
CommonGrid began with one person trying to answer one question about demand response programs for co-ops. We think many better products, analyses, and decisions can begin with everyone having access to the same underlying picture.
The grid is shared infrastructure. The basic knowledge of how it's put together should be shared, too.
—-
FAQs
What is CommonGrid?
CommonGrid is a free, public, community-maintained registry of U.S. energy infrastructure — utilities, service territories, grid operators, power plants, transmission lines, substations, rates, wholesale pricing nodes, EV charging stations, and demand response programs, all connected in one data model. It's built and funded by Texture and released under the Open Database License (ODbL).
Who can edit or contribute to CommonGrid?
Anyone. Like Wikipedia, users can create an account, propose an edit, and cite a source for the change. A team of moderators reviews each proposal before it becomes part of the canonical record, and every accepted edit keeps a permanent history of its author, source, and timestamp.
How is CommonGrid different from existing public grid data sources like EIA or FERC filings?
Existing sources publish raw, disconnected data — a utility's territory in one file, its rates in another, its regulatory filings somewhere else entirely. CommonGrid normalizes and links those pieces into one relational model, so a utility connects to its territory, its territory to its balancing authority, and so on — instead of leaving users to reconcile schemas and identifiers themselves.
Does Texture use CommonGrid internally, or is it just a public dataset?
Texture uses CommonGrid directly — when Texture's platform displays public transmission infrastructure, power plants, or other CommonGrid data, it calls the same API available to everyone else. That's intentional: it keeps CommonGrid dependable rather than letting it become an abandoned export.
Does CommonGrid connect to Texture's grid operating system?
Yes — CommonGrid data (utility territories, transmission infrastructure, power plants) feeds directly into Texture's platform, giving co-ops and utilities public grid context alongside their private operational data in one connected model.
