E/06 · The teardown
The matter opening teardown: redesigning the step between yes and live
Matter opening is the gap between deciding to take a case and that case actually existing anywhere a lawyer can work from. Here is what it looks like rebuilt on the six MATTER primitives, step by step, with nothing left to whoever happens to be free that afternoon.
By Raghav R Handa · Founder · August 2026 · 13 min
The gap nobody times
Conflicts checking has a clear end. Matter opening has a fuzzy one, and that is the problem.
A conflicts check has an unambiguous finish line: cleared, waived, or declined. Matter opening does not. It ends whenever whoever is doing it decides it is 'done enough', which in most practices means a matter number exists, a folder has been created, and the file has been physically handed to the person doing the work. Everything else - the deadlines, the task list, the team, the document structure, the starting research - gets built as it is discovered to be missing, usually by the person doing the work, usually days or weeks into the matter.
That is the wrong sequence, for the same structural reason the conflicts check is the wrong sequence when it runs on memory. The step between 'we have decided to take this case' and 'the matter is actually live and usable' is not paperwork. It is the point at which every downstream system - the deadline calendar, the task list, the file structure, the research a lawyer starts from - either gets built correctly once, or gets rebuilt badly, piecemeal, by whoever notices the gap first.
Firms that have systematised conflicts checking often still treat matter opening as the reward for having passed it: the conflict cleared, so now someone can finally 'set the matter up', and setting it up means whatever that person happens to remember to do that day. This teardown rebuilds matter opening on the six MATTER primitives, in the same order the doctrine always insists on: name it, systematise it, automate it. It picks up exactly where the conflicts check teardown leaves off, and it ends exactly where real work begins.
The diagnosis
What matter opening actually is, once you stop calling it admin.
Matter opening answers one structural question: given a matter type that has been opened many times before, what does this new instance need built before a lawyer can start productive work on it, without first reconstructing scaffolding that should already exist? Stated that plainly, it is obviously a templating problem - take a known matter type, instantiate its known requirements. Run informally, it is instead a recall problem, where the person opening the matter has to remember, from experience, everything a matter of this kind eventually turns out to need.
The gap between those two descriptions is the entire redesign. A templating problem can be named once per matter type and then instantiated automatically, every time, in seconds. A recall problem cannot, because it depends entirely on whoever is opening the matter that day having opened enough matters of that exact kind to remember what belongs in it - and even then, memory drops things under time pressure that a template never would.
The redesign
Matter opening, rebuilt on all six primitives.
Each primitive answers a specific structural gap in how matter opening is normally run. Together they turn 'set the matter up' from a memory exercise into a repeatable instantiation of a known template, done once per matter type and then run automatically every time that type opens.
Matter - the naming, numbering and classification decision everything else depends on
Before a single task, date or document exists, the matter needs three things fixed at the same moment: a matter number that will never be reused, a matter type chosen from a defined list, and a name that a stranger could read a year later and understand.
This is the single decision every other primitive in this teardown depends on, which is why it comes first and why it cannot be casual. The matter type is not decoration - it is the key that everything downstream reads from. Choose 'commercial lease renewal' instead of just 'commercial property' and the action library, the key dates, and the starting research that get pulled in the rest of this sequence are all specific rather than generic. Choose a vague or wrong type and every later primitive inherits that vagueness: the wrong task list, the wrong deadlines, the wrong starting point.
The classification has to be a closed list, not a free-text field. A free-text 'matter type' produces forty near-duplicate spellings of the same handful of practice areas within a year, and a closed list is what makes automatic instantiation possible at all in the primitives that follow. The matter number should be assigned by the system, not chosen by a person, for the same reason a party registry beats memory in the conflicts check: a sequence a machine assigns cannot be duplicated, guessed, or reused by accident.
The testCould a colleague, reading only the matter number, name and type six months from now, correctly guess what kind of work this matter involves, without opening it?
Actions - the standard task list a matter type should trigger, not invent
Every matter type that has been opened before has an opening task list that repeats: the letters that go out, the searches that get ordered, the accounts that get set up, the internal notices that get filed. Write that list once per matter type. Instantiate it automatically, every time.
Most informal matter-opening processes have exactly one implicit action: 'set it up', performed by whoever is free, from memory of the last similar matter they personally handled. Written out properly, the opening task list for a given matter type is a named, ordered set of concrete actions - each with an owner and a due point relative to the open date - and it should trigger the instant the matter type is chosen in the Matter step, not get assembled piecemeal as gaps are discovered.
The two most commonly missing items on an informally-built list are the ones with no visible deadline: the internal notice that a new matter has opened (to conflicts, to billing, to whoever runs capacity across the practice) and the client-facing confirmation that the matter is live and who to contact. Neither has a court date attached, so neither gets remembered under pressure - which is exactly why they belong on a named list rather than in anyone's head.
The testFor your most common matter type, do you have a written, ordered opening task list that any competent hire could execute without asking a senior lawyer what comes next?
Time - key dates calculated from the matter type, not re-derived by hand
Limitation periods, statutory notice windows, court deadlines and internal review points are a function of the matter type and the open date. They should be calculated once the type is known, not worked out from scratch by whoever opens the file.
This is the primitive where an informal matter-opening process fails most expensively. A limitation date is not a matter of judgment; it is arithmetic on a known rule applied to a known date. Working it out by hand, every time, from memory of the relevant statute, is not thoroughness - it is a needless repeat of a calculation that should have been encoded the first time this matter type was ever opened. Encode it once, as a rule attached to the matter type, and every future matter of that type gets its key dates calculated automatically the moment it opens, before anyone has done a minute of substantive work.
The dates that matter here split into two kinds, and both need to exist from the first day: the absolute ones (statutory deadlines, court-imposed dates) that are fixed the moment the matter type and any governing date are known, and the internal ones (first review point, next client update, file review interval) that the practice sets for itself and that a matter with no internal review date attached is a matter nobody is scheduled to look at again until a deadline forces it.
The testThe moment a new matter of a known type opens, are its key dates already sitting on the file, or does someone still have to work them out?
Team - who is on the matter and what each of them is told, at open, not on discovery
A named responsible partner, a named handling lawyer, and anyone else the matter type standardly requires (a paralegal, a costs specialist, a conflicts contact) are assigned at open, and each is notified of specifically what they are on the hook for.
Informal matter opening usually assigns exactly one role explicitly - the lawyer who is 'running it' - and leaves everyone else to discover their involvement when a task lands in their inbox with no context. That produces the same inconsistency the conflicts check teardown describes for an undefined decider: a supervising partner who finds out about a matter's existence three weeks in, a paralegal who only learns they are on a file when a task is already overdue.
The fix is the same move as elsewhere in the doctrine: name the team at the same moment the matter is named, not after. That means writing down, per matter type, which roles a matter of this kind standardly needs, assigning named people to each role at open, and sending each of them a notification specific to their role - the supervising partner gets an overview and the key dates, the handling lawyer gets the full opening task list, the paralegal gets only the tasks assigned to them. A single generic 'new matter' email to everyone achieves the appearance of notification without the substance of it.
The testOn the day a matter opens, does every person on it know they are on it and specifically what they own, or does that only become clear when their part comes due?
Evidence - the document structure created empty but ready, not improvised as files arrive
Every matter type has a known shape of documents it will eventually hold. Build that folder and file structure at open, empty, correctly labelled and in the right order, so the first document that arrives has somewhere obvious to go.
The common failure here is not the absence of a document structure - it is a document structure that gets improvised the moment the first file arrives, and then never rationalised again, so six months later a matter's evidence is organised by whatever order things happened to turn up in rather than by what they are. A commercial lease renewal and a debt recovery claim do not need the same folders, but each needs the same folders every single time it is opened, because that consistency is what lets anyone, not just the person who built it, find a specific document without asking.
This extends past folders. Standard document templates for the matter type - the engagement letter variant, the first client letter, the standard notice - should be sitting in the structure at open, pre-populated with what is already known (party names, matter number, key dates), ready for a lawyer to complete rather than start from a blank page. An empty, correctly shaped container is not busywork; it is the same anchoring discipline the conflicts check teardown applies to conflicts records, applied here to the matter's eventual paper trail.
The testWhen the first substantive document for a new matter arrives, is there already an obvious, correctly labelled place for it to go, or does someone have to decide the structure on the spot?
Research - the starting precedent and prior answers pulled in automatically, not searched for from zero
If this matter type has been handled before, the practice already has research, precedent clauses, or a prior similar fact pattern on file. Surface it at open, before the lawyer has asked, rather than leaving them to remember it exists and go looking.
This is the primitive most matter-opening processes skip entirely, because research feels like something that happens once real work starts, not at open. But the research stock, if the practice has built one the way the conflicts check teardown and the research primitive both describe, already knows more about this matter type than the lawyer opening the file does on day one - it holds the last three matters of this exact type, the clause variants that worked, the questions that came up and how they were resolved.
Surfacing that stock automatically at open, keyed to the matter type chosen in the first primitive, means the lawyer's first hour on a new matter starts from what the firm already knows rather than from a blank search. This is the same compounding logic that makes a firm's second waiver decision faster than its first: a matter type opened for the fortieth time should be measurably easier to start than the first, and the only thing that makes that true is whether the prior work is retrievable at the exact moment a new matter needs it.
The testWhen a matter of a familiar type opens, does the lawyer see the firm's relevant prior work automatically, or only if they think to go looking for it?
Where automation actually fits
A bounded agent, not an autonomous one.
Once the matter type is a closed list, the opening task list is named per type, key dates are encoded as rules, the team roles are defined per type, the document structure is templated, and the research stock is tagged by matter type, a matter-opening agent has something to grip. Its job is narrow and specific: given a matter type and an open date, instantiate the task list with owners and due points, calculate the key dates, create the document structure from the template, notify the assigned team members with their specific tasks, and surface the relevant research stock - all inside the seconds after a lawyer confirms the matter type and clicks open.
What the agent must never do is choose the matter type itself, assign team roles that were not already defined for that type, or decide that a matter needs no internal review date. It instantiates a template a human already built and approved. A human - the responsible partner named in the Team primitive - remains the one who confirmed the classification that started the whole sequence, and remains accountable for the matter that results. This is the same bounded pattern the conflicts check teardown insists on: the machine does the assembly, on a task that has already been named and systematised, and a named person remains the one who decided and is responsible for the result.
The failure mode this redesign closes is not 'the matter was opened late'. It is 'the matter was opened, technically, and then spent its first three weeks being quietly rebuilt by the lawyer working it' - and that failure mode disappears the moment matter opening has a template per matter type, instantiated automatically, before a single hour of billable work begins.
Questions, answered plainly
Why does matter opening need a redesign rather than just a better checklist?
A checklist still depends on someone remembering to open it, work through it in full, and know which version applies to which matter type. The redesign here replaces a checklist that a person has to remember to use with a template that instantiates itself automatically the moment a matter type is chosen - tasks, dates, team notifications, document structure and research all appear without anyone having to recall that a checklist exists.
Is it safe to let an AI agent open matters automatically?
Yes, for instantiation, inside a bounded role. The agent assembles the task list, key dates, document structure and research surfaced for a matter type that a human already defined and approved, once a human has confirmed the classification. It never chooses the matter type and never invents team roles or dates that were not already part of the template - a named responsible partner remains accountable for the matter that results.
What is the single highest-leverage change a small firm can make to matter opening this month?
Write the opening task list and key-date rules for your single most common matter type, in full, once. That one template, applied consistently, removes the majority of the piecemeal rebuilding that otherwise happens in the first few weeks of every matter of that type - and it requires no new software and no AI to start paying off.
How does matter opening relate to the conflicts check that comes before it?
Conflicts checking answers whether a matter can open at all. Matter opening answers what that matter needs to be usable once it does. They are sequential and structurally similar - both are templating and matching problems that informal practice runs on memory instead - which is why both are rebuilt here on the same six primitives, in the same order: name it, systematise it, automate it.