Mandates and their evidence

A mandate is a post, not a personality. It has a written remit that comes from the core, a declared set of capabilities, and a list of tools the server will actually serve it. Those three come from registries and are crossed at build time — nothing on this page is a description of intent.

#Why a post and not one assistant

One assistant wearing eleven hats can be asked anything and refuses nothing. A mandate can: the news role holds open-web access and nothing else, so it cannot read your deposited data; the fundamental role holds filings and market data and no web access, so it cannot substitute a blog post for a filing. The refusals are the product, and they are enforced by the capability table rather than by a prompt.

#What counts as evidence here

• VERIFIEDSealed replayA capture of the application, sealed against a named build and listed in a manifest. Eight mandates have one, taken on 2026-09-08 against version 0.0.15 — the version is on the capture, not hidden.
• PLANNEDNo sealed runSix mandates have none. Their page shows the mandate and the tools, and says so. Nothing is shown in place of a run that did not happen.
• PLANNEDA delegation treeNone exists for any mandate. The sub-agent boundary is written and covered by tests in the core, and nothing calls it yet.

LimitBorrowing another mandate’s screen would be the cheapest possible lie on this site, and the hardest to notice. The table below leaves the column empty instead.

#Reading the table

• The mandate is the canonical remit, translated — never widened. The core writes it in French; this surface is English, and a test requires the two lists to cover exactly the same roles.
• The capabilities are the ones the role declares in its own file. The application refuses to open if any role ever combines reading your data with reaching outward.
• The tools are crossed from the capability each tool requires. A tool a role may not call does not appear in its listing at all — it is not shown as a locked door.