Insert Coin, Uncle Sam

A mashup of three “Summer into AI” entries, and why it exists

This week’s contest theme was simple: dig up boring federal data nobody ever turned into anything, and turn it into something. Three entries did exactly that, in three completely different directions. This piece is what happens when you smash all three into one arcade cabinet.

The three cartridges

Cartridge one is Eric’s data.PUNK — CDC life expectancy and death-rate data, reimagined as a Little Richard-style platformer. Punk rock, mortality statistics, and a punchline built right in: no music included.

Cartridge two is Ride for Liberty, built by Jake Strait and reviewed by Eric in his Saturday Plays column. A three-lane rocket ride crashing through fireworks and beer kegs, themed “Red, White, Boom” for the week’s patriotic prompt.

Cartridge three is Myles’s White Nose — thirteen winters of USGS bat-plague surveillance data, county by county, animated into a map you can actually watch spread. The most quietly devastating of the three: a real epidemic, fully documented by the federal government, that nobody had ever bothered to visualize until now.

What connects them

On the surface, a punk-rock health chart, a fireworks rocket ride, and a bat plague map don’t have much in common. But look at the shape of each project and the pattern is identical: someone found a dataset the government collected and then abandoned, and gave it a pulse. Different genres, same move.

That’s the “cheat code” this mashup is built around — the idea that data.PUNK, Ride for Liberty, and White Nose aren’t really three separate entries so much as three difficulty settings on the same game.

Why an arcade cabinet

The contest itself already leans into an arcade, remix-culture spirit — Eric’s Saturday Plays column exists specifically to play and dissect other people’s submissions, treating each week’s entries like cartridges in a shared machine. Building a literal arcade cabinet — with all three cartridges bursting out of the coin slot, connected by string-light wiring spelling out “SUMMER INTO AI” — just makes that metaphor visible instead of implied.

The eagle-with-guitar, eagle-in-a-rocket, and bat-in-a-lab-coat details are there because the brief for this piece was “fun, playful, and slightly bizarre.” A punk-rock bald eagle felt like the right connective tissue across three otherwise unrelated dataset stories — equal parts patriotic and unhinged, which is more or less the spirit the whole contest runs on.

Credit where it’s due

• data.PUNK — Eric, advisoryhour.substack.com

• Ride for Liberty — built by Jake Strait, reviewed by Eric, advisoryhour.substack.com

• White Nose — Myles, merlinforge.substack.com

This piece is a remix built on top of their work for this week’s combination challenge — go read the originals, especially the White Nose map. It’s the real thing.

Here ya go,

The short version: you enter a U.S. location, and the app opens a blunt little public-data case file about the place.

Not tourism data.
Not “best places to live.”
Not a shiny civic dashboard pretending everything is manageable.

The app looks at three ordinary systems nobody gets to opt out of if survival is the goal:

Air. Food. Weather damage.

It pulls from public federal data and turns the record into something readable:

• historical air quality

• food access pressure

• FEMA weather/natural disaster declarations

Then it gives the place a NOT FINE SCORE and shows the weak points in plain language.

The tagline is:

Your town is not doomed. It is, however, documented.

That is the whole project in one line.

This was my Week 3 submission for Summer Into AI, and the theme was Data.Punk.

Basically: take public data, make it useful, make it weird, make it hit harder than a spreadsheet.

So I made this.

What the app does

You type in a town, city, county, or ZIP.

The app resolves that to county-level data where possible, then opens a report with sections like:

WHAT YOU’RE BREATHING

This uses EPA historical air quality data.

Important note: it is not live AQI. It is the recent record.

The app says that directly:

This is not a live air reading. It is the recent record.

Because a bad day is one thing.

A pattern is another.

And the file line is:

You do not visit the air. You live inside it.

THE SUPPLY LINE

This uses USDA food access data.

I wanted this section to be about infrastructure, not personal choices. Food access is not a character test. It is a map problem. A distance problem. A transportation problem. A money problem. A systems problem.

The line that came out of that section:

The crisis does not always start with an empty shelf. Sometimes it starts with a store that was never close enough.

HOW IT GETS YOU

This uses FEMA disaster declaration data, filtered to weather and natural disasters.

Severe storms. Floods. Hurricanes. Fire. Tornadoes. Snow and ice. Drought. Earthquake. Landslide.

The app looks at the official county record and says: this is the kind of damage that keeps showing up here.

Not because the app can predict the future. It cannot.

Because the record already has fingerprints on it.

What it looks like

I did not want this to look like Civic Dashboard Template #437.

No soft gradients.
No rounded little wellness cards.
No “community insights” stock-photo energy.

The target was more like:

The government posted the data. Someone tore it down, photocopied it badly, circled the weak points in red marker, and stapled it to a wall.

Think:

• 1980s punk flyer

• bad photocopy

• public notice

• warning label

• zine table

• red marker

• black ink

• dirty paper

• case file

Not cyberpunk.
Not vaporwave.
Not sleek tech dystopia.

More like a municipal report got shoved through a basement-show copier and came out angry.

The big landing page headline is:

YOUR TOWN

IS NOT

FINE

Which is not subtle.

That was the point.

Why this fits Data.Punk

The thing about public data is that it is often technically public and functionally buried.

It exists.

Sure.

In a giant spreadsheet.
In an API endpoint.
In a PDF.
In a download with 47 columns and a government naming convention that makes your eyes go dead.

That is not the same thing as readable.

That is not the same thing as usable.

That is not the same thing as public in any practical sense.

So the Data.Punk move here was not just “use a dataset.”

It was:

Take the official record and strip out the polite fog.

The app does not say:

Environmental indicators suggest potential area-level concern.

It says:

The air record shows pressure. Not a single event. A condition.

It does not say:

Food access varies across census tracts.

It says:

The map makes food harder to reach in places where failure costs more.

That is the whole attitude.

The record is public.
The damage is ordinary.
Nobody fixed the system.
Here is the file.

The score

The app creates a NOT FINE SCORE from 0–100.

To be very clear: this is not an official federal score. It is not an EPA, USDA, or FEMA category. It is an app-defined signal.

The MVP formula is:

• 40% historical air quality

• 40% food access pressure

• 10% catastrophe indicator

• 10% data weirdness / source limitations

The labels are intentionally blunt:

• CLEANER THAN EXPECTED

• STILL HOLDING

• UNDER PRESSURE

• FRAYING AT THE EDGES

• THE LINE IS THIN

I wanted the score to feel like a warning stamp, not a school grade.

No town is “bad.”

No residents are being judged (out loud).

The score is not about the people living there. It is about the systems around them.

One of my hard rules for the project was:

Hard on the conditions. Never hard on the people.

That stayed on the wall the whole time.

Metaphorically.

Although honestly, for this project, it probably should have been literally taped to a wall in red marker.

The data sources

The final app uses processed JSON files built from public datasets.

Not the raw monster files. Those are too large and clunky for the front end.

The source data came from:

EPA AirData

Historical annual AQI by county, 2020–2024.

This powers the air section.

USDA Food Access Research Atlas

Food access indicators, originally at tract level, summarized to county.

This powers the supply line section.

FEMA Disaster Declarations Summaries

Weather and natural disaster declarations grouped by county.

This powers the catastrophe section.

I had to do a cleanup pass here because the first version let Biological/COVID declarations show up as the dominant disaster type in some places.

That was real FEMA data.

It was also wrong for this app.

The “How It Gets You” section is about weather and natural catastrophe patterns, so I filtered the file to the relevant incident types.

A punk interface with sloppy data is just costume.

The file has to be honest.

The geography problem

One thing I ran into fast: location data is annoying because humans and datasets do not talk about places the same way.

People say:

“Des Moines.”

Federal datasets say:

“Polk County, Iowa.”

Or they say census tract.
Or county FIPS.
Or ZIP.
Or monitoring region.
Or some other geography that almost, but not quite, matches the way a normal person thinks.

So the app shows the report geography clearly.

Example:

REPORT GEOGRAPHY: POLK COUNTY, IOWA
AIR: COUNTY-LEVEL DATA · FOOD: TRACT-DERIVED COUNTY SUMMARY · CATASTROPHE: FEMA COUNTY DECLARATIONS

That matters.

The app should not pretend the data is more precise than it is.

One of the method rules is:

Missing or broader data lowers confidence, not safety.

If the file is incomplete, the app should say the file is incomplete.

It should not magically make the town safer.

It should not magically make the town worse.

No fake precision.

No clean bill of health.

No pretending a blank cell is good news.

What still holds

The app is not an emergency system.

It does not send alerts.
It does not predict disasters.
It does not diagnose health conditions.
It does not measure every local risk.
It does not replace official sources.

It is a file.

So the final section is called:

WHAT STILL HOLDS

Not “solutions.”

Not “five easy steps.”

Not “empower your community with resilience.”

No thanks.

Just practical things the file should make you check:

• Find your county emergency alert system.

• Check current air readings before hard outdoor work.

• Know the nearest reliable grocery options.

• Keep water, light, and phone power covered for a short outage.

• Know the flood map if water is the local break point.

• Check official sources when weather turns.

And the three lines I like best:

Do not wait for the siren to learn where the alerts are.
Do not wait for smoke to learn where the air data lives.
Do not wait for the shelf to learn how far the next one is.

That is probably the actual heart of the app.

The design is loud.
The language has teeth.
The whole thing is wearing a black jacket it definitely found at a thrift store.

But underneath that, it is simple:

Read the file before the system fails in front of you.

What I learned

Public data is weird because it is both available and buried.

Not buried like secret.

Buried like: technically downloadable, emotionally hostile.

A spreadsheet can be public and still be unusable to most people.

A dataset can be official and still need translation before it becomes civic knowledge.

A report can satisfy the requirement and still fail the human reading it.

That feels like the Data.Punk part to me.

Not just using public data.

Refusing to leave it in a locked filing cabinet with the door open.

This project made me think a lot about how much of civic life is already documented somewhere. The air record is there. The food access record is there. The disaster declarations are there.

The public record has been keeping receipts.

The app just opens the file and says it without the beige wallpaper.

Your town is not doomed.

It is, however, documented.

This is my Week 2 (Red, White, Boom!) submission for the Summer Into AI Competition, which is a public AI build competition where people make projects, publish them, show proof, and earn points.

That sounds simple.

Then people started submitting things.

A lot of things.

Some people had one project. Some people had several. Some projects had a Substack post and a live demo. Some had a Substack post, a live demo, and GitHub. Some people wrote about other people’s projects. Some projects had names that sounded similar enough that I had to stare at them for a while and wonder whether I was looking at one thing or three things wearing a trench coat.

At some point I realized I did not just want to know the leaderboard.

I wanted to know what was happening underneath the leaderboard.

So I built Leaderboard Oracle.

It’s basically a competition tracker for Summer Into AI. It keeps track of competitors, projects, scored events, point totals, and the pieces of evidence that explain why someone has the score they have.

This is not a production app. It is not trying to be beautiful software for the ages. It is a practical app for a specific competition, built because I wanted a clearer answer to one very important question:

How worried should I be?

The competition is simple, but the data gets messy fast

The rules are clear enough. You build something, publish it, and show proof. Different kinds of posts and proof are worth different point values.

But once multiple people start building multiple things, the scoring gets hard to follow casually.

A project is not always the same thing as a scored event.

That was the big thing I had to sort out.

A project is the thing someone made.

An event is the thing that earns points.

So if someone builds a project and posts a Substack article with a live demo, that’s a scored event. If they also share code, that changes the point value. If they write a separate post about someone else’s project, that may be another scored event.

The app needed to understand that difference.

Otherwise it would be very easy to accidentally treat a project like it earned points just by existing, which, unfortunately, is not how life works.

Week 2: Red, White, Boom!

The theme led to a lot of projects with Revolutionary War names, fireworks names, liberty names, founding father names, and at least one project title that made me question whether everyone else was sleeping.

This app just watches events and scores, with some fireworks in the background. Every competition eventually needs one person in the corner with a spreadsheet asking, “Wait, does that count?”

Apparently that person is me.

My favorite feature: Path to Independence

My favorite part of the app is called Path to Independence.

The name sounds dramatic, but the feature is very practical.

It looks at where a competitor is in the standings and shows what it would take for them to move up.

For example, if someone is 35 points behind the next person, the app can show whether one strong submission would close the gap. It can show whether a smaller submission would help but not be enough. It can make the difference between “I’m behind” and “I need one Substack post with a demo and code.”

That is the kind of information I wanted.

Not motivation. Not vague encouragement. Just the actual math.

Because when you’re looking at a leaderboard, “you can do it” is less helpful than “you need 40 points.”

Path to Independence makes the competition feel more playable. It turns the leaderboard from a static ranking into a strategy view.

It answers the question I actually have:

What would it take?

My other favorite feature: Opportunity Radar

The other part I really like is Opportunity Radar.

This feature looks for places where there may be points available or useful moves to make.

That might mean noticing that someone has a project but not much proof attached. Or that a competitor could gain ground with one complete submission. Or that there are scoring opportunities people may be missing because they are focused only on building and not on publishing, explaining, or documenting.

This matters because in this competition, the work does not really count unless it is visible.

You can build something cool, but if there is no post, no demo, no code, or no clear explanation, it may not help your score very much.

Opportunity Radar is basically the part of the app that says:

You might be leaving points on the table.

Which is annoying.

But useful.

The rumor mill is part of the data model

One of the funniest parts of building this app was realizing that the leaderboard is not just made of official scores.

It is also made of the rumor mill.

Someone mentions that a project exists. Someone says they saw a demo. Someone else knows there was a Substack post. A GitHub link appears in the wild. A project title shows up twice with slightly different punctuation and suddenly I am trying to decide whether these are duplicates or if someone really did make two separate liberty-themed apps with almost the same name.

This is where the app gets practical.

Not every piece of information should immediately become points. That would be a mess. But it is still useful to track what people are hearing, what might exist, and what needs confirmation.

So the app separates confirmed events from softer signals.

A confirmed event is something I’m comfortable treating as real for scoring purposes. It has enough evidence to say, yes, this happened, and yes, these points make sense under the rules.

A rumor is different. A rumor might be useful, but it is not the same as a score.

That distinction matters more than I expected.

Because in a fast-moving competition, the rumor mill is often the first place a real submission shows up. Someone says, “I think Adam posted another one.” Or “Did Jake just submit again?” Or “Wait, is that Eric project archived or does it count?”

The app does not have to believe all of that immediately. But it does need a place to put it.

That is what makes the tracker feel useful instead of just decorative. It can hold the messy middle stage between “I have no idea what is happening” and “this is confirmed and should affect the leaderboard.”

And honestly, that is most of the competition.

The official scores are the clean part. The rumor mill is where the work is.

What the app actually does

Leaderboard Oracle tracks the main pieces I care about:

Who is competing.
What projects they have.
Which events are confirmed.
How many points each event is worth.
What kind of proof exists.
What the standings look like.
Who is close enough to catch.
Where someone might have an opportunity to gain points.

It is not trying to predict the future with mystical accuracy. It is not pretending to know things it does not know.

A big part of making the app useful was cleaning up the data. Some rows were confirmed. Some were duplicates. Some were unknown. Some project names appeared more than once. Some entries had enough detail to calculate the score from the official rules. Others had to be treated more carefully.

That cleanup work was not glamorous, but it mattered.

The app is only useful if the data underneath it is honest.

What I learned

I learned that even a small competition tracker needs a good data model.

That sounds boring, but it ended up being the heart of the project.

At first glance, it seems like the app should track projects. And it does. But projects are not the thing that earn points by themselves. Events earn points.

That distinction made the app much cleaner.

A project can have one event or several. A competitor can have several projects. A leaderboard should count the events, but still let you see which project they belong to.

Once I got that straight, the rest of the app made a lot more sense.

I also learned that I like dashboards more when they tell me what to do next.

A leaderboard is nice. A leaderboard plus “here is how you could catch the next person” is much better.

Is this overbuilt?

Probably.

But only a little.

The competition moves quickly, and people are submitting enough work that it is genuinely hard to keep track. A simple list of scores does not show the whole picture.

I wanted something that showed the score, the reason for the score, and the possible next move.

So I built it.

And now, instead of manually trying to figure out who is ahead and whether I should panic, I can open an app that tells me.

This is progress.

Not emotional progress, necessarily.

But progress.

And… now will have more to grumble about because contestants will be able to figure out exactly what to do to get ahead. Hypothetically. Trust nobody.

Find it HERE

More specifically, I made a game where you build an eagle nest, play little mini-games to collect stuff to improve your nest, and then better eagles show up because your nest is cooler.

About SKY KING

The basic loop is:

>>play mini-games
>>get stuff
>>upgrade nest
>>better bird moves in
>>wonder what the next bird is

That’s pretty much it.

The important part is the “wonder what the next bird is” part.

The game is intentionally tuned to be easy to finish. For the challenge, I wanted players to see the full progression and reach the ending, so the resource requirements are very forgiving. In a longer version, the difficulty could be adjusted almost entirely through the grind system.

So the mini-games needed to be fun, fast, and simple. They’re resource generators. That’s their job.

The bird arrivals are the reward.

The bird list is:

Red-tailed Hawk
Bald Eagle
**********
************
********************
*********
******
SKY KING

What, you thought you’d get to know what all the birds were without doing the work? Ha. You thought wrong.

The player will only see the bird log entries they’ve already unlocked. I didn’t want a full progression chart. I didn’t want silhouettes of everything. I wanted the player to keep thinking, “Wait, what else can show up?”

The final entry is visible, but locked.

THE SKY KING

No nest has ever been deemed worthy.

That’s about it.

The player should assume it’s the biggest eagle. The final eagle. The most eagle an eagle can be.

The design for the final bird appeared during a late-night discussion with ChatGPT, when enthusiasm was running unusually high.

I kept it.

So now the ending is basically:

finish the nest
sky gets weird

really cool music plays
…..

Sky King reveal

(*audio is essential for maximum Sky King reveal coolness)

And that’s the game.

ABOUT THE PROCESS

I used ChatGPT to talk through the requirements and build a v0 prompt to generate the game. That prompt got me 95% of the way there. The largest chunk of time was spent on audio - picking the right sound effects and addressing issues with audio causing graphic asset load lag. That and generating (and re-generating) the bird sprites until they had the feel I wanted. Audio (music) was generated in Suno. Game sound effects were found on OpenGameArt (shiru8bit, Little Robot Sound Factory). All game art was generated by either v0 or ChatGPT.

It’s playable on desktop or mobile, but desktop is the superior experience; the task of tweaking for mobile layout and a variety of orientations is usually a time-consuming chunk of work that I didn’t want to do this time. Mobile optimization sounds like a good goal for my week 2 project - I’m curious to see how good my AI workflow is at solving that very annoying problem.

Here’s the most interesting thing I learned. I’ve used this trick on other projects, but this was the first time it gelled for me as a strategy.

Change the ask from “What could I do?” to “What’s the minimum I need to do to achieve the result I want?”

When I was adding audio to the Sky King game, my first question was literally: “Hey chat, where should I put sound?” The answer was a huge list—like 30-40 different opportunities for music, ambient audio, and sound effects. While technically correct, it created a lot of work and complexity.

The better question was: “What is the minimum amount of sound needed for the game to feel complete, polished, and engaging?”

That completely changed the answer.

Instead of dozens of sounds, chat recommended:

• A click sound for navigation

• A resource collection sound

• A mini-game completion sound

• A nest upgrade sound

• A new bird arrival sound

• Maybe a looping background track

I decided to also include distinct tracks for the main screens and an epic track for the final reveal.

By focusing on the minimum effective implementation, the audio plan shrank dramatically while still delivering the feeling of a finished, satisfying game.

This principle applies far beyond game development. AI is often excellent at generating comprehensive lists of possibilities, but those lists can create unnecessary work. A powerful follow-up question is:

“What is the smallest set of things I can do that will still make this feel complete?”

The goal is not to find every possible improvement. The goal is to identify the handful of elements that create most of the impact.

HOPPING BACK TO THE GAME EXPLANATION

I’m trying very hard not to add seventeen more systems to it, because this is supposed to be doable in a week. I gave myself an ever shorter time limit - a 24 hour timer, 1 single day - from idea to submission.

The gameplay target is 15–20 minutes for a normal playthrough, which means the game moves pretty quickly. New bird every few minutes. No drawn out grinding. No complicated crafting tree. No bird happiness meter. No avian city-builder complexity. (If your “AI generated prose” meter isn’t flagging right now, it should be.)

Just a nest, some fast li’l mini-games, and the question:

what shows up next?

This was a fun project to work on. I hope you enjoy playing through it!

Oh, and one other thing. To meet the “America 250” theme requirement, all of the birds are pretending to be bald eagles. They’re trying so, so hard.

Go play SKY KING now!

Eric

Summer into AI: Theme 1

8-bit America…

Read more

a month ago · 1 like · Eric