When legal software has to be right: building systems that carry consequence

Most software fails gracefully. A portal that goes down is an inconvenience. A reporting tool that miscounts is embarrassing and gets fixed.

Some software does not have that latitude. When a system produces a determination that a firm will act on, advise a client on, or submit to an authority, being approximately right is not a partial success. It is a failure with consequences that reach beyond the software.

We have built systems of this kind for law firms, including software that determines tax status against complex and changing rules. This article is about what changes when the output has to be right.

The difference between a system that stores and a system that decides

A document portal stores and retrieves. If it does that correctly, it is working. The information it holds was created and verified by people, and the software's responsibility ends at handling it faithfully.

A determination system produces something that did not exist before. It takes inputs, applies rules, and returns an answer that someone will rely on. The software is not handling a professional's judgement, it is encoding part of it.

That distinction changes almost everything about how the project is run: how requirements are gathered, how the logic is validated, how it is tested, how changes are managed, and what the firm needs to be able to demonstrate afterwards.

Modelling rules that change

Legal and tax rules are not static. Thresholds move, definitions are revised, exemptions are introduced and withdrawn. A system encoding those rules has to accommodate change as a normal event rather than an exception.

The design consequence is that rules should be modelled as data wherever possible rather than embedded in code. When a threshold changes, updating a value is a controlled operation. Changing a hard coded rule requires a development cycle, testing and deployment, which means either the system lags behind the rules or corners get cut.

The other requirement is that rules are versioned by date. A determination made last year was made under last year's rules, and the system needs to be able to reproduce that determination as it stood, not as the rules stand now. Without this, historic records become indefensible the moment the rules change.

Making the logic explainable

A system that returns an answer without showing its reasoning is of limited use in a professional context. The person relying on it needs to be able to see why.

This is partly about trust and adoption. A fee earner presented with a determination they cannot interrogate will check it manually, which removes the benefit. It is also about defensibility: if a determination is questioned, the firm needs to demonstrate the basis on which it was made.

In practice this means the system should record not just the answer but the path to it: the inputs used, the rules applied, the version of those rules in force, and the resulting determination. That record needs to be readable by a professional rather than only by a developer.

Validating with the people who know the rules

This is the part most often underestimated, and it is where these projects succeed or fail.

Developers do not know tax law. The people who do are usually senior, busy, and expensive, and their time is the scarcest resource on the project. The temptation is to gather requirements once at the start and then build. That does not work, because the difficult cases only surface when someone knowledgeable looks at concrete examples.

The approach we use is iterative validation against real scenarios. Rather than asking an expert to review a specification, we build a working version of the logic and put actual cases through it with them, including deliberately awkward ones. Ambiguities in the rules become visible immediately, in a way they never do when reviewing a document.

It is also worth being explicit that some of these ambiguities are genuine. Not every rule has a single obvious interpretation, and where a firm has taken a position, that position needs recording as a decision rather than buried in code as though it were self evident.

Testing for the cases that matter

Standard software testing checks that the system behaves as specified. Determination systems need more than that, because the risk is not that the code does the wrong thing, it is that the specification was incomplete.

The useful technique is building a library of test cases with known correct answers, verified by the firm's own experts, and running the whole library on every change. Over time this becomes the most valuable asset in the project. It means a rule change can be made with confidence, because if it breaks a previously correct determination, that is visible immediately.

Boundary cases deserve particular attention. Errors cluster at thresholds, at transitions between categories, and wherever two rules interact. Those are the cases worth constructing deliberately rather than waiting to encounter.

What this means for how the project runs

Projects of this kind are not longer than other software projects because the code is harder. They are longer because validation takes time and because access to expert input is the limiting factor.

Plan for that from the start. Establish who the subject matter experts are, agree how much of their time is realistically available, and structure the work so their input arrives in short, frequent sessions with concrete material rather than long reviews of documents.

Scope tightly to begin with. A system that handles the most common determinations correctly and refers the unusual ones to a person is more valuable than one that attempts everything and is trusted on nothing. The scope can widen once the approach is proven.

Building something that has to be right?

We build systems for law firms where the output carries real consequence, including determination and compliance software for international practices. If you are considering a project of this kind, we would be glad to talk through the approach before anything is committed.

An initial conversation is free and carries no obligation. Get in touch at hello@16i.co.uk or call +44 (0)1242 654 000.