Somewhere in the second slide of most AI vendor pitches in this industry, including some of ours, there is a line about which frontier model the product runs on. The name is meant to reassure. It usually works. But I was building statistical models to clean up OCR on recorded documents long before anyone called that AI, and the lesson I learned then still holds: the size of the model is not the feature. The fit between the model and the task is. For most of what title work actually is, the biggest model available is the wrong tool, and buying it is often buying the wrong thing at the wrong price.

What Title Work Actually Is

Decompose the work and it falls into a handful of task types. Classification: what kind of instrument is this page? Extraction: pull the grantor, the grantee, the legal description, the recording information, the amount. Matching: does this instrument belong to this parcel, this chain, this name? Summarization: turn forty instruments into something an examiner can read in two minutes. And judgment: is this an encumbrance that matters, what requirement does it generate, what exception does it produce.

Those are not the same kind of problem, and they do not need the same kind of model. The first three are narrow. The vocabulary is fixed, the document formats are finite even when they are ugly, and the errors that matter are domain-specific: a transposed section number, a grantee read as a grantor, a release matched to the wrong mortgage. The last two are open-ended. They reward broad reasoning, long context, and the ability to notice that something unusual is unusual.

Where the Small Model Wins

On the narrow tasks, a small model trained specifically on title documents will match or beat a frontier model, and I mean that as a plain engineering statement rather than a marketing one. A general model has seen every kind of document in the world and has to figure out, from the prompt, which of its knowledge applies. A model trained on a few hundred thousand recorded instruments has nothing else to be distracted by. It knows what a county clerk’s stamp looks like in 1974. It knows the fourteen ways a legal description can be formatted in your state. It does not need to be told, on every page, what a mortgage is.

The July 7 post on plant data quality made the point that the model is only as good as the index it reads. The companion point is that a model built on that index, rather than on the internet, learns the specific pathologies of that data. The September 3 post on reading a photocopy of a photocopy is the clearest case: a model trained on degraded recorded documents is better at degraded recorded documents than one trained on clean web text and asked to generalize. And the October 27 post on OCR versus extraction showed why the checks that matter are domain checks against the record, which is exactly what a purpose-built model can be trained to make.

The Cost Curve Decides the Pricing

Then there is the arithmetic. A frontier model charges by the token, and a title plant is millions of pages. Run every page of every file through the largest model on the market and the per-order cost is real money, which is why so many AI pricing sheets in this industry look the way they do. The August 11 post on per-order pricing and the October 15 post on volume tiers both come back to the same root: a vendor’s pricing is a reflection of its cost structure, and if the cost structure is a frontier model on every page, the customer pays for that on every order. A small model runs at a small fraction of that cost per page. That difference is what makes it possible to price the narrow work the way it should be priced: as infrastructure, not as a metered luxury.

Run It Where the Data Lives

The argument I care about most is not cost. It is where the data goes. In September I wrote about what happens to your file data when your vendor calls an AI, and the four questions to demand in writing: retention, training carve-outs, subprocessors, and SOC 2 scope. Every one of those questions exists because the data leaves. A small model does not need to send it anywhere. It can run inside the vendor’s own environment, or inside yours, with no third-party model provider in the chain at all. That is not a contract clause promising your data won’t be retained. It is an architecture in which there is nobody to retain it. For an independent agency answering the security questionnaires I wrote about last week, that distinction is the difference between a paragraph of explanation and a single word.

Where the Frontier Model Still Earns Its Keep

None of this means the big model goes away. The judgment layer is where it belongs: the unusual instrument, the chain that doesn’t make sense, the question that needs reasoning across forty documents rather than reading one. That is also the layer where a human is reviewing the output, which is where the July 16 post on human-in-the-loop design said the human should be. The right architecture is a small, fast, cheap model doing the bulk of the narrow work close to the data, with a frontier model as the escalation tier for the cases that need it, and a person above both. We are actively testing exactly that split right now, and I will write about what we find when the numbers are in rather than before.

The One Question to Ask Any Vendor

So when the slide with the model name comes up, ask one question: which tasks run on which model, and why? A vendor who has done the decomposition will have a crisp answer, and it will probably involve more than one model. A vendor who says the whole product runs on the biggest model they could license has either not thought about it or is hoping the name does the thinking for you. The model is not the feature. Knowing which model each part of your work actually needs is.

See how we match the model to the task across the title workflow →