A regional legal-services firm files documents into a state court system every working day. The filings are routine in the way that airline safety checks are routine: the same shape every time, and expensive in a very specific way when one goes wrong. A submission is irreversible. It is timestamped, it is billable, and it is attached to a real case belonging to a real person who is having a bad enough month already.
The work of preparing one is almost entirely mechanical. Read the case details, pick the filing type from the suit amount, choose the right document category, attach the right files with the right names, select the venue, enter the parties. Twenty minutes of careful clicking where nineteen of those minutes are transcription and one is judgement.
That ratio is exactly the shape that invites automation, and exactly the shape that punishes it.
I read the rules before I wrote anything
Before a line of code existed I read the court’s governing chapter, the electronic filing user agreement, and the site terms of use, looking for one specific thing: whether automated interaction was prohibited. It was not. That answer could easily have gone the other way, and if it had, the correct outcome was no project.
I mention this not because it is clever but because it is the step most automation projects skip. The usual order is build it, demo it, and discover the constraint when someone senior asks an awkward question. Reading first cost an afternoon and removed the possibility of building something that had to be thrown away.
One requirement from that reading is still open, and I would rather write it down than let it quietly disappear: the documentation trail for credential authorisation is not finished. It is tracked as a gap, not as a detail.
The decision: automate the assembly, not the submission
The tool drives a real browser through the entire filing wizard. It logs in, selects the case type, derives the filing category from the amount in controversy, enters the parties, attaches the documents, and fills every field on every screen.
Then it stops. It saves a draft and it hands control to a person.
It never presses submit. It never pays. That is not a limitation I intend to remove later when the tool is more mature — it is the invariant the whole design is built around, and the code enforces it rather than merely avoiding it.
The reasoning is about where error becomes irreversible. Everything before the final confirmation is editable: a wrong venue, a mistyped party, the wrong document type. A person reviewing a completed draft catches those in seconds, because reviewing a filled form is a fundamentally easier cognitive task than filling one. After the confirmation, the same mistake is a filed document, a fee, and a phone call.
So the machine does the nineteen minutes of transcription and the human does the one minute of judgement. Automating that last minute would have captured a rounding error of the effort and taken on all of the risk.
What that choice costs
It is worth being honest that this is not free. A person still has to sit down, open each draft, and approve it. On a heavy day that is a real queue, and there is a version of this tool that runs entirely unattended and finishes the job while everyone is at lunch.
I did build an unattended mode. It exists behind an explicit flag, it is not the default, and turning it on is a deliberate act by someone who understands what they are accepting. The default posture of a tool is the posture it will have in practice, because defaults are what people actually use.
The part nobody writes about: it has to survive an office
The automation was the easy half. The tool runs on the machines of people who did not ask for a browser automation framework in their lives, and most of the engineering went into that reality rather than into the filing logic.
- The browser has to be there. A packaged desktop application cannot assume a driver runtime exists on a receptionist’s laptop. There is a small state machine that detects whether the browser engine is installed, installs it if not, polls until it is genuinely usable, and escalates clearly if it cannot get there — instead of throwing a stack trace at somebody who has a filing deadline.
- Credentials are somebody’s professional identity. They are stored encrypted, gated behind a passphrase, and every run records which operating-system user on which machine performed it. Not because anyone is expected to misbehave, but because a filing made under a professional’s credentials should have an answer to the question of who caused it.
- Client data arrives as spreadsheets, and spreadsheets lie. Column headers are mapped once per client and saved. The mapping scaffold only ever appends columns, never rewrites them, because the fastest way to lose a firm’s trust is to modify a file they gave you.
- The interface has to be legible. Four themes, all checked against contrast standards, because the people using this work in the same window for hours and a tool that is unpleasant to look at is a tool that gets worked around.
The refactor I would not have predicted
It began as a tidy eight-module pipeline, structured the way you are supposed to structure things. It is now one file.
The reason is not aesthetic. Across several rounds of debugging a stubborn failure, the module being edited was repeatedly not the module being executed — a stale copy sitting somewhere else on the path was winning. Every fix appeared to do nothing, which sends you looking for increasingly exotic explanations for a problem that is simply not there.
For a script that lives on someone else’s machine and is updated by sending them a new copy, a single file removes an entire category of failure. The tidy structure was correct for a codebase and wrong for a deliverable. Those are different things, and I had been optimising for the wrong one.
The part that generalises
Most automation is pitched on how much of the process it removes. The more useful question is where in the process the errors stop being recoverable, and whether your automation is on the safe side of that line.
Draw the line there and a surprising amount becomes straightforward. You are no longer building a system that has to be right, which is impossible; you are building one that has to be reviewable, which is achievable. The human keeps the irreversible click, and gets to spend their attention on the only part that ever needed it.
This is one of the case studies collected on the writing index. The short version of the same question — where to stop automating an irreversible process — is on the answers page.