How Lumen answers and what it can see
This page explains how an answer is built and why Lumen can only show you what you may already see.
No separate index
Section titled “No separate index”Lumen does not copy your data into its own search index. When you ask a question, the model asks Lumen to call read tools, and each read tool calls the API of the product (Orbit, Forge, Pulse or Folio) as you, with your own session. The product checks your project roles on every request, as it does for the interface.
The consequence is simple: a person who is not a member of a project gets nothing from it in an answer, in its sources or in Find everywhere. This is proved by an integration test that asks the same question as two different users and checks that the outsider gets nothing from the project.
The read tools cover:
| Product | What Lumen can read |
|---|---|
| Orbit | Work items with JQL and text search, comments and links, projects |
| Forge | Repositories, the file tree and files, commits, merge requests, pipelines, job logs |
| Pulse | Logs, spans and traces, services, errors and their events, incidents, monitors, deployments, metrics, dashboards, SLOs and profiles |
| Folio | Search, pages, spaces, the page tree, versions, pages of a work item |
Each product joins Lumen with a manifest that names its tools, the fields Lumen may see, its suggested questions and how to link back.
How an answer is built
Section titled “How an answer is built”- The model decides which read tools to call. It can use up to 6 rounds of tool calls, 4 in parallel, with 20 seconds per call.
- Each result is trimmed to the fields named in the product’s manifest and to a size limit (16,000 characters per call and 60,000 per answer).
- Results are passed to the model as untrusted data, separate from the instructions.
- The server numbers the sources it actually read. Citations
[n]in the answer are normalised, and references to anything the model did not read are removed. If the answer names a work item that was read but gives no citation, it becomes a source too. - If the model runs out of lookups, it is asked once to answer from what it read.
Answers stream to the panel, and you can stop them.
Sources, dates and conflicts
Section titled “Sources, dates and conflicts”Every source shows its product, the date it last changed and its author. A Folio page older than 180 days is marked may be outdated. When sources conflict, or a fact has changed, the answer gives the current value and the previous one, each with its source and date.
If there is nothing to support an answer, Lumen answers “not found” and suggests where to look; it does not make facts up. A set of evaluation questions checks this, including questions about other people’s projects.
Queries that Lumen writes
Section titled “Queries that Lumen writes”- Text to JQL: Orbit’s own search validates the query. If it is rejected, the error goes back to the model to fix. You see the final JQL, with a button that applies it in Orbit’s search.
- Text to a Pulse query: validated by Pulse (
/query/validate), corrected using the error position, shown to you and opened in Logs. - Generated configuration is checked by the product before you can run it: Orbit automation rules, Forge
.gitlab-ci.yml(through CI lint) and Pulse monitors. See Actions with confirmation cards.
Prompt injection
Section titled “Prompt injection”Work items, pages, logs and commits can contain text that tries to give the model orders. Lumen treats that as data:
- Product content reaches the model in an envelope that inserted text cannot close, separate from the instructions, and only the fields the manifest names are sent.
- An instruction found in data never runs without a card that you confirm. The Lumen server has no write path at all.
- Answers are rendered without HTML, without external images, and with external links marked.
- An attack test set with injections in work items, pages, logs and commits runs on every delivery. In the recorded runs, 9 of 9 cases passed twice, with no leak and no unconfirmed change.
What a model provider receives
Section titled “What a model provider receives”Only what the answer needs: the question, the context of the page you have open, the rules, and the fields named in the manifests, within their limits. A provider does not receive your session, your e-mail address or your user id (an opaque reference is used instead), or product fields outside the manifests. On Orbit’s cloud they will go to Claude Haiku 5.5 from Anthropic, which writes the answer In development. Answering on Orbit’s cloud is in final testing; see Models, providers and cost.
Your Orbit session is not stored by Lumen and does not appear in its logs.
Conversations and retention
Section titled “Conversations and retention”A conversation (question, answer and citations, but not the data read) is stored for its author only. An administrator sets the retention from 0 to 365 days; the default is 30, and 0 means nothing is kept. Expired conversations are deleted every hour. Administrators cannot read other people’s conversations.
Limits per person
Section titled “Limits per person”Questions and tool calls are limited per person, and Origin is checked on every write. An administrator can also set a daily question limit per user.