Skip to documentation
eli.aidocs

Use cases by industry

Use case: matter research

A litigator asking "what's on the docket for the Atlas deal?" needs today's deadline, the controlling precedent behind the memo, and an honest "I don't know" when a question is really a judgment call — not a confident guess with no case behind it. This guide builds that assistant end to end for a business law firm, threading seven module slices: Intake to ingest the matter files, Atlas to structure them into a graph, Warrant to certify the controlling authorities, Conduit to pull the live docket, Lens to answer with citations, Lineage to trace any answer back to its precedent, and Crucible to keep it accurate as matters move. Internal research only — not legal advice.

One knowledge base, seven slices. Certified authorities (Warrant) and the live matters database (Conduit) both feed the grounded answer; the dashed edge is the loop that keeps it honest — an abstention the golden set catches steers the next round of curation.

Follow along in the seeded workspace

Everything below runs against a real starter workspace. Seed it with yarn demo:seed legal and it appears as Marlowe & Finch LLP (Legal)— a mid-market firm with two flagship practices, its attorneys, clients, matters, controlling authorities, and a read-only matters database already wired in. The entity names, query slugs, and questions in this guide are that workspace's actual content. Browse the full catalogue in Demo workspaces.

Prerequisites

  • A workspace key with kb:write, kb:read, data:read, data:run, agents:run, and runs:read, exported as $ELI_KEY. See Getting started.
  • Owner/admin on the workspace, to certify authorities and verify documents.
  • An enabled chat model, so /query can generate — otherwise 409 no-model-configured.

1 · Intake — ingest the matter files

A firm's knowledge already exists as documents — the firm overview, the attorney roster, client files, matter memos, the Authorities Library, and the conflicts findings. In the seeded workspace these are markdown with explicit references such as [[Revlon v. MacAndrews]] and [[Atlas-Summit Acquisition]] for later graph enrichment. Post one the same way yarn demo:seed does — as a document:

POST/api/v1/documentsBearer · kb:write

Save markdown through the vault. The file, chunks, and full-text index commit before 201; embedding and graph enrichment continue as detached work, so the response contains stored-document metadata only.

Example requestbash
curl -s -X POST https://your-host/api/v1/documents \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "path": "matters/atlas-summit-acquisition.md",
    "title": "Matter — Atlas-Summit Acquisition",
    "content": "# [[Atlas-Summit Acquisition]]\n\nLead [[Vivian Marlowe]], execution [[Priya Anand]]. Client [[Atlas Robotics]] is acquiring [[Summit Automation]] under the [[Delaware General Corporation Law]]. Controlling authorities: [[Revlon v. MacAndrews]], [[Unocal v. Mesa]]."
  }'
Responsejson
{ "docId": "01KY11MATTER0000000000000A", "path": "matters/atlas-summit-acquisition.md", "contentHash": "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824", "title": "Matter — Atlas-Summit Acquisition" }

At 201, the matter is stored and FTS-searchable. As detached enrichment completes, Atlas can build the concept graph — attorneys, clients, matters, practice areas, and authorities linked by extracted evidence. The whole firm arrives at once with yarn demo:seed legal; posting documents by hand is how you extend it.

2 · Atlas — type the firm into a graph

Text alone is a pile of pages; a graph is navigable. This workspace's ontology types every node — Attorney, Client, Matter, PracticeArea, Authority, and Rule — connected by relations like represents, cites, and in_practice_area. List the matters to find the one you care about:

GET/api/v1/entities?type=MatterBearer · kb:read

List canonical entities of a type, highest-PageRank first. The ontology makes retrieval structured, not just full-text — you can ask for every Matter, Authority, or Attorney by type.

Example requestbash
curl -s "https://your-host/api/v1/entities?type=Matter&limit=5" \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "entities": [
    { "id": "01KZMATTERATLAS000000000A", "name": "Atlas-Summit Acquisition", "type": "Matter", "pagerank": 0.041 },
    { "id": "01KZMATTERHARB000000000AB", "name": "Harborline v. Coastal Terminals", "type": "Matter", "pagerank": 0.038 }
  ],
  "total": 2
}

Now expand the frontier around the Atlas-Summit matter to see exactly what it touches — its lead attorney, its client, its practice area, and the controlling authorities it cites:

GET/api/v1/entities/{id}/neighborhoodBearer · kb:read

The knowledge-graph frontier around one entity — canonical relations in both directions. This is the structured backbone Lens retrieves against and Lineage walks.

Example requestbash
curl -s https://your-host/api/v1/entities/01KZMATTERATLAS000000000A/neighborhood \
  -H "Authorization: Bearer $ELI_KEY" | jq '.edges[] | {rel: .type, to: .dstName}'
Responsejson
{
  "entity": { "id": "01KZMATTERATLAS000000000A", "name": "Atlas-Summit Acquisition", "type": "Matter" },
  "edges": [
    { "type": "in_practice_area", "dstName": "Mergers & Acquisitions" },
    { "type": "cites", "dstName": "Revlon v. MacAndrews" },
    { "type": "cites", "dstName": "Unocal v. Mesa" }
  ]
}

3 · Warrant — certify the controlling authority

Extraction gives you an Authority node named Revlon v. MacAndrews at authority machine_extracted — a starting point, not something an attorney will rely on. In Warrant, pin its holding as a reviewable change, then certify it — certified is the only tier the assistant states without hedging:

POST/api/v1/change-requestsBearer · kb:write

Propose the canonical holding as a reviewable change rather than editing silently. Approval promotes authority to at least curated and records the reviewer on the append-only revision.

Example requestbash
curl -s -X POST https://your-host/api/v1/change-requests \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "update",
    "entityId": "01KZREVLON00000000000000A",
    "payload": { "description": "Revlon v. MacAndrews: once a board pursues a sale of control, enhanced scrutiny attaches and directors must maximize immediate stockholder value." },
    "note": "Locking the Revlon holding the Atlas-Summit memo cites"
  }'
Responsejson
{ "id": "01KZCR00000000000000000AA", "entityId": "01KZREVLON00000000000000A", "kind": "update", "status": "open" }
POST/api/v1/entities/{id}/certifyBearer · kb:write

Owner/admin sign-off — authority certified. Also starts the review clock: nextReviewAt lands at now + the workspace's reviewIntervalDays, so a controlling authority can't quietly go stale.

Example requestbash
curl -s -X POST https://your-host/api/v1/entities/01KZREVLON00000000000000A/certify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"note": "Signed off by Sofia Bello (research) and Dana Okoro (GC)"}'
Responsejson
{ "authority": "certified", "lifecycleStatus": "published", "version": 2, "nextReviewAt": "2027-01-19T09:10:00.000Z" }

Do the same for the source document — verify the Authorities Library so its provenance carries a governance tier that Lineage will report:

POST/api/v1/documents/{id}/verifyBearer · kb:write

Glean-style document verification. Stamps the verification tier, the verifier, and the next re-verify date — the governance block Lineage reports and the manifest counts.

Example requestbash
curl -s -X POST https://your-host/api/v1/documents/01KY10AAAAAAAAAAAAAAAAAAAA/verify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"verification":"certified","note":"Authorities Library reviewed by Sofia Bello"}'
Responsejson
{ "id": "01KY10AAAAAAAAAAAAAAAAAAAA", "verification": "certified", "verifiedAt": "2026-07-22T09:12:00.000Z", "nextVerifyAt": "2026-12-29T00:00:00.000Z" }

Certification is what lets the policy answer

Because Revlon is certified, the question "What authority governs board duties in a change-of-control sale?" clears the answer floor — the seeded policy decision is answer at 0.81 confidence (confidence_above_answer_floor). An uncertified or missing authority is exactly what makes the policy hedge or abstain in the next slice. Curate in the UI too: the Curation page shows the open change-request queue and a certify button per authority.

4 · Conduit — pull the live docket

"What's on the docket for the Atlas deal?" can't be answered from a memo — deadlines move. The seeded workspace wires the firm's matter-management system in as a read-only Conduit connector, marlowe-finch-mms (Postgres), exposing a handful of governed named queries — no free-form SQL. List them, then run one; every execution writes an append-only data_calls row and returns a dataCallId, the [Dn] provenance anchor:

GET/api/v1/data/queriesBearer · data:read

List named queries (domain components) available to run, with their parameter specs. Secrets never appear — you see slugs, titles, and params.

Example requestbash
curl -s https://your-host/api/v1/data/queries \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "queries": [
    { "slug": "hours-and-fees-by-matter", "title": "Billable hours and fees by matter", "connectorName": "marlowe-finch-mms", "params": [] },
    { "slug": "matters-in-practice-area", "title": "Open matters in a practice area", "connectorName": "marlowe-finch-mms", "params": [ { "name": "practice_area", "type": "string", "required": true } ] },
    { "slug": "upcoming-deadlines", "title": "Upcoming docket deadlines for a matter", "connectorName": "marlowe-finch-mms", "params": [ { "name": "matter", "type": "string", "required": true }, { "name": "days", "type": "number", "required": true } ] }
  ]
}
POST/api/v1/data/queries/{slug}/runBearer · data:run

Execute a named query with validated params. Read-only, row-capped (maxRows 200), timed, and provenance-logged. Params are bound, never interpolated — this is why the docket can't become a SQL-injection target.

Example requestbash
curl -s -X POST https://your-host/api/v1/data/queries/upcoming-deadlines/run \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"params":{"matter":"Atlas-Summit Acquisition","days":30}}'
Responsejson
{
  "dataCallId": "01KY10CCCCCCCCCCCCCCCCCCCC",
  "connectorName": "marlowe-finch-mms",
  "queryTitle": "Upcoming docket deadlines for a matter",
  "columns": ["matter", "title", "deadline_type", "due_date"],
  "rows": [
    { "matter": "Atlas-Summit Acquisition", "title": "Board approval of merger agreement", "deadline_type": "closing", "due_date": "2026-08-03" },
    { "matter": "Atlas-Summit Acquisition", "title": "HSR waiting period expires", "deadline_type": "regulatory", "due_date": "2026-08-11" }
  ],
  "rowCount": 2,
  "truncated": false,
  "durationMs": 47,
  "executedAt": "2026-07-22T09:15:00.000Z"
}

Authoring the queries is a UI job, on purpose

The upcoming-deadlines query is bound onto the Atlas-Summit Acquisition entity with days fixed at 30 and matter filled from the model — so an attorney never writes SQL, they ask a question. Authoring connectors and their SQL is an owner/admin task in the Data page; the API only consumes the governed surface. See Query live data.

5 · Lens — the attorney asks, and gets a cited answer

Now the payoff. An attorney asks in plain language; Lens retrieves against the graph, grounds the answer, and returns inline [Sn] citations, an atomic claimsbreakdown, and a policy decision that says how much to trust it. Ask one of the workspace's golden questions verbatim:

POST/api/v1/queryBearer · agents:run

Run the grounded query pipeline: retrieval + entity detection + one generation + a groundedness check + the answer-policy engine. Returns a cited answer with a policy decision. The workspace comes from the key.

Example requestbash
curl -s -X POST https://your-host/api/v1/query \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"question":"What authority establishes enhanced scrutiny of board duties in a sale of control?"}'
Responsejson
{
  "answer": "Enhanced scrutiny of board fiduciary duties in a sale of control is established by Revlon v. MacAndrews [S1]; the Atlas-Summit Acquisition memo analyzes the board's duties under it [S2].",
  "claims": [
    { "text": "Revlon v. MacAndrews establishes enhanced scrutiny in a sale of control", "citations": ["S1"] },
    { "text": "The Atlas-Summit board's duties are analyzed under Revlon", "citations": ["S2"] }
  ],
  "sources": [
    { "id": "S1", "docId": "01KY10AAAAAAAAAAAAAAAAAAAA", "docTitle": "Authorities Library", "docPath": "authorities/key-precedents.md", "chunkId": "01KY10BBBBBBBBBBBBBBBBBBBB" },
    { "id": "S2", "docId": "01KY11MATTER0000000000000A", "docTitle": "Matter — Atlas-Summit Acquisition", "docPath": "matters/atlas-summit-acquisition.md" }
  ],
  "entities": [
    { "id": "01KZREVLON00000000000000A", "name": "Revlon v. MacAndrews", "type": "Authority", "authority": "certified" },
    { "id": "01KZMATTERATLAS000000000A", "name": "Atlas-Summit Acquisition", "type": "Matter" }
  ],
  "policy": { "decision": "answer", "confidence": 0.81, "reason": "confidence_above_answer_floor" },
  "groundedness": { "verified": 2, "total": 2 },
  "model": { "chat": "claude-sonnet-4-5", "judge": "claude-haiku-4-5" }
}

The policy block is the trust signal: answer at 0.81because the proposition is backed by a certified authority. The firm's rule — cite a controlling authority for every legal proposition, or abstain — is enforced by the policy engine, not by hoping the model behaves. Ask a judgment call instead — "Should Harborline accept a $2M settlement?" — and the seeded decision is abstain_with_pointers at 0.13, reasons no_relevant_chunks and requires_attorney_judgment: no citable authority, so it routes to a licensed attorney rather than inventing an answer. The same pipeline is a native MCP tool, so it drops straight into an attorney's Claude. Internal research only — not legal advice.

6 · Lineage — trace the answer to its authority

A partner reviewing the assistant asks the fair question: where is this coming from, and can I trust it? The answer cited S1 → docId 01KY10…, the Authorities Library. Pull that document's lineage and read the whole trail in one call — origin, governance, and the answers it is grounding right now:

GET/api/v1/documents/{id}/lineageBearer · kb:read or runs:read

The unified per-document lineage trail: origin provenance, governance, the audit trail, derived knowledge, and downstream impact. This is how you prove an answer's pedigree end to end.

Example requestbash
curl -s https://your-host/api/v1/documents/01KY10AAAAAAAAAAAAAAAAAAAA/lineage \
  -H "Authorization: Bearer $ELI_KEY" | jq '{origin: .origin, verification: .governance.verification, citedBy: .downstream.citedByAnswers}'
Responsejson
{
  "origin": {
    "kind": "upload",
    "docTitle": "Authorities Library",
    "docPath": "authorities/key-precedents.md",
    "ingestedAt": "2026-07-22T09:05:12.004Z"
  },
  "verification": "certified",
  "citedBy": 6
}

There it is, closed loop: the answer traces to the Authorities Library memo (authorities/key-precedents.md), the document is certified, and it is currently grounding 6answers — so an edit to it has a known blast radius. The partner didn't have to trust the model; they read the pedigree. The full trail also lists the derived authorities (Revlon, Unocal, Twombly) and the dependent cache entries that would invalidate if the library changed.

Same trail, three surfaces

The workspace UI renders this exact DocumentLineage as a visual trail on the document page (via the BFF at GET /api/w/{workspaceId}/documents/{docId}/lineage), and the Matter Research Assistant can pull it mid-run with the kb_document_lineage MCP tool. One shape, three surfaces.

7 · Crucible — lock the accuracy in

Matters move, authorities get re-reviewed, and a wrong citation in front of a partner is expensive. The seeded workspace ships a golden set of the questions attorneys actually ask — "Which attorney leads the Atlas-Summit Acquisition?", "What authority establishes enhanced scrutiny of board duties in a sale of control?", "Which practice area handles Harborline v. Coastal Terminals?" — so Crucible can prove the assistant still answers them after every change. Anchor a golden item to the Authorities Library chunk that should ground it:

POST/api/v1/qrelsBearer · kb:write

Author a graded relevance judgment for a golden item. source=provenance derives the highest-grade judgment from the item's anchored citation — deterministic, no judge model needed.

Example requestbash
curl -s -X POST https://your-host/api/v1/qrels \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "queryId": "01KZGOLDEN000000000000000",
    "chunkId": "01KY10BBBBBBBBBBBBBBBBBBBB",
    "docId": "01KY10AAAAAAAAAAAAAAAAAAAA",
    "grade": 3,
    "source": "provenance"
  }'
Responsejson
{ "id": "01KZQREL0000000000000000A", "queryId": "01KZGOLDEN000000000000000", "grade": 3, "source": "provenance" }

Run the Matter research Q&A baseline config from the evals workspace, then read the metrics for the run. Retrieval and abstention numbers are deterministic; RAGAS numbers carry the judge model that produced them:

GET/api/v1/evals/runs/{id}/metricsBearer · kb:read or runs:read

Retrieval, RAGAS, and abstention metrics for one run — overall and by facet. Abstention truthfulness is the legal ruler: does the assistant correctly decline the settlement question, and correctly answer the Revlon one?

Example requestbash
curl -s https://your-host/api/v1/evals/runs/01KZRUNA00000000000000000/metrics \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "runId": "01KZRUNA00000000000000000",
  "n": 24,
  "retrieval": { "recallAtK": 0.79, "ndcgAt10": 0.74, "mrr": 0.82, "hitAtK": 0.94 },
  "ragas": { "faithfulness": 0.92, "responseRelevancy": 0.85, "contextPrecision": 0.68 },
  "abstention": { "truthfulness": 0.71, "abstainRate": 0.17, "aurc": 0.061 }
}

The same golden set gates the Matter Research Assistant (agent matter-research) that ships with the workspace — its cited-or-abstain behavior is exactly what these metrics measure. When a re-review demotes an authority and an answer regresses, the golden set names the question that broke; promoting that miss back into the set turns it into a permanent test. That is the dashed loop in the diagram: Crucible's abstentions steer the next round of Warrant curation. And when a new matter trips the conflicts screen, the workspace raises a conflict.flagalert — "escalate to Dana Okoro under ABA Model Rule 1.7" — rather than answering around it. Compare two configs behind a two-gate significance test in Measure & compare.

The leverage

Seven slices, one knowledge base, one audit trail. The attorney gets a fast, cited answer and a live docket; the partner can trace any answer to a certified authority and see its blast radius; the policy engine declines the questions that need a licensed judgment instead of guessing; and the whole thing is measured, so accuracy is a number you watch rather than a hope. Swap "matter research" for wealth management, clinical protocols, or incident response and the shape is identical — the platform doesn't care what the documents are about, only that every answer is grounded, governed, traceable, and measured. Internal research only, reviewed by a licensed attorney — not legal advice.

Keep going

Seed it yourself with yarn demo:seed legal and browse the other starters in Demo workspaces, see the sibling walkthroughs Sales enablement and Automated reports, or take in the whole platform at a glance in the Capability map.