Console reference — every screen and the permission it needs
This page is the map of the console. It lists every route the application mounts —
not a selection, not the ones somebody remembered to write up — with the permission a
principal needs to enter it and where to read more.
The console has one navigation structure: nine areas with sections. Every screen
sits in one area and one section of it, and every place that shows where a screen is
names the same place: All areas (in the account menu and the command palette, and More
on a phone), the area directory pages and the row of links above a
screen, which lists the other screens of its section. The top bar names five places, the
first job first (Now, Sessions, Tools, Rules, Ledger; Business adds Organization),
and a place stays marked on the other screens of its section. All areas lists each area
and its screens, two levels, without the places the bar already shows. A navigation filter
replaces the grouped tree with a ranked list of authorized matches; the command palette
uses the same index, ranking and permission projection. An area directory is a page of
links — the entries your permissions allow — not a live reading of capability,
availability or readiness.
A new installation lists the first job only: Now, Sessions, AI tools,
Approvals, the setup wizard and Settings. Every other screen is a preview there: its
address, API and CLI keep working, and navigation, the command palette and the shortcuts
do not list it. An installation that existed before the upgrade lists every screen it did,
and so does one whose administrator has chosen its modules, from its next start, or that
runs the seeded demo.
It is generated. The roster comes from web/src/features/route-census.json, the
append-only census that registry.route-conservation.test.ts pins against the built
router, so a screen cannot be added, moved or lost without this page changing with it.
Each screen’s name and one-line description are the console’s own strings, taken from
the same translation catalog the console renders, so what you read here is what you see in
the product. The tables below group those rows by area, after Now (the overview) and
before sign-in, setup and account. The nine area directory pages sit with the routes
mounted outside the feature registry.
Screen — the name All areas, the area directories and the command palette use.
Path — the URL under your deployment’s console origin. It is a published contract:
a bookmark, a runbook deep link and a docs cross-reference are all this string.
Requires — the RBAC permission. any signed-in user means the route is open to
every authenticated principal; no sign-in means it is served before there is a
session at all.
Reference — the page the console’s own help link opens for that screen.
The headings below are the areas, in the order All areas lists them: Infrastructure,
AI, Data & context, Work & communications, Automation, Security & identity,
Delivery, Oversight, then System & settings.
The console publishes 74 routes. Every one of them is in the tables below, with the
permission it requires and the reference page its in-product help link opens.
These are mounted outside the feature registry. The ones marked no sign-in are
served before there is a session — they are the only console routes that are.
Screen
Path
What it is
Requires
Reference
Accept an invitation
/accept-invite
Where an emailed invitation link lands: the invitee sets a password and joins the workspace, with no prior session.
no sign-in
—
AI
/areas/ai
Directory of the AI area: observe and operate sessions, provider profiles and environments, models, specialized execution and provider reference. Lists the entries your permissions allow.
any signed-in user
—
Automation
/areas/automation
Directory of the Automation area: flows and orchestration, events and notifications. Lists the entries your permissions allow.
any signed-in user
—
Data & context
/areas/data-context
Directory of the Data & context area: capabilities, knowledge and artifacts. Lists the entries your permissions allow.
any signed-in user
—
Delivery
/areas/deployment
Directory of the Delivery area: how deployments are prepared and controlled. Lists the entries your permissions allow.
any signed-in user
—
Infrastructure
/areas/infrastructure
Directory of the Infrastructure area: the inventory and workspaces of the estate. Lists the entries your permissions allow.
any signed-in user
—
Oversight
/areas/observation
Directory of the Oversight area: status and activity, costs and adoption, audit, evaluation and evidence. Lists the entries your permissions allow.
any signed-in user
—
Security & identity
/areas/security-identity
Directory of the Security & identity area: identity and access, policies and governance boundaries, protection and response. Lists the entries your permissions allow.
any signed-in user
—
System & settings
/areas/system
Directory of the System & settings area: administration, installation and maintenance, developer tools and personal preferences. Lists the entries your permissions allow.
any signed-in user
—
Work & communications
/areas/work-communications
Directory of the Work & communications area: the durable cross-session work backlog and governed communications. Lists the entries your permissions allow.
any signed-in user
—
Sign in
/login
The credential and token sign-in page for an already provisioned account.
no sign-in
—
Settings
/settings
Workspace and account settings
any signed-in user
—
First-run setup
/setup
The one-time page that turns a fresh deployment into a usable one: it consumes the setup token and creates the first owner account.
no sign-in
—
Public status
/status-page
Component health for people who are not signed in, refreshed on its own while the page is open.
It is a map, not a manual. It says which screens exist, where they live and who may open
them; it does not walk you through a task. For those, start at
Paths by role or the how-to guides.
Screens whose backend is deny-closed until an operator provisions it appear here like any
other — the route exists and the permission is real. Which module actuates and which is
gated is recorded in the modules overview, and the
honesty and limits page states the general rule. An area
directory listing is not a live capability or readiness reading.
