It Has to Be Aimed

The honest answer: a lot. But not the way most people imagine.

I’m not an engineer. My career started at an institution, then expanded to campus master plans, space-needs assessments, and classroom utilization studies across dozens of them. I’ve never written production code. Now I direct AI to do analysis that used to take weeks.

“Direct” is the operative word. AI doesn’t show up one morning and start analyzing your occupancy data. It has to be aimed. I spent months building the foundation — data dictionaries that define every metric in our system, field definitions that translate technical column names into language a facilities director can actually use.

One of my biggest fights with AI is its default register. My customer doesn’t care that a field is called occupied_rate_v2. He cares how well the spaces in his science building are being used. That translation — from what the data is called to what the data means — still requires someone who understands the work.

That’s the part I bring to it.

AI Still Gets Things Wrong

Last month, I was pulling numbers for a similar-sized institution and got a seat count that was physically impossible. The bot had summed every zone in our building hierarchy — zones, floors, and building totals — as if they were all separate rooms. It counted the same seats three times.

I caught it because I know what a real seat count looks like. Then I built the guardrail. Now the bot knows not to sum across hierarchy levels, and I know how to better direct it when starting an analysis.

A few weeks ago, a customer deliverable had gone through our full review process — AI pass, human eyes. When I pulled up the source data, a number was off. The AI hadn’t flagged it. My review did.

These aren’t embarrassing admissions. They’re the reason the work is good.

Building the Checks Into the Process

When we started using AI for customer deliverables, we hit another problem: revisions lost context. So we built what we call metric registries — structured records that tie every figure in a deliverable back to the original data, the query that produced it, and the metric definition that gives it meaning.

When the bot drifts, the registry pulls it back. If a number shifts between drafts, we can trace exactly where it changed and why.

Every customer-facing deliverable also gets human review plus a second AI review. We call it a second opinion, because AI wants to please. In practice, it feels a lot like editing — draft, challenge, revise, verify against the source. It’s the same thing any good analyst does, only faster and with one more set of eyes.

About Those Em Dashes

One more thing, because I find this genuinely funny: a customer noticed that our reports use em dashes. He flagged it as an “AI tell.” Our sales team strips em dashes from proposals for the same reason — apparently they now read as machine-generated.

I use em dashes in everything I write. I have a keyboard shortcut for them. They’re grammatically correct. I will die on this hill.

If a report reads as AI-generated, that’s feedback I want to hear. But the em dash isn’t the tell. The tell is when the analysis doesn’t survive a question — when someone asks, “Where did this number come from?” and the answer is hand-waving instead of a data trail.

That’s what we built the systems to prevent.

The Expertise Is Still Human

A couple of years ago, I was a space analyst who used spreadsheets, Access databases, and PowerPoint. AI didn’t replace my domain expertise. It made that expertise buildable in ways I never expected — deeper analysis, new questions we never had the capacity to ask — while also exposing exactly how much human judgment the work still requires.

The customer’s question was the right one. How much of this is AI? Enough to compress weeks of analysis into days. Not enough to send it without a human who knows what the numbers should look like.