Capture Once, File Everywhere

The problem

A single family law case can require eleven or more court forms: petitions, financial affidavits, insurance affidavits, child support applications, service waivers. Here is the part that matters: those forms are not eleven different sets of questions. They are largely the same forty or fifty facts, asked over and over, in different layouts, with different formatting rules, on different pieces of paper.

The client's name appears on most of them. The income figure shows up in several places, formatted several different ways. Someone spends the afternoon copying the same information between documents, checking and rechecking, because a single missing or misformatted field can get an entire filing rejected. Every rejection means delay and another round of rework.

Now swap the nouns. A mortgage file. An insurance new-business packet. A patient intake and referral bundle. An employee onboarding stack. A permit application to three agencies. The specifics change. The shape does not. It is always the same underlying facts, re-entered by hand across many outputs, with formatting rules that differ per document and a real cost when something is wrong.

That shape is the opportunity.

The core idea: separate the facts from the forms

The instinct most people have is to automate form by form. Build a tool that fills the petition, then another for the affidavit. That never scales, because every new form is a new project and the shared facts get duplicated into every tool.

I did the opposite. I built one canonical model of the facts, a single structured record of everything true about a case, and treated every form as nothing more than instructions for projecting those facts onto paper. Three layers, kept strictly separate:

• The facts. One record. Captured once, stored once, true once.
• The mapping. For each form, a simple configuration file that says which fact lands in which blank. The mapping is data, not code.
• The formatting. A library of rules for how a fact must appear on a given form. The same number might need dashes on one document and only its last four digits on another. The fact does not change, only its presentation.

That separation is the whole game. It is the difference between a system that gets harder to maintain with every form you add and one that gets easier.

Why it works: the decisions underneath

The value is deduplication, not speed. The headline benefit looks like fast form-filling. The real benefit is never entering a fact twice. The system looks across every required form at once, gathers all the fields, removes the duplicates, and compares the combined list against what was already captured. Then it asks one focused question: here are the fifteen things still missing. Not "fill out eleven forms." Just the genuine gaps, on one screen. If five forms need the same date, the human is asked once.

Adding a document is configuration, not engineering. Because each form is a mapping file rather than custom code, extending the system does not require a developer to write new logic. It requires someone to describe where the facts go on a new page. Form number eighty-six is a config file, not a new build. That is what lets a system like this cover an entire practice area or department rather than a handful of showcase documents.

AI generates the mapping, a human approves it, deterministic code does the filling. This is the decision most people get backwards. I use AI for the tedious first draft of describing a new form, reading its fields and proposing where each one maps. That draft is cheap to produce and easy to check. But when a real case gets filled, there is no AI in the loop at all. The filling is done by plain, predictable code following the approved mapping. There is no hallucination risk on a live document. The output is repeatable and explainable, and you can point at any field and say exactly why it holds the value it holds. In regulated or high-stakes work, people do not want "the AI decided." They want a rule they can inspect. I put the AI in one-time setup under human review and kept it out of the hot path where correctness is everything.

The human stays in the loop on purpose. The system does not file anything. It prepares drafts and hands them to a person for review, with the fields that deserve attention flagged and the obvious ones left quiet. Every manual change is recorded. The final package carries a record of what was populated automatically, what a human changed, and who approved it. For a law firm that audit trail is liability protection. For an insurer, hospital, or lender it is the compliance story. The reviewable trail is often the thing that makes automation acceptable at all.

It learns, so quality goes up while cost goes down. Every time the system got something wrong in early work, I did not just fix that case. I captured the mistake as a permanent rule so that entire class of error could never happen again, then added automated checkers that scan every new mapping for known bad patterns before they can become a visible bug. The result is an asset that improves with use. The tenth form was easier to add than the third. The knowledge that normally lives in one senior person's head gets captured in the system itself.

The architecture outlived its own file format. Here is the proof the layering was right. Partway through, one set of PDF forms became painful to work with. So I pointed the same canonical model at a completely different document technology and rendered the same facts into Word-based templates instead. Nothing about the facts changed. The expensive asset, the model and the mappings, survived a total swap of the output format underneath it.

The economics

The before-state is typical for this kind of work: two to three hours of manual preparation per case, and a high rejection rate driven by missing or misformatted fields. The system is designed to take that to roughly twenty minutes of human time per case, with most fields correct on the first pass and rejections pushed toward single digits, because the formatting rules courts enforce get applied automatically and consistently.

For an operation handling twenty cases a month, that is on the order of fifty hours of skilled time returned every month. The same math runs in any high-volume, forms-heavy operation.

The engine is real and in production. The time and rejection figures represent the documented before-state and the system's design target for the after-state.

Where this applies beyond law

The same pattern fits any operation where the same facts feed many documents, formatting rules differ per document or jurisdiction, errors are expensive, the work is done by skilled people whose time is worth more than data entry, and a reviewable trail matters.

That includes mortgage and lending files, insurance underwriting and claims, healthcare intake and referrals, HR onboarding and benefits, and government or permit applications. In every one, the play is the same: capture the facts once, ask only for what is genuinely missing, project onto every required document with the correct formatting, keep a human in the loop with a clean audit trail, and let the system learn from every correction.

The takeaway

This build looks like a legal-forms tool. It is really a demonstration of a pattern: the paperwork tax is not inevitable, and the way to remove it is not to automate documents one at a time. It is to separate the facts you know from the documents you produce, capture the facts once, and let a reviewable, learning system handle the projection.

The forms are just where the facts land. The system is about the facts.