IT HootClub — AI Community Newsletter

What Doesn’t Go In

Last week the schema stopped being a diagram and became a real database: tables sitting empty on Neon, waiting. This week was supposed to be the easy part — fill them. I’d been pointing at “get the data” for a month, and I assumed the work would be mechanical. Find the orgs, enter them, move on.

It wasn’t mechanical at all. The hardest decision in this project so far hasn’t been a line of code or a column type. It’s been deciding what doesn’t belong.

Here’s the trap I kept walking into. The moment you start listing Milwaukee tech organizations, the list explodes — every company with an engineering team, every startup, every consultancy. And I kept catching myself adding them, because surely a software engineer moving to Milwaukee wants to know about employers. But that’s not the question this database exists to answer. The question is about community: where you go to get involved, meet people, find events, volunteer — to belong somewhere before you belong anywhere on a payroll. A list of employers answers a different question. A real one, maybe even the one the engineer secretly wants — but I can’t assume that. Maybe they want to contribute before they interview. The second I start guessing at intent and padding the database with “probably useful” entries, I’ve rebuilt the exact thing I’m trying to beat: a generic search that returns everything and makes you sort it out.

That’s the whole point, and it took building the thing to feel it. The advantage of a purpose-built data source isn’t how much it holds — it’s how much it leaves out. A general-purpose model casts the widest net it can and hopes relevance falls out the other side. This does the opposite: a narrow, deliberate net, where the discipline of keeping it narrow is the product. Garbage in, garbage out — and “garbage” here doesn’t mean wrong data. It means correct data that answers the wrong question.

The schema now enforces that discipline structurally instead of leaving it in my head. National events like CypherCon or BSides need a home in the data so their events have something to attach to — but they aren’t Milwaukee community organizations, so they’re flagged to stay out of the featured inventory. The editorial rule — “don’t pad the inventory with things that don’t fit the question” — is no longer something I have to remember every single time. It’s built into the database itself: nothing is part of the inventory until a human deliberately says so. (How that flag actually works is this week’s Under the Hood.)

And here’s what I didn’t expect to be thinking about: this isn’t build-once-and-walk-away. Keeping garbage out on day one is one problem; keeping it out as organizations fold, rename, move, and drift is a different one entirely. Curated data starts decaying the moment you stop tending it. That realization is what became this week’s Fireside Chat — I asked the models where data and database maintenance sits among the fastest-growing fields in tech. Their answers are below. I suspect it’s far more central than it gets credit for, and building this is exactly why I think so.

As for the data itself: it’s not all in yet, and I won’t pretend otherwise. I have outgoing queries to authoritative sources, confirming specific organizations before I commit them, because the entire premise is that nothing goes in unverified. Watching the inventory actually fill with real, sourced, Milwaukee organizations is a reveal I’m saving for when it’s real. Consider this the partial unveiling — the discipline, the structure, the decisions behind what earns a row. The populated database comes before the model work, and it arrives when it’s earned. Patience.

A Rule the Database Won’t Let Me Forget

Building Intelligence this week made the case that the inventory’s value comes from what stays out of it. This is the part where that editorial rule stops living in my head and becomes something the database itself enforces. It came down to adding two small fields. The interesting part isn’t what they are — it’s when I added them, and everything I deliberately chose not to do.

First, what they are, in plain terms. I added two yes/no switches to the database: one on each organization that says “is this a Milwaukee-local org that’s allowed to show up in the inventory?”, and one on each source that says “is this trustworthy enough to feed the events list?” In database terms, a yes/no field like this is called a boolean — it can only ever hold one of two answers. I set both up so they can never be left blank (the database rejects any row that doesn’t answer the question) and so they start on “no” by default. That default is the entire philosophy compressed into a setting: nothing is eligible, nothing is trusted, until a human deliberately switches it to “yes.” Silence means no. You have to earn the yes.

Now the timing, which is the real lesson. I added these two switches before entering a single organization — while every table is still empty. That sounds backwards: why build the filter before there’s anything to filter? The answer is about what it costs to add a mandatory field to a table that already holds data. If I’d added a “can’t be blank” field to a table holding fifty organizations, the database would have to go back and write an answer into all fifty existing rows to satisfy the rule — a slow, heavy operation that has a name: a backfill. On an empty table, there are no rows to fix, so the same change is instant and free. Add it now, it costs nothing. Add it after I’ve hand-entered fifty verified organizations, and I’ve bought myself that backfill plus a stretch of time where the rule wasn’t being enforced yet. Doing it first wasn’t caution for its own sake — it was catching the cheap moment on purpose.

Then the part I’m quietly proud of: what I left out. There’s a database feature called an index — essentially a lookup shortcut that helps you find rows quickly in a large table. I added none. At the five-to-eight organizations this will hold at the start, the database can read the entire table faster than it could consult a shortcut, so an index would be pure decoration — something that makes me feel like an engineer without doing anything useful. I also didn’t add these switches to events or venues, because those get excluded by a judgment call when I simply choose not to enter them; a field there would be enforcing a rule that nothing actually breaks. And I gave the organization switch a name that reads like plain English when you ask the database a question, so that future-me, reading the query back months later, understands it instantly. Each of those was a small “no.” The design is as much about what I refused to add as what I added — the same instinct as the inventory itself.

Here’s what those two switches really buy, and it’s bigger than filtering. They turn “is this trustworthy? is this in scope?” into a recorded fact attached to the data — not a decision I’m carrying around in my head, hoping to apply consistently. That’s the same idea running through the whole schema: the separate “raw” versus “human-approved” descriptions, the consent flags on people, every fact tracing back to a cited source. The database isn’t just storing what I know about Milwaukee’s tech scene; it’s storing how much I trust each piece, and why. A judgment that used to live in my memory now lives in the data, where it can’t quietly drift, be forgotten, or depend on my mood the day I enter a row. That’s the real upgrade — not a filter, but provenance you can point at.

There’s a name for what all of this adds up to: structured data. It just means information organized into a predictable, labeled shape — tables, defined fields, fixed relationships — so a machine can ask it precise questions and get reliable answers back, instead of guessing at meaning from a wall of free-form text the way it has to with a random web page. And structured, verified data like this is the closest thing I’ve found to a natural enemy of hallucination — the problem that started this whole series. A model invents things when it has nothing solid to stand on and is forced to generate from patterns. Give it a clean, curated, structured source to draw from, and you’ve taken away the reason it had to guess in the first place. This database isn’t the AI. It’s the ground the AI will eventually stand on — the first, unglamorous, non-optional step toward a model you can actually trust about Milwaukee.

I know what some of you are already thinking: well, that’s not really AI anymore — you’re cheating by handing it all the answers. It’s a fair objection, and a big one, and I’m going to take it seriously — in a future edition, once the whole exercise is finished and I can show you the result instead of just arguing about it. For now I’ll say only this: handing it the right answers first isn’t a workaround. It’s the point. But that’s a debate that’s earned its own edition, so I’ll leave it there.

This week’s prompt came straight out of the work. After spending the hardest stretch of this project deciding what belongs in a database — and bracing for the job of keeping it accurate as the real world drifts — one question wouldn’t leave me alone: how big a deal is this, actually? So I asked all three models where the fastest-growing fields in tech are right now, and where the unglamorous work of data and database maintenance lands on that list — today and looking forward.

Read their answers the way this section always asks you to: skeptically. Watch for whether each model takes the maintenance question seriously or treats it as an afterthought to the flashier picks — that contrast is often more telling than the rankings themselves. My own bias is on the table: I think tending data is closer to the center of where this is all going than the hype suggests, and building this is the reason I think so. See if they make the case better than I just did, or worse.

What is the fastest-growing tech-related field in the world right now? And where would you place the need for data and database maintenance in relation to that list — both now and in the future?