What Happens When the Document Is No Longer the Work?

I read Anthropic's post about Scion, its new source-control system, and ended up thinking about legal documents, which wasn't where I expected to go with an article about Git or maybe it was, it's hard to keep track of where things might go nowadays.

The scale of what's happening inside Anthropic is quite incredible. In May, it was merging around 2,500 code changes a day. By September, that was over 30,000. Its monorepo was being checked out roughly 25 million times a day, much of that driven by agents and automated jobs rather than developers sitting at their laptops. Keeping Git running at that scale involved hundreds of internal mirrors, so a team of seven built Scion and moved the monorepo across in five months. Anthropic says the new setup uses around 200 times less CPU and memory than the old mirrors.

Git has served software engineering extraordinarily well, but a lot of its design makes sense when you picture developers working on local copies of code, sometimes without a connection, and synchronising their changes later. That's increasingly unlike the workload Anthropic needs to support. Most of those automated jobs are connected, short-lived and interested in a small part of the repository. Once the balance shifted far enough, it was worth building for that reality rather than finding ever more elaborate ways of keeping the old setup going.

There's a second part to the story that I found just as interesting. The engineers describe spending less time writing every change themselves and more time specifying what they wanted, checking whether the result respected the system's constraints and pushing back when it didn't. That's a different kind of engineering work, and it puts pressure on all the tools around it.

I think something similar could happen in legal services, although I suspect the implications go quite a bit further than swapping one version-control system for another.

Why does everything have to be a document?

Look at how most legal work is organised. We take instructions, investigate, draft, review, negotiate, approve and eventually produce something. It might be an agreement, an opinion, a board paper or a letter of advice. Along the way we accumulate emails, comments, tracked changes, earlier versions and notes explaining why a particular decision was made, assuming anyone remembered to write that last part down.

We've built a lot of good technology to manage this. Document management systems keep the files organised and comparison tools show what changed, then workflow systems move things through review and approval. More recently we've started asking AI to search across the lot, extract information and produce new drafts.

I can see why we've approached it that way. For most of the history of legal practice, creating and reviewing those documents has taken significant human effort, so the documents became the obvious things to organise work around. They also happen to be tangible. You can put one in front of a client, agree its wording and sign it.

Though when I think about what a lawyer is actually doing, much of the important work happens around the document rather than in the act of writing it. Working out whether a client has a right to do something. Understanding which facts matter. Deciding whether a risk is acceptable. Establishing whose consent is needed and whether something agreed six months ago changes the advice today.

The document often becomes the place where we record the result of that thinking. Sometimes it's the instrument that gives the result legal effect. Those are important jobs, but they're not the same thing, and we've tended to manage both through the same collection of files.

As drafting becomes easier, I wonder whether that arrangement starts getting in our way.

Start with what changed

Imagine a fund with forty investors. There's a governing agreement, subscription documents and a collection of side letters giving certain investors specific rights. One investor might have additional reporting arrangements, another different fee terms, and so on.

Six months after the fund is established, an investor asks for a reporting right similar to one granted to somebody else. There's a most-favoured-nation provision that might allow it, depending on the investor's eligibility, the exclusions and how the original right was agreed.

A lawyer would need to find the relevant documents, check the terms, work through the legal and commercial questions, speak to the right people and perhaps prepare an election notice or some amended drafting. AI can already help with several of those steps. A better search tool or a more capable drafting agent would certainly make the process faster.

What I'd like to try is a system where the request enters as a change to the matter, rather than as a task to open and edit some documents.

The system would already have a record of the investors, the rights they've been granted, the documents supporting those rights and the decisions made along the way. It would identify which provisions could apply to the new request and what still needs to be established. If the position is ambiguous, that ambiguity stays visible. If the change needs approval from the fund's governing body or advice from a lawyer, it waits for that. Once the appropriate steps have happened, the record can reflect the outcome and the necessary documents can be prepared.

I'm deliberately saying record rather than change the legal position. Entering something into software doesn't make it legally effective. The system might record a proposed right on Monday, an approval on Wednesday and an executed agreement on Friday. Those are three different events, and they shouldn't be collapsed into one simply because it's convenient for the application.

There's a reasonable amount of familiar technology in this idea: structured information, rules, linked documents, audit trails and workflows. The difference is where the centre of gravity sits. Instead of asking a system to find the latest version of every relevant file and reconstruct the matter from them, we'd be maintaining an understanding of the matter as it evolves, with those files available as evidence and, where appropriate, the actual legal instruments.

For a one off contract review, that may well be unnecessary complexity. For a fund with dozens of investors, numerous side letters and years of changes, I think it's worth investigating.

So this is when the comparison starts to break a little...

Git can reconstruct what a repository looked like at a particular point. That's enormously useful, but legal work has several different kinds of history running at once.

Say a contract was signed in January and then something happened in March that may have breached it, but the client didn't tell the lawyers until April... In May the counterparty disputed the facts... and then in June the parties reached an agreement about what to do next.

The contract might be identical in January and June, yet the advice you'd give in those two months could be completely different. The event happened in March, knowledge of it arrived in April, the interpretation was challenged in May and the parties' agreed position changed in June and even then, they might disagree about what happened in March.

A normal version history doesn't really describe that. We'd need to keep track of what was asserted, when it was said to have happened, when people learnt about it, what evidence supported it, which interpretations were adopted and who had the authority to make the relevant decisions. We might also need to reconstruct what a lawyer reasonably knew at the time they gave advice, rather than judging everything using information that only emerged later.

Some of that information won't fit neatly into a field with a single correct answer. Two parties might disagree about the meaning of a clause for years. Sometimes the wording was left deliberately open because that was the only way to reach agreement. I'd be wary of any system that treated uncertainty as a data-cleaning problem and quietly picked the interpretation it liked best.

That's why I don't think the answer is simply 'Git for contracts', or even converting every contract into machine-readable rules. There's useful work already happening on computable contracts and projects such as Accord, but the thing I'm describing would need to handle the parts of legal work that aren't readily computable as well. Evidence, disputed facts, changing interpretations, delegated authority and formal acts that give something legal effect would all have to coexist.

It would be a maintained model of the legal relationship, not an alternative source of law. The underlying agreements, legislation, decisions and other authoritative materials would still matter, often more than anything the model concluded about them.

We'd probably review work differently too

If agents make it much cheaper to produce legal analysis and drafting, having a human review every generated page in the same way we do now could become the limiting factor. I don't think the answer is to review less carefully. We need to be more deliberate about what the reviewer is being asked to decide.

Take a heavily marked-up agreement with two hundred changes. Those edits might represent a handful of commercial decisions, along with a lot of drafting needed to put them into effect. I'd rather give a partner a clear view of those decisions, the evidence and agreed negotiating parameters behind them, who can authorise them and where the proposed drafting gives effect to each one. The partner could then go straight into the wording wherever close scrutiny is required.

There will always be changes where the precise words are the issue, such as a subtle qualification which can completely alter an obligation, and no tidy summary should stand between a lawyer and the text when that matters, but making a redline the main interface for every approval doesn't necessarily help someone understand the substance of what they're approving.

There's also a governance issue hiding somewhere in here. An agent might correctly identify a risk and draft a perfectly reasonable response, yet the client may have reserved that decision to its general counsel or investment committee. The system needs to know the difference between being capable of recommending something and being authorised to do it. I wouldn't want the same agent that proposed a change to be the sole judge of whether it needs supervision.

That seems to me like a more interesting engineering problem than producing another contract in thirty seconds.

What would we actually build?

I wouldn't start by trying to create a universal model of law, that sounds like a good way to spend several years producing something nobody can use and an easy way to end up going insane.

I'd pick one contained type of matter with enough complexity to make the problem worthwhile. Fund investor rights might work? You could use synthetic governing agreements and side letters, then introduce a series of events: a new investor, a request for a preferential right, a change in eligibility, conflicting information and an approval that hasn't yet been given.

I'd run the same scenarios through two approaches. Give one a strong document search and drafting setup. Give the other that same capability, but also a structured history of events, rights, evidence, dependencies and approvals. Then ask both to work out what's affected and what should happen next.

I'd want to know which approach misses fewer consequential dependencies, which can explain the basis for its conclusions, which keeps disputed matters genuinely unresolved and which is better at distinguishing a proposal from an effective legal change. We'd also need to count the human effort involved in maintaining the structured information, because a system that saves ten minutes of review but requires an hour of data housekeeping isn't much of an improvement.

Perhaps the document-centred approach wins for most matters. Perhaps the structured approach only becomes worthwhile when relationships are long-running or the same rights keep being revisited. That's useful to know. I suspect the answer will depend far more on the shape of the legal work than on the capability of the underlying model.

And if the structured approach does work, the commercial implications could be quite significant. A client could engage a firm to keep an agreed set of obligations or legal exposures under review, with changes assessed against the recorded position rather than starting from scratch every time. That's a different service from producing an opinion and filing it away. It would need a properly defined scope, reliable updates and clear responsibilities, of course. Just because a system can watch something doesn't mean the firm has agreed to monitor it forever.

I keep coming back to the same question, though, if agents can produce more documents and legal analysis than we can realistically read, store and reconcile, are we really going to solve that by building better ways to manage the files?

I'm not suggesting we stop producing documents. A signed agreement isn't just a convenient output format, and in plenty of legal work the precise document is the kind of the whole point, but there's a lot of activity around those instruments that we've ended up treating as document work because that's how our processes developed.

Anthropic's Scion work made me wonder what happens when we design around the work that's now possible, rather than the pace at which people used to do it. I'd quite like to build the small fund example and see where it breaks. My guess is we'd learn more from that than from another demonstration of an AI drafting a contract in thirty seconds.