Why Your Case File Should Work Like a Smart Building

Here is a sentence that sounds like a mistake: the data standard underneath Sound Suite's legal search was invented for air conditioning.

It isn't a mistake, and the reason why turns out to explain most of what makes the system useful. This post is the non-technical version — no code, no jargon that isn't defined on the spot. If you want the engineering account, that's a separate post.

First: what "ETL" means

You will hear this term if you spend any time around people who build data systems. It stands for Extract, Transform, Load, and it describes something you already do by hand.

Imagine a banker's box arrives. Inside: motions, exhibits, a deposition transcript, correspondence, a few things nobody labelled. To make that box useful you do three things. You take the documents out and read what's in them — that's extract. You work out what each one is, who filed it, when, and what it responds to, writing that on a folder tab or a spreadsheet — that's transform. Then you put it where you can find it again, in an order that matches how you'll look for it — that's load.

ETL is that process done by a computer, at scale, repeatably. Extract the text from a PDF, including the pages that are only scanned images. Transform it into structured facts: this is a motion, filed this date, responding to that one, signed by that judge. Load it into something searchable.

The reason the term matters is that almost all the value is in the middle step. Extracting text from a PDF is close to a solved problem. Storing things is easy. Working out what a document is and how it relates to everything else — that's the hard part, and it's the part that determines whether an AI can answer real questions about your case or merely find pages containing words you typed.

The problem with folders

Every case file you have ever worked with is organised as a hierarchy. Folders inside folders. It is so familiar that it takes effort to notice how little it can express.

A folder can say exactly one thing: this is inside that.

Now consider what's actually true about a motion to compel:

• A response opposes it.
• A reply answers the response.
• An exhibit is attached to the response.
• An amended version supersedes it.
• An order resolves it.
• One attorney is the movant; the same attorney is the respondent on a different motion in the same case.

Not one of those relationships is containment. So they get encoded in filenames — 2026-03-14 Resp to MTC (Amended).pdf — and in your memory. The filename is a note to yourself. A computer reading it learns almost nothing.

This is why searching a case folder is frustrating even when the search works. You can find every document containing "proportionality." You cannot ask "what did they say in response to my motion, and did I answer it?" — because the word "response" in a filename is a label, not a link.

What Haystack actually is

Project Haystack is an open data standard that has been running in commercial buildings for over a decade. Chillers, air handlers, sensors, meters.

Strip away the equipment and it's three ideas:

1. Things are described by tags, not columns.
Instead of a rigid form with fixed fields, each thing carries a set of labels. A record might be tagged motion, signed, opposed. Another might be motion, amended. You don't have to decide in advance every property anything might ever have.

2. Things point at each other, and the pointer has a meaning.
Not just "these are related" — this document responds to that one. The relationship has a name, so a computer can follow it in a specific direction and know what it means.

3. A dictionary defines what the tags mean.
Otherwise motion and moton become two different things and nobody notices. The dictionary says what a valid record looks like — a motion must belong to a case, may have a judge — and checks new records against it.

That's it. Tags, meaningful links, and a dictionary.

Why a building and a lawsuit are the same shape

Here's the mapping, and it is almost uncomfortably neat:

The nesting one is what convinced me. Amendment chains are genuinely awkward to model — a Motion to Compel, its First Amended version, its Second Amended version — and most systems either flatten them into unrelated files or bolt on a "version" field that breaks the first time something unusual happens. Haystack's equipment model already nests, because equipment already nests. No adaptation required.

Why the fit isn't a coincidence

Building automation and litigation look nothing alike, but they hit the same four walls:

• Thousands of things, with no realistic prospect of a tidy master list.
• Inconsistent naming across vendors, or across courts and jurisdictions. Nobody agrees on what to call anything.
• Relationships that matter more than hierarchy. Which valve feeds which coil; which reply answers which response.
• A schema nobody can finish. A new sensor type appears. A jurisdiction invents a filing nobody anticipated.

Haystack was built for exactly that combination, by people who had already failed at it a few times. Reaching for it wasn't clever — it was refusing to spend three years rediscovering the same lessons.

What the connections buy you

Once relationships exist as real links rather than filename conventions, a category of question opens up.

Select a motion, and you can select everything connected to it — the opposition, its exhibits, the reply, the order, the amended version. Not "documents in the same folder." Documents that are actually part of that argument.

Ask "what did the other side argue about timeliness, and how did I answer it?" and the system can walk from your motion to their response to your reply, in order, because those steps are recorded.

The difference between that and keyword search is the difference between following an argument and finding pages that mention a topic. Keyword search will happily return your motion, their response, and an unrelated exhibit that used the same word, with no indication of how the three relate — or that a fourth document exists and answers the question directly.

And the honest part: when a connection is missing — a filing arrived without anything saying what it responds to — the system shows you that gap rather than quietly returning an incomplete answer. A confident answer drawn from a broken graph is worse than an obvious hole, because you can't see it to check it.

Where this goes

Today, building the graph involves a person. Documents are ingested automatically, but connecting a response to the motion it opposes still takes someone who knows the case, working through a list.

That is not where it stops.

The pieces needed to do it automatically already exist and already run: the text is extracted, scanned pages are read, the structure of each page is understood — headings, tables, transcript line numbers. What remains is inference. A document that opens "Respondent files this response to Movant's motion to compel filed January 15" contains, in plain language, everything needed to place it in the graph.

The goal is blunt: drop a folder, get a case. Point the system at a box of PDFs and have it work out what each document is, who filed it, when, and what it answers — then show you the graph it built, with its uncertain calls flagged for you to confirm.

Notice the last clause. Not "trust it." The realistic version of this is a machine doing the tedious 90% and being explicit about the 10% it isn't sure of. A system that silently guesses at relationships produces a case file that looks organised and is wrong in ways nobody can see.

Why any of this matters

It would be easy to read all of the above as plumbing. It isn't, for one reason.

An AI reasoning over your case file is only as good as the structure underneath it. Give a language model a folder of PDFs and it will do an impressive job of finding relevant-looking passages and a poor job of knowing what it missed. Give it a graph — where a motion knows its response, a response knows its exhibits, and a transcript citation reaches an actual line number — and it can do something different in kind: reason about the shape of an argument, not just its vocabulary.

That structure is also what makes verification possible. Every claim traces back to a document, a page, and often a line, because the system knew what it was indexing rather than just that it existed.

Which is the whole point. Not a machine that writes your brief. A machine that can tell you, quickly and specifically, what is wrong with the one you wrote — and show you exactly where it looked.

Sound Suite runs on your own hardware; documents are never uploaded. See Scope & the Haystack Block View for how the connections work in practice, or Version 110 in Four Days for what this looks like while actually drafting.