Add a product to Lumen with a manifest
A manifest tells Orbit Lumen what a product offers: which tools it can read, which fields Lumen may see and how to link back. This page is a reference for how Lumen learns what a product offers. It is for developers and administrators who want to know what Lumen can read and why.
Orbit, Forge, Pulse and Folio use manifests that are built into Lumen. They are written in the format below. For how Lumen uses the results, see How Lumen answers and what it can see.
How a product joins
Section titled “How a product joins”- The product publishes its manifest at
GET /api/v1/<product>/assistant/manifest, in the formatorbit-lumen-manifest/v1. - Lumen reads the manifest when it starts and then again at regular intervals.
- Lumen validates it with the same checks as the built-in manifests.
- A valid manifest replaces the built-in one for that product. Without a valid manifest, the built-in one stays.
- The Lumen admin console shows whose manifest each product uses.
The address of a product comes only from Lumen’s own configuration, never from the manifest. Orbit maintains that configuration, so on Orbit’s cloud a company cannot connect its own product to Lumen today.
What a manifest describes
Section titled “What a manifest describes”| Part | What it holds |
|---|---|
| Read tools | Each tool has an input schema in JSON Schema. A request template points to a path under /api/v1/ of the product. |
| Result fields and limits | The fields Lumen may keep from a result, and their size limits |
| Sources | How a result becomes a source, shown with its product, date and author and a link back |
| Find everywhere | The search that Lumen runs across products without a model |
suggestions |
Suggested questions for the entity a person has open |
show |
The query and link that Lumen shows under each search |
| Actions | Changes that Lumen proposes as confirm cards. A prepare step reads fresh versions just before the change. |
request.check |
Lets the product validate a draft when a card is shown and again before it runs. Only a path ending in lint or validate is allowed. |
request.form |
A read that the browser makes when a card is shown, to get what the card needs, such as the required fields of a create screen |
readOnlySessions |
true lets agents and coding tools read the product with a read-only session |
Validation rules
Section titled “Validation rules”Lumen rejects a manifest, or a tool in it, that breaks these rules.
| Rule | Detail |
|---|---|
| Product name | Must match the product that is configured |
| Tool names | Must carry the product’s prefix |
| Requests | Only paths under /api/v1/ of the configured address, without .. |
| Inputs | Escaped when they are put into a request URL |
What Lumen does with the product
Section titled “What Lumen does with the product”- Lumen reads with the signed-in person’s session, so the product applies that person’s permissions.
- Each result is trimmed to the fields in the manifest and to 16,000 characters per call and 60,000 per answer. The content reaches the model as untrusted data.
- Lumen’s server has no write path into products. A person’s browser makes the request after they confirm a card.
- A product with
readOnlySessionsset totrueaccepts agent sessions only on GET and HEAD of the routes its manifest names. They work only for the projects of the grant. Agent sessions and the MCP server for coding agents are In development, see Connect Claude Code or Codex (MCP).