Case law that stays connected to what cites it.

Similar-sounding case law is not the same as controlling case law.

Flat semantic search over case text finds passages that sound relevant, but a researcher needs to know what happened after: was this holding cited approvingly, distinguished, or overturned by a later court? That answer lives in the citation graph connecting CASE records through CITES relationships, not in any single chunk of retrieved text, however similar it reads.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

Citation research arrives as CASE records nesting HOLDING text and CITES references to other cases and STATUTE sections. RushDB keeps that nested structure linked on import, so a CASE-to-CASE citation is a traversable relationship immediately, and suggested-relationship analysis can propose STATUTE links for cases imported flat from a docket feed.

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.

Data 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.

{
  "caseId": "doe-v-acme-2023",
  "jurisdiction": "9th Circuit",
  "decidedAt": "2023-08-02",
  "HOLDING": [{ "text": "Email notice satisfies the statute when actual receipt is shown." }],
  "CITES": [{ "caseId": "smith-v-jones-2019", "treatment": "distinguished" }]
}

Working example

Find the holding, then check what happened to it.

Semantic search finds the matching case. Graph traversal from that case surfaces later cases that cite, distinguish, or overturn its holding.

CASE smith-v-jones-2019
  jurisdiction: "9th Circuit"
  decidedAt: "2019-04-11"
  HOLDING: "Notice by email satisfies the statutory notice requirement."

CASE doe-v-acme-2023
  jurisdiction: "9th Circuit"
  decidedAt: "2023-08-02"
  CITES smith-v-jones-2019 treatment: "distinguished"

{
  "labels": ["CASE"],
  "propertyName": "holding_text",
  "query": "Does email notice satisfy statutory notice requirements?",
  "where": { "jurisdiction": "9th Circuit" },
  "limit": 10
}

{
  "matched_case": "smith-v-jones-2019",
  "holding": "Notice by email satisfies the statutory notice requirement.",
  "later_treatment": [
    { "case": "doe-v-acme-2023", "treatment": "distinguished", "decidedAt": "2023-08-02" }
  ]
}

TypeScript SDK

Load schema, search holdings, then follow the citation graph.

The search step finds the matching holding. The traversal step is what tells the researcher whether that holding still stands.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

schema = db.ai.get_schema_markdown({'labels': ['CASE', 'STATUTE', 'HOLDING']}).data

db.ai.indexes.create({'label': 'CASE', 'propertyName': 'holding_text'})

matches = db.ai.search({
    'labels': ['CASE'],
    'propertyName': 'holding_text',
    'query': 'Does email notice satisfy statutory notice requirements?',
    'where': {'jurisdiction': '9th Circuit'},
    'limit': 10,
})

later_treatment = db.records.find({
    'labels': ['CASE'],
    'where': {'CITES': {'caseId': matches.data[0]['caseId']}},
})

Implementation blueprint

Build the citation-graph research path.

Use this sequence to keep case law connected to its later treatment instead of returning isolated matching text.

Relevant docs

Read the exact primitives behind this pattern.

These links point to the RushDB docs pages that map directly to this blueprint: ingestion, labels, properties, values, SearchQuery, relationships, semantic search, MCP, or deployment.

How it works

Build the smallest useful workflow first.

Know where it fits.

Questions developers ask.