The most useful thing my tool does is refuse to answer

The instinct when you build a tool that answers questions is to make it answer every question. An empty result feels like failure, a "not sure" feels like unfinished work, so you reach for a default or a plausible-sounding guess and ship a thing that always has an opinion.

For a tool a professional relies on, that instinct is backwards. The opinion it shouldn't have is the one it can't stand behind.

PermitCheck reads a permit package and tells a designer whether it's ready: complete, and compliant with the zoning that applies to that specific lot. The temptation, the whole time, is to always return a verdict. The drawing is busy and the number is small, but the model could guess. The binding limit is site-specific and I'm not certain of it, but a generic default is close enough. Every one of those shortcuts produces a confident answer, and every one is a small lie waiting to be believed.

The math of trust is asymmetric

It took me a while to internalize that for a professional user, a false positive and a false negative aren't equal, and neither is anywhere near as expensive as a confident wrong answer.

A designer who gets one wrong flag, the tool insisting a compliant thing is a violation, doesn't file a bug. They decide the tool is unreliable and stop opening it. You don't get a second chance to be wrong with confidence. So the most important number in my system isn't how much the tool catches, it's how often it's right when it speaks.

You buy precision by being willing to say less. Every time the tool can't confirm a value, or can't confirm the limit it would compare against, it returns "not verifiable, check this manually" instead of computing a verdict off something it isn't sure of. For someone whose name is on the submission, that's the most valuable thing the tool can do: tell them where its confidence stops so they know what to check themselves.

Abstention has to be designed in, not bolted on

It's easy to say "the tool should know when it doesn't know." It's hard to make true, because by default these systems don't abstain. A language model asked for a number will give you a number. The not-knowing has to be enforced by something that isn't the model.

So I built the boundary explicitly. A verdict is allowed to be confident only when two separate things both hold: the value was read cleanly, and the limit it's compared against was resolved from a source I trust for that specific property. If either is shaky, the result is capped at "not verifiable" before any confident claim can leave the system. A generic default that happens to be close can't masquerade as the real limit, and a low-confidence number read off a crowded page can't become a violation. The abstention is a gate sitting in front of every answer.

“Value read cleanly, within the limit resolved for this lot”

SUPPORTED

“Value read cleanly, over the limit resolved for this lot”

CONTRADICTED

Flagged as a violation: both the value and the limit were confirmed.

“Small number on a busy drawing”

NOT VERIFIABLE

The read couldn't be confirmed. Check this manually.

One payoff surprised me. When a user reports a wrong number, I know immediately it isn't the model, because the model was never allowed to be the last word on a number it couldn't stand behind. When the tool fails, it fails by being quieter than I wanted that day, and quiet is a failure I can live with.

What you give up

The cost is recall. A tool that refuses to answer when it's unsure catches less than one that guesses, and on the page that looks like a weaker product. I decided that was the right trade and I'd make it again. A checker that catches eighty percent of problems and is right every time it flags one gets folded into a professional's process. A checker that catches everything and cries wolf one time in five gets abandoned.

If you're building something whose output a person will act on, make "I can't confirm this" a real outcome and build the gate that enforces it. Measure precision before anything else.