The worst moment on a matter is not the hard question. It is the blank page before the hard question — the point where the file has accumulated documents, correspondence and notes, and you have to rebuild the whole shape of the case in your head before you can do any actual thinking. Who are the parties and what are their roles. What is claimed and what is answered. Which document proves which fact. What authorities are in play. What the dates are, running from first instruction to the next deadline.

You have done this before on this very matter. You will do it again next time it reaches a decision point. Sixty to ninety minutes, each time, to reconstruct what the file already holds.

We built a module to hand you that structure so you can spend the hour on the judgement instead.

What 'prepare case' produces

You click prepare case. The assistant reads the matter — the documents you have already put in it — and returns a typed case-graph:

  • the parties and their roles,
  • the claims and counter-claims,
  • the evidence items, each linked to the document it sits in,
  • the authorities cited or proposed,
  • and the date spine, from first instruction to next deadline.

It is a skeleton, not a brief. It does not write your advice, and it is not trying to. It gives you the marshalled structure a fee-earner normally rebuilds by hand, so that when you sit down you are starting from a prepared position rather than a cold file.

Reactive, not autonomous

The word we use for this internally is reactive: the tool reacts to what is in the matter and lays it out. It does not decide anything. Every branch of the graph is something for you to read, keep, edit, or throw out.

That distinction runs through the whole product, and it is not decoration. A case skeleton that made the judgement calls for you would be a case skeleton you could not trust, because the judgement calls are the case. So the tool does the marshalling — the part that is mechanical and thankless — and leaves the reasoning where it belongs, on your desk. You edit the parts that need a solicitor's judgement, and you sign off on the shape.

Why it is a typed structure, not a summary

The case-graph is rendered as a typed structure — parties, claims, evidence, authorities, dates as distinct, laid-out things — not as a free-text paragraph. This is deliberate. A prose summary reads well and hides its gaps; you finish the paragraph with a feeling of coverage and no way to check it. A typed graph lets you audit each branch against its source: click the evidence item, see the document; click the authority, see where it came from. You are reviewing structure you can verify, not trusting a paragraph you cannot.

Where the matter stays

The case-graph is built from the documents already inside the matter — and the matter lives in your browser, on your own machine. Preparing the case does not ship the file off to be processed somewhere. When the model is needed, only the text required for the step goes out, with the client's identity stripped first. The prepared position is assembled on your desk, from your file.

Before: you re-read the matter, sketch parties and dates on a pad, hunt for authorities, and hope nothing slipped. Sixty to ninety minutes to rebuild what the file already contained.

After: the module produces the case-graph skeleton, you review each branch, edit the judgement calls, and sign off. Today this runs on demand — one click, whenever a matter reaches the point where you need to see it whole.

← All posts