All guides

Every page of this site, by who it is for. New here? Get started in 5 minutes first.

Limma is retrieval and verification infrastructure for AI agents. Give it documents and a question and it returns facts at addresses — entity · attribute · period — each with a byte-addressed receipt, a count of what exists at the address, and verdicts an agent can check against the stored bytes. The surface is an HTTP API, an MCP server and a Python SDK; there is no human UI.

Using the hosted service

• Get started in 5 minutes — a key, your agent connected, your data loaded.
• How the map builds itself — what Limma organises on its own from your documents and records, and the one thing set up with you.
• Pricing and limits — the plans and what each allows.
• What you can connect — sources and file formats, and what is not there yet.
• Security and your data — where the service runs and what it does with your data.
• Questions people ask.
• Legal: Terms of Service, Privacy Policy, Acceptable Use Policy, Sub-processors.

The agent integrator

You are attaching an agent to a workspace and need to know what a response means and what it licenses.

• Quickstart — an agent over MCP in under ten minutes.
• Embedding Limma in your platform.
• MCP over HTTP — the endpoint, the one-line setup per client, errors, keys and roles.
• Files from an agent, waiting for a read, and your usage.
• Sync and access — keeping a workspace equal to a source system, per user.
• Connectors — a folder, a bucket, Google Drive or SharePoint, kept current with one command.
• The concepts, one page each: an address, a receipt, a count, None versus Not recorded, contested, provenance, supersession.
• The categorical side: relations (the relation address, relation_query, active_in), vocabulary (what an expansion line means), search (a brief to a closed set), criteria (a condition no field holds, read from each candidate's own documents with the sentences that say so), ideas (where the documents discuss something), one thing, entered twice (records of any entity type merged only on evidence, so a list counts things) and corrections, generations and erasure.
• What it will not do — eight limits, in plain words.
• Troubleshooting and errors — refusals and status codes, what an ingest and a retry cost, and the smaller rules a reply follows.
• The generated verb reference — every public route and every MCP tool, with what each field licenses.

The operator — Limma inside your own network

You are deploying and running Limma yourself.

• For the operator — keys and roles, and the operator's pages.
• Quickstart — install, use, data and install Limma inside your network.
• Licensing.
• Data handling for a workspace holding personal data.
• Operating the connect path and loading a sync tool's output.

The person at the window

You are asking questions through the demo window and reading result sets.

• For the person at the window.
• Search mode, people search and the Q&A view — the page a customer is sent.

How the examples work

Every code example on these pages is run by Limma's test suite against the real application, and must print exactly the output block shown beneath it; an example that stops working fails the build. The convention: a fence marked python run is followed by a fence marked output. Inside an example, client is an HTTP client for the API (in your code, httpx.Client(base_url=..., headers={"X-API-Key": ...}) — the same .get / .post calls), WS is a workspace id, SOURCE is the source id of the seeded annual report, OLD / NEW are the two generations of the seeded quarterly update, and API_KEY is the whole configured key entry the seeded app accepts (sk_docs:org_docs:analyst). Examples print only fields that are deterministic — never a generated id, a hash or a timing.

Examples on the categorical pages need a workspace with a pack applied and relation rows loaded. They import it from docs/examples/roster.py: roster(client) returns a workspace (shared by the read-only examples, built once per app) with the expert-network pack applied and a small invented warehouse export — six roles, three screenings — connected as rows; new_roster(client) builds a fresh copy for an example that corrects, re-syncs or erases; new_workspace(client) is an empty one. Every step goes through the public verbs (apply_pack, connect) except creating the workspace, which a keyed deployment's HTTP route cannot give an organisation; the module says so.

The criteria page searches PEOPLE: a third workspace — ten invented experts, a country each, and their profiles and call transcripts registered as documents — loaded through apply_pack, connect and ingest. A model reads documents in a deployment; the test suite runs offline for $0, so on that page the model's replies are scripted stand-ins (the replies the product's own tests hold for those documents) and everything after the reply is the product's code. The page says so before its first example; the brief its examples send is in docs/examples/niche.py. PEOPLE is those tests' ten-expert world with two sentences led by the person's name (a length, a denial): the product's reader takes a length, and a firm "no", only from a sentence that names the person, and the page documents the product's reader. Three of its sections search ON_RECORD, a fourth workspace built the same way: eight invented experts whose roles are connected as held_role rows, for the examples that count a length, send a record check (and show what it is, and is not, read for) and accept another name for a condition. Two more search IN_DOUBT, a fifth: three invented experts — one whose own call note denies the niche in a sentence the reader cannot attribute, one whose "since 2001" her record closed, and one whose call note denies a name the caller accepted.

The verb reference is generated from the API's OpenAPI schema and the MCP registry, and the test suite regenerates it and fails with a diff if the published copy has drifted.