{"id":14067,"date":"2026-06-24T17:12:19","date_gmt":"2026-06-24T17:12:19","guid":{"rendered":"https:\/\/prizmlaw.com\/site\/?p=14067"},"modified":"2026-07-17T16:55:09","modified_gmt":"2026-07-17T16:55:09","slug":"trust-but-verify","status":"publish","type":"post","link":"https:\/\/prizmlaw.com\/site\/2026\/06\/24\/trust-but-verify\/","title":{"rendered":"An Open Toolkit for Pulling Actual Estate-Planning Documents Out of Court Files"},"content":{"rendered":"\t\t
\n\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t
\"Image<\/div><\/div>\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
Part of a series on building TrustDrafting, an AI estate-planning tool.\u00a0<\/em><\/strong><\/div>
I’m an estate planning attorney building an application called TrustDrafting. It takes in a client interview and produces the standard package a plan needs \u2014 revocable living trust, pour-over will, powers of attorney, health-care directive, and the rest. For that to work, the system has to know how trusts are actually written, and not just one firm’s way of writing them. Early on, my entire clause library was built from two real trusts. Two. Every drafting decision the system made was quietly assuming those two documents were “the way trusts are written,” when they were really just the way two lawyers wrote them.<\/div>
The fix is obvious to say and hard to do: read a lot more real trusts, drafted by a lot of different firms, across a lot of years. But polished trust documents are scarce and proprietary. Nobody publishes their forms.<\/div>

The reservoir hiding in plain sight<\/h3>
Court files. When a trust gets litigated, the instrument itself is filed as an exhibit \u2014 the complete, executed document, signatures and notary blocks and schedules and all. A colleague handed me roughly 117 California court filings, about a gigabyte of complaints, petitions, and accountings, with real trusts buried inside them.<\/div>
Buried is the right word. A 100-page filing might hold a trust on pages 12 through 58, a pour-over will on 60 through 67, two amendments somewhere after that, and pleadings everywhere else. Many were photocopies of photocopies, scanned as flat images with no readable text. Some were mislabeled. One was outright corrupt. Several hundred genuine estate-planning documents sat mixed into thousands of pages of litigation paperwork, and reading it all by hand was never going to happen.<\/div>
So I built a pipeline to do it, ran it across the whole pile, and ended with 283 clean, verified documents from 86 families’ court files \u2014 trusts, restatements, amendments, wills, codicils, powers of attorney, health-care directives \u2014 for a few dollars in processing cost. That corpus now feeds everything else in my product.<\/div>
This post is about the pipeline itself, because I’ve extracted it from my project into a standalone toolkit any attorney can run on their own pile of filings. The link is at the end.<\/div>

How the toolkit works<\/h3>
The design principle, which I wrote about in the last post, is a deterministic shell around a probabilistic core. AI does the reading and the judgment calls \u2014 deciphering a 1987 photocopy, deciding where a trust ends and the next exhibit begins, recognizing that a filing holds two unrelated families. Plain code enforces the rules \u2014 every document has its three files, every carved PDF opens and matches its page span, and no source document is ever lost. The model judges; the code verifies.<\/div>
Concretely, the work happens in stages:<\/div>
A survey pass<\/strong> sweeps the raw pile once. For each filing it reads the text, names the matter from the trust’s own title \u2014 not the docket-style filename, which usually names the plaintiff \u2014 and files it into a per-family folder with an index row and a cheap “does this look like a trust?” score.<\/div>
Per-folder deep processing<\/strong> is where the real work happens, and it’s done by AI agents rather than a script, because it requires judgment. Each agent reads one family’s folder against a written spec: audit the filing, find *every* estate-planning instrument and its exact page span, carve each one into its own PDF with a full-text transcription and a one-page overview, and write a manifest documenting what was found and what was deliberately left behind. The spec is the heart of the system \u2014 a plain-language operating manual with numbered acceptance criteria, hardened every time a run surfaced a new way to fail.<\/div>
A mechanical verifier<\/strong> then checks every folder against those acceptance criteria \u2014 no AI involved, just code confirming completeness, integrity, and above all that no source filing was deleted. Only folders that pass get kept.<\/div>
A catalog generator<\/strong> builds a single browsable page over the whole corpus, so “show me every trust with a QTIP marital structure” becomes a glance instead of an archaeology project.<\/div>
The OCR layer underneath deserves a word, because it’s where the economics live. Before committing to anything, I ran a bake-off on my hardest scans: plain text extraction, two free local OCR engines, and two AI vision models. The AI models were the only ones that kept every clause, got the legal terms right, and rebuilt mangled structure \u2014 and the small model matched the expensive one at a tenth of the cost, about half a cent per page. Just as important, the pipeline routes page by page: if a page already carries a clean digital text layer, that layer is used directly, free. Only genuinely scanned pages go to the vision model, and a free offline engine stands by as a fallback \u2014 which is why, when my API credits ran out mid-run, the pipeline degraded gracefully instead of dying. The whole corpus cost single-digit dollars to process.<\/div>

What the pile taught me<\/h3>
The first pass lies, gently, in predictable ways.<\/strong> Every filing the survey flagged as “no trust here” actually contained one \u2014 they were image-only scans the text-based triage couldn’t see. One person appeared as two separate cases under two surnames. One folder held two unrelated families who happened to share a name. None of this is the model being stupid; it’s the model being confidently wrong exactly where a careful human would slow down. It’s why the verification layer isn’t optional.<\/div>
Identify documents by content, never by filename.<\/strong> Some full court filings had been copied under trust-like names. An AI agent, trying to be tidy, deleted one \u2014 a 101-page source filing named like a trust. A tripwire in the verifier flagged the deletion before it became permanent, and the fix became a permanent line in the spec: never delete a source, even one named like a trust. No agent has repeated the mistake since.<\/div>
Real legal documents trip AI safety filters.<\/strong> Notary stamps, court seals, elder-abuse allegations, tax schedules full of Social Security numbers \u2014 all of these occasionally caused the vision model to refuse a page. The pipeline treats a refusal like any other failure: fall back to whatever text exists, note the page, keep going. Several documents only completed because of that.<\/div>
And the one I learned late: formatting is legal content.<\/strong> My first pass extracted everything to plain text, and it took actually working with the documents to see what that destroys. In a trust, typography carries meaning. Bold and italics mark defined terms. An underlined phrase may be doing legal work. Quotation marks scope exactly what a provision incorporates. A plain-text file silently flattens all of it, and once flattened, you can’t tell what was emphasized from what wasn’t. The toolkit now transcribes to Markdown, with the vision model reproducing the typography actually on the page \u2014 bold as bold, italics as italics, quotes exactly as printed. There’s a subtle catch: a clean digital text layer, the fast free path, carries no formatting at all. So for an instrument whose typography matters, the toolkit reads every page visually, at half a cent a page. Cheap insurance against destroying meaning you didn’t know was there.<\/div>

If you want to run it on your own pile<\/h3>
A few honest notes. Court filings are public records, which is what makes AI-vision OCR appropriate here \u2014 the pages do get sent to an API. Don’t point this at client-confidential material without confirming your confidentiality and data-handling obligations first. The corpus keeps documents as filed; if you republish extracted language in a product or a form bank, redaction is your job at that point. And the per-folder processing assumes you’re working with an AI coding agent that can follow a written spec \u2014 the spec and the verifier are what make that safe, but “validate on two folders before you batch fifty” is a rule I’d keep.<\/div>
The toolkit is here: [github.com\/bryantjk\/court-corpus-toolkit<\/a>]. The README covers setup and usage, the processing spec ships as the operating manual it became, and the lessons above \u2014 plus the ones I didn’t have room for \u2014 are written up in the repo’s `docs\/LESSONS.md`.<\/div>
\u00a0<\/div>
Two documents was a thin foundation for teaching a machine how lawyers draft. Two hundred and eighty-three is a start worth building on \u2014 and the courthouse has more.<\/div><\/div>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

Part of a series on building TrustDrafting, an AI estate-planning tool.\u00a0I’m an estate planning attorney building an application called TrustDrafting. It takes in a client interview and produces the standard package a plan needs \u2014 revocable living trust, pour-over will,…<\/p>\n","protected":false},"author":1,"featured_media":14162,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_siteseo_robots_primary_cat":"4","pagelayer_contact_templates":[],"_pagelayer_content":"","footnotes":""},"categories":[4,27],"tags":[],"class_list":["post-14067","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-articles","category-legal-tech"],"_links":{"self":[{"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/posts\/14067","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/comments?post=14067"}],"version-history":[{"count":17,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/posts\/14067\/revisions"}],"predecessor-version":[{"id":14168,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/posts\/14067\/revisions\/14168"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/media\/14162"}],"wp:attachment":[{"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/media?parent=14067"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/categories?post=14067"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prizmlaw.com\/site\/wp-json\/wp\/v2\/tags?post=14067"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}