Extracting Fields From a Title Insurance Commitment

A title commitment contains two consecutively numbered lists, set in the same typeface, on facing pages, under headings that differ by a few words. One is a list of things somebody must do. The other is a list of things the policy will not cover. Merge them and you have produced a document that is not merely inaccurate but actively dangerous.

The shape of a commitment

The commitment forms in general use in the United States are published by the American Land Title Association, and the structure is consistent: a notice, a set of commitment conditions, Schedule A, and Schedule B in two parts — Part I, Requirements, and Part II, Exceptions. Regional and state-specific variants exist and some insurers add their own schedules, but the four-part backbone is what you build the schema around.

Treat the form’s revision as an extracted field. ALTA forms carry a revision date, usually in a footer alongside the form name, and the arrangement of content has changed across revisions. A pipeline that hard-codes “requirements start on page 3” against one revision will silently mis-slice another.

Schedule A is the transaction

Schedule A is a short block of typed fields and it is the part with an obvious schema:

• Commitment date, frequently given to a time of day. The time matters — it is the effective moment of the title search, and anything recorded afterwards is outside it. Store it as a timestamp with the stated time zone if one is given, not as a date.
• Policies to be issued, each with a type (owner’s or loan), a proposed insured, and a policy amount. This is a repeated group, not a single set of fields: one commitment routinely covers an owner’s policy and a lender’s policy with different amounts and different named insureds.
• The estate or interest — fee simple, leasehold, easement — as a controlled vocabulary.
• Title vested in, the current record owner, exactly as vested. The vesting language (“as tenants in common”, “a married person as sole and separate property”, “trustee of the … Trust dated …”) is part of the value and must not be trimmed to a name.
• The legal description, usually by reference to an attached exhibit.

The one systematic error here is flattening the policies group. A schema with a single policy_amount forces the model to choose between the purchase price and the loan amount, and it will pick whichever appears first, so half your records will report the transaction value as the mortgage.

Requirements and exceptions are opposites

Schedule B Part I lists requirements: things that must be done before the policy issues. Pay the seller’s loan and obtain a reconveyance. Obtain and record a deed from the record owner. Provide the insurer with an affidavit. Requirements are actionable and they are clearable; a closing runs, in part, by working through this list.

Schedule B Part II lists exceptions: matters the policy does not insure against. Taxes not yet due. A recorded easement. A restrictive covenant. The rights of parties in possession. Exceptions are not tasks. They are permanent unless separately removed, and their presence is information the buyer and lender are entitled to weigh.

Now the failure. Both are numbered from 1. Both are set as a plain numbered list. They are separated by a heading and often a page break, and on many forms the headings are “Requirements” and “Exceptions” in the same weight as the surrounding text. A text-order read of the PDF produces a single run of numbered paragraphs in which the reset from item 9 back to item 1 is the only structural signal — and if the last requirement is item 5 and the first exception is item 1, the reset is easy to read as a formatting artefact.

The consequences run both ways and both are bad. A requirement classified as an exception is a task nobody does, and the policy does not issue, or issues without a lien being cleared. An exception classified as a requirement is a permanent title matter presented as a closing to-do, which someone will mark complete. So schedule_b_part is a required field on every item, its value is derived from the heading above the item rather than from the item’s own text, and an item that cannot be attributed to a part is an error rather than a default.

Practical detection: work from the layout rather than the text stream — find the heading positions on the page and assign each numbered item by its vertical position relative to them. This is the same class of problem as reading a two-column paper, and it is solved the same way, with coordinates. The general technique is in PDF parsing.

Two smaller structural facts. Exceptions are commonly split into “standard” or general exceptions, which appear on every commitment from that insurer, and specific exceptions found by the search. Only the second set is about this property, so tagging them is worth doing. And items are sometimes deleted with the numbering preserved — “5. Intentionally deleted.” — which must be retained as a numbered item rather than dropped, or every subsequent reference by number goes wrong.

The legal description

The legal description is the one field where an approximate extraction is worthless. It arrives in two broad forms. A lot-and-block description references a recorded plat (“Lot 14, Block 2, of SAMPLE ADDITION, according to the plat recorded in Book 12, Page 34”) and is short and structured enough to parse into components. A metes-and-bounds description is a sequence of bearings and distances — “thence North 12 degrees 14 minutes 30 seconds East, 148.62 feet to a point” — that traverses the boundary and must close.

For metes and bounds, the correct default is to capture the text verbatim, with line breaks preserved, and not to normalise anything. Bearings use degree, minute and second symbols that OCR mangles routinely, and a single misread digit changes the parcel. If you do parse the calls, you get a genuine arithmetic check: the traverse should return to its point of beginning, and a closure error beyond a small tolerance means either the description is defective or you misread a call. That is worth running as a validator, and it is worth reporting the closure error rather than a pass or fail, because surveyors expect a small one.

Where it breaks

The exhibit is a separate page or a separate file. The legal description is usually “attached hereto as Exhibit A” and lives at the back or in another PDF. A commitment whose Schedule A extraction succeeded but whose legal description field contains the words “see Exhibit A” has failed, and it will not look like a failure. Assert that the reference resolved.

Recording references are a compound key. Exceptions cite instruments by book and page, by instrument or document number, or by both, plus a county. Parse them into components; a single string cannot be matched against a recorder’s index. Formats vary by county, so keep the raw citation.

Supplements and updates. Commitments are updated as the closing approaches, and a supplement adds, deletes or modifies items by number against a stated prior commitment. The same replay problem as with escrow instruction amendments applies, and the commitment date advances with each update.

Continuation across pages loses the item number. A long exception wraps to the next page and its continuation begins with a lower-case word and no number. Items must be reassembled by indentation and numbering, not by page, or you will produce orphan fragments as separate exceptions.