How ran works.
The two layers under the operator — and the guarantees they enforce.
01#layers
Two layers.
ran is built as two layers. The knowledge layer is a per-user graph: for every source you connect it derives text, computes embeddings, and stores pointers back to the origin — it never mirrors your files.
The operator layer is a single runtime that reads that graph alongside the live tools and takes action behind holds. Every query and every job passes through these two layers and nothing else.
02#ingestion
Reference, don't duplicate.
ran references your sources instead of copying them. On connect it indexes what a source contains; after that it syncs incrementally — only the deltas since the last pass — so the graph stays current without re-reading everything.
Disconnect a source and every derived artifact for it — text, embeddings, pointers — is purged, and a receipt confirms it's gone.


03#retrieval
Hybrid search, claim-level citations.
A question runs through hybrid retrieval — semantic vector search and full-text search together — and every claim in the answer carries a citation to the passage it came from. When retrieval comes back thin, ran abstains rather than guess.
Retrieval quality is measured, not asserted. In an open benchmark — a 16-document team corpus, 31 questions, LLM-judged — ran answered 91% correctly, retrieved the right sources for 93% of them, and abstained honestly on 100% of the unanswerable ones.




04#operator
Every job is an event-sourced plan.
A job runs as an event-sourced plan: each step is an event on an append-only log, so the full history of what ran did is always reconstructable. Steps that only touch the graph run straight through.
Any step that acts outward holds on its own, showing the exact artifact about to leave. Releasing it resumes the plan exactly once — enforced in the database, not by retry luck — and every internal change is undoable, the undo itself recorded as another event on the log.




05#access
Scoped to what your account can see.
Your corpus is bounded by what your own connected accounts can see. That scope is enforced in the database at query time — a retrieval simply cannot return a passage from a source your account has no access to.
Workspaces are isolated from one another, data is encrypted in transit and at rest, and nothing in your workspace is ever used to train models.
06#inference
Your inference, your terms.
By default ran runs on a managed model key. You can instead bring your own Anthropic or OpenAI key per workspace, so reasoning runs under your DPA, your retention window, and your bill.
Or skip ran's inference entirely and let the Claude or ChatGPT subscription you already have do the reasoning over ran's MCP server.
07#mcp
The knowledge layer as a service.
ran exposes the knowledge layer through a Model Context Protocol server. Point the AI you already pay for at it and Claude or ChatGPT queries your ran graph directly — the same retrieval, the same citations, the same access scope, inside the assistant you already use.
It's the same guarantees, reached through a different front door.
Clear it for your company.
We're onboarding technical design partners now. Bring your stack, your keys, and your access rules, and put the mechanisms above to the test.