When

before

The exports and memos the console replaced carry the identifiers the whole design exists to keep out of view. They are not shown, and they were never in the repository.

during

The review console behind the login shows real records to one reviewer. It is not captured, for the same reason the raw files are not.

after

Walkthrough video: coming soon.

Problem

A municipal court's collections submission arrived as PII-bearing exports and memos. Someone outside the city's IT had to review each record and record a disposition, and the existing process was hand work over sensitive files.

Constraint

The reviewer is a clerk with a browser, not an engineer. Real client data can never sit in git, and the application tier can never hold the identifiers that make a court export sensitive.

Decision

Redact at the boundary and build the console for the reviewer: a pass that blanks SSN, date of birth, license number, address, ZIP, phone, and email while keeping names; an auth-gated review console behind a court-branded magic-link login; a plain-language guided wizard with a finish flow; document serving with an in-app reader and PDF download; an onboarding email that carries the end-to-end instructions; and an admin runbook.

• Load the raw exports into the app database

  Then the database is the PII. The database and the browser only ever see minimal, low-sensitivity display fields, and the raw exports stay git-ignored in private storage.

• Narrative documentation for the reviewer

  Reads well, fails in practice. The wizard verifies each step where it happens, and the instructions email walks the whole flow end to end.

What shipped

An accuracy pass on the submission batch, the review console, the guided wizard and court login, document serving and an in-app reader, the reviewer onboarding email, and the admin runbook, in use by the city.

What I'd do differently

The reviewer's access grant was committed to the repository's permissions file. #1918 moved it to an environment override so no client detail sits in git, which is the rule the redaction pass already enforced for records and should have covered the access list from day one.

Verify it yourself

• The court login, the only public face of the console
• Run the document redaction on a local export (never on committed files)npm run court:redact
• The platform the console was cut down from, as a public demo on invented data

If you ask me about this

How do you write for a clerk, not an engineer?

A large-type wizard that verifies each step where it happens, and an email that walks the whole flow before they open it. If a step has no way to confirm it worked, that step is not finished.

Where does the sensitive data live?

Outside the app. Raw exports and memos are git-ignored and stay in private storage; redaction runs before anything reaches the database, and the browser gets display fields only.

Evidence

1. Accuracy pass: municipal court collections submission (Batch COURT-20260527)

   #570 · 2026-05-28 · feature · +625 −0, 4 files

2. Auth-gated municipal court collections review console

   #571 · 2026-05-28 · feature · +1,635 −10,927, 35 files

3. Court console: guided wizard, court login, doc serving, finish flow

   #573 · 2026-05-28 · docs · +1,251 −48, 22 files

4. Redaction --src default + court admin runbook

   #574 · 2026-05-28 · feature · +69 −3, 2 files

5. Add reviewer onboarding email for Court console collections

   #579 · 2026-05-28 · feature · +265 −1, 4 files

6. Court docs: PDF download, download-all, and an in-app reader

   #581 · 2026-05-29 · docs · +661 −23, 6 files

7. Remove Court console client PII from committed permissions.json (#1806)

   #1918 · 2026-07-08 · feature · +55 −25, 11 files