Skip to documentation

Overview

Capability map

eli.ai is eight named module slices working as one platform. Each slice owns one job — ingesting sources, building the semantic layer, governing it, tracing it, joining live data, answering, measuring, and exposing it all programmatically. This page is the map: what each slice is, the concrete capabilities inside it, and how a single document flows through every one of them. These are the same eight names used across the product, the API, and the rest of these docs.

One document, eight slices

A page you sync today enters through Intake, contributes concepts to Atlas, gets certified in Warrant, becomes traceable in Lineage, may join live rows via Conduit, grounds an answer in Lens, is scored by Crucible, and is reachable over Ports. The slices are boundaries, not silos — the value is the seam between them.

How it flows, end to end

The backbone runs Intake → Atlas → Warrant → Lens → Ports, with Conduit joining live data into the answer, Lineage making every answer traceable back to its sources, and Crucible feeding measured regressions back into curation.

Solid edges are the data path from a raw source to a cited answer and its programmatic surfaces; dashed edges are the two loops that make it trustworthy — lineage tracing an answer back to a source, and evaluation steering what gets curated next.

The eight slices

1 · Intake

Connect & ingest

Every source of truth — Confluence, SharePoint, Slack, a markdown vault, a bulk upload — normalized into one deduped, incrementally-synced document corpus.

  • Read-only connectors with resumable checkpoints and content-hash upserts, so a re-sync that yields the same bytes is a no-op.
  • ACL-aware ingestion — a source document arrives with the permissions it had at the source.
  • One normalized document shape regardless of origin, so everything downstream is source-agnostic.

In the engagement — Point it at the systems a client already lives in; the knowledge base builds itself from where the work happens.

2 · Atlas

The semantic layer

A typed, 10-type ontology with domain/range-constrained edges — the canonical graph of what the corpus is actually about, where LLM extraction and human curation coexist.

  • Ten entity types and typed relations with domain/range validation, not a free-for-all tag cloud.
  • Machine-extracted concepts and hand-authored ones live in the same graph, non-destructively merged.
  • The manifest orients the whole workspace by directed graph in-degree — the hub concepts surface themselves.

In the engagement — A shared vocabulary the whole engagement agrees on — the difference between a pile of documents and a knowledge asset.

3 · Warrant

Govern & certify

Authority and lifecycle for every concept and document — who vouches for this, is it still current, and is it allowed to change without review.

  • Authority tiers escalate machine_extracted → asserted → curated → certified; only certified is stated without hedging.
  • A lifecycle of draft → published → deprecated → superseded, with owners, stewards, and review SLAs.
  • Gated change requests and Glean-style document verification make every edit reviewable, never silent.

In the engagement — Defensibility. When a client asks 'who signed off on this number?', the answer is a name, a tier, and a timestamp.

4 · Lineage

Provenance & traceability

Append-only PROV-O revisions and a unified per-document trail: where a document came from, what knowledge it produced, and what breaks downstream if it changes.

  • One read assembles origin, governance, derived concepts/relations, and downstream impact for any document.
  • Every entity revision is append-only and attributed — a full audit trail, not a mutable 'last edited by'.
  • Blast-radius counts: how many live concepts and cited answers a document is grounding right now.

In the engagement — Trace any answer back to the exact documents behind it — and see what a source change would ripple into before you make it.

5 · Conduit

The live-data layer

Governed named queries bound onto entities and types — the bridge from the semantic graph to live SQL and Snowflake fact tables, with append-only call provenance.

  • Named queries are reusable domain components, not ad-hoc SQL scattered through prompts.
  • Entity and type bindings let a concept in the graph resolve to live rows on demand.
  • Every execution is recorded as an append-only data call — a Data Citation you can quote inside an answer.

In the engagement — Answers that quote today's number, not last quarter's document — with the query and its result auditable after the fact.

6 · Lens

Retrieve & answer

The full grounded-answer pipeline: query understanding → hybrid FTS + vector → graph fusion → rerank → token-budget assembly → an answer-policy engine that decides confidence, conflicts, clarify, or abstain.

  • Hybrid lexical + semantic retrieval fused with the graph, then cross-encoder reranked.
  • Grounded Citations on generated answer claims — Source Citations to documents and Data Citations to live data — with policy-controlled clarify/abstain paths.
  • A policy engine chooses to answer confidently, flag a conflict, ask to clarify, or abstain — plus a semantic cache.

In the engagement — A grounded answer you can defend in the room — with citations that click straight through to the evidence.

7 · Crucible

Evaluate & measure

Concept-anchored golden sets and a real evaluation stack: retrieval recall@k and nDCG, RAGAS, CRAG abstention with risk-coverage, paired significance tests, drift, and judge governance.

  • Golden items are anchored to concepts, so a failing test names the exact knowledge that regressed.
  • Offline IR metrics against graded qrels plus RAGAS and CRAG truthfulness — not vibes.
  • Paired-bootstrap significance behind an A/B gate: ship a retrieval change only when the win is real.

In the engagement — Prove quality moved — or didn't — with a number and a significance test, before a change reaches a client.

8 · Ports

Programmatic surfaces

Every capability above, exposed programmatically: durable agents, a standalone /api/v1 with granular scopes and a playground, a native MCP server, and an OpenAPI spec.

  • A scoped REST API — the same operations the UI uses, under keys you grant least-privilege.
  • A native MCP server so Claude or any MCP client reads the graph, runs queries, and traces lineage as tools.
  • Durable, provider-agnostic agents with budgets, guardrails, and human-in-the-loop approvals.

In the engagement — Embed eli.ai inside a client's own tools and agents — the platform is an API surface, not a walled app.

See it end to end

Two guides walk a real workflow across the whole map rather than one slice at a time:

  • Sales enablement, end to end — connect a source (Intake), curate and certify the concepts (Warrant), ask grounded questions (Lens), trace an answer back to its documents (Lineage), and measure with golden sets (Crucible).
  • Automated reports, end to end — pull governed live-data queries (Conduit), generate a scheduled report with concept-version citations (Warrant), benchmark its quality (Crucible), and render a client-ready PDF.

Where to start reading

New here? Read the slices top-to-bottom — they are in dependency order. Building an integration? Jump to Ports. Evaluating whether the graph is trustworthy? Start at Lineage and GET /api/v1/documents/{id}/lineage.