Building OpenClaw: How We Built an AI-Powered Legal Research Platform From Scratch

The Problem: Legal Research Is Broken

If you've ever tried to research case law, you know the pain. Westlaw charges thousands per month. Google Scholar's legal section is a graveyard of bad UX. And if you're a solo practitioner, a law student, or a startup founder trying to understand your legal landscape? You're out of luck.

That was the spark behind OpenClaw. We wanted to build a platform that made legal research as intuitive as searching Google — but powered by AI that actually understands legal language.

The Vision

OpenClaw wasn't just a search engine. The vision was a full ecosystem: ingest millions of court opinions, parse them into structured data, embed them into vector space, and let users query them in plain English. Ask a question like "Can a landlord evict a tenant during a pandemic in California?" and get back relevant case law, summarized and cited.

Simple to describe. Absolutely brutal to build.

Phase 1: Data Ingestion — The Hard Part Nobody Talks About

We started with the Court Listener API and bulk data dumps from the Free Law Project. That gave us access to roughly 8 million court opinions spanning federal and state courts from the 1700s to present day.

The problem? The data was a mess. Inconsistent formatting. Missing metadata. OCR artifacts from scanned documents that turned "Supreme Court" into "Suprerne Cort." HTML mixed with plain text mixed with PDF extractions that had line breaks in the middle of words.

We built a multi-stage cleaning pipeline:

• Stage 1: Format normalization — Strip HTML, fix encoding issues, normalize whitespace
• Stage 2: OCR correction — Custom regex patterns + a fine-tuned model to fix common OCR mistakes in legal text
• Stage 3: Metadata enrichment — Extract court name, date, judge, parties, and citation from unstructured headers
• Stage 4: Deduplication — Many opinions exist in multiple sources with slight variations. We built a fuzzy matching system using MinHash to identify and merge duplicates

This pipeline alone took six weeks. It processed 8.2 million documents, reduced to 6.7 million unique opinions, and output clean structured JSON ready for the next phase.

Phase 2: The Database Architecture

We needed a database that could handle full-text search across millions of documents, store vector embeddings for semantic search, and serve results in under 200ms. After evaluating the options, we landed on a hybrid approach:

• PostgreSQL with pgvector for storing embeddings alongside structured metadata
• Supabase as the managed Postgres layer — giving us auth, row-level security, and real-time subscriptions out of the box
• Redis for caching frequently accessed opinions and search results

The schema was deceptively simple on the surface: an opinions table, a courts table, a citations table for the citation graph, and an embeddings table with a vector column. But the indexes were where the complexity lived.

We built a GIN index on the full-text search column, an IVFFlat index on the vector column (later migrated to HNSW for better recall), and composite indexes on court + date for filtered searches. Getting the index tuning right was the difference between 2-second queries and 150ms queries.

Phase 3: Embeddings — Teaching AI to Read Law

This is where it got interesting. We needed to convert every court opinion into a vector embedding that captured its legal meaning — not just keywords, but concepts like "Fourth Amendment unreasonable search," "breach of fiduciary duty," or "force majeure in commercial contracts."

We started with OpenAI's text-embedding-ada-002 model. It worked, but it treated legal text the same as any other text. "Motion to dismiss for failure to state a claim" and "the case was thrown out" would get similar but not identical embeddings. For legal research, that gap matters.

So we fine-tuned. We used Ollama to run a local instance of Llama 2 and created a training dataset of 50,000 legal text pairs — semantically similar opinions that should be close in vector space, and dissimilar ones that should be far apart. We then fine-tuned a sentence transformer model on this dataset.

The results were dramatic. Retrieval accuracy on our test set jumped from 72% to 91%. The model finally understood that "respondeat superior" and "employer liability for employee actions" were the same concept.

Embedding 6.7 million documents took 11 days on a cluster of 4 GPU instances. We chunked each opinion into ~500 token segments with 50-token overlaps, generating roughly 40 million embedding vectors total.

Phase 4: The Search Engine

OpenClaw's search wasn't a single system — it was three systems working together:

1. Keyword search — Traditional full-text search using PostgreSQL's ts_vector and ts_query. Fast, precise, great for exact citations and case names.
2. Semantic search — Vector similarity search using our fine-tuned embeddings. The user types a question in plain English, we embed it, and find the nearest neighbors in vector space.
3. Hybrid reranking — We combined results from both systems using Reciprocal Rank Fusion (RRF), then passed the top 20 candidates through a cross-encoder reranker for final ordering.

The cross-encoder was the secret weapon. It took pairs of (query, document) and scored their relevance with much higher accuracy than either search method alone. It was slower — about 200ms for 20 candidates — but the quality improvement was worth it.

Phase 5: The AI Summarization Layer

Finding relevant cases was only half the battle. Court opinions are long. The average federal appellate opinion is 4,000+ words. Nobody wants to read 10 of those just to answer a simple question.

We built a summarization pipeline using a combination of Ollama (running Mistral 7B locally for development) and GPT-4 for production. The pipeline worked in stages:

1. Extract the holding — What did the court actually decide?
2. Extract the reasoning — Why did they decide that way?
3. Generate a plain-English summary — Explain it like the user isn't a lawyer
4. Pull key quotes — Direct quotes from the opinion that support the summary

We prompt-engineered extensively to prevent hallucination. Every summary included citations back to specific paragraphs in the source opinion. If the model couldn't find support for a claim in the actual text, it was instructed to say so rather than fabricate.

We cached every generated summary in Supabase so we'd never have to regenerate it. Over time, the platform built up a library of pre-computed summaries that made subsequent searches instant.

Phase 6: The Frontend

The frontend was built with Next.js 14 using the App Router, server components, and streaming. This wasn't a vanity choice — it was architecturally necessary.

When a user submits a search query, the results page uses server components to fetch the initial results on the server, sending fully-rendered HTML to the client. No loading spinners. No layout shift. The page arrives complete.

But the AI summaries stream in. We used React's Suspense boundaries with streaming server components to progressively render summaries as the AI generated them. The user sees the case list immediately, and summaries fade in one by one over the next 2-3 seconds.

The UI itself was deliberately minimal. A single search bar. Clean typography. No sidebar clutter. We studied how lawyers actually work — they scan, they skim, they need to move fast. Every pixel served that workflow.

Key technical decisions on the frontend:

• Emotion CSS-in-JS for scoped, themeable styles
• Optimistic UI updates for saving opinions to collections
• Keyboard navigation throughout — lawyers live on their keyboards
• Citation link detection — any citation like "Brown v. Board of Education, 347 U.S. 483 (1954)" automatically becomes a clickable link to that opinion

Phase 7: The Citation Graph

This was the feature that made legal professionals lose their minds.

We parsed every citation in every opinion and built a directed graph of which cases cite which other cases. 6.7 million nodes. 89 million edges. Stored in PostgreSQL with a self-referential join table and materialized views for common queries.

With this graph, users could:

• See every case that cites a given opinion (and how many times)
• Find the most-cited cases in a specific legal area
• Trace how a legal principle evolved over time through its citation chain
• Identify if a case has been overruled, distinguished, or questioned by later opinions

We visualized the citation graph using a force-directed layout rendered with WebGL. Zooming into a cluster of cases and seeing the citation relationships animate into view was genuinely beautiful — and genuinely useful.

Phase 8: Deployment and Infrastructure

The stack in production:

• Next.js deployed on Vercel with edge functions for the API layer
• Supabase (managed PostgreSQL + pgvector) on a dedicated instance with 64GB RAM
• Redis on Upstash for serverless caching
• Docker containers for the embedding pipeline and batch processing jobs, running on AWS ECS
• Ollama running on a dedicated GPU instance for local model inference during development and for fallback in production
• Stripe for subscription billing — free tier with 10 searches/day, pro tier with unlimited
• GitHub Actions for CI/CD with automated testing, linting, and preview deployments

Total monthly infrastructure cost at launch: approximately $2,400/month. For a platform serving millions of legal documents with AI-powered search and summarization, that felt like a steal.

The Results

OpenClaw launched in beta three months after we started building. Within the first month:

• 2,100 registered users
• 48,000 searches performed
• Average search-to-result time: 1.2 seconds (including AI summary)
• User satisfaction score: 4.7/5 from post-search surveys
• 142 paying subscribers on the pro tier

But the number that mattered most? Law students told us they were spending 60% less time on legal research. Solo practitioners said they could now do work that previously required a Westlaw subscription. A legal aid organization integrated our API to help provide free legal information to underserved communities.

What We Learned

Data quality is everything. We spent more time cleaning data than building features. That ratio felt wrong at the time, but it was the single most important investment we made. Garbage in, garbage out applies tenfold when AI is involved.

Hybrid search beats pure vector search. Semantic search is powerful, but it's not magic. Keywords still matter, especially in a domain as precise as law. The combination of keyword + semantic + reranking produced results that neither approach could achieve alone.

Streaming UX changes everything. The difference between a 3-second loading spinner and a page that progressively reveals content is enormous. Users perceived the streaming version as faster even when the total load time was identical.

Build for the workflow, not the technology. Every feature decision was filtered through one question: "Does this help a legal researcher find what they need faster?" If the answer was no — no matter how cool the tech — we cut it.

What's Next

We're currently building a conversational interface — a chat mode where users can have a back-and-forth dialogue with the AI about a legal topic, with every response grounded in actual case law. Think ChatGPT, but it can't hallucinate because every claim is traced back to a specific court opinion.

We're also expanding to international law, starting with UK and Canadian case law, and building an API so other legal tech companies can build on top of OpenClaw's search and summarization infrastructure.

The legal industry is one of the last sectors to be transformed by modern software. OpenClaw is our bet that AI, combined with thoughtful engineering and respect for the domain, can make justice more accessible to everyone.

Ready to build something fast?