The Scope That Makes You Better
A tool's scope is not just what it covers — it's what allows it to be good at what it covers. Narrow scope is not a limitation. It's a prerequisite for excellence within the scope you chose.
Document-Processing
Closing the Loop
The production gap and the disappearing failure report are two symptoms of the same problem: an open loop. The tool that improves fastest is the one that closes it — tightly, deliberately, as a first-class part of how the product is built.
The Failure That Teaches
Not all failures are equally useful. A failure on a document the tool has never seen before is the most valuable feedback it can produce — but only if you capture it before it disappears.
The Production Gap
A document tool's performance on your evaluation set and its performance on your users' actual documents are two different numbers. The gap between them is structural, not a bug — and closing it requires a different kind of work than improving the eval.
The Honest Decline
No tool handles the entire long tail. The behavior that separates a trustworthy tool from a dangerous one is what it does on the document it can't handle: decline honestly, or guess and hope.
The Long Tail of Documents
The easy documents are all easy in the same way, and a tool handles them on day one. The value — and the difficulty — lives in the long tail of documents that are each weird in their own particular way.
Walking Down the Tail
If the tail is the product and honest declines mark its edge, then the work is a slow walk down the tail — turning each declined document into a handled one. That walk is what compounds into a tool nobody can catch.
Designing for the Skim
Users don't carefully audit every field a tool extracts. They skim. A tool that assumes a thorough review gets one that doesn't happen — so the output has to be built for the glance, not the audit.
The Attention Budget
A user reviewing a tool's output has a small, fixed amount of attention to spend. The tool's real job at the review stage is to spend that budget where it changes outcomes — not to hope there's more of it than there is.
The Plausible Wrong Answer
The dangerous extraction error isn't the one that looks broken — the user catches that. It's the one that looks exactly like a right answer and sails straight through the quick review.
The First Mile
If the last mile is getting output into the user's workflow, the first mile is getting the document in. The friction at the start of the task quietly decides whether the tool gets used at all.
The Last Mile of the Output
A document tool's job isn't done when it produces a correct result on its own screen. It's done when that result is sitting in the format and place the user actually works in. The gap between those is where tools quietly fail.
The Tool That Disappears
The highest compliment a workflow tool can earn isn't 'I love using it.' It's that the user stops noticing it — because it fits the work so well it stopped being a separate step.
Domain Knowledge Is the Product
The extraction engine is increasingly a commodity. What's left as the durable product is the domain knowledge encoded around it — and that's the part a generic competitor can't copy.
Not All Errors Cost the Same
Aggregate accuracy treats every field as equally important. The user doesn't. Where a tool spends its reliability should follow the cost of being wrong, not the count of fields.
The Fields You Choose Not to Extract
The instinct is to extract every field a document contains. The more useful discipline is deciding which fields the tool should refuse to extract — and saying so.
The Defensible Output
For a professional, the output of a document tool isn't the end of the work — it's something they may have to defend to a client, a reviewer, or a counterparty. That changes what the output has to be.
The Reliance Threshold
There's a specific moment when a professional stops double-checking a tool and starts relying on it. Everything before that moment is a trial; everything that matters happens after. Most tools never get a user across it.
Where the Document Goes
For a tool that processes confidential documents, the first question a serious buyer asks isn't about accuracy. It's where their document goes — and most tools answer it badly or not at all.
The Confidence Score Trap
Attaching a confidence score to every extracted field feels like a transparency win. Uncalibrated, it's worse than nothing — it launders uncertainty into a number users can't act on.
The First Wrong Answer
Every extraction tool eventually produces a wrong answer a user catches. Whether the tool survives that moment is decided by design choices made long before it happens.
The Verification Budget
Every user of an extraction tool has a finite amount of attention they'll spend checking its output. The tool's real job is to spend that budget well — and most tools spend it badly.
Absent vs. Unknown
When document extraction returns an empty field, there are two very different reasons. Collapsing them into a single null output is a design mistake that quietly destroys trust.
The Extraction Boundary
There's a line between what a document processing system can extract and what requires domain reasoning. Getting that line wrong in either direction is expensive.
The Large Document Problem
Document processing tools that work on short documents often break on long ones. Large-doc support needs to be a day-one requirement, not a later addition.
What the Citation Enables
An AI-extracted output without a source citation is a claim. The same output with a citation — page number, table, line — is auditable work product. The citation is what makes the output usable in professional contexts, not a nice-to-have.