Document AI has become good. Point a modern extraction model at an invoice, a purchase order, a driver's licence or a standard lease, and it will return the fields you asked for with accuracy that would have been implausible five years ago. It is reasonable to assume the same tools will work on a warranty deed. They do not — or rather, they appear to work, which is worse.
The reason is not that courthouse records are harder to read. Many are perfectly legible. The reason is that a recorded instrument is not a form. It is a legal document whose meaning depends on things that are not printed on the page, and a system built to find fields will find them and miss the meaning.
What generic document AI is actually built for
General extraction systems are optimised for documents that share three properties.
Bounded vocabulary. An invoice has a total, a date, a vendor, line items. A model can learn what a "total" looks like across millions of invoices because every invoice has one and calls it something similar.
Layout regularity. Forms put the same information in roughly the same place. Even free-form documents like contracts have recognisable structure — parties at the top, signatures at the bottom, numbered clauses between.
Field independence. The value of one field rarely changes the meaning of another. A vendor name is a vendor name whether the total is large or small.
Recorded instruments violate all three, and they do it in ways that look innocuous from the outside.
Failure one: the instrument type changes what everything else means
A warranty deed and a quitclaim deed can be word-for-word identical in their party block, their legal description and their consideration clause. The difference is a phrase — "grant, bargain, sell and convey… with general warranty" against "quitclaim and release" — and that phrase determines whether the grantor is guaranteeing title or merely walking away from whatever interest they may have had.
A generic model reads both and extracts the same fields. It may even label both "deed". A title examiner reads both and sees two different legal acts with different consequences for the chain.
The same is true across the instrument catalogue. A deed of trust and a mortgage secure debt differently. A partial release and a full release do different things to a lien. An affidavit of heirship transfers nothing but establishes who can. A correction deed replaces a prior instrument rather than adding to it. Classification is not a labelling exercise that happens before extraction; it is a legal judgement that determines what the extracted fields signify.
Failure two: party roles are structural, and the conventions are unwritten
"Grantor" and "grantee" look like two fields. They are not. They are roles in a transaction, and identifying who holds which role requires reading the instrument as a whole.
Consider what a party block routinely contains. Names in surname-first order in the index but given-name-first in the body. Marital status qualifiers — "a married woman as her sole and separate property," "husband and wife," "a single man" — which are not descriptive colour but determine how an interest passes and whether a spouse's signature was required. Capacities — "as Trustee of the Alvarez Family Trust," "as Independent Executor of the Estate of…" — which mean the named person is not the party at all; the trust or the estate is. Corporate parties with successor language: "First Mesa Bank, successor by merger to Cedar Valley Savings."
Then there are the multi-party instruments. An oil and gas lease may name fifteen lessors in the body and fifty more in an attached exhibit, each with a fractional interest. A Lis Pendens may list its parties in a prose paragraph rather than a block. A generic extractor trained on two-party documents will find the first name in each role and stop.
None of these conventions is documented anywhere a model could learn them from. They are known by the people who have read ten thousand instruments from that county.
Failure three: the legal description is a grammar, not a field
Ask a generic system for the "property address" and it will find one if the instrument has one. Most recorded instruments do not describe land by address. They describe it by legal description, and a legal description is not a value to be captured — it is a structured statement to be parsed.
"The Southeast Quarter of the Southwest Quarter of Section 14, Township 22 South, Range 2 East, N.M.P.M." contains a quarter-quarter call, a section, a township with a direction, a range with a direction, and a meridian. Each is a separate component; each is needed to post the instrument to the right place in a geographic index. Capture it as a text block and you have preserved the words while losing the structure — the plant cannot post to a string.
Metes-and-bounds descriptions are a sequence of bearings and distances that has to be read as a sequence. Lot-and-block descriptions reference a plat that has to be resolved. Abstract-and-survey descriptions in Texas reference a survey system that exists nowhere else. And a single instrument can contain two or three of these, describing multiple tracts, each of which needs posting separately.
A generic model, asked for the legal description, will return the paragraph. That is not wrong. It is just not useful.
Failure four: the document refers to documents it does not contain
Very often the legal description is not in the instrument at all. It reads: "being the same property conveyed to Grantor by deed recorded in Book 412, Page 88." The instrument is describing land by pointing at an earlier instrument.
Resolving that reference means finding Book 412, Page 88 in the plant, reading its legal description, and carrying it forward — while checking that the earlier instrument actually describes what the later one claims it does. A system that processes one document at a time cannot do this, because the information it needs is in a different document. It will extract "Book 412, Page 88" as text and move on, and the instrument will be posted, if it is posted at all, as a "see instrument" entry: present in the plant, invisible to a property search.
This is not an edge case. In a mature county, a substantial share of deeds describe land by reference.
Failure five: the records themselves are hostile
Courthouse records are old, and they were not produced with machine reading in mind. Typewritten text over pre-printed forms, where the form's lines cross the typed characters. Handwritten marginal notes that change the meaning of a clause. Exhibits scanned rotated ninety degrees. Carbon copies. Microfilm reproductions of microfilm reproductions. Stamps and seals over the party names. Fonts that have not been in use since the 1950s.
Modern OCR handles many of these. The point is not that the text cannot be read; it is that the reading has to be reliable enough to post an instrument on, and the cost of a misread character in a section number is not a typo in a database — it is an instrument posted to the wrong tract, where no search for the right tract will ever find it.
Why the failures are expensive: they are silent
An invoice extraction error is caught when the total does not reconcile. A form extraction error is caught when a required field is blank. The feedback is fast and the fix is local.
A courthouse extraction error produces a plausible-looking record that goes into the plant and stays there. A quitclaim classified as a warranty deed does not throw an exception. A legal description captured as a string posts nowhere and nobody notices. An instrument posted to Section 41 instead of Section 14 sits in the wrong place for decades. The error surfaces, if it surfaces, when an examiner searches the right tract, finds a clean chain, and issues a commitment on a title that has a cloud on it — which is the precise outcome a title plant exists to prevent.
That asymmetry is why accuracy claims about generic tools are not reassuring. Ninety-five percent field accuracy on invoices means five percent of invoices need a human look. Ninety-five percent on recorded instruments means five percent of a county's chains are quietly wrong.
What purpose-built looks like
The alternative is not a better general model. It is a system built around what recorded instruments are.
A domain schema, not a field list. Instrument types as legal categories with defined consequences. Party roles as structural positions. Legal descriptions as parsed components in the description system the county actually uses.
Reference resolution as a first-class operation. "See instrument" is a link to follow, not a value to store.
County conventions as configuration. Abbreviations, name formats, index eras and description systems captured as rules that accumulate, so the hundredth county benefits from the ninety-nine before it.
Human review where the cost of error is highest. Confidence scoring that routes exceptions to a reviewer rather than spreading review thinly across every field. Every approval recorded with lineage — page, field, reviewer, time — so that when a question arises years later, there is an answer.
Evaluation against the right standard. Not "did we extract the fields" but "would this record post correctly, and could an examiner rely on it."
Generic document AI is genuinely good at what it was built for. Courthouse records are not what it was built for, and the failures do not announce themselves. That combination is why the title industry has been slower to automate than its document volumes would suggest — and why the tools that do work look less like document AI and more like a title examiner who happens to be very fast.