AI on rails

The instinct with a powerful model is to hand it the wheel — feed it the data, ask for the answer, ship whatever comes back. It’s a good demo and a bad product. The interesting design question isn’t how much you can let the AI do. It’s what you must never let it do, and how you build the rails that keep it there.

Claude is genuinely good at the analyst’s cognitive work: reading a messy file and understanding it, spotting that a column of text is really a date, deciding that revenue-by-region is the comparison that matters here, noticing what changed since last month. That’s judgment — and judgment is exactly what you want a strong model doing.

What you don’t want it doing is the math. The moment a number has to be exact — a total, a growth rate, a filtered sum — that belongs to deterministic code running over the real rows, not to a model producing a plausible token. So in blueberry. the model never touches the arithmetic. It chooses what to compute; a governed query compiler computes it; the result is rendered as it comes back.

Let the model think. Let the code count. Never confuse the two.

This is the difference between an AI that’s impressive and one you can leave running your reporting. The rails — schema-validated artifacts, a compiler that re-checks everything, the raw data kept out of the model’s reach — are not a limitation on the AI. They’re what make its judgment usable. A brilliant analyst who might be making the numbers up is not an analyst you keep.

“AI on rails” isn’t a compromise between smart and safe. It’s how you get both — the model’s judgment and a number you can trust — at the same time. That’s the only version of this worth building.