Anyone who has built a title plant for more than one county knows the moment: the pipeline that worked perfectly in the first county produces garbage in the second. Not because the second county's records are worse, but because they are different — in ways nobody wrote down, because within that county everyone already knew.
This article is about those differences. It is written for people deciding how to automate land-record work, because the single most important thing to understand before choosing a method is that there is no such thing as "county data." There are more than three thousand counties, and each is a format.
Where the variation comes from
Land records are recorded by county officials operating under state law, and the law generally specifies what must be recorded and indexed, not how. Within that latitude, each recorder's office has made its own decisions over a century or more — about numbering, about indexing, about imaging, about which vendor's software to buy and when — and each decision left a layer in the records.
The result is that variation exists along at least six independent dimensions, and a county can sit anywhere on each of them.
Dimension one: how instruments are identified
The oldest layer is book and page: instruments were recorded into physical volumes, and an instrument's identity was the volume number and the page it started on. "Book 412, Page 88." Many counties still cite this way for older records, and the plant has to as well, because that is how every later instrument refers back.
At some point — a different year in every county — recorders moved to instrument numbers: a sequential or date-encoded identifier assigned at recording. Some counties kept book-and-page alongside; some abandoned it; some assigned instrument numbers retroactively to the back records; some did not.
Automation has to handle both systems, know which era an instrument falls in, and resolve references across the boundary. A 1998 deed citing "Volume 1204, Page 331" and a 2015 release citing "Instrument 2015-0047221" may be describing the same chain.
Dimension two: how the index is structured
Every county maintains a grantor–grantee index, but the fields in it, how names are formatted, and how corporate and government parties are entered vary widely.
Names may be surname-first or given-name-first. They may include middle names, initials, suffixes, or none. Marital qualifiers may be in the name field or a separate one. Trustees may be indexed under their own name, the trust's name, or both. "The United States of America" may appear under U, T, or as a code.
Some counties index a "return-to" party or a legal description alongside the parties. Some index the consideration. Most do not. The plant has to know what the county's index does and does not contain, because anything not in the index has to be read from the image.
Dimension three: vocabulary
Ask twenty counties to name a warranty deed and you will get "WARRANTY DEED", "WD", "DEED-WARRANTY", "W/D", "GENERAL WARRANTY DEED", "DEED", and a handful of codes that mean nothing outside the office that assigned them. The same is true of every instrument type, every marital qualifier, every capacity, and every abbreviation in a legal description — "SUBD" and "SUB" and "SUBDIVISION"; "BLK" and "BLOCK" and "B"; "S/2" and "S1/2" and "SOUTH HALF".
None of this is wrong. Each county's vocabulary is internally consistent and its staff use it fluently. But a system that learned one county's vocabulary will misclassify the next county's, and a plant that stores unnormalised vocabulary cannot be searched reliably.
Normalisation — mapping every county's terms to one canonical set — is the unglamorous core of multi-county work, and the mapping is different for every county.
Dimension four: how images are delivered
Recorded instruments are images. How a county delivers them varies in ways that matter for processing.
Format. Multi-page TIF is the traditional courthouse export and remains the most common. PDF is increasingly available. Some counties provide per-page image files with a separate manifest; some provide one file per instrument; some provide a single enormous file for a day's recordings.
Resolution and quality. Two hundred dots per inch from a modern scanner; a hundred from a 1990s digitisation project; whatever the microfilm reader produced for records older than that. Bitonal, greyscale, colour. Compressed with methods that were current at the time.
Orientation and structure. Exhibits attached rotated. Plats attached as separate large-format images. Cover sheets that are or are not part of the instrument. Pages in an order that reflects how they were fed into the scanner, not how they read.
Naming. File names that encode the instrument number, or the book and page, or a batch sequence, or nothing meaningful at all.
A pipeline that assumes one delivery format will need reworking for each new county — unless the assumption is that every county is different, and the ingestion layer is built to be configured rather than rewritten.
Dimension five: how data is exported
Counties that provide bulk data — index records, or index plus images — do so in whatever format their system produces. CSV with the county's column names, in the county's order, with the county's delimiter and encoding. Fixed-width text from a mainframe-era system. XML from a newer one. Occasionally a database dump.
Column names differ. "GRANTOR" and "PARTY1" and "FROM_NAME" are the same field. Date formats differ. Empty values are blank, or "N/A", or a sentinel like "01/01/1900". Multi-value fields — several grantors on one instrument — may be repeated rows, delimited strings, or numbered columns.
The plant's schema is fixed. Every county's export has to be mapped onto it, and the mapping is a piece of county-specific knowledge that has to be captured, tested and kept.
Dimension six: how land is described
This is the deepest variation, because it reflects how the land itself was originally divided.
Thirty states are surveyed under the Public Land Survey System, and describe land by section, township and range. Texas uses abstract and survey. The original colonies and much of the East use metes and bounds. Everywhere, platted land uses lot and block. A county can contain several systems at once, depending on when and where within it land was first divided.
A geographic index — the thing that makes a plant a plant — has to be built for the description systems the county actually uses, with posting rules for each. That is not a configuration setting; it is a structural decision about how the index is organised. It is also why a plant built for one region cannot simply be pointed at another.
Why this defeats "one model"
The instinct when automating is to build one system that handles everything. County variation makes that instinct expensive.
A model trained on one county's instruments learns that county's vocabulary, layout and conventions. Applied to the neighbouring county, it does not fail loudly — it produces confident output using the wrong conventions. "WD" becomes an unknown type. A surname-first name is parsed as given-name-first. A section-township-range description in a county that has moved to a different meridian posts to the wrong place. The output looks like data. It is not the county's data.
Retraining for every county is possible but slow, and it discards what was learned. The alternative that works in practice is to separate what varies from what does not.
What works: configuration over rebuild
What does not vary between counties is the structure of the problem. Every county has instruments with types, parties with roles, dates, references, and legal descriptions in one of a small number of systems. That structure can be built once.
What varies is the surface — vocabulary, layout, formats, conventions — and the surface can be captured as configuration:
- A canonical vocabulary, with a mapping from each county's terms to it, maintained as data rather than code.
- Ingestion profiles describing each county's image and export formats, so a new county is a profile rather than a rewrite.
- Description-system rules per county, specifying which systems are in use and how to parse and post each.
- A central store of county overrides, with audit timestamps, so that a rule discovered in one county's records is available to every subsequent build and can be traced to when and why it was added.
Then the first documents from a new county go through human review at a higher rate than usual — not because the system is untrusted, but because the review is how the county's conventions get discovered and captured. Once the profile stabilises, review returns to exception handling.
The measure of a multi-county system is not how well it does on the first county. It is how long the second one takes.
What this means if you are buying rather than building
If you are evaluating a vendor or a tool for multi-county work, the questions that separate systems built for variation from systems that discovered it the hard way are simple:
- How do you onboard a new county, and how long does it take?
- Where does county-specific knowledge live — in code, in configuration, or in someone's head?
- When you learn something about one county, does it help with the next?
- Can you show me the same instrument type from three different counties, and how each was normalised?
The answers will tell you whether you are buying a system or a project.