Contract memory outside the context window.

Repeated contract review wastes context on facts you already know.

A contract copilot should already know the current term, governing law, renewal window, and which clauses back each fact. Without that memory, every revision reloads the full document set, re-extracts facts that never changed, and flattens clause provenance into prompt text — so revisions overwrite prior interpretation instead of building on it, and reviewers lose the citation trail behind each answer.

Graph intelligence on ingest

Incoming data becomes queryable graph context.

Contract text arrives as MATTER and CLAUSE data at different times: a base FACT like governing_law on intake, then revised CLAUSE text like clause 8.2 on amendment. RushDB infers types on each write, auto-links CLAUSE records to their MATTER, and keeps prior clause revisions addressable instead of overwritten, so facts and the clauses that support them stay queryable together.

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.

{
  "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 schema. 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, schema, and focused retrieval path.

from rushdb import RushDB

db = RushDB('RUSHDB_API_KEY')

schema = db.ai.get_schema_markdown({'labels': ['MATTER', 'CLAUSE', 'FACT', 'REFERENCE']}).data
facts = db.records.find({'labels': ['FACT'], 'where': {'active': True, 'MATTER': {'matterId': 'matter-northstar-msa'}}, 'limit': 20})
clauses = db.ai.search({
    'labels': ['CLAUSE'],
    'propertyName': 'text',
    'query': 'renewal termination indemnity governing law',
    'where': {'MATTER': {'matterId': 'matter-northstar-msa'}},
    'limit': 20,
})

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.

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.