AI DISCLOSURE

Every fact in every summary comes directly from the EPA's publicly available Superfund site profiles at epa.gov. The EPA site profiles are organized into multiple sections and subsections, like site background, contaminants, cleanup activities, community involvement, and others.

The text and tables from each section of every EPA profile page were collected and submitted to the AI models as-is. No data was pulled from any other source to create the summaries, including the API data that powers other features, like the map, contaminants list, Congressional information, etc. The AI's only tasks were to take raw text fields retrieved directly from EPA profile pages and compress them into site-specific summaries.

You may see a note in parentheses at the bottom of some site summaries, typically clarifying a date, highlighting a notable contradiction, and/or recommending you contact EPA directly for the current site status. These notes were written by me, the developer and real-life human person, for sites whose corresponding EPA profile pages appeared to contain minimal or contradictory information.

A large language model (LLM), the category of AI software used here, generates text by taking words, turning them into numbers, and calculating what word is most likely to come next. At its core, an LLM is a text predictor operating on an enormous and complex computational scale. It does this based on patterns learned from massive amounts of data.

An LLM doesn't understand what a Superfund site is. It doesn't know how benzene can damage bone marrow, or why a five-year-old growing up downstream from a lead mine can end up in kidney failure. It produces text that looks like a clear, factual summary because it reviewed an enormous amount of clear, factual summaries in its training data.

That is a real and important limitation. The summaries in the Overview section have not been reviewed by a toxicologist, an EPA official, or a community organizer. They only reflect what the EPA has explicitly written and published on its profile page. If the EPA's profile page is outdated, incomplete, or otherwise inaccurate, the summary will almost certainly reflect that.

Every site profile includes a link to the official EPA profile. I encourage people who use this tool to review the EPA's official resources as well, and to reach out to EPA staff with any site-related questions.

Generating each site profile summary involved two rounds of AI calls:

Round 1: Section SummariesEach EPA profile consists of multiple profile groups. Each profile group consists of one or more section fragments. Raw text from each profile group was summarized separately using a smaller, faster AI model (Claude Haiku 4.5). This generated up to three paragraphs per profile group.

Round 2: Site Composite SummariesThe profile group summaries were then combined and submitted to a larger model (Claude Sonnet 4.6), which generated the short summary you see on the map page and the longer summary on the full site profile page.

Both rounds used the same written instructions and rules (prompts) sent to the model before each call.

EPA site profile pages are written and updated over time by different EPA staff. Sometimes two sections of an EPA profile for the same site make contradictory claims about the same fact. An example of a genuine contradiction might be one section saying human exposure to a contaminant is under control while another section says there's insufficient data to determine human exposure.

When the AI encounters a genuine contradiction like this, the instructions tell it to report both claims in the longer summary and highlight it as a conflict rather than silently choosing one or attempting to resolve them. In the short summary on the map, any conflicting details in source text are excluded entirely rather than being presented one way or the other.

The EPA data is the authoritative source. If you notice a discrepancy between what a summary says on KCC SuperScan and what the linked EPA profile says, always defer to the EPA's official profile. If the EPA's profile is outdated or lacks sufficient information, I highly encourage people to reach out to EPA staff directly with site-specific questions. EPA staff are more likely to ensure their site profiles remain accurate and up-to-date when enough people engage them directly.

Two kinds of prompts were used. A single system prompt set the overall rules, tone, and prohibitions, and was sent with every call to both models. A user prompt then changed each round and carried the actual text to summarize. The following are verbatim reproductions of the prompts used, included here for transparency. Per-site data is shown as {{ placeholders }}.

TONE: Plain-language and conversational, like a knowledgeable neighbor explaining the situation. Preserve exact technical meaning but keep sentences short and direct. Prefer specificity over vague phrasing, but never invent details. Treat the reader as an interested non-expert and explain acronyms on first use.

READABILITY: target Flesch-Kincaid grade ≤ 8.0; average sentence length ≤ 15 words.

CONFLICT DEFINITION: A genuine contradiction exists only when two source passages make direct logical opposites of the same factual claim — for example, one states human exposure is under control and another states it is not under control or is unknown. Do NOT treat the following as contradictions: date discrepancies of a few days or less; plausible spelling variants of the same substance (e.g. 'trichloroethylene' and 'trichloroethene'); differences in level of detail about the same fact; or a general claim alongside a more specific one that is consistent with it.

RULES:
- Do not invent contaminants, dates, agencies, or status changes that are not in the source text.
- Do not claim that information is unavailable, not yet released, pending, or unknown unless the source text itself makes that statement. If a detail is simply absent from the source, omit it — do not comment on its absence.
- Do not soften or sensationalize health risks; report them as written.
- Do not use marketing language ('cutting-edge', 'world-class') or hedging filler ('it is important to note').
- Do not use em dashes (—). Use a comma or split into a separate sentence instead.
- Do not use semicolons. Use a comma or split into a separate sentence instead.
- Do not use first-person voice.
- Do not use markdown headings or any line beginning with #. Output must be plain prose paragraphs only.
- Do not begin the summary with the site name, profile group name, or any heading-style title. Start directly with a substantive sentence.
- Ignore any website navigation or UI chrome in the text — phrases like 'On this page:', 'Top of Page', 'Note: Large collections may take longer to load', or 'Jump to main content'. Summarize only substantive site content.
- Do not use spatial or navigational references to page structure. Phrases like 'using the contact details below', 'as shown in the table above', 'see the list on this page', 'in the section below', or 'as described above' are forbidden. These summaries are published on a separate website — any reference to the layout or sections of the original EPA source page will be wrong in context.
- If the source text is too sparse to summarize, return exactly: NO_CONTENT

You are summarizing one profile group from an EPA Superfund site profile for a public-facing map.

LENGTH: at most 200 words. One to three short paragraphs. No bullet lists, no headings.

CONTEXT
- Site name: {{ site name }}
- Profile group: {{ profile group }}

=== {{ section title }} ===
{{ raw section text }}
STRUCTURED DATA:
{{ serialized tables }}

[…one block per section in the group…]

Write the summary now as plain prose — no headings, no markdown, no title. Do not open with the site name, the profile group name, or any label. Begin with a substantive sentence about the site. Focus on facts relevant to public understanding. Omit navigation chrome and administrative metadata. If a detail is absent from the source text, omit it silently — do not state that it is unavailable or not yet released unless the source text says so explicitly. If you identify a genuine contradiction (per the CONFLICT DEFINITION in your instructions), report both claims as stated in the source rather than resolving or averaging them. If there is no meaningful content across all sections, output only the single word NO_CONTENT with nothing before or after it — no explanation, no punctuation, no additional sentences.

You are writing two summaries for a Superfund site on a public-facing map.

CONTEXT
- Site name: {{ site name }}
- Location: {{ site location }}
- NPL status: {{ npl status }}

PER-SECTION SUMMARIES
### {{ section label }}
{{ section summary }}

[…one block per profile-group summary from Round 1…]

Write two summaries and a contact list. Return nothing outside the XML tags.

SHORT (150–250 characters, one or two sentences): state what the site is, the primary contamination concern if known, and current cleanup status. If any detail is contested between sources (per the CONFLICT DEFINITION in your instructions), omit that detail entirely rather than mentioning the conflict.

LONG (300–500 words, 3–5 plain prose paragraphs, no headings or bullets): cover what the site is and where it sits in the cleanup lifecycle; contaminants and affected media; responsible parties and cleanup actions to date; current status; and how community members can stay involved. Omit any topic not supported by the per-section summaries. If a detail is contested between sources (per the CONFLICT DEFINITION), note both claims as stated rather than resolving them.

CONTACTS: Scan every per-section summary for named individuals with contact information (phone number, email address, or both). Return a JSON array where each element has "name" (string, required) plus any of "role", "organization", "email", "phone" that are explicitly stated in the source. Return [] if no contacts appear. Do not invent details.

<short>[your short summary]</short>
<long>[your long summary]</long>
<contacts>[JSON array or []]</contacts>

If the per-section summaries together are too sparse to produce meaningful output for either summary, return:
<short>NO_CONTENT</short>
<long>NO_CONTENT</long>
<contacts>[]</contacts>

Using cloud AI models for this tool has a real energy cost. To be honest, I struggled with this piece. KCC SuperScan is a public interest tool built to spread awareness of environmental hazards in an accessible format. But the AI tools used in pursuit of that have an environmental downside that simply cannot be ignored.

That deserves a straight answer, so I'm going to loosen my tie a bit for this one.

The first version of KCC SuperScan used only data fetched via APIs. It included things like NPL listing dates, contaminant lists, geographical data, and so on. While that can be helpful when it comes to visualizing the scope of Superfund sites and recognizing patterns and trends in data, it doesn't provide much benefit to a person looking to get a quick handle on what their local Superfund site is about. Solving for this required expanding the tool to include natural language rather than just throwing more datasets at it.

It was immediately obvious that using the raw text from EPA profiles directly wasn't going to be an acceptable solution. Individual EPA profile pages are often messy, outdated, and/or include conflicting information. One page might get an update while another page for the same site doesn't.

The EPA Office of Inspector General released a report in 2025 that characterized some Superfund information as being kept "inconsistently across multiple locations" and stated "public access and transparency is impaired" when that occurs. Raw text reproduction wasn't going to do much to make the information any less messy or any more accessible. And manually reviewing and summarizing information for 1,840 Superfund sites while keeping them up-to-date is, for obvious reasons, a complete non-starter.

When it was clear raw text reproduction was not going to work, I began researching open-weight LLMs to run locally that could take that raw text and generate summaries. This proved promising, and I got as far as running test batches of summary generations using models like Qwen2.5 and Gemma 3 on my personal computer. However, due to hardware constraints, I wasn't able to load LLMs with enough context to generate consistently reliable summaries at scale. Running local LLMs will require upgrading my personal computer. So until I'm able to upgrade my own hardware, I've chosen to use Anthropic's Claude models to bridge that gap.

Large language models like Claude run in data centers that consume enormous amounts of electricity and water. The water cools the servers, often in amounts that strain local supplies, disrupt local ecosystems, and drive utility bills up for the people living around them. As of June 2026, Anthropic hasn't published a sustainability report, though they primarily lease capacity from data centers that have their own clean energy commitments. But verifying those commitments is tough, and energy demand is increasing rapidly regardless.

If I intend to grow KCC SuperScan into a much more comprehensive tool on a personal budget without increasing the environmental cost, I'll need to incorporate a more sustainable solution for the plain-language components. And thankfully, I've already got that figured out.

For most people, AI changed from an abstract concept to something they could actually use when ChatGPT launched in 2022, but running any kind of AI model on your own PC was still a niche hobby, and it wasn't going to be capable of accomplishing much. In the past few years, AI models have been optimized and compressed to fit and function on consumer-level hardware, not just because the hardware got more powerful, but because the models themselves got significantly more efficient. Today, you can write code, summarize text, and even generate images using AI models downloaded straight to your computer for free through sites like huggingface.co. That level of capability and accessibility wasn't possible even a few years ago.

The cleanest long-term solution, and the one that I'm actively working to implement, is to generate summaries locally using a series of smaller, specialized, open-weight LLMs. In addition to a substantially reduced energy cost and more detailed, near-real-time site summary updates, there are numerous other advantages. For example, by using a technique called retrieval-augmented generation, local models will be able to review data extracted from documents and find patterns across all sites while actively incorporating new information shortly after it is released. This kind of capability becomes possible at scale with very little environmental impact. Cleanup delays, local economic impacts, regulatory failures, and so on can get surfaced automatically in response to newly released information. It can even surface potentially problematic relationships between contractors, corporations, and regulators, something that cloud-based LLMs are certainly capable of doing, but without the collateral damage of a massive AI model running in a resource-hungry data center.