Methodology

How this site is built

Midwest AI Watch is research. Every facility on the map exists because someone opened a county planning packet, watched a council livestream, read an Army Corps notice, or filed a public-records request. The site is a place to put what comes out of that research so it doesn't sit buried in PDFs nobody reads.

Software helps us keep up with the volume of public information. Editorial calls (what gets published, how a field reads, when a record changes) stay with the team, not the tools.

Where the data comes from

Each entry is built from public sources. In rough order of how often they show up in our pipeline:

• County and municipal planning documents: applications, staff reports, conditional-use permit filings, site plans, traffic studies
• Council, planning commission, zoning board, and county board agendas, minutes, and meeting recordings
• State PUC filings and utility interconnection queues
• Air, water, and stormwater permit applications filed with state environmental agencies
• Property records and assessor data (parcel size, ownership, recent sales)
• Public Notices, Notices of Application, Environmental Assessments, and FOIA / open-records responses
• SEC filings, earnings calls, and investor materials when operators are publicly traded
• News reporting from local and trade outlets, including company press releases
• Community submissions from residents and approved volunteer contributors

When a field on a facility page shows a value, that value traces back to one or more of these sources. We aim to cite the source on the facility's timeline. Where a citation is missing, treat it as in-progress, not as fact.

How a facility gets onto the map

1. Discovery. Someone (usually a team member, sometimes a tip from a resident through /report) spots a public document or news article suggesting a facility is being proposed, permitted, built, or operated.
2. Sourcing. We trace the claim back to a primary source: a permit, a filing, an agenda packet, a public statement. Anonymous claims and second-hand summaries don't go on the map on their own; they trigger a search for the underlying document.
3. Field extraction. A team member reads the source(s) and pulls the structured fields: location, operator, status, planned megawatts, water draw, footprint, hearing dates, tax-incentive terms, and so on. Each field gets a citation.
4. Editorial review. A second pair of eyes, typically the site administrator, confirms the citation actually supports the proposed value before the field becomes public.
5. Publication. The facility appears on the map. The timeline gets an entry for every source we used. Subsequent updates (a council vote, a new permit, an expansion) attach to that timeline so the record is auditable over time.

Where software helps

We use a small set of tools to keep up with the volume of public information. None of them publish anything on their own.

• Scheduled news fetch. A daily job queries Google News for the operator name and town of each tracked facility, deduplicates against what we've already seen, and drops new links into an internal "needs review" queue. A team member reads each article and decides whether anything in it warrants a change to the facility record.
• Document scanning. When a contributor or team member uploads a planning PDF, a text-extraction step pulls quoted passages so a reviewer can find the relevant section faster. The reviewer still reads the document.
• Relevance triage. When community reports come in through /report, an automated relevance check flags submissions that look off-topic (e.g. "this article is about a different industry") versus ones worth a closer look first. False negatives go to a backlog queue, not the trash; the queue still gets walked through manually.

These tools are convenience layers. If you removed them, the site would still exist; it would just take longer to keep current. Editorial decisions (what gets published, what each field reads) are not delegated to them.

How community reports are handled

Anyone can submit a tip at /report. Tips do not publish directly to the map. They go into a review queue and follow the same path as anything else:

• A reviewer reads the submission and any links or attachments.
• If the submission is about a facility already on the map, the reviewer matches it and decides whether to update fields, add a timeline entry, or take no action.
• If it's about a new facility, the reviewer traces the claim to a primary source before creating a new map entry.
• Approved contributors (a vetted group of volunteers) can submit per-field updates with required citations. Other contributors can vouch or flag a submission to help prioritize the queue.

Contributor names are not displayed publicly. The reasoning is editorial: published facts belong to the facility record, not the person who first surfaced them.

Update cadence

We aim for these rhythms, though real life is messy:

• Daily: news scan against tracked facilities; tip-queue triage.
• Weekly: review of pending contributor submissions; publication of timeline updates.
• As-needed: new-facility additions when a credible primary source surfaces.
• Quarterly: back-fill audit. We pick a state and re-check planning records for facilities we might have missed.

Corrections and disputes

If a value on a facility page is wrong, please tell us. Two paths:

• Use the "Suggest an edit" control on the facility's detail card. Include the source that supports the corrected value.
• Or email contact@dpdigital.io with the URL of the facility page and what's wrong.

We publish corrections by updating the field and adding a timeline entry that documents the change and the new source.

What we don't do

• We don't publish anonymous accusations or unsourced rumors.
• We don't rate facilities good or bad. We try to publish the facts and let readers decide.
• We don't take money from data-center operators, real-estate developers, utilities, AI companies, or industry trade groups.