Skip to documentation

Get started

Core principles

Before the product tabs, the philosophy. eli.ai is not a wrapper around a chat model — it is a set of design commitments about trust: that an answer must cite its evidence, that a fact must be traceable, that authority is earned by sign-off, that isolation is enforced by the database, and that the parts that must be reproducible do not roll a model each time. Every feature in the rest of these docs is one of these principles made concrete. Read this page first; the product tabs are the mechanics.

The why, and the what

These eight principles are the why. The eight named capability systems below — Intake, Atlas, Warrant, Lineage, Conduit, Lens, Crucible, Ports — are the what: the modules that enforce the principles in code. Each principle points into the product doc where you can see it working.

The eight principles

1 · Grounded, not generative

Generated factual answers are grounded in retrieved evidence and carry source labels — [Sn] for documents, [Dn] for live data, [Cn] for supplied context. Clarify/abstain branches do not manufacture a factual answer.

Why it matters — A generative assistant that answers from its weights is confidently wrong at the worst possible moment — in front of a client. eli.ai retrieves first, packs evidence into a token-budgeted context block, and requires citations on generated factual claims; the answer policy clarifies or abstains when evidence is not there. An asynchronous groundedness check verifies shipped answer claims against cited evidence.

2 · Provenance & lineage, end to end

For any fact you can trace where it came from — and see what breaks downstream if it changes.

Why it matters — When a client asks "where did this number come from?" the answer is a document, a connector, a sync run, and a timestamp — one DocumentLineage read that stitches origin, governance, derived concepts, and downstream impact together. The reverse direction is the blast radius: before you deprecate a source, you can see the live concepts and cited answers it is grounding right now. Append-only, deterministic, no model call.

3 · Governed authority

Authority advances only by human sign-off — machine_extracted → asserted → curated → certified — and only certified is stated without hedging.

Why it matters — Auto-extraction is fast and fallible, so it lands at the lowest authority by default and is promoted post-hoc — pre-moderating everything is the pattern that failed at Wikimedia scale. Retrieval and the answer policy are authority-aware: a certified concept outranks an extracted one, and the phrasing an answer uses is calibrated to the tier behind it. Defensibility means the answer to "who signed off on this?" is a name, a tier, and a date.

4 · Tenant isolation by construction

Isolation is enforced by Postgres, not by a WHERE clause you have to remember. FORCE row-level security on every tenant table; the workspace comes from the URL, never the session.

Why it matters — A consultant with two client tabs open is one forgotten filter away from writing client X's notes into client Y's workspace — and a session-derived scope would let RLS happily permit it, because the write is "correctly" scoped to the wrong tenant. So identity derives from the URL path, every tenant table is FORCE-RLS and fails closed to zero rows when context is unset, and a permanent CI canary proves cross-tenant reads and writes are impossible — a new table physically cannot ship without RLS.

5 · Durable by default

Agents run server-side and survive a closed tab. Run state persists at every step; a suspended run can wait days for approval and then resume exactly where it paused.

Why it matters — A long agent run tied to a browser session dies the moment the laptop sleeps. Here the worker process drives durable runs over pg-boss, run state is persisted at every step, and a reaper marks crash-orphaned runs interrupted instead of leaving them hung. A human-in-the-loop suspend survives a restart — the run is a server-side record, not a websocket that closed with the tab.

6 · Human-in-the-loop for changes

Writes go through approval. An agent's only path into the knowledge base is a proposal a human accepts.

Why it matters — An agent that writes documents directly is an unbounded blast radius. The kb_propose_note tool is requiresApproval, so calling it suspends the run into an approvals inbox: approve and the proposal materializes as a real vault document and the run resumes with the new id; reject and it resumes with the rejection. Concept edits route through the same gate — a change request drafts → reviews → publishes, and every mutation is attributed. Nothing changes the knowledge base without a name on it.

7 · Self-hostable & model-portable

MIT-licensed, runs on a laptop or a single VPS, and speaks to any provider. Your documents, your graph, your data never have to leave your infrastructure.

Why it matters — The whole system is Postgres plus two Node processes — no serverless lock-in, no vendor tie. The AI layer is provider-agnostic (OpenAI, Anthropic, Google, any OpenAI-compatible base URL, or local Ollama), resolved per-workspace behind an allowlist, so a data-residency requirement is code rather than a promise — and extraction degrades gracefully to a weak or air-gapped local model. Anthropic-backed calls can receive supported prompt-cache and adaptive-thinking options without changing the portable runtime.

8 · Deterministic where it matters

The parts that must be reproducible do not call a model — the wikilink + co-occurrence graph, RRF fusion, the seeded graph layout, and stamped report snapshots.

Why it matters — A demo that renders a different graph on every load, or a report you cannot reproduce, is not defensible. So the graph stays connected from zero-LLM wikilinks and co-occurrence edges even with the model off; reciprocal-rank fusion needs no cross-channel score calibration to stay stable; the graph explorer reads a server-persisted, seededForceAtlas2 / Louvain layout instead of recomputing per browser; and a report snapshot is stamped with its layout and analytics versions, so "you told us Compliance was 78%" stays provable months later.

The eight capability systems

The principles are enforced by eight composable module slices, in dependency order — the same names used across the landing page, the API, and the rest of these docs. A document flows through all of them: it enters through Intake, contributes concepts to Atlas, is 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.

Intake
Connect & ingest
01

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

Atlas
The semantic layer
02

A typed, ten-type ontology with domain/range-constrained edges — the canonical graph of what the corpus actually means.

Warrant
Govern & certify
03

Authority tiers, lifecycle, owners, review SLAs, and gated change management on every concept and document.

Lineage
Provenance & traceability
04

Append-only revisions and one per-document trail: where it came from, what it produced, and what breaks if it changes.

Conduit
The live-data layer
05

Governed named queries bound to entities — the bridge from the graph to live SQL and Snowflake, with call provenance.

Lens
Retrieve & answer
06

Query understanding → hybrid + graph retrieval → rerank → an answer policy that decides confidence, conflict, clarify, or abstain.

Crucible
Evaluate & measure
07

Concept-anchored golden sets and real metrics — recall@k, nDCG, RAGAS, CRAG — behind a paired-significance A/B gate.

Ports
Programmatic surfaces
08

Every capability exposed programmatically: durable agents, a scoped /api/v1 with a playground, and a native MCP server.

Each system has a deep dive; the Capability map walks all eight and diagrams how one document flows through every one of them, end to end.

Where to go next

Ready for the mechanics? The Architecture page is the canonical system design behind these principles, and the Quickstart gets a workspace running on a laptop. Evaluating whether the graph is trustworthy? Start at Lineage and GET /api/v1/documents/{id}/lineage.