Every matter starts the same way, and the start is the dull part. Someone reads the inbound — an email thread, a signed contract, a barrister's brief, a client's Word document that wanders — and types the same things into a matter file that they have typed a hundred times before. Parties. Jurisdiction. Key dates. The claims. The facts that will end up in the chronology. It is careful work, it is slow, and nothing about it is the work you trained to do.

So the first thing we built into the engine was a module that reads the papers for you.

What it actually does

You select the document and click extract. The assistant reads it and returns a structured matter card: the parties and their roles, the jurisdiction, the key dates, the claims, and the facts it thinks belong in the matter chronology. Each of those is a proposal — not a fact written into your file, but a fact offered up for you to look at.

Crucially, every proposed fact carries a link back to the exact paragraph it was pulled from. If the assistant says the contract was dated 14 March, you can click through to the line in the document that says so and check it yourself in a second, rather than trusting a summary and hoping.

You then go down the list. Accept a fact, reject it, or edit it. Only what you keep gets written into the matter file. Nothing lands in your records that you did not put there.

Why the confirm step is the point, not the friction

It would have been easier to write a tool that reads the document and fills in the matter file directly. It would also have been wrong.

A solicitor is answerable for what is in the file. An extraction that quietly writes twenty facts into your matter — some right, some subtly off, none reviewed — is not saving you work; it is handing you a liability you did not read. The human confirmation is not a courtesy we bolted on. It is the design. The tool proposes; you decide. That is the correct division of labour between a solicitor and a machine, and we were not willing to blur it to look more impressive in a demo.

The back-reference to the source paragraph is what makes the confirm step fast rather than tedious. You are not re-reading the whole document to check the assistant — you are glancing at one linked paragraph per fact.

Where the papers stay

The document you drop in does not leave your machine to be read. The matter lives in your browser, on your own disk. When the assistant needs the model to help with the extraction, only the text required for that step is sent — and the identity of your client is stripped before it goes, restored locally when the answer comes back. The papers on a live matter are the most sensitive thing a firm holds; the architecture treats them that way by default, not on request.

What it replaces

Before: a fee-earner or paralegal reads the inbound, types the parties and dates into the file, copies the key paragraphs across, and hopes nothing was missed on a tired afternoon.

After: the module produces the matter card and the fact proposals, and you review each one against its source and accept or reject it.

The saving is real, but the quieter gain is the missed-nothing feeling — every fact in the document has been surfaced and put in front of you, rather than left to whether you read carefully enough that day. Today this runs on demand, one document at a time. It is the first thing the engine does with a matter, because it is the first thing the day does with one.

← All posts