Case study: legal RAG
Contract memory outside the context window.
Persist extracted facts and clause references after the first review, then assemble focused context for later revisions instead of rehydrating an entire matter blindly.
Repeated contract review wastes context on facts you already know.
A contract copilot should remember the current term, governing law, renewal window, and cited clauses. Sending the full matter back through every review makes later runs expensive and harder to explain.
Before
- Every review reloads the full document set
- Stable facts are extracted repeatedly
- Clause provenance gets flattened into prompt text
- Revisions overwrite prior interpretation
With RushDB
- Stable facts persist with supporting references
- Changed clauses are retrieved for focused review
- Ontology keeps query planning grounded in stored labels
- Application code measures assembled context size
Graph intelligence on ingest
Incoming data becomes queryable graph context.
RushDB turns structured data into graph-ready context without a separate modeling pipeline. Structure already encoded in a nested payload is linked immediately. For flat records imported from scattered sources, relationship analysis can propose stable cross-source patterns.
01
Normalize as data arrives
Import JSON or CSV. RushDB infers property types and adds new fields to the live, queryable ontology without a schema migration.
02
Auto-link nested structure
Nested objects become connected records automatically, preserving the parent-child graph structure already encoded in your payload.
03
Enrich scattered sources
After flat imports or schema changes, analyze the project ontology. RushDB can suggest join patterns and semantic relationship types for your review.
Suggested relationship analysis requires an LLM configured for the project. Suggestions stay in draft form until you approve them, so inferred domain meaning never mutates the graph silently. You can also add explicit relationships through the SDK or API.
Review suggested relationship patternsData model
One flexible graph for the workflow.
Start with the payload shape your product already produces. RushDB stores it as Records, infers typed properties, and keeps nested or approved domain relationships queryable.
Changed clauses, durable facts, and references stay separate so review prompts can stay focused and cited.
{
"matterId": "lease-2026",
"clientId": "northstar",
"DOCUMENT": [{
"documentId": "lease-v3",
"version": 3,
"CLAUSE": [{
"number": "8.2",
"changed": true,
"text": "Notice must be delivered 120 days before renewal.",
"FACT": [{ "key": "renewalNoticeDays", "value": "120" }],
"REFERENCE": [{ "page": 14, "sourceId": "lease-v3-p14" }]
}]
}]
}Working example
Review the revision, not the whole matter.
The first pass stores clause-linked facts. A later pass retrieves active facts plus changed clauses so the application can assemble a smaller, cited review prompt.
MATTER lease-2026
FACT governing_law: "New York"
FACT renewal_notice: "90 days"
CLAUSE 8.2 revision: 2
"Notice must be delivered 120 days before renewal."{
"labels": ["CLAUSE"],
"propertyName": "text",
"query": "What changed about renewal notice?",
"where": { "matter_id": "lease-2026", "changed": true }
}{
"existing_fact": "Renewal notice: 90 days",
"changed_clause": "Clause 8.2: Notice must be delivered 120 days before renewal.",
"review_action": "Supersede the active renewal-notice fact."
}Python SDK
Load ontology. Retrieve the delta. Assemble a cited prompt.
The token-footprint improvement is an application-level result to measure on your own prompt assembly. RushDB supplies the persisted facts, references, ontology, and focused retrieval path.
Implementation blueprint
Build the memoized legal RAG path.
Use this sequence to persist contract facts and retrieve focused deltas without sending an entire matter through every review run.
- 01Import MATTER, DOCUMENT, CLAUSE, FACT, and REFERENCE records
- 02Create a managed index for CLAUSE.text
- 03Extract durable facts with clause references
- 04Retrieve active facts plus changed clauses for each revision
- 05Measure prompt-size reduction in the application payload
Build path
- Keep stable facts separate from clause text and revisions.
- Preserve citation links from FACT records to supporting CLAUSE records.
- Supersede changed facts instead of mutating history away.
- Report token reduction only as a measured application-level result.
Relevant docs
Read the exact primitives behind this pattern.
These links point to the RushDB docs pages that map directly to this case study: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.
AI overview and ontology
Load live labels, fields, values, ranges, and relationships before an agent plans contract retrieval.
Open docsSemantic search
Retrieve clauses and memoized facts by meaning while filtering to a matter, revision, or changed clause set.
Open docsRelationships API
Link facts, clauses, references, revisions, and review memos for citation-preserving workflows.
Open docsHow it works
Build the smallest useful workflow first.
01
Extract durable facts once
Persist facts such as governing law, term length, and renewal notice with references to the supporting clauses.
02
Load ontology before retrieval
Give the agent the live labels and fields it can query instead of allowing guessed schema names.
03
Assemble focused context
Retrieve current facts, changed clauses, and supporting references, then measure the resulting prompt payload in application code.
Know where it fits.
Measure the token claim
Report context-size reduction from the application payload. Do not present it as a generic RushDB benchmark.
Preserve legal history
Append or supersede fact and clause revisions instead of mutating away prior review state.
Questions developers ask.
Next step