The raw capability at the center of a document-extraction tool — read a document, pull out structured values — is becoming a commodity. The underlying models keep getting better at it, and they’re available to everyone. If your product is just “point a good model at a document,” then your product is something a competitor can stand up in an afternoon, and so can the model provider itself. The extraction engine is not where the durable value is. What’s durable is the domain knowledge encoded around the engine — and the last two ideas, about which errors cost the most and which fields to decline, are both really about that.

Knowing which fields carry the highest cost when wrong is domain knowledge. A generic tool can’t know that a particular date is the one that triggers a financial consequence while another is incidental, or that a specific figure means something different depending on surrounding terms. That knowledge comes from understanding the work the output feeds into. Knowing which fields to decline — which ones look extractable but actually require human judgment — is domain knowledge too. It comes from having seen the cases where a naive extraction was confidently wrong in a way that mattered. Neither of these is in the model. Both have to be supplied by someone who knows the field.

This is why the defensible product isn’t the extraction; it’s everything that surrounds it with judgment. The mapping of which fields are high-stakes and deserve conservative handling. The decisions about what’s in scope and what’s explicitly handed back. The understanding of what provenance a professional needs to make the output defensible in their own work. The calibration of where to flag uncertainty because that’s where errors are expensive. All of that is a layer of encoded expertise sitting on top of a commodity engine, and it’s the layer that a generic competitor — or a general-purpose model with a clever prompt — doesn’t have and can’t easily acquire.

It also reframes what “building the product” means. The temptation is to treat the work as primarily technical: better extraction, more fields, higher accuracy. But if the engine is a commodity, the technical work has a ceiling, and beyond that ceiling the competition all has access to the same capability. The work that compounds is the domain work: deepening the model of which errors matter, refining the scope boundary, encoding more of the judgment a domain expert applies. That work gets more valuable over time and is specific to you in a way the extraction capability never will be.

The practical implication for someone building in a specific vertical: your advantage is not that you can extract better than the next tool. You probably can’t, for long. Your advantage is that you understand the domain well enough to know what matters, what to refuse, and what the user needs to trust the output — and you’ve built that understanding into the product. Lead with the domain judgment, treat the extraction engine as the commodity input it’s becoming, and invest in the layer that competitors can’t copy by swapping in a better model. The model is everyone’s. The judgment is yours.