Dossier Engine

The Insight

Every regulated industry has the same problem: structured forms that need to be filled with data that already exists somewhere. A bankruptcy attorney types the debtor's name into Form 101, then types the same name into Schedule A/B, Schedule D, Schedule E/F, the Statement of Financial Affairs, and every other form in the package. The data exists — it was entered once. The routing is what's missing.

Dossier solves this with three ideas that compose into a general-purpose document assembly engine. The engine itself knows nothing about law, bankruptcy, insurance, tax, or any specific domain. All domain knowledge is externalized into three JSON artifacts: schemas, forms (with bindings), and data sources.

The result: populate a few schema keys from any source, and the binding engine cascades the values to every form that needs them — across 70+ forms in a bankruptcy package, or across any set of forms in any domain.

How It Works

The Schema sits at the center. DataSources write to it (inbound), Bindings read from it (outbound). Every interaction — manual or automated — produces the same artifact: an Entry (a batch of schema key = value pairs with source tracking).

Fill Once, Populate Everywhere

The debtor's first name is entered once. The binding engine routes it to every form that needs it. This works for every data point — creditor names cascade to every schedule, addresses appear on every form that asks, social security numbers are masked where required. One schema key, many targets.

debtor1.first_name
    → Form 101, field "Debtor1.First name"
    → Schedule A/B, field "Debtor 1 First name"
    → Schedule D, field "Debtor 1 Name"
    → Schedule E/F, field "Debtor 1 Name"
    → Statement of Financial Affairs, field "Debtor 1"
    → Declaration, field "Name of Debtor"
    → ...every form in the package that needs it

Any Source, Same Result

All data sources produce the same thing: an Entry with schema key = value pairs. The binding engine doesn't distinguish between a lawyer typing a name and a credit report XML providing 80 creditor records.

Example Flows

Every path through the system follows the same pattern: something produces entries on a case, bindings route them to PDF fields.

What's Been Built

The first domain is bankruptcy. The extraction pipeline has processed every federal form, generated bindings, and composed packages — proving the engine works end-to-end.

The Extraction Pipeline

Building a new domain follows a repeatable 5-step pipeline:

Engine Implementation

Why It Generalizes

The engine has no concept of "law" or "bankruptcy." It knows five abstract things:

Swap the schema, forms, and bindings — you have a different domain. The engine, server, database, and API routes are unchanged.

What Changes Per Domain

For any industry where structured forms need to be filled with data from a shared vocabulary, the engine works as-is. The only question is whether the domain needs concepts beyond the core model — and if so, it's 1-2 new tables, not a rewrite.

Cross-Domain Concept Mapping

The core concepts translate directly across industries:

Next Verticals

Ranked by volume and Dossier fit:

The 8 Names

Architecture

Four layers, one spine. The Schema sits at the center. DataSources write to it (inbound), Bindings read from it (outbound). Every interaction — manual or automated — produces Entries on a File.

Entities

The domain splits into two sides: Producers create entry values, Consumers use them. The schema key = value pair is the central currency.

Schema

The schema defines what data points exist for a domain. Every key has a type, label, hint, and group. Forms bind to schema keys. DataSources map to schema keys. One schema per domain variant.

Schema Entry schema entry

One data point definition in a schema. The schema entry is the human-facing side — simpler than the raw form fields.

Form

One entity replaces the old Form + Blueprint split. A form can be a leaf (has a PDF with fields), a composite (has children), or both. Recursive — composites can contain composites.

Form entity

A PDF with extracted fields, children, and bindings. All optional — a leaf has fields + filePath, a composite has children, a top-level form has a schemaId.

FormField on Form

A single field extracted from a PDF's AcroForm dictionary.

ChildEntry on Form

A reference to a child form within a composite form.

Binding

Connects a source expression to one or more target field addresses. The core data-wiring mechanism. Array syntax with [] supports repeating groups.

Cross-form sync

A composite form's binding can route one schema key to multiple child forms. The debtor's name entered once appears on every form that needs it.

{
  "source": "debtor1.first_name",
  "targets": [
    "$b101.Debtor1.First name",
    "$b106ab.Debtor 1 First name",
    "$b106d.Debtor 1 Name",
    "$b106ef.Debtor 1 Name",
    "$b107.Debtor 1 Name"
  ]
}

Validation on Form

DataSource

A reusable recipe that turns external data into schema key values. Combines parse rules (how to read the source format) with field mapping (how to transform into schema keys). Scoped to a schema, not to individual forms.

DataSource entity

Inbound vs Outbound

The schema is the clean boundary. DataSources don't know about PDF fields. Bindings don't know about APIs. Both use the same key vocabulary — build the key picker once, use it everywhere.

Input Types

Data Flow

DataSource Structure

{
  "id": "credit-report-bankruptcy",
  "name": "Credit Report (Bankruptcy)",
  "type": "api",
  "schemaId": "bankruptcy.individual",

  "singleton": {                            // one-to-one mappings
    "debtor1.full_name": "CONCAT(borrowers[0].firstName, ' ', borrowers[0].lastName)",
    "debtor1.ssn": "borrowers[0].ssn"
  },

  "collections": {                          // one-to-many mappings
    "creditors": {
      "source": "liabilities",
      "filter": "AND(IN(status, 'Open'), balance > 0)",
      "classify": {
        "secured": { "rule": "IN(loanType, 'Secured', 'Mortgage')", "targetPrefix": "creditor.secured[]" },
        "unsecured": { "rule": "DEFAULT", "targetPrefix": "creditor.unsecured[]" }
      },
      "fields": {
        "name": "creditorName",
        "account_number": "RIGHT(accountNumber, 4)",
        "claim_amount": "balance"
      }
    }
  }
}

File & Entry

Everything that produces data on a file — typing, credit reports, API syncs — produces the same thing: an Entry. One event = one entry containing a batch of data point changes. A file is a timeline of entries.

File entity

Entry batch of values

File timeline

Nickie Green's Chapter 7 case. Three entries: lawyer types basics, credit report is pulled, lawyer corrects a name.

Three entries, not 86. The credit report is one entry with 80 values (pending confirmation). The lawyer's correction is a separate entry that overrides one value from the credit report. Current state = merge all entries by priority and timestamp, latest wins per key. PDF generation = snapshot of the current state.

Composition Graph

A composite form contains children — other forms (leaf or composite). Each child has a key (alias used in expressions) and a position (print order). Children can have a condition that controls inclusion.

Expression Syntax

All source, condition, and computed expression fields are parsed by the expression engine in packages/core/src/expressions/.

References

Disambiguation Rule

Operators

+  -  *  /          // arithmetic (+ also concatenates strings)
== != >  <  >= <=  // comparison

Functions

22 built-in functions following Excel/Google Sheets naming conventions. Used in bindings, DataSource mappings, validations, and computed fields.

AST

Expressions are parsed into an AST with 5 node types:

literal   → { value: "hello" | 42 | true }
reference → { key: "debtor.first_name" }         // schema key
formRef   → { child: "b106ab", field: "line55" } // $child.field
binary    → { op: "+", left: ..., right: ... }
call      → { name: "CONCAT", args: [...] }

Scoping Rules

Not every reference type is available in every context. This matrix defines what's legal where.

ID Convention

IDs are deterministic UUIDs that encode the entity type, domain, and a hex-leet name. Readable at a glance.

Type Prefixes

Group 5: Hex Name (12 chars, read right to left)

NNNNNNNNCCCT
│       │  └―― T: filer type (last char)
│       └――――― CCC: chapter hint (0C7=Ch7, CD3=Ch13, 000=shared)
└―――――――――――― NNNNNNNN: hex-leet name (zero-padded)

Examples

F0000001-BA01-4000-8000-C40700000001   ← Ch7 Individual (top-level)
F0000005-BA01-4000-8000-C40700000002   ← Ch7 Non-Individual (top-level)
F0000101-BA01-4000-8000-BE7171090001  ← Petition (composite, Individual)
F0000206-BA01-4000-8000-5C4ED0000002  ← Schedules (composite, Non-Individual)
F0001010-BA01-4000-8000-000000000000  ← Form 101 (leaf, no filer suffix)

Database Tables

PostgreSQL 17 with Drizzle ORM. Core tables store forms, files, and entries.

Example Flows

Every path through the system — manual or automated — follows the same pattern: something produces entries on a file, bindings route them to PDF fields.