◆Solutions — Legal

Legal isn’t a generic retrieval problem.

Most systems treat a legal corpus like any other pile of text. It isn’t. Lawyers search by exact terms, a single firm’s corpus holds a dozen distributions, a vague question has to resolve to precise jurisdictions, and decades of shifting document formats sit underneath it all, with an accuracy bar where a miss is malpractice. Below is a field log of problems we’ve actually worked through in this domain, and how we approached each one.

Talk to usRead the field log
Field logLegal domain
01
Sparse retrieval

Lawyers search by keyword. BM25 doesn’t know which keywords matter.

Term-awarelearned token weights, not raw statistics

Keyword search is non-negotiable in legal: practitioners type the exact terms of art they have in mind. But BM25 ranks tokens by raw corpus statistics, so it can’t tell that “judgement” carries far more legal weight than “judge,” despite near-identical co-occurrence.

So we built a supervised variant: learnt-BM25. Using the firm’s corpus plus synthetic relevance signal generated with GPT, we learn which tokens deserve weight instead of inheriting it from frequency alone. Keyword search that actually understands legal vocabulary.

Learned token weight · sparse
judgement0.94
judge0.28
remand0.88
reminder0.16
Similar co-occurrence statistics, very different legal weight. Illustrative weights.
02
Personalized search

One firm’s corpus is not one distribution.

+16%recall, from per-cluster pipelines

A firm hands us its whole corpus. But inside it, M&A agreements read nothing like employment disputes, and neither looks anything like a scanned exhibit or a cap table. Stretching one generic embedding model across all of them is mediocre at each.

So we auto-discover the sub-clusters in the firm’s data and tune the pipeline per cluster with PreciseSearch. The interesting part: the right component changes by cluster. Some clusters worked with vanilla text embeddings out of the box; others (scanned exhibits, or cap tables where the layout carries the meaning) needed a VLM to embed the page faithfully. Different components, assembled per cluster, instead of one bloated model trying to be everything.

Auto-discovered sub-corpora
text-embed
M&A agreements
Employment disputes
VLM
Scanned exhibits
Cap tables & schedules
Each cluster gets the component it needs: vanilla text embeddings where they suffice, a VLM where tables and figures matter.
03
Agentic retrieval

A vague query has to resolve to exact jurisdictions.

30% → 92%correct jurisdiction-code selection

The tools in the client’s harness were good; the agent orchestrating them was the problem. Given a vague legal request, it has to pick the right search tool, decide when to call it, and construct the structured arguments that go with it: jurisdiction, dates, document and case types. All of that sat in one overloaded prompt, so as the tool catalog grew, rules meant for one tool bled into the next, and every wrong call was met with another hand-written patch.

So we had AgentGrad write a skill file for each jurisdiction and tool. Each one carries both halves of the tool call: when to invoke the tool and how to orchestrate it in the workflow, and the detailed rules for the arguments to search within that jurisdiction. It tunes them from labeled failures and keeps only edits that generalize, so the rules stay separated, nothing hand-maintained rots, and a wrong call traces to one rule.

ca_courts_jurisdiction.skill.mdCalifornia
##Court hierarchySuperior Court — trial court · one per county (58)Courts of Appeal — six appellate districtsSupreme Court — discretionary review
##Civil money matters — which divisionSmall claimsindiv. ≤ $12,500 · entity ≤ $6,250Limited civil≤ $35,000 in controversyUnlimited civil> $35,000 in controversy
##Courts of Appeal — district by county1st San FranciscoAlameda, Marin, Napa, Sonoma…2nd Los AngelesLA, Ventura, Santa Barbara…6th San JoseMonterey, Santa Clara, Santa Cruz…
A slice of one AgentGrad skill file: the agent reads it before routing a query to the right jurisdiction.
04
Data preparation

Decades of drifting court formats break naïve chunking.

+10%retrieval, from reformatting before chunking

Court documents have changed shape enormously over the years. The usual debate is how to chunk (semantic vs. fixed token count), but that argument misses the real issue: the source structure itself is inconsistent.

Working with a client, we found that re-formatting each case into a single predefined structure first, then chunking along it, beat the chunking-strategy debate outright: a clean +10% retrieval from normalization alone.

Normalize, then chunk
No. 74-1042  ·  filed mar. 1974
IN THE MATTER OF ...
   opinion of the court, p.3
   see also dissent infra
[ headings vary case to case ]
normalize
## Caption
## Holding
## Facts
## Procedural History
## Disposition
Consistent structure across eras, then chunk along it → +10% retrieval.
What you own

The assets a competitor can’t replicate.

Across every engagement, what we deliver is yours: proprietary assets calibrated to your corpus, not a licensed configuration of someone else's APIs that a rival could buy off the same shelf.

◆Learnt-BM25 token-weight matrices — supervised sparse weights tuned to legal vocabulary.
◆Per-cluster dense + sparse adapters — one tuned pipeline per auto-discovered sub-corpus.
◆Auto-generated jurisdiction skill files — plus the tool-call harness the agent reads before research.
◆Document normalization pipeline — reformats drifting court formats into one chunkable structure.
Who we work with

Built for teams shipping legal AI to production.

Organizations

  • AmLaw 200 firms building in-house research tools
  • Corporate legal departments with ML capacity
  • Legal-tech companies shipping to their own customers

Roles

  • Heads of Legal Engineering
  • In-house ML teams owning the search stack
  • Product leads accountable for an accuracy KPI

Tell us your hardest legal-AI problem.

Keyword search that respects terms of art, a corpus with a dozen distributions, vague queries that must hit exact jurisdictions, a rule-application workflow that has to be verifiable: send us the one you're stuck on.

Writing behind the legal work.

From From the Field and Search That Works.

Search That Works
Component benchmarks lie. Tune the stack.

From a production legal-search engagement: a ten-point component lead all but disappeared in the stack that shipped.

9 min read · Jun 2026
Thesis
The stack is the product.

The anchor essay: why assembled stacks stall, and the end-to-end loop that fixes them.

11 min read · Aug 2026
Search That Works
vstackai-law-1: a best-in-class legal embedding model.

Top of the MTEB law leaderboard: a 32k context, multilingual coverage, and roughly 3x the accuracy per dollar of the nearest legal rival.

6 min read · Dec 2024