Walkthrough · Track A

The client hit submit.
You get a working case.

John fills the firm's portal and uploads documents. Twelve minutes later the attorney opens a Ch 13 case that's already running — every value sourced, the plan calculator pencilling feasibility, a divergence already flagged between what John typed and what his paystub says. This walkthrough skips the wizard intermediate steps (the orientation track describes them) and focuses on the moments where the engine does the work.

STEP 01 00:00

The case is already built

Attorney signs in. New case on her dashboard — Ch 13, status Intake. The Overview is already drawn: verdict strip across the top, synopsis, KPIs, filing timeline, blockers, parties rail. Nothing to set up.

One schema, one source of truth Every value the portal collected wrote to the case's canonical schema. The Overview reads from the same schema. The calculators read from the same schema. No "sync the data over" step — there's nothing to sync.
Overview tab fully populated from portal data with the verdict strip across the top
STEP 02 00:30

A timeline of where everything came from

Forms → Entries: every write on the case, in order, with its source. Client portal. Paystub extraction. Attorney manual. Each entry is auditable down to the field it touched. The court file carries the value the attorney picked, not whatever happened to land last.

Entries inbox showing portal / paystub / attorney source chips and a chronological timeline
STEP 03 01:00

One field, many forms

Open any schema field and the inspector's "Affects N forms" panel maps every PDF that field flows into. Schema is the spine; bindings are the radials. Edit the value once; every form updates.

Field inspector cropped to the right rail: Affects 2 forms panel with cropped PDF tiles and edit history
Cropped to just the inspector rail — the chrome's identical to step 4 so the rail is where the story lives.
STEP 04 01:30

Two sources, one delta

The attorney's intake notes wrote $5,800. The paystub extraction read $6,108.65. Same field, two writes, delta +$308.65. The inspector surfaces the conflict with both rows, source, timestamp, and a one-click apply-to-schema. Neither value is overwritten silently.

!
The trust moment Most systems silently overwrite the debtor's answer with the extraction — or ignore the extraction. Dossier keeps both, sourced. The attorney picks; the court file carries her answer.
Field inspector cropped to ConflictsCallout with two source rows and a numeric delta pill
STEP 05 02:00

Toggle → reveal

On the Form lens, flip a gate — marital status, joint debtor, asset type. Dependent rows light up gold and slide in; obsolete rows fade out. The cascade is the dependency made visible. No hand-rolled if-then ladders; every conditional row is just an expression on the schema.

visibleIf in action The animation lasts 1.5 seconds — long enough to see the dependency. Underneath, the engine re-resolves the form's bindings on every keystroke; the gold band is just the diff against the prior visible set.
Form lens mid-cascade with newly-visible rows highlighted in gold
STEP 06 02:30

The verdict strip

Three calculator pills across the top of the Overview — means test, exemptions, plan feasibility. Each carries a verdict and a one-line detail. Click any pill to land on the calculator with its worksheet expanded.

Overview verdict strip cropped tight: means / exemptions / plan pills
Cropped to the verdict band so the pills fill the frame — the Overview chrome was already on the page above.
STEP 07 02:55

Plan worksheet, line by line

The plan calculator's TraceDisclosure: disposable-income math, commitment-period bump (above-median → 60 months), priority-claim sum, projected unsecured dividend. Each line is the expression with substituted values and a statutory citation. Edit a disposable-income input and every line below it updates — same as a spreadsheet, only sourced and auditable.

Σ
Value change → recalculation Type a new disposable-income figure; the plan payment, the projected dividend, and the verdict pill on the Overview all update live. The whole case is one reactive graph — bindings make every form a derived view on the schema.
Plan calculator TraceDisclosure cropped to the calculation section with substituted values and citations per line
STEP 08 03:20

Real PDF, real fields

Forms → PDF lens. The real fillable PDF for B 101 with the focused-field overlay. Click a row in the rail; the highlight jumps to the box on the page. Click a field on the page; the rail jumps to the matching schema key. Same data, third projection.

PDF lens on the petition with the focused-field overlay and a row highlighted in the rail
STEP 09 03:45

Petition assembled

Court → Filings. The Ch 13 group expands — petition, schedules A/B through J, SOFA, means-test forms, the plan — each leaf populated from the schema, the pre-flight rail flagging blockers. Download merged PDF, sign, file via CM/ECF.

Court → Filings with the Ch13 group expanded and the pre-flight rail on the right
STEP 10 04:10

Every change on the record

History is the auto-generated audit trail. Every data change, import, status transition, and filing event lands here, with the invoker who triggered it. Read-only. When opposing counsel asks "when did this number change, and from what?" you point at History.

History tab with a chronological audit trail of entries, status changes, and filings

Two more ways in.

Same case, other directions — the attorney has the documents, or a guided tour of the chrome itself.