Skip to documentation
eli.aidocs

Use cases by industry

Use case: academic advising

Advising runs on two kinds of truth that rarely sit in the same place: the catalog — who teaches what, which course requires which, what a degree demands — and the live record— which sections are full, who is on an advising hold, who can still register. An advisor answering a student needs both, cited, and needs the assistant to say "I can't tell you that" rather than invent a grade. This guide builds that advising assistant end to end for the Lakeside University — School of Computing demo, touching seven module slices: Intake to ingest the catalog, Atlas to type the graph, Warrant to certify it, Conduit to run live student-information-system queries, Lens to answer with citations, Lineage to trace any answer, and Crucible & Ports to keep it accurate behind a golden set and a packaged agent.

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

Seed this workspace and follow along

Everything below is real seeded content. Run yarn demo:seed education and the workspace appears as Lakeside University — School of Computing (Education) — the catalog docs, the lakeside-sis connector, the three named queries, and the advising-assistant agent all land together. Browse the full set in Demo workspaces, then open this one and run each call as you read.

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 catalog concepts and verify source documents.
  • An enabled chat model, so /query can generate — otherwise 409 no-model-configured.

1 · Intake — ingest the catalog

The advising knowledge base is markdown: a department overview, a faculty roster, one page per degree program, one per course, the research labs, per-student advising notes, and the academic-standing policy. The seed loads them for you, but the shape is a plain document post — explicit references in the body give later enrichment useful surfaces, but are not resolved in the storage response. Here is the gateway course page going in:

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": "courses/cs-201-data-structures.md",
    "title": "Course — CS 201 Data Structures",
    "content": "# [[CS 201 Data Structures]]\n\nTaught by [[Priya Raman]]. A prerequisite for [[CS 310 Operating Systems]], [[CS 340 Databases]], and the [[CS 495 Senior Capstone]]. Required by both [[BS in Computer Science]] and [[BS in Data Science]]."
  }'
Responsejson
{ "docId": "01KYCS201DOCAAAAAAAAAAAAAA", "path": "courses/cs-201-data-structures.md", "contentHash": "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824", "title": "Course — CS 201 Data Structures" }

Once detached enrichment completes, Atlas can turn those references into a concept graph — [[Priya Raman]] becomes a Faculty node that teaches CS 201, which several Program nodes require. The 201 only confirms the committed document, chunks, and FTS index; it carries no graph status.

2 · Atlas — type the graph

Text alone is a search index; a typed graph is what lets retrieval reason. The Lakeside ontology types every node as Faculty, Program, Course, ResearchGroup, Student, or System, and every edge as teaches, requires, enrolled_in, advises, or member_of. List the courses to see the typed nodes extraction produced:

GET/api/v1/entitiesBearer · kb:read

List entities, filterable by type. Each carries its ontology type, authority tier, and the document it was extracted from.

Example requestbash
curl -s "https://your-host/api/v1/entities?type=Course" \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "entities": [
    { "id": "01KZCS201ENTITY0000000000", "name": "CS 201 Data Structures", "type": "Course", "authority": "machine_extracted" },
    { "id": "01KZCS340ENTITY0000000000", "name": "CS 340 Databases", "type": "Course", "authority": "machine_extracted" },
    { "id": "01KZCS420ENTITY0000000000", "name": "CS 420 Machine Learning", "type": "Course", "authority": "machine_extracted" }
  ],
  "total": 9
}
GET/api/v1/entities/{id}/neighborhoodBearer · kb:read

The typed neighborhood around one entity — the edges that make CS 201 the bottleneck it is. This is the structure retrieval walks, not just nearby text.

Example requestbash
curl -s https://your-host/api/v1/entities/01KZCS201ENTITY0000000000/neighborhood \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "center": { "id": "01KZCS201ENTITY0000000000", "name": "CS 201 Data Structures", "type": "Course" },
  "edges": [
    { "relation": "teaches", "from": "Priya Raman", "to": "CS 201 Data Structures" },
    { "relation": "requires", "from": "BS in Computer Science", "to": "CS 201 Data Structures" },
    { "relation": "requires", "from": "BS in Data Science", "to": "CS 201 Data Structures" },
    { "relation": "requires", "from": "CS 340 Databases", "to": "CS 201 Data Structures" },
    { "relation": "requires", "from": "CS 495 Senior Capstone", "to": "CS 201 Data Structures" }
  ]
}

Explore the graph in the UI

The same typed neighborhood renders as an interactive graph view on the entity page — click CS 201 Data Structures and you see every program and course that depends on it, which is exactly why a full section stalls half a dozen degree plans.

3 · Warrant — certify the catalog

Extraction leaves concepts at authority machine_extracted— a good draft, not a source of truth. Advising can't quote a draft. In Warrant, curate the concepts advisors will actually cite and certify them — certified is the only tier the assistant states without hedging. Pin the canonical definition of the gateway course as a reviewable change, then sign it 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": "01KZCS201ENTITY0000000000",
    "payload": { "description": "CS 201 Data Structures: core prerequisite for CS 310, CS 340, and the CS 495 Senior Capstone; required by the BS in Computer Science and BS in Data Science. Highest-demand section in the department." },
    "note": "Pinning the CS 201 prerequisite chain advisors quote"
  }'
Responsejson
{ "id": "01KZCREDU0000000000000000A", "entityId": "01KZCS201ENTITY0000000000", "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 catalog concept can't quietly go stale between academic years.

Example requestbash
curl -s -X POST https://your-host/api/v1/entities/01KZCS201ENTITY0000000000/certify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"note": "Verified against the FY26 catalog by the advising office"}'
Responsejson
{ "authority": "certified", "lifecycleStatus": "published", "version": 2, "nextReviewAt": "2027-01-17T09:10:00.000Z" }

Do the same for the source page — verify the course document so its provenance carries a governance tier that Lineage and the coverage manifest 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/01KYCS201DOCAAAAAAAAAAAAAA/verify \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"verification":"certified","note":"Current as of the FY26 catalog"}'
Responsejson
{ "id": "01KYCS201DOCAAAAAAAAAAAAAA", "verification": "certified", "verifiedAt": "2026-07-21T09:12:00.000Z", "nextVerifyAt": "2026-12-28T00:00:00.000Z" }

Certified evidence changes the verdict

This is not paperwork — it moves the policy. Because the catalog and standing concepts are certified, an advisor asking "Which sections are over capacity this term?" gets verdict answer at 0.81 confidence (reason confidence_above_answer_floor) rather than a hedge. Everything here is also a click on the Curation page; the API and the UI write the same append-only revisions.

4 · Conduit — run the live SIS queries

The catalog is static; enrollment is not. "Is CS 201 full?" can't be answered from a markdown page — it has to hit the record. Conduit wires the read-only lakeside-sis data connector to three governed named queries, each bound onto an entity. List them, then run one — every execution is row-capped, timed, and writes an append-only data_calls row you can cite later:

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

List named queries (domain components) available to run, with their parameter specs and the connector they run against.

Example requestbash
curl -s https://your-host/api/v1/data/queries \
  -H "Authorization: Bearer $ELI_KEY"
Responsejson
{
  "queries": [
    { "slug": "enrollment-by-program", "title": "Enrollment headcount by program", "connectorName": "lakeside-sis", "params": [] },
    { "slug": "section-fill-rate", "title": "Section fill rate for a course", "connectorName": "lakeside-sis",
      "params": [ { "name": "course_code", "type": "string", "required": true, "description": "Course code to check, e.g. CS 201" } ] },
    { "slug": "students-on-probation", "title": "Students on academic probation", "connectorName": "lakeside-sis", "params": [] }
  ]
}
POST/api/v1/data/queries/{slug}/runBearer · data:run

Execute a named query with validated params. Read-only, row-capped at 200, 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/section-fill-rate/run \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"params":{"course_code":"CS 201"}}'
Responsejson
{
  "dataCallId": "01KYDATACS201FILL00000000A",
  "connectorName": "lakeside-sis",
  "queryTitle": "Section fill rate for a course",
  "columns": ["code", "term", "capacity", "enrolled", "fill_pct"],
  "rows": [ { "code": "CS 201", "term": "2026-FA", "capacity": 120, "enrolled": 134, "fill_pct": 111.7 } ],
  "rowCount": 1,
  "truncated": false,
  "durationMs": 41,
  "executedAt": "2026-07-21T09:14:00.000Z"
}

There it is in the record: CS 201 is at 112% of capacity with an active waitlist. That same condition fires a capacity.overflow alert (education:cs201-capacity) so an advisor doesn't have to poll for it. The section-fill-rate query is bound to the CS 201 Data Structures entity, so the next slice can run it automatically when that course is the subject of a question.

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

Now the payoff. An advisor 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. Take a golden question straight from the pack:

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 programs require CS 201 Data Structures?"}'
Responsejson
{
  "answer": "CS 201 Data Structures is required by the BS in Computer Science and the BS in Data Science [S1].",
  "claims": [
    { "text": "The BS in Computer Science requires CS 201 Data Structures", "citations": ["S1"] },
    { "text": "The BS in Data Science requires CS 201 Data Structures", "citations": ["S1"] }
  ],
  "sources": [
    { "id": "S1", "docId": "01KYCS201DOCAAAAAAAAAAAAAA", "docTitle": "Course — CS 201 Data Structures", "docPath": "courses/cs-201-data-structures.md", "chunkId": "01KYCS201CHUNKBBBBBBBBBBBB" }
  ],
  "entities": [ { "id": "01KZCS201ENTITY0000000000", "name": "CS 201 Data Structures", "type": "Course", "authority": "certified" } ],
  "policy": { "decision": "answer", "confidence": 0.9, "reasons": ["confidence_above_answer_floor"] },
  "groundedness": { "verified": 2, "total": 2 },
  "model": { "chat": "claude-sonnet-4-5", "judge": "claude-haiku-4-5" }
}

Grounded, cited, certified — the advisor can quote it. The real test of a serious assistant, though, is what it does with a question it must not answer. Ask it to predict a grade:

POST/api/v1/queryBearer · agents:run

The same pipeline on an out-of-bounds question. With no chunk and no record backing a grade prediction, the answer-policy engine abstains with pointers instead of inventing a number.

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 grade will Jordan Alvarez get in CS 340?"}'
Responsejson
{
  "answer": "I can't predict a student's grade — that isn't backed by the catalog or the student record. For Jordan Alvarez's standing, see their advising notes or the students-on-probation query with their assigned advisor.",
  "claims": [],
  "sources": [],
  "policy": { "decision": "abstain_with_pointers", "confidence": 0.11, "reasons": ["no_relevant_chunks"] }
}

That abstain_with_pointers verdict at 0.11 confidence is the whole point of the answer policy — it refuses to guess a grade and it refuses to leak a standing to anyone but the assigned advisor. Between the two extremes sits the caveat band: "Should Maya Chen drop CS 420 this term?" returns answer_with_caveat at 0.43, because the record supports part of the answer but the judgment call belongs to a human. Certified fact, honest hedge, hard stop — the three behaviors advising demands.

6 · Lineage — trace the answer back to its source

A student challenges the answer, or a registrar audits it: where is this coming from, and can I trust it? The cited answer pointed at S1 → docId 01KYCS201…. 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/01KYCS201DOCAAAAAAAAAAAAAA/lineage \
  -H "Authorization: Bearer $ELI_KEY" | jq '{origin: .origin, verification: .governance.verification, citedBy: .downstream.citedByAnswers}'
Responsejson
{
  "origin": {
    "kind": "upload",
    "path": "courses/cs-201-data-structures.md",
    "ingestedBy": "yarn demo:seed education",
    "ingestedAt": "2026-07-21T09:05:12.004Z"
  },
  "verification": "certified",
  "citedBy": 9
}

Closed loop: the answer traces to the seeded courses/cs-201-data-structures.md page, the document is certified, and it is currently grounding 9answers — so a catalog edit has a known blast radius. The auditor didn't have to trust the model; they read the pedigree. The full trail also lists the derived concepts (CS 201 and the programs that require it) and the dependent cache entries that would invalidate if the course page 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 advising-assistant agent can pull it mid-run with the kb_document_lineage MCP tool. One shape, three surfaces.

7 · Crucible & Ports — lock the accuracy in, then ship the agent

Catalogs change every term and a wrong prerequisite is a lost year for a student, so accuracy has to be a number you watch. Capture the questions advisors actually ask as a golden set — the pack ships three, including "Who chairs the School of Computing?" and "Why is CS 201 Data Structures a prerequisite for the Senior Capstone?" — anchor each to a provenance qrel from the chunk that should ground it, and let Crucible prove the assistant still answers them after every catalog change. The seeded "Advising Q&A baseline" config has already run; read its metrics:

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?' Abstention scores whether it refused the grade question it should have refused.

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

When a metric drops after a catalog 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 abstentions steer the next round of Warrant curation.

With quality measured, Ports packages the whole thing as a runnable agent. The seeded advising-assistantcarries the system prompt ("cite the catalog or the data source for every claim; abstain rather than guess; never disclose a student's standing to anyone but their advisor"), the bound SIS queries, and its memories — the probation threshold and the CS 495 prerequisite chain. Kick off a run over the same questions:

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

Start an agent run. Admits under the workspace's concurrency and budget policy, then enqueues; returns the runId and a stream URL. The advising-assistant answers with the same grounded pipeline, its bound queries, and its abstention policy.

Example requestbash
curl -s -X POST https://your-host/api/v1/agents/advising-assistant/runs \
  -H "Authorization: Bearer $ELI_KEY" \
  -H "Content-Type: application/json" \
  -d '{"input":"Which sections are over capacity this term, and who should I flag for an advising hold?"}'
Responsejson
{ "runId": "01KZRUNADVISING0000000000A", "status": "queued", "stream": "/api/v1/runs/01KZRUNADVISING0000000000A/stream" }

Reattach to GET /api/v1/runs/{runId} to read the finished run — its cited answer, the section-fill-rate and students-on-probation data calls it made, and the standing.probation alert it surfaced for Jordan Alvarez. The same pipeline is a native MCP tool, so the advising desk can call it straight from Claude.

The leverage

Seven slices, one knowledge base, one audit trail. The advisor gets a fast, cited answer that quotes the certified catalog and reads live enrollment in the same breath; the question it must not answer — a predicted grade, another student's standing — is refused, not fabricated; every answer traces to a certified source with a known blast radius; and the whole thing is measured, so accuracy is a number you watch rather than a hope. Swap "advising" for admissions, financial aid, or the registrar and the shape is identical — the platform doesn't care what the records 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 — browse the rest of the starter workspaces in Demo workspaces, or see the whole platform at a glance in the Capability map.