If you build anything that watches work happen in a law office — time capture, document filing, deadline extraction, a dashboard of what is in flight — you will eventually have to answer one question over and over:
Which matter is this?
It is a deceptively hard question, and the way most systems answer it is wrong in a way that is specific to our profession. The instinct, inherited from every other kind of software, is that a system which usually produces an answer is better than one which sometimes shrugs. Coverage is a feature. Blank fields look like failure.
In a law office, that instinct is backwards. Here is the principle I ended up building everything around, after getting it wrong first:
An unattributed entry is honest. A confidently wrong one puts a deadline on the wrong file or bills a client for someone else’s work.
(Every example in this article is invented. No client information, matter numbers, real captions, or real data appear anywhere in it.)
How I got it wrong the first time: reading is not working
The first version of a time-reconstruction tool I built did something that seems obviously right. It read through a work session and looked for any matter folder path mentioned anywhere in it. If a session touched the Anderson folder, that session was Anderson’s.
Here is what that produces.
Say you spend a Tuesday building an internal system — no client work at all. Somewhere in the middle of it you open a document in a client folder to check how a particular caption was formatted, because you want to copy the structure. You read one file. You close it.
Under the naive rule, that entire Tuesday is now attributed to that client.
That is not a subtle rounding error. In the case that taught me this, a multi-day infrastructure project was attributed almost entirely to a single litigation matter, and the matter’s reconstructed time was inflated by roughly twelve hours. Had that gone into a draft invoice unexamined, it would have been a bill to a client for work performed for somebody else.
The fix is a one-line rule with a lot of judgment behind it:
Only writes count.
Reading a file in a matter folder is not evidence you were working on that matter. Editing, creating, or saving a file in that folder is. Reference is not labor. Once I ranked evidence that way — and dropped every session whose only connection to a matter was a read — attribution stopped inflating.
How I got it wrong the second time: surnames
The second version of this mistake happened in calendar matching, and it is more instructive, because the fix looked so reasonable.
The goal: tie calendar events to matters so the board can show which upcoming hearings have work behind them. Events are titled by human beings, so the obvious approach is to match on the client’s last name.
First attempt. Match on surname. A hearing captioned with a common Minnesota surname matched a client with that surname — one arbitrary client among many with the same name. Wrong matter, high confidence, no signal that anything had gone amiss.
Second attempt, the “improvement.” Only match surnames that belong to exactly one matter on the books. That removes the ambiguity problem, and it feels airtight.
It then matched a hearing to an entirely unrelated matter because the event title contained the name of the judge.
Sit with that for a second. Event titles in a litigation practice are dense with proper names, and almost none of them are your client’s. They contain judges. Opposing parties. Opposing counsel. Court reporters. Mediators. Venues named after people. Building names. A surname matcher, no matter how carefully restricted, is a machine for confusing the person you represent with everyone else in the room.
So surname matching came out entirely. What replaced it is narrow and boring: match on the file number, and only when that number corresponds to a matter that actually exists. Firm calendars here already carry the file number in the title — most well-run practices do — and requiring a real, existing number keeps docket numbers, dates, dollar figures, and times from matching by coincidence.
The result is that a meaningful fraction of calendar events show no matter at all. That is not a gap in the system. That is the system declining to guess, which is exactly what I want it to do with a hearing date.
Why the stakes are different in this profession
Software people have a well-developed intuition for precision and recall, and a well-developed comfort with trading one for the other. What that framing misses is that in a law office, the two kinds of error have wildly asymmetric costs.
A missed attribution costs you a few minutes. Someone looks at an unlabeled entry and labels it. Mildly annoying, entirely recoverable, and — crucially — visible. The blank field is its own alarm.
A wrong attribution costs you something else entirely, and it is invisible by construction. It looks exactly like a correct one. Consider what it can produce:
- A bill to the wrong client. Minn. R. Prof. Conduct 1.5(a) provides that “[a] lawyer shall not make an agreement for, charge, or collect an unreasonable fee or an unreasonable amount for expenses.” A fee for work performed on a different client’s matter is not merely unreasonable — it is not that client’s fee at all. And note who is exposed: the system generated the entry, but you reviewed and submitted the invoice.
- A deadline docketed to the wrong file. The right file now shows nothing due.
- A privileged document filed into another client’s folder, where the next person to open that folder will find it.
- A conflicts picture that is quietly incomplete, because the work that would have shown the connection was recorded somewhere else.
Every one of those is a professional-responsibility problem before it is a technical one. And each is produced by a system doing precisely what it was designed to do: always come up with an answer.
The four design rules
1. Prefer null.
When the evidence does not clear the bar, write nothing. Make the empty state a normal, expected, well-rendered thing in the interface, not an error. If a blank looks broken, people will fill it in with a guess — which is the same failure with an extra step.
2. Rank evidence, and be explicit about the ranking.
Not all signals are equal, and the ranking should be written down where a future reader can see it:
- Authoritative — the matter folder the work actually happened in. If you were working inside
/Clients/Anderson, Ruth/01234-Anderson/, that is not an inference, that is a fact. - Inferential — files written into a matter folder during the session. Good evidence, not conclusive.
- Rejected — anything merely mentioned, anything matched on a personal name, anything matched on a number that is not verified to be a real matter.
3. Label every inference with where it came from.
Any attribution the system made rather than knew should say so in the interface: from folder, from files, from event title. It costs one line of display. It converts a claim into a claim-with-a-basis, and it means the person reviewing an invoice can see which entries deserve a second look.
4. Write down what you rejected, and why.
This is the one people skip, and it is the one that saves you.
Six months from now, someone — quite possibly you — will look at the coverage statistics, see all those unattributed calendar events, and think: we could match a lot of these on the client’s last name. It will look like an obvious improvement. It will pass a casual review. It is the exact bug you already fixed twice.
So the codebase carries a comment where the surname matcher used to be, recording that it was tried, what it broke, and that the second version failed by matching a judge. Not a note in a wiki. A comment at the site of the temptation, where the next person to reach for it has to read it first.
Document your failures next to the code that would repeat them. Institutional memory that lives anywhere else does not survive contact with a busy afternoon.
What this looks like in practice
Concretely, in the systems running here:
- Roughly a third of calendar events show no matter. Nobody is bothered by this, because the ones that do show a matter are right.
- Reconstructed time entries display where the attribution came from, and the ones marked as inferred get looked at harder before anything is approved.
- No entry becomes a bill without a human reading it. The system’s job is to make sure nothing is forgotten, not to decide what is owed. Those are different jobs, and only the first one should be automated.
That last distinction is the whole philosophy, honestly. Automation is extremely good at noticing that work happened. It is not good, and should not be trusted, at deciding whose work it was — because it cannot tell the difference between the folder you were working in and the folder you happened to glance at, unless you make it treat those differently on purpose.
The general form
I have come to think this generalizes past attribution, to nearly every place we point automation at legal work:
A system that serves a professional obligation should be built so that its failures are visible, and its silences are truthful.
Every automated thing in this office has an obligation behind it. A deadline system serves the duty of competence. A billing system serves Rule 1.5. A conflicts system serves Rules 1.7 through 1.10. In each case the professional obligation runs to a human being who signs something, and the system’s only legitimate role is to make that person’s judgment better informed.
A system that guesses is not making them better informed. It is manufacturing confidence and handing it over with your signature block attached.
Blank fields are not a failure of the system. They are the system telling you the truth about what it knows — which is the only thing you can safely build a professional judgment on top of.
Sources
- Minn. R. Prof. Conduct 1.5(a) (“A lawyer shall not make an agreement for, charge, or collect an unreasonable fee or an unreasonable amount for expenses.”), verified against the Minnesota Rules of Professional Conduct as published by the Minnesota Revisor of Statutes.
This article describes general design practice for internal law firm systems. All examples are invented. It contains no client information and is not legal advice. Rule references are general and are not a substitute for reading the rules, which every lawyer should do for themselves.