Structured legal data decides what you can actually find

A practitioner opens a search, sets the court, narrows the date range, picks a judge, and gets a short list of judgments back. That looks like a small convenience. It is the visible end of a long chain of decisions taken months earlier, before a single document from that source was ingested. Every filter on that screen exists because someone read the underlying documents, understood what kind of document they were, and decided that a particular piece of information was worth pulling out of the text and storing as data in its own right.

That work is what structured legal data means, and it matters more now than it did five years ago. Legal search is being rebuilt around AI, and an AI answer inherits the quality of the data underneath it. When the structure is weak, the answers are plausible and imprecise. Our own AI features work because the corpus they read has been structured first.

Take a name inside a paragraph of a judgment. Stored as text, that name is just a run of letters. The system knows nothing about it. It carries no more meaning than any other word in the same sentence, and there is no way to use it.

Now take the same paragraph and, while bringing it in, detect that the name belongs to a person, and extract it into its own field. The name stays in the body of the text, where it belongs, and it also exists separately as a term. A single unit, unique, addressable. At that point it becomes filterable, which it was not before.

This is what enrichment means in practice. It is not a decorative layer added at the end. It is the difference between a document you can read and a document you can interrogate. And the enrichment goes further than identifying a person, because the useful part is the role. Knowing that a string is a person’s name is worth something. Knowing that it is the judge, or the solicitor on record, is worth considerably more, because now the term carries a category and everything in that category can be counted, grouped, and filtered. The same logic applies to addresses, monetary figures, dates, and procedural labels.

The practical result is the search experience practitioners already use. Ask for a judgment from January, before a named judge, in a particular court, and the platform can answer, because those three things stopped being text and became terms.

Every decision happens before ingestion

Each source has its own structure, so each source gets its own analysis before anything is loaded. We work with 36 official sources as of July 2026, and the list keeps growing, which means this exercise is not a one off. We produce a document for each one: what fields exist, which ones are worth extracting, whether each field will be used as a search filter or left to free text search, and how each one should be stored. A list in the database or plain text are two different decisions with two different consequences.

That document takes two weeks at a minimum, and most sources take longer than that. How much longer depends on the complexity of the source and on how much of the information we judge worth making searchable. Most of that time is discussion inside the team rather than writing. It is where the disagreements happen and where they get resolved.

Some of those questions are genuinely hard. Judges’ names are the clearest example. A single surname, no more, and a great many judgments. Deciding whether the Judge Smith in one matter is the same person as the Judge Smith in another is not a formatting problem. It is a judgment call that has to be made explicitly, documented, and applied consistently, because everything downstream depends on the answer.

The reason all of this happens up front, rather than iteratively, is arithmetic. Suppose a source holds 100,000 documents and we have extracted three filters from each. Deciding later that a fourth filter would be useful means going back and reading those 100,000 documents again, one by one, to extract a field nobody looked for the first time. So we extract everything worth extracting on the first pass. When a filter appears in the interface is a separate question, and it often comes later.

A sample first, then the rest

We do not process a new source in full on the first attempt. We take a random subset, whatever proportion is straightforward to pull, and we iterate on that sample until the extraction is right. Only then do we run the remainder. It is rare for that first pass to miss anything, although occasionally a handful of unusual documents appear, carrying a field the rest do not have.

This is where the approach differs from general purpose data collection. Plenty of operations scrape a website without ever needing to understand what the documents on it are. There is no reason for them to understand, and no incentive. Our technical team spends its time in the opposite position, reading Irish legal documentation closely enough to know where each thing sits and why. The volume matters far less than knowing what you are holding.

The original document stays one click away

Two commitments follow from the same principle. The first is synchronisation. When a document changes at source, it changes here. When it is removed at source, it is removed here. A static copy of a legal source drifts from reality, and a drifting copy is worse than no copy at all.

The second is provenance. Every result links back to the originating document, and that was decided at the very beginning of the platform.

Neither is standard practice, and it is worth being precise about why. We do not know how every provider works. We do know what general practice looks like. Extraction is often handled as a quick pass, outsourced to a team working at speed or left to a model to decide what matters. Real synchronisation is often absent, either because nobody is in direct contact with the people who manage the source or because a document that has already been published is treated as finished business. Neither of those choices is careless. They are simply cheaper.

The provenance decision has aged well. In a research environment where more of what practitioners read has passed through some kind of processing, being able to reach the source itself is not a nice detail. It is how a practitioner verifies, and verification is the whole job.

Automated checks, and a person where it counts

Automation without verification is just volume moving quickly. Every step of the pipeline carries its own automated check, and those checks cover a wide range. At one end, something as ordinary as a possible typo in an extracted field. At the other, an anomaly in the volume of documents arriving from a source, which is the kind of signal that goes unnoticed for weeks in a system nobody is watching.

Our policy on those checks is deliberately noisy. We would rather deal with a false positive than miss a real error, so we accept being alerted about things that turn out to be fine. The alternative is hearing about the problem later, from a user, which is the worst possible way to find out.

Some checks matter enough that automation is not allowed to decide on its own. In those cases the pipeline stops and a person reviews and approves it before anything proceeds. That is a deliberate limit on how much we let the machinery decide, and it sits at the points where an error would reach a practitioner’s screen.

Discipline scales better than headcount

Behind all of this runs a continuous pipeline over a corpus of more than 5 million documents. On a normal day it executes more than 50,000 automated jobs collecting and processing new material. Nothing at that scale can be supervised by hand, which is exactly why the checks above exist, and the architecture has been rebuilt as the volume grew, moving from a service based model with multiple queues to durable workflows.

The design rule behind it is simple and it is not really a technology rule. I would rather spend more time now doing something properly than maintain it for years afterwards. Maintainability is treated as a feature. What it buys is attention: a team that is not watching what already works can spend its time on what does not exist yet.

Which answers a question we get asked in different forms. A platform serving leading firms and public bodies is expected to sit on a department of several hundred developers. It does not. A technical team is far less about the technology it uses than about method, sequencing, and the discipline to do things the same way every time and to be able to say why it is done that way and not another. There is a conversation happening right now about AI allowing teams to stay agile at a size that would once have been impossible. We have been working that way since well before the current tools existed, and the reason is the same then as now.

That is what eventually shows up as a filter on a screen that returns the right list.

If you want to see what that looks like from the inside, get in touch at vizlegal.com/contact and we will walk you through the sources that matter to your practice.

💡 Author: Vizlegal co-founder and CTO, Jose Alberto Suárez.