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
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.
Every step of the grounded answer path, listed in order below, followed by all eight systems and every documented handoff between them. On large screens the plate also draws those systems and handoffs as a map, with this path picked out.
- Intake
Normalize source material and preserve source permissions.
- Atlas
Connect evidence through typed entities and relations.
- Warrant
Apply certification, lifecycle, and content ACL policy.
- Lens
Retrieve, rerank, answer, clarify, or abstain.
- Ports
Deliver the result to a person or programmatic caller.
- Intake
- Atlas
- Warrant
- Lineage
- Conduit
- Lens
- Crucible
- Ports
All system handoffs
- Intake → Atlas Normalized documents feed typed entity and relation extraction with sentence evidence.
- Atlas → Warrant Graph concepts receive authority tiers, lifecycle state, ownership, and governed change.
- Atlas → Lens Graph neighborhoods join lexical and vector retrieval before reranking.
- Warrant → Lens Content ACLs and certification state constrain what the answer pipeline may state.
- Conduit → Lens Entitled named queries contribute live rows and auditable Data Citations.
- Lens → Ports Grounded results reach the workspace, REST clients, MCP hosts, and durable agents.
- Lens → Crucible The real answer pipeline runs against golden sets and measured quality gates.
- Crucible → Warrant Significance-gated evaluation results govern consequential configuration changes.
- Lens → Lineage Answer claims, source revisions, data calls, and policy verdicts remain traceable.
- Lineage → Intake Reverse provenance resolves a result back to the exact ingested source revision.
On wide screens the plate draws all eight systems as a map: the grounded-answer path — Intake → Atlas → Warrant → Lens → Ports — is emphasised, and every other documented handoff stays recessed behind it. Among those recessed edges are the loops that make the map trustworthy: Crucible → Warrant, where a significance-gated regression governs what changes next, and Lineage → Intake, the reverse-provenance edge that resolves a finished answer back to the exact ingested source revision. Below that width the map gives way to the same content as text — the ordered path, all eight systems, and an “All system handoffs” list naming every edge and the mechanism behind it.
The eight slices
1IntakeConnect & 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.
2AtlasThe 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.
3WarrantGovern & 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.
4LineageProvenance & 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.
5ConduitThe 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.
6LensRetrieve & 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.
7CrucibleEvaluate & 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.
8PortsProgrammatic 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.
How the modules compose
No module is an island, and the product says so out loud: every workspace surface carries a module trail in its header — a tinted chip naming the system that owns the page, then "builds on" icons for the systems it composes with, each tooltip naming the concrete mechanism in one sentence. The edges are the real ones from the code, not marketing arrows:
- Chat (Lens) builds on Conduit (data citations pull live rows through governed queries), Atlas (graph fusion surfaces neighbor documents), and Warrant (retrieval is ACL-filtered before ranking).
- Live data (Conduit) builds on Atlas (named queries bind to entities), Warrant (row entitlements bind the caller), and Lineage (every execution freezes a snapshot + hash).
- Agents (Ports) build on Lens, Conduit, and Atlas through their governed tools — and on Warrant for the human checkpoint every consequential call suspends into.
- Records (Atlas) build on Intake (each version projects into the corpus as a citable document) and Lens (answers cite
record:<type>/<key>@v<n>). - Evals (Crucible) build on Lens (runs exercise the real pipeline) and veto through Warrant (acceptance gates block consequential settings flips until the evidence passes).
The same colour identity runs everywhere — sky is Lens because Lens emits the Source Citation, emerald is Conduit because Conduit emits the Data Citation — so a hue on the homepage, in the docs diagrams, and in the app chrome always means the same module.
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.