Approximately Right
Is Wrong

Architecting AI for domains that have exact answers

The industry AI playbook assumes tolerance for being wrong. Recommendations, search ranking, summarization, creative generation make us feel 92% right is a triumph. An enormous class of systems doesn't work that way: tax, payroll, custody, settlement, lending, grading. These have an answer, and the cost of missing it is legal, not experiential.

The reflex is to chase a better model. That's the wrong axis. The right move is architectural: put the probabilistic component outside the correctness boundary. The model extracts, navigates, explains, triages and proposes. A deterministic, verifiable system computes and commits.

We already know how to do this. We spent thirty years learning to build reliable systems on unreliable networks. We didn't make packets stop dropping but we built ordering, retransmission and idempotency on top of a substrate that offers no guarantees. Reasoning is now that substrate. It's lossy, non-deterministic and occasionally confidently wrong. The answer is the same: don't fix the substrate, design the layer above it.

Where the line goes

The test I use is blunt. Delete the model. Can the system still reach a correct answer, more slowly? If not, the model is inside the boundary and it shouldn't be.

Two things we shipped at PWCC, the collectibles marketplace I led as CTO before the acquisition, make the line concrete.

The grade was an exact answer decision. A card's condition set its price, and a mis-grade was a direct financial loss on an asset we held in custody, part of $900M+ under management. We ran computer vision on EfficientNetV2 for detection, centering and surface-defect analysis, but it fed a workflow where the committed grade stayed reviewable, reproducible and attributable. The SEC examined that workflow during our review as a regulated marketplace. It held up, because compliance was auditable system behavior rather than policy documentation.

The valuation tool was the opposite case, and the more interesting one. Collectors were shipping us cards worth less than the postage. We gave them a model that estimated value before they shipped — knowing openly that it is an approximation with no commitment. Worthless intake dropped 60%.

Same technology, opposite sides of the line. Approximate where approximate is fine, exact where it isn't. Most of the available value sits upstream of the decision you can't afford to get wrong.

Provenance is a schema problem

Every committed output should carry its inputs, model version, rule-set version and decision basis in the record, not in the log. Not just for compliance, but so that eighteen months later you can reconstruct why the system did what it did. Logs rotate. Schemas don't.

What I got wrong

Years earlier at Ebates I sponsored a unified multi-merchant cart. I validated consumer demand exhaustively. I never validated the merchants whose cooperation the whole model depended on. It launched, it worked, and it died when they blocked us at the IP level.

The component was fine. The failure was at a boundary I hadn't modelled.

That's the same mistake teams are making with AI right now by evaluating the model in isolation and calling the system safe. An eval tells you how often the model is right. Architecture decides whether the system is allowed to be wrong.