Use cases by industry

Use case: sales enablement

A sales team is only as good as its answers. A rep on a call needs the current pricing, the certified competitive positioning, and the security posture — not last quarter's deck, and not a confident hallucination. This guide builds that assistant end to end, touching five module slices: Intake to connect the deal room, Warrant to certify the messaging, Lens to answer with citations, Lineage to trace any answer back to its source, and Crucible to keep it accurate as the story changes.

One knowledge base, five slices. The dashed edge is the loop that keeps it honest: a regression the golden set catches steers the next round of curation.

Prerequisites

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

1 · Intake — connect the deal room

Sales content already lives somewhere — a Confluence space of battlecards, a SharePoint of contracts, a Slack channel of deal debriefs. Wire it in as a content connector so it becomes searchable, citable documents that sync themselves. Create the source, then kick off the first full backfill:

POST/api/v1/connectorsBearer · kb:write

Create a content connector source. The credential is stored encrypted and masked on every read; the source does nothing until its first sync is enqueued.

Example requestbash

curl -s -X POST https://your-host/api/v1/connectors \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "confluence",
    "config": { "baseUrl": "https://acme.atlassian.net/wiki", "spaceKeys": ["SALES"] },
    "credential": { "email": "svc-eli@acme.com", "apiToken": "<atlassian-api-token>" }
  }'

Responsejson

{ "id": "01KZCONNSRC00000000000000", "type": "confluence", "status": "active", "hasCredential": true, "lastSyncedAt": null }

POST/api/v1/connectors/{id}/syncBearer · kb:write

Enqueue the first full sync. The worker persists every document in a page before advancing its checkpoint and upserts by (source_id, external_id), so retries replay safely rather than duplicate or skip content.

Example requestbash

curl -s -X POST https://your-host/api/v1/connectors/01KZCONNSRC00000000000000/sync \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"kind":"full"}'

Responsejson

{ "enqueued": true, "sourceId": "01KZCONNSRC00000000000000", "kind": "full" }

As documents land, the worker chunks them, embeds them, and runs entity extraction — Atlas builds the concept graph automatically. Watch the sync_runs history on the Connectors page. No source of your own? Post markdown directly with POST /api/v1/documents per Ingest documents — the rest of this guide is identical.

2 · Warrant — certify the messaging

Extraction gives you concepts at authority machine_extracted — a starting point, not a source of truth. Sales messaging has to be vouched for. In Warrant, curate the key concepts and certify the ones reps will quote — certified is the only tier an assistant states without hedging. Take the pricing concept, pin its definition, and sign off:

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

Propose the canonical definition 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": "01KZPRICINGTIER0000000000",
    "payload": { "description": "Enterprise tier: $60k/yr floor, annual commit, includes SSO and the audit-log add-on." },
    "note": "Locking the FY26 enterprise pricing reps should quote"
  }'

Responsejson

{ "id": "01KZCR00000000000000000AA", "entityId": "01KZPRICINGTIER0000000000", "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 certified messaging can't quietly go stale.

Example requestbash

curl -s -X POST https://your-host/api/v1/entities/01KZPRICINGTIER0000000000/certify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"note": "Signed off by RevOps + Legal for FY26"}'

Responsejson

{ "authority": "certified", "lifecycleStatus": "published", "version": 3, "nextReviewAt": "2027-01-17T09:10:00.000Z" }

Do the same for the source document itself — verify the battlecard so its provenance carries a governance tier:

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":"Current as of the FY26 pricing update"}'

Responsejson

{ "id": "01KY10AAAAAAAAAAAAAAAAAAAA", "verification": "certified", "verifiedAt": "2026-07-21T09:12:00.000Z", "nextVerifyAt": "2026-12-28T00:00:00.000Z" }

Curate in the UI too

Everything here is also a click: the Curation page shows the open change-request queue, the review-due list, and a certify button per concept. The API and the UI write the same append-only revisions — pick whichever fits the reviewer.

3 · Lens — the rep asks, and gets a cited answer

Now the payoff. A rep asks in plain language; Lens retrieves, grounds, and returns an answer with inline [Sn] citations, an atomic claims breakdown, and a policy decision that says how much to trust it. Certified concepts are stated plainly; thin evidence makes the policy hedge or abstain rather than bluff.

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 is our enterprise pricing floor and what does it include?"}'

Responsejson

{
  "answer": "The enterprise tier has a $60k/yr floor on an annual commit, and includes SSO and the audit-log add-on [S1].",
  "claims": [
    { "text": "Enterprise tier floor is $60k/yr on an annual commit", "citations": ["S1"] },
    { "text": "It includes SSO and the audit-log add-on", "citations": ["S1"] }
  ],
  "sources": [
    { "id": "S1", "docId": "01KY10AAAAAAAAAAAAAAAAAAAA", "docTitle": "FY26 Enterprise Battlecard", "docPath": "sales/battlecards/enterprise.md", "chunkId": "01KY10BBBBBBBBBBBBBBBBBBBB" }
  ],
  "entities": [ { "id": "01KZPRICINGTIER0000000000", "name": "Enterprise Pricing", "type": "concept", "authority": "certified" } ],
  "policy": { "decision": "answer", "confidence": "high", "reason": "single certified source, no conflicts" },
  "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 highconfidence because the evidence is a single certified source with no conflict. Ask something the corpus doesn't cover and the policy engine returns abstain or clarify instead of inventing a number — the behavior sales content demands. The same pipeline is a native MCP tool, so it drops straight into a rep's Claude or CRM assistant.

4 · Lineage — trace the answer back to its source

A sales manager reviewing the assistant asks the fair question: where is this coming from, and can I trust it? The answer cited S1 → docId 01KY10…. 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/01KY10AAAAAAAAAAAAAAAAAAAA/lineage \
  -H "Authorization: Bearer $ELI_KEY" | jq '{origin: .origin, verification: .governance.verification, citedBy: .downstream.citedByAnswers}'

Responsejson

{
  "origin": {
    "kind": "connector",
    "sourceType": "confluence",
    "externalId": "SALES-4471",
    "sourceVersion": "9",
    "lastSyncedAt": "2026-07-21T09:22:41.008Z"
  },
  "verification": "certified",
  "citedBy": 14
}

There it is, closed loop: the answer traces to a Confluence page (SALES-4471, source version 9), the document is certified, and it is currently grounding 14answers — so an edit to it has a known blast radius. The manager didn't have to trust the model; they read the pedigree. The full trail also lists the derived concepts and the dependent cache entries that would invalidate if the battlecard changed.

Same trail, in the document view

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 an agent can pull it mid-run with the kb_document_lineage MCP tool. One shape, three surfaces.

5 · Crucible — lock the accuracy in

Sales messaging changes constantly, and a wrong answer to a prospect is expensive. Capture the questions reps actually ask as a golden set so Crucible can prove the assistant still answers them correctly after every content change. Anchor a golden item to the certified pricing concept, and seed a provenance qrel from the battlecard 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 set 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. The ruler for 'did the assistant get worse?'

Example requestbash

curl -s https://your-host/api/v1/evals/runs/01KZRUNA00000000000000000/metrics \
  -H "Authorization: Bearer $ELI_KEY"

Responsejson

{
  "runId": "01KZRUNA00000000000000000",
  "n": 42,
  "retrieval": { "recallAtK": 0.74, "ndcgAt10": 0.71, "mrr": 0.79, "hitAtK": 0.93 },
  "ragas": { "faithfulness": 0.91, "responseRelevancy": 0.84, "contextPrecision": 0.66 },
  "abstention": { "truthfulness": 0.62, "abstainRate": 0.11, "aurc": 0.074 }
}

When a metric drops after a messaging update, 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 with a two-gate significance test in Measure & compare.

The leverage

Five slices, one knowledge base, one audit trail. The rep gets a fast, cited answer; the manager can trace any answer to a certified source and see its blast radius; and the whole thing is measured, so accuracy is a number you watch rather than a hope. Swap "sales" for support, onboarding, or compliance 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.

Keep going

Automate the deliverable side of this with Automated reports, end to end, or see the whole platform at a glance in the Capability map.