Skip to documentation
eli.aidocs

Use cases by industry

Use case: claims operations

A claims operation runs on facts that have to be right: which treaty backs a catastrophe loss, who is drowning in open files this week, and whether the Homeowners line just blew through its loss-ratio target. This guide builds that assistant for Sentinel Mutual Insurance— a policyholder-owned property & casualty (P&C) insurer — end to end, touching seven module slices: Intake to ingest the claim files, Atlas to type the graph, Warrant to certify the reinsurance terms, Conduit to read the live claims database, Lens to answer with citations (or abstain), Lineage to trace any answer to its file, and Crucible & Ports to run the analyst agent against a measured golden set.

One claims knowledge base, seven slices. Both the certified treaty terms (Warrant) and the live claims numbers (Conduit) feed the answer; the dashed edge is the loop that keeps it honest — a regression the golden set catches steers the next round of curation.

Seed this workspace and follow along

Everything below runs against a real, pre-loaded workspace. Run yarn demo:seed insurance and it appears as Sentinel Mutual Insurance (P&C) — adjusters, underwriters, coverage lines, policies, claims, and reinsurance treaties, densely wikilinked so the graph populates with zero LLM calls. Every identifier in this guide (entity names, the sentinel-cms connector, the query slugs, the claims-analyst agent) is what you will actually see. Browse the full catalog at 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 treaty terms and verify source documents.
  • An enabled chat model, so /query and the agent can generate — otherwise 409 no-model-configured.

1 · Intake — ingest the claim files

The seed already loaded Sentinel's corpus — the company overview, the team roster, one document per coverage line, the two reinsurance treaties, the policy-admin and claims systems, and the open claim files (CL-4471, CL-5238, CL-6012). New material arrives the same way it did: as markdown documents with explicit names and links that later enrichment can reconcile into entities. Post a fresh first-notice-of-loss note; its storage response arrives before that graph work:

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": "claims/cl-4471-hail-damage.md",
    "title": "Claim CL-4471 — Hail Damage",
    "content": "# [[Claim CL-4471]]\n\nFiled against [[Policy HO-88213]] on the [[Homeowners Line]]; adjusted by [[Trevor Osei]]. Roof and siding hail damage from the Q2 storm, counting toward the [[Property Catastrophe Excess-of-Loss Treaty]] aggregate."
  }'
Responsejson
{
  "docId": "01KZDOCFNOL000000000000000",
  "path": "claims/cl-4471-hail-damage.md",
  "contentHash": "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824",
  "title": "Claim CL-4471 — Hail Damage"
}

At 201, the claim note is durably searchable through FTS. Atlas extracts and reconciles entities later as detached enrichment; the create payload does not claim that work is complete. The live claims database comes later, in Conduit; here we are building the governed record of what each file says.

2 · Atlas — type the claims graph

Free text is not enough for claims work — you need to know that CL-4471 is a Claim filed against a Policy, handled by an Adjuster, on a CoverageLine that cedes to a ReinsuranceTreaty. Sentinel's ontology defines exactly those six entity types — Adjuster, Underwriter, CoverageLine, Policy, Claim, ReinsuranceTreaty — plus four relation types: adjusts, underwrites, filed_against, and ceded_to. Retrieval reasons over that structure, not just the prose. Expand the neighborhood around the Homeowners Line to see the typed edges the seed built:

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

The knowledge-graph frontier around one entity: its card plus typed edges out to depth hops. This is the structured backbone that grounds retrieval and powers Conduit's entity-bound live queries.

Query parameters

depthintegerHops to expand, 1–3. Default 1.
Example requestbash
curl -s "https://your-host/api/v1/entities/01KZHOMELINE00000000000000/neighborhood?depth=1" \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "entity": { "id": "01KZHOMELINE00000000000000", "name": "Homeowners Line", "type": "CoverageLine" },
  "nodes": [
    { "id": "01KZADJTREVOR00000000000000", "name": "Trevor Osei", "type": "Adjuster" },
    { "id": "01KZUWHELENA000000000000000", "name": "Helena Bjork", "type": "Underwriter" },
    { "id": "01KZCATXOLTREATY0000000000", "name": "Property Catastrophe Excess-of-Loss Treaty", "type": "ReinsuranceTreaty" }
  ],
  "edges": [
    { "srcEntityId": "01KZADJTREVOR00000000000000", "dstEntityId": "01KZCLAIM4471000000000000", "type": "adjusts" },
    { "srcEntityId": "01KZUWHELENA000000000000000", "dstEntityId": "01KZHOMELINE00000000000000", "type": "underwrites" },
    { "srcEntityId": "01KZHOMELINE00000000000000", "dstEntityId": "01KZCATXOLTREATY0000000000", "type": "ceded_to" }
  ],
  "truncated": false
}

The graph is the join key

Because Homeowners Line ceded_to the Property Catastrophe Excess-of-Loss Treaty is a typed edge, an answer about a hail loss can walk straight from the claim to the treaty that backs it — no keyword luck required. Manage types and edges by hand or let extraction fill them in; see Manage entities.

3 · Warrant — certify the treaty terms

The single most consequential fact in this workspace is where the catastrophe protection attaches. Extraction gives you the Property Catastrophe Excess-of-Loss Treaty at authority machine_extracted — fine for search, not something an analyst should quote in a reserving call. In Warrant, pin its terms as a reviewable change, then certify it — certified is the only tier the answer policy states without hedging:

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

Propose the canonical treaty terms as a reviewable change rather than editing silently. Approval promotes authority to at least curated and records the reviewer on the 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": "01KZCATXOLTREATY0000000000",
    "payload": { "description": "Per-occurrence excess-of-loss treaty; attaches at $10M per occurrence; protects the Homeowners and Commercial Property lines against catastrophe accumulation. Placed by Omar Farah." },
    "note": "Locking the CAT XoL attachment point the reserving team quotes"
  }'
Responsejson
{ "id": "01KZCRCATXOL00000000000000", "entityId": "01KZCATXOLTREATY0000000000", "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 treaty term can't quietly go stale between placements.

Example requestbash
curl -s -X POST https://your-host/api/v1/entities/01KZCATXOLTREATY0000000000/certify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"note": "Attachment confirmed against the placement slip by Omar Farah (Chief Actuary)"}'
Responsejson
{ "authority": "certified", "lifecycleStatus": "published", "version": 3, "nextReviewAt": "2027-01-18T09:10:00.000Z" }

Do the same for the source document — verify the treaty write-up so its provenance carries a governance tier that Lineage reports and the manifest counts:

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.

Example requestbash
curl -s -X POST https://your-host/api/v1/documents/01KZDOCCATXOL0000000000000/verify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"verification":"certified","note":"Current placement year; matches the signed slip"}'
Responsejson
{ "id": "01KZDOCCATXOL0000000000000", "verification": "certified", "verifiedAt": "2026-07-22T09:12:00.000Z", "nextVerifyAt": "2026-12-29T00:00:00.000Z" }

Certification is what lets the policy answer plainly

Certifying the treaty is not paperwork — it moves the evidence tier the answer policy sees. When a reader asks a supported question in Lens, the verdict comes back answer with the reason confidence_above_answer_floor precisely because the grounding source is certified rather than machine-extracted. Curate all of this in the UI too — the Curation page writes the same append-only revisions.

4 · Conduit — read the live claims database

The documents tell you what each file says; the numbers live in the claims system. Sentinel exposes a read-only Conduit connector named sentinel-cms (Postgres) with three governed named queries bound onto entities: open-claims-by-line (bound to Claims Management System), loss-ratio-by-line (bound to Homeowners Line), and adjuster-workload (bound to Marcus Del Rio). List them, then run one — every execution is row-capped, timed, and writes an append-only data_calls row that hands back a dataCallId, the [Dn] provenance anchor you can cite:

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

List named queries (domain components) available to run, with their parameter specs. Credentials and connection configs are never returned.

Example requestbash
curl -s https://your-host/api/v1/data/queries \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "queries": [
    { "slug": "open-claims-by-line", "title": "Open claims by coverage line", "connectorName": "sentinel-cms", "params": [] },
    { "slug": "loss-ratio-by-line", "title": "Loss ratio for a coverage line", "connectorName": "sentinel-cms", "params": [ { "name": "line", "type": "string", "required": true, "description": "Coverage line, e.g. Homeowners" } ] },
    { "slug": "adjuster-workload", "title": "Adjuster workload", "connectorName": "sentinel-cms", "params": [] }
  ]
}
POST/api/v1/data/queries/{slug}/runBearer · data:run

Execute a named query with validated params. Read-only, row-capped at the connector's maxRows, timed, and provenance-logged. Params are bound, never interpolated. Returns a dataCallId — the [Dn] provenance anchor.

Example requestbash
curl -s -X POST https://your-host/api/v1/data/queries/open-claims-by-line/run \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"params":{}}'
Responsejson
{
  "dataCallId": "01KZDATACALLOPEN0000000000",
  "connectorName": "sentinel-cms",
  "queryTitle": "Open claims by coverage line",
  "columns": ["coverage_line", "open_claims", "total_reserves_usd"],
  "rows": [
    { "coverage_line": "Homeowners", "open_claims": 37, "total_reserves_usd": 2410500.00 },
    { "coverage_line": "Commercial Property", "open_claims": 9, "total_reserves_usd": 1875000.00 },
    { "coverage_line": "Personal Auto", "open_claims": 24, "total_reserves_usd": 612300.00 }
  ],
  "rowCount": 3,
  "truncated": false,
  "durationMs": 44,
  "executedAt": "2026-07-22T09:14:03.412Z"
}

That is Marcus Del Rio's morning view — open reserves by line, largest first — as a live, cited number instead of a month-late spreadsheet. Run loss-ratio-by-line with {"params":{"line":"Homeowners"}} and the same connector returns the incurred losses over earned premium; when it crosses 75%, the workspace raises a loss_ratio.breachalert ("Homeowners Line loss ratio exceeded the 75% underwriting threshold this quarter") so a breach is caught the day it happens, not at quarter-end. Full mechanics in Query live data.

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

Now the payoff. An analyst asks in plain language; Lens retrieves, grounds, and returns an answer with inline [Sn] citations, an atomic claimsbreakdown, and a policy decision that says how much to trust it. Ask one of Sentinel's golden questions — the treaty behind a Homeowners catastrophe loss — and because the treaty is certified, the policy answers plainly:

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":"Which reinsurance treaty covers catastrophe losses on the Homeowners line?"}'
Responsejson
{
  "answer": "Catastrophe losses on the Homeowners line are ceded to the Property Catastrophe Excess-of-Loss Treaty, which attaches at $10M per occurrence [S1].",
  "claims": [
    { "text": "Homeowners catastrophe losses cede to the Property Catastrophe Excess-of-Loss Treaty", "citations": ["S1"] },
    { "text": "The treaty attaches at $10M per occurrence", "citations": ["S1"] }
  ],
  "sources": [
    { "id": "S1", "docId": "01KZDOCCATXOL0000000000000", "docTitle": "Reinsurance — Property Catastrophe XoL Treaty", "docPath": "reinsurance/property-cat-xol-treaty.md", "chunkId": "01KZCHUNKCATXOL00000000000" }
  ],
  "entities": [ { "id": "01KZCATXOLTREATY0000000000", "name": "Property Catastrophe Excess-of-Loss Treaty", "type": "ReinsuranceTreaty", "authority": "certified" } ],
  "policy": { "decision": "answer", "confidence": "high", "reasons": ["confidence_above_answer_floor"] },
  "groundedness": { "verified": 2, "total": 2 },
  "model": { "chat": "claude-sonnet-4-5", "judge": "claude-haiku-4-5" }
}

Fuse the semantic and data layers in one call. Ask a reserving question with includeData: true and the detected Homeowners Lineentity's bound query runs as a governed [Dn] lookup alongside the document [Sn] citation:

POST/api/v1/queryBearer · agents:run

Grounded answer fusing documents and live data: detected entities' bound queries run as governed [Dn] lookups next to document [Sn] citations. The policy verdict reflects the seeded post-stage decision for this question.

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 is the open-claims reserve on the Homeowners line?","includeData":true}'
Responsejson
{
  "answer": "The Homeowners line has 37 open claims with $2.41M in total case reserves [D1], the largest open reserve of any line [S1].",
  "claims": [
    { "text": "Homeowners has 37 open claims totaling $2.41M in reserves", "citations": ["D1"] },
    { "text": "It is the largest open reserve of any line", "citations": ["D1", "S1"] }
  ],
  "dataCalls": [ { "id": "D1", "dataCallId": "01KZDATACALLOPEN0000000000", "queryTitle": "Open claims by coverage line", "executedAt": "2026-07-22T09:14:03.412Z" } ],
  "sources": [ { "id": "S1", "docId": "01KZDOCHOMELINE00000000000", "docTitle": "Coverage Line — Homeowners", "docPath": "coverage-lines/homeowners-line.md" } ],
  "policy": { "decision": "answer", "confidence": 0.8, "reasons": ["confidence_above_answer_floor"] }
}

The policy abstains rather than bluffs

Sentinel's answer policy is tuned to claims risk. Ask a speculative question — "Will there be a hurricane this hail season?" — and the pre-stage verdict is abstain_with_pointers (confidence 0.1, reason no_relevant_chunks): no guessing about future catastrophes. Ask a coverage question the file only partly supports — "Is claim CL-6012 covered under Policy CP-77420?" — and it comes back answer_with_caveat (0.42, confidence_in_caveat_band), surfacing the facts and routing the actual coverage decision to the adjuster of record. That is the abstain-first behavior claims work demands.

6 · Lineage — trace the answer to its file

A reserving reviewer asks the fair question: where is this treaty term coming from, and can I trust it? The golden answer cited S1 → docId 01KZDOCCATXOL…. Pull that document's lineage and read the whole trail in one call — origin, governance, and the downstream 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/01KZDOCCATXOL0000000000000/lineage \
  -H "Authorization: Bearer $ELI_KEY" | jq '{origin: .origin, verification: .governance.verification, citedBy: .downstream.citedByAnswers}'
Responsejson
{
  "origin": {
    "kind": "upload",
    "path": "reinsurance/property-cat-xol-treaty.md",
    "ingestedAt": "2026-07-22T08:41:12.008Z"
  },
  "verification": "certified",
  "citedBy": 6
}

There it is, closed loop: the answer traces to reinsurance/property-cat-xol-treaty.md, the document is certified (from step 3), and it is currently grounding 6answers — so an edit to the attachment point has a known blast radius across every reserving answer that leans on it. The reviewer didn't have to trust the model; they read the pedigree. The full trail also lists the derived entities (the treaty, the two lines that cede to it) and the dependent cache entries that would invalidate if the treaty write-up 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 claims analyst agent can pull it mid-run with the kb_document_lineage MCP tool. One shape, three surfaces.

7 · Crucible & Ports — the golden set and the analyst

Claims facts change every week — reserves move, files close, the loss ratio drifts — and a wrong answer in a reserving call is expensive. Capture the questions the team actually asks as a golden set so Crucible can prove the assistant still answers them after every change. Sentinel ships the Claims Q&A baselineset — "Which reinsurance treaty covers catastrophe losses on the Homeowners line?", "Who is the adjuster on claim CL-4471?", "Why did the Homeowners line loss ratio spike in Q2?". Anchor a golden item to the certified treaty concept and seed a provenance qrel from the 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": "01KZGOLDTREATY000000000000",
    "chunkId": "01KZCHUNKCATXOL00000000000",
    "docId": "01KZDOCCATXOL0000000000000",
    "grade": 3,
    "source": "provenance"
  }'
Responsejson
{ "id": "01KZQRELCATXOL0000000000A", "queryId": "01KZGOLDTREATY000000000000", "grade": 3, "source": "provenance" }

The same grounded pipeline is packaged as a named agent — Ports exposes the Claims Operations Analyst (claims-analyst), whose system prompt cites a source for every claim and abstains without support, and which never makes a coverage or claim-denial decision — it surfaces facts and routes the call to the adjuster or underwriter of record. Run it on a golden question and get a blocking RunResult:

POST/api/v1/agents/{slug}/runsBearer · agents:run

Start a run of the named agent. SSE stream when stream is true (default); a blocking JSON RunResult when false. Same harness the workspace UI uses — keyed, attributed, and budgeted.

Request body

inputrequiredstringThe task or question (min length 1).
streambooleanSSE stream when true (default); JSON RunResult when false.
Example requestbash
curl -s -X POST https://your-host/api/v1/agents/claims-analyst/runs \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input":"Who is the adjuster on claim CL-4471?","stream":false}'
Responsejson
{
  "runId": "01KZAGENTRUN00000000000000",
  "status": "succeeded",
  "text": "The adjuster on claim CL-4471 is Trevor Osei, the Property Adjuster on the Homeowners line [S1].",
  "citations": [ { "docId": "01KZDOCFNOL000000000000000", "chunkId": "01KZCHUNKFNOL00000000000A" } ]
}

Run the golden set through 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 of the Claims Q&A baseline — overall and by facet. The ruler for 'did the analyst get worse?'

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

When faithfulness drops after a reserve update or a treaty edit, the golden set names exactly which question regressed — and promoting that miss back into the set turns it into a permanent test. That is the dashed loop in the diagram: Crucible's regressions steer the next round of Warrant curation. Compare two configs behind a two-gate significance test in Measure & compare.

The leverage

Seven slices, one claims knowledge base, one audit trail. The analyst gets a fast, cited answer — or an honest abstain; the reviewer can trace any answer to a certified treaty term and see its blast radius; the live claims database turns "what's our open reserve by line?" and "who's overloaded?" into grounded numbers; and a loss-ratio breach or a catastrophe approaching the $10M treaty attachment fires as an operational alert instead of a quarter-end surprise. Swap Sentinel's P&C corpus for life, health, or specialty lines and the shape is identical — the platform doesn't care what the claims are about, only that every answer is grounded, governed, traceable, and measured.

Keep going

See the other end-to-end walkthroughs — Sales enablement and Automated reports — or see the whole platform at a glance in the Capability map.