← Engineering Notes

Postmortem

Designing for the False Negative

Oct 2026 · Contract Explainer · Claude API, serverless

In legal extraction a missed clause costs more than a wrong one — so the architecture optimizes for recall and makes every flag cite its source.


Most AI demos optimize for looking right. Contract Explainer had to optimize for not being wrong in the one way that matters.

The product reads a contract or policy and surfaces the clauses that carry hidden liability — auto-renewals, indemnification, arbitration waivers, acceleration. Early on I had to decide which kind of error I was willing to tolerate, because you cannot drive both to zero. A false positive flags a harmless clause; the user reads one extra paragraph and moves on. A false negative stays silent on a real indemnification clause, and the user signs it. Those two errors are not equal, and pretending they are is how you ship something dangerous. I tuned the whole system toward recall: I would rather over-flag and let the user dismiss than under-flag and let them get hurt.

That decision cascaded into three architectural choices.

First, grounding. Every flag the model returns has to quote the exact span of source text it came from. The model does not get to assert "this contract auto-renews" in the abstract; it has to point at the sentence. That lets the user verify instantly, and it collapses a whole class of hallucinations — an output with no corresponding source span becomes a bug I can catch rather than a confident lie I can't.

Second, chunking with overlap. Real contracts blow past a context window, and the naive fix — split into chunks — creates a new failure mode: a liability that straddles a chunk boundary gets cut in half and missed by both halves. So chunks overlap, and clause detection is allowed to fire on either side of a seam instead of assuming each chunk is self-contained.

Third, a deterministic floor. Under the probabilistic model sits a plain keyword-and-pattern scanner — the same logic that runs in the browser demo on my site. It will never be as smart as the model, but it is not subject to temperature, prompt drift, or a bad day. If the model is having one, the floor still catches "indemnify," "arbitration," "non-refundable." The probabilistic layer extends recall; the deterministic layer guarantees a minimum. Production AI is rarely one model doing everything — it's usually a smart layer and a dumb layer that fail in different directions.

What I'd do differently: I leaned on prompt instructions for recall before I had a labeled set to measure against, which means for a while I was asserting the system was thorough without proof. You earn the word "thorough" with a test set, not a prompt. That's the discipline I carried into the Security Scanner, where I built the answer key before I trusted the tool.

The lesson is small and blunt: decide which error you're afraid of before you design, because every real system is a negotiation between two kinds of being wrong.

← Back to Engineering Notes · © 2026 ParqueMedia LLC