Academic research

Data Analysis — the full caselaw stack, for researchers

LawDiver maintains one of the most complete, queryable U.S. caselaw research stacks available commercially: more than 10 million federal and state court opinions (U.S. Supreme Court, federal courts of appeals, federal district courts, and the appellate and supreme courts of all fifty states.), a bidirectional citation graph, full-text and semantic indexes, AI analysis cards, and supporting statute and rules layers. We open that stack to qualified academic researchers — students, professors, nonprofit data scientists, and allied research teams — by running custom searches and returning structured results.

You bring the research question. We run it against the live databases and indexes — the same infrastructure that powers CaseDiver — and deliver tables, hit lists, samples, or aggregate statistics you can cite and reproduce. No Westlaw or Lexis license required. No need to stand up your own replica for a well-scoped study.

Who this is for

Qualified academic and public-interest researchers: law students and faculty, political science and computational social science labs, legal-tech dissertations, nonprofit data science teams, journalists with a research partnership, and similar projects that need real caselaw at scale rather than a toy sample.

Smaller, well-bounded searches are offered without cost to the researcher. Larger retrieval projects — bulk extracts, multi-pass pipelines, or heavy compute — are done at cost so we can keep the corpus healthy for everyone. Tell us the scope; we will tell you honestly which side of that line you are on.

What you can ask us to search

All 10 million opinions are available for sophisticated boolean and keyword search, as well as vector (semantic) search over case text. The most-cited one million cases are available for AI analysis queries — issue, holding, posture, disposition, and related analysis fields — including vector retrieval against those AI summaries. Citation-graph walks, name and reporter lookups, and statute/rule cross-indexes are in scope too.

Boolean & keyword search (full corpus)

Apache Lucene / OpenSearch over the entire 10 million-document full-text index (133 GB): AND / OR / NOT, exact phrases, and proximity connectors (same sentence, same paragraph, within n words), with BM25 ranking and field boosts across body, case name, and syllabus. If you can write it as a Westlaw-style boolean, we can almost certainly run it — see Search Connectors.

Vector search on case text (full corpus)

1024-dimension Qwen3-Embedding-8B embeddings over opinion body text, stored as pgvector halfvec and retrieved with binary-quantized HNSW (fast Hamming first pass, full-precision rerank). Ask for opinions that mean what your research question describes, even when the exact keywords never appear. All 10 million cases are in scope for vector retrieval on case text.

AI analysis queries (most-cited one million)

Model-authored issue, holding, procedural posture, disposition, and quotation extraction — with a dedicated vector set built from those analysis cards, not from raw opinion prose. AI analysis queries and analysis-vector search cover the one million most-cited opinions. That is how a natural-language legal question finds holdings written in the language of holdings, instead of drowning in procedural recitation.

Citation graph & authority analytics

78 million resolved opinion-to-opinion edges, traversable both ways: what a case cites, and everything that has cited it since. Underneath: 182 million in-text citations with character offsets and pin cites, plus 18 million reporter / parallel-cite rows. Ideal for network studies, treatment timelines, landmark detection, and “who cites whom” questions that keyword search cannot answer.

Name, citation, and party lookup

Dedicated search-store indexes: 15.5 million citation-index rows keyed on a normalized reporter key, and 10 million name-index rows with trigram fuzzy match on case and party names. Fast exact and near-exact resolution before a deeper corpus pass.

Qwen vectors — what they are and how we search with them

Every opinion (and every AI analysis card) in the LawDiver stack is also stored as a vector: a list of 1024 numbers that capture meaning, not just keywords. Those vectors are produced by Qwen3-Embedding-8B — an open-weights embedding model from Alibaba's Qwen family with eight billion parameters. “Qwen” is the model family; “Embedding-8B” is the specialized encoder that turns legal text into a point in 1024-dimensional space. Passages about the same legal idea land near each other even when the wording differs — “unlawful detainer” near “eviction for nonpayment of rent,” “qualified immunity” near “clearly established constitutional right.”

Think of each vector as a coordinate on a map with 1024 axes instead of two. You cannot plot that map on a screen, but the geometry still works: similar legal ideas sit close together; unrelated ones sit far apart. A short holding about summary judgment and a long appellate opinion that turns on summary judgment can still land in the same neighborhood, because the model encodes the doctrine, not the page count.

Why Qwen? Smaller embedding models are cheaper and blur distinctions that matter in law (for example, “dismissed with prejudice” versus “dismissed as moot”). Much larger models and much wider vectors buy only modest laboratory gains while exploding index size and latency at corpus scale. Eight billion parameters at 1024 dimensions is the accuracy-versus-speed point that lets us search the entire caselaw vector database on behalf of researchers without pretending a toy sample is enough.

What happens when you give us a search term

When a researcher sends a vector-search term — a legal question, a doctrine phrase, a hypothetical fact pattern, or a paragraph of analysis — we do not keyword-match that string against opinion text. We run it through the same Qwen embedding model that built the corpus. Qwen turns the search term into its own 1024-dimension vector. We then compare that query vector against the Qwen vector database for the case corpus (opinion-body vectors, AI-analysis vectors, or both, depending on how we construct the search with you).

Comparison uses cosine similarity: how aligned two arrows are in meaning-space, not how long each arrow is. Imagine two arrows drawn from the origin. If they point the same way, the angle between them is small and cosine is near 1 — a strong semantic match. If they point at right angles, cosine is near 0 — unrelated topics. If they point opposite ways, cosine goes negative. Length is ignored on purpose so a one-sentence research question can still match a fifty-page opinion about the same idea.

A concrete walkthrough: you send “May a municipality be liable under § 1983 for failure to train police officers when the need for training was obvious?” Keyword search might miss opinions that never say “failure to train” but discuss “deliberate indifference” and municipal policy. Vector search embeds your question, finds opinions whose vectors point nearly the same direction — often including City of Canton v. Harris-line cases and later applications — and ranks them by cosine. A hit at 0.82 is tightly aligned with your question; a hit at 0.55 may share the civil-rights neighborhood but not the training theory; a hit near 0.20 is noise for this study. Those numbers are what we put in your methods appendix.

Another example: a query about “whether a noncompete covenant is enforceable after an involuntary termination” can surface cases that talk about “restrictive covenants,” “reasonableness as to time and geography,” or “protectable business interest” — vocabulary the researcher did not type — because those phrases live near the same point in embedding space. Boolean search still matters when you need exact statutory language or a known reporter cite; vector search matters when the research question is conceptual and the corpus uses many phrasings for one idea.

Retrieval uses a fast binary HNSW first pass (a neighborhood index over compressed vectors), then a full-precision cosine rerank of the shortlist so the scores you see are real cosine results, not an opaque “relevance” badge.

We can report those cosine results back to the researcher for each hit — opinion identifier, case name, court, date, and the cosine similarity score against your query vector — so a methods section can say exactly how close each result was in embedding space. That audit trail is part of the deliverable, not an afterthought.

The same pipeline works against the entire database: all 10 million opinions for case-text vectors, and the one million most-cited opinions for AI-analysis vectors. Filters (court, year, jurisdiction, publication status, cite-count bands) can be applied before or after the cosine rank so you get semantic neighbors inside the slice your study actually needs.

Why this is beyond Westlaw, Lexis, or anything public

Commercial research platforms are built for lawyers looking up cases, not for data scientists who need reproducible, instrumented retrieval. Their public search boxes do not let you specify the embedding model, choose body versus analysis vector sets, set cosine thresholds, combine boolean pre-filters with semantic ranking, or export the similarity scores that drove the hit list. You get a ranked screen of cases — not a methods appendix.

LawDiver's data analysis service is different because we can granularly control exactly what is searched and how the search is constructed: which stores (Postgres tables, OpenSearch full-text, Qwen vector sets), which fields, which filters, which boolean skeleton, which vector set, which top-k, which cosine floor, and which joins across the citation graph. And we can provide in the results exactly what was done — the query text as embedded, the model (Qwen3-Embedding-8B), the dimension (1024), the stores touched, the filters applied, and the per-hit cosine (or boolean) scores — so another researcher could understand, critique, or replicate the procedure.

That combination — full-corpus Qwen vector search run for you, with cosine scores and a full methods dump — is simply not publicly available anywhere but here. Westlaw and Lexis do not offer it. Open scrapes and bulk dumps do not come with this retrieval stack already built and staffed. If your project needs meaning-based recall across millions of opinions with numbers you can publish, this is the service.

PostgreSQL tables researchers care about

The primary corpus lives in PostgreSQL (303 GB store of record). Representative tables and what they contain:

A separate Postgres search store holds cd_citation_index and cd_name_index for high-volume lookup without scanning the main corpus.

OpenSearch indexes

Other queries data scientists ask for

How it works

Email a short proposal: research affiliation, question, desired outputs (CSV, JSON, summary tables, sample opinions, per-hit cosine scores), and approximate scale. We scope the query against the live stores, run it, and return results with enough methodological detail for you to describe the search in a paper or dissertation appendix — including, for vector work, the Qwen model identity and the cosine similarity of each hit. Smaller searches: no cost. Larger retrieval projects: at cost, quoted up front.

Need a continuous feed or a replica inside your own environment instead? That is the Bulk Data product. This page is for research collaborations where LawDiver runs the queries for you.

Request a research search

Write [email protected] with your affiliation and research question. If it fits the academic / nonprofit bar and a bounded search, we will run it — and help you get further than a public keyword box ever could.

Back to home