reference architecture · immigration
This page is a reference architecture: a precise specification of how I design and build a form assembly pipeline for a high-volume immigration practice. It is an engineering document, not a case study. What follows is exactly what you would be hiring: the system, its data flow, its failure handling, and where your attorneys stay in control.
// skimmable for an attorney · specific enough for your office manager to pressure-test
The problem
A family-based case is a stack of forms that all describe the same people. Names and aliases, dates and places of birth, address history, entry dates, A-numbers: the same biographic facts appear on the I-130, the I-485, and the rest of the packet, and again on the N-400 years later. In most firms, each form gets those facts by someone typing them in again.
The data usually arrives messy: questionnaires, emailed PDFs, photos of documents. Staff key it into Docketwise or INSZoom, then work through per-form questionnaires, per family member. A practice filing at volume is re-keying the same facts thousands of times a year.
Every pass is a chance for the error that matters: a name transliterated two ways in the same packet, a transposed date of birth, an entry date that conflicts between two forms filed together. Inconsistencies across filings are exactly the kind of thing that draws an RFE, and at volume, RFEs are the tax a firm pays on re-keying.
Then there is the churn. USCIS revises forms on its own schedule: new edition dates, fields added, renumbered, or split. File on a stale edition and the packet can come back rejected. Every revision lands on staff as the same manual question: which of our in-flight cases does this touch?
Current state
// the same biographic data typed once per form, per family member; form editions checked by hand
Target architecture
The pipeline is built around a person-centric data store. Each family member is one record, entered once and validated once. Petitioner, beneficiary, and derivative are relationships between records, not fresh copies of the same facts. Every form in every packet reads from that single source.
// there is no LLM anywhere in this pipeline: every field mapping is explicit code that can be read, tested, and audited
Data flow
Capture
Client answers come in through a structured questionnaire. The raw submission is stored unmodified: the permanent record of what the client actually said, separate from anything derived from it.
Normalize
Each family member becomes one record in the client data store. Petitioner, beneficiary, and derivative are links between records. A person's name exists in exactly one place, spelled exactly one way.
Validate
Field-level rules pinned to the current edition of each target form: formats, required fields, address history with no gaps, and cross-form consistency across the whole packet. Failures route to the exception queue.
Populate
Validated data flows into Docketwise or INSZoom. Every field mapping is versioned against the specific form edition it targets, so "which edition was this built for" is a fact in the system, not a memory.
Review
An attorney reviews every populated form before signature. The pipeline prepares filings. It never signs, submits, or files anything.
Error handling & audit trail
Failures stop, they don't guess
A value that fails validation never reaches a form. It lands in the exception queue with its source shown, and a person resolves it. The pipeline does not substitute a default and keep going.
Every write is recorded
Source field, destination, value, timestamp, and whether it was client-entered or staff-corrected. If USCIS questions a value years later, where it came from is one lookup, not an excavation of old emails.
The packet agrees with itself
Cross-form checks run before anything is populated: the same name, the same date of birth, the same entry history on every form filed together. The inconsistencies that draw RFEs are caught as validation errors instead.
Edition churn is detected
The form-edition watcher flags new USCIS editions, lists every affected field mapping and every in-flight case that touches the form, and blocks population against a stale mapping until it is updated and re-validated.
What stays human-reviewed
Engagement shape
01
Workflow mapping
I sit with your paralegals and follow real cases from intake to filing: which fields get re-typed, on which forms, for which family members. Days of work, not months, and it produces the field map the build is priced from.
02
Fixed-scope proposal
Exactly which integrations get built, the full field mapping, and what "done" means. Scoped and priced per firm, because every stack and every caseload is different.
03
Build + parallel run
The pipeline starts with one case type, such as family-based adjustment. Before anything goes live, its output runs in parallel against your current hand-keyed process on real cases until the two match.
04
Cutover + support
Staff training, monitoring, and reconciliation reports. Keeping mappings current as USCIS revises forms and your vendors ship changes is part of the engagement, not a surprise invoice.
30 minutes. I'll map where your client data gets re-keyed and tell you honestly whether this architecture fits your caseload.