Who is acting
Personas, roles, and what each one can actually reach
This platform declares 5 personas and 6 roles, and they are not the same thing. The persona decides what a screen puts first and where signing in lands. The role decides what may be reached, and it is enforced on the server at each of the 11 endpoints and each of the 4 page routes named below. 6 of 119 accounts carry a persona on their record; the rest act through whichever lens their role sits at by default. Open any lens for the routes it reaches, the routes it does not, and which of its declared priorities anything actually honors.
7
endpoints behind a role floor
Of 11 declared. The rest need a session and nothing more.
2
endpoints that spend money
Each one calls a paid model, so the floor on it is a cost control as much as an authority one.
6
accounts carrying a persona
113 accounts have never chosen one and take their role default.
5
surfaces that change with the lens
One of them renders on the server. The rest shape the browser only.
4
page routes behind a role floor
Of 97 in the navigation. 0 of them are closed by the persona lens — the floor is held on the role, and the lens moves nothing.
The five lenses
What each persona puts first, and where it opens
A persona is an ordering and a landing page. Two personas looking at the same record see the same record; they meet it in a different order and arrive from a different screen.
Enterprise Chief of Staff
Owns the enterprise operating picture across all 14 functions and arbitrates work that crosses org charts.
acting through it now
2
accounts
puts first
- Cross-function flow health
- Enterprise trust score
- Autonomy phase progression
roles that may act through it
Enterprise Chief of Staff
Function Leader
Owns outcomes for a single function and the human accountability that sits behind its agent roster.
acting through it now
1
account
puts first
- Function KPIs
- Agent roster health
- Capacity released
roles that may act through it
Enterprise Chief of Staff · Function Leader
Process Owner
Designs and tunes the lifecycle stages, autonomy ceilings, and escalation rules a function runs on.
acting through it now
1
account
puts first
- Touchless rate
- Override rate
- Gate throughput
roles that may act through it
Enterprise Chief of Staff · Function Leader · Process Owner
Approver
Sees only the items an agent could not clear on its own and renders the decision that unblocks them.
acting through it now
1
account
puts first
- Queue age
- Decision SLA
- Materiality mix
roles that may act through it
Enterprise Chief of Staff · Function Leader · Process Owner · Approver
Requester
Submits work into the system and tracks it without needing to know which agent or function handles it.
acting through it now
1
account
puts first
- Request status
- Time to resolution
- What still needs me
roles that may act through it
Enterprise Chief of Staff · Function Leader · Process Owner · Approver · Requester · Operator (legacy)
The endpoint register
11 endpoints, each with a declared floor
Before this register existed, two endpoints checked a role and the rest asked only for a session. Every endpoint below now imports its floor from one file, so the answer to "who may write this" is written down once rather than argued in each handler. 4 of them are deliberately open to any signed-in account.
What each floor means in practice
A session below the floor is refused with the rule name ROLE-FLOOR and the floor it failed.
Answer a question about the estate. Reading the estate is open to every signed-in account on purpose. A requester who cannot see the answer cannot check what was done with their request.
Also refuses on: Logs the asking role against every attempt.
Generate a narrative brief. Each brief calls a paid model against the estate account and writes a document other people will quote. That is a spend, so it sits above the two lenses that only read and decide.
Also refuses on: Persists the brief against the signed-in account.
Record an executive decision. A decision binds the estate. A requester may raise work; they may not sign it off.
Also refuses on: ROLE-CEILING — a lens above the role cannot sign · SOD-01 — the raiser cannot also approve · AUTH-REGISTER — no grant, no decision.
Clear an item in the single queue. Clearing an item closes it for everybody downstream of it.
Also refuses on: QUEUE-OWNERSHIP — the item is addressed to one post and its named cover · SOD-01 — the raiser cannot also close it · AUTH-REGISTER — the cap has to reach the value at stake.
Commit a sandbox scenario. A committed scenario changes what the platform will do next. That is the process owner’s job, not the approver’s.
Also refuses on: ROLE-CEILING — the lens has to be one the role holds.
Save or pin a view. A saved view is a bookmark. It creates nothing another account can be held to, and a requester tracking their own work has as much reason to keep one as anybody.
Also refuses on: VIEW-09 — you cannot save a view you could not open.
Open a saved view. The floor lives on the view, not on the route: each saved view carries its own, and the loader applies it.
Also refuses on: The floor stored on the individual view.
Change the persona lens. Choosing a lens is a preference every account may set. What the lens is allowed to do is a separate question, answered by the role.
Also refuses on: PERSONA-CEILING — a lens above the role is not stored.
Pull a discovery export. A discovery export is the whole evidence spine in one file, leaving the platform. It is the one read on this list held above the process owner.
Also refuses on: Scoped to the calling account’s tenant.
Render an evidence pack. The pack is rendered by a paid service and is the document an approver hands to an auditor.
Probe the tenant boundary. The probe exists to be refused, and a refusal that names a boundary is itself information about how the estate is partitioned.
Also refuses on: TENANT-ISOLATION — the owning tenant is never named.
The register is a declaration kept in one file, and each handler imports its own floor from it. Nothing walks the route folder to check that every endpoint appears here, so an endpoint added without a line in the register is enforced by whatever its own handler does and by nothing else.
Two paths sit outside the register on purpose: /api/auth/* and /api/signup. Sign-in, sign-out and the session probe. Closing these would close the door on the door.
The page register
4 page routes carry a floor, and every other route says why it does not
Until this wave the register covered endpoints only, and every screen on the platform opened for anybody who could reach the address. That was right for a readable estate and wrong for the handful of pages whose whole purpose is a spend, a write or the identity directory. A page carries a floor only when the thing the page exists to do is the thing the floor protects. Pages that embed a single control which already refuses at its own endpoint stay open, because closing them would hide a read that everybody is entitled to without adding a boundary anywhere.
Routes closed to a session below the floor
A session under the floor is shown a screen that names the rule PAGE-FLOOR, the floor it failed and the reason, rather than a blank denial.
The page is a console for generating narrative briefs, and every generation calls a paid model against the estate account and produces a document other people will quote. The endpoint behind it has been floored at the process owner since the endpoint register was written; leaving the console open meant offering a control that could only ever refuse.
Same floor on POST /api/brief · guard written in app/(cockpit)/brief/page.tsx
Committing a scenario changes what the platform will do next, for everybody. The page is the commit surface and nothing else on it is a read anyone is missing — the same figures are published on the autonomy and policy pages without a floor.
Same floor on POST /api/sandbox · guard written in app/(cockpit)/sandbox/page.tsx
Every row on this page is an item waiting for a human decision, and clearing one closes it for everybody downstream. A session that cannot clear anything on the queue is being shown a list of other people’s pending obligations with their materiality and their age. The queue as a count is published on the escalations and queue pages instead.
Same floor on POST /api/queue/decide · guard written in app/(cockpit)/inbox/page.tsx
The page names every account that may sign in, the role the directory gives it, the tenant it belongs to, and where the boundary between the live estate and the sandbox sits. It also carries the tenant probe, whose endpoint was already floored at the function leader. An account roster is the one read on this platform that is worth more to somebody who should not have it than to somebody who should.
Same floor on POST /api/tenancy/probe · guard written in app/(cockpit)/identity/page.tsx
93 routes stay open, under 5 named reasons
Open by design is a decision, so it is written down like one. Every route in the navigation is assigned exactly one of these.
The estate is meant to be readable
Reading what the estate is doing is open to every signed-in account on purpose. Looking through a lens above your own ceiling is not holding authority, and a person who cannot see what was done with their work cannot check it. Nothing on these pages can be written from them.
Carries a control that refuses at its own endpoint
These pages embed one control that writes or spends, and that control is already refused on the server by the endpoint register. The page around it is a read of the governance record, so a second gate would remove the read and add no boundary.
Your own record and your own work
These pages show the account its own requests, its own saved views and its own profile. Putting a floor on them would gate a person out of their own request.
This is where the rules are published
Closing these would mean the only way to learn what the platform refuses is to be refused by it. A boundary a reader has to discover by trial is not a declared boundary.
Explains the platform rather than reports on the estate
These pages describe how the platform is meant to work. There is no estate record behind them to protect.
This register is a declaration in one file, and each gated page imports its floor from it. Nothing walks the route folder to check that every page appears here, so a page added without a line in the register is open, and open silently. The four gates below are the whole list.
Declared against exercised
15 declared priorities, 1 of them honored by an ordering the lens actually changes
Each of the 5 personas declares three things it puts first, and the front door prints them under the acting lens. Printing is not ordering. Read one at a time against the surfaces that branch on a persona: one priority changes what is shown because of the lens, one is honored identically for every lens, and 13 are declared and never exercised at all.
1
Exercised by the lens
A surface orders or filters differently because this lens is the one acting.
1
Exercised, but not by the lens
A surface does order by this, and it orders the same way for every lens.
13
Declared, never exercised
Printed under the lens on the front door. Nothing sorts, filters or scores by it.
The 13 priorities nothing orders by
Named here rather than left implied. Each is printed under its lens on the front door and honored nowhere.
The priority table is kept by hand. It was compiled by reading the persona-aware surfaces one at a time, because nothing running can be asked which component sorts by which phrase. A priority marked as never exercised means no persona-aware surface orders or filters by it; it does not mean the estate never reports the number.
Every persona is also the name of a role, and the floors are held on the role. An account holding a high role that chooses to look through a low lens still opens every page its own role opens — the lens changes nothing about reachability. The rows below are computed for the role of the same name, which is the strictest reading of the lens and not what a session carrying that lens necessarily gets.
Who holds what
The accounts behind the roles
119 accounts exist on this platform. Each row shows how many hold that role, how many of them have chosen a persona rather than inheriting one, and the ceiling the role sits under.
Role census, read live from the account table
The ceiling is the set of lenses the role may act through. Lenses above it stay readable and refuse every write.
The account census counts rows on this platform only. It is not an identity directory, and it says nothing about whether the person behind an account still holds the role the record gives them. Every role on this list has at least one account behind it.
Where it shows
5 surfaces change with the acting lens
This is the whole list. It is short, and saying so is the point: a persona is not a permission model, and pretending otherwise would be the easiest lie on this platform to tell.
components/inbox/inbox-board.tsx
browserFilters the queue to the items this lens can clear and counts them on the strip.
components/decisions/decision-actions.tsx
browserRefuses a decision above the lens materiality before the request is sent.
components/sandbox/scenario-console.tsx
browserBlocks a policy commit taken through a lens above the role ceiling.
components/shell/command-bar.tsx
browserNames the acting lens and its remit in the top bar.
app/(cockpit)/page.tsx
serverRenders the acting lens, its priorities and its landing page from the session.
The surface list is kept by hand. It is the honest answer to "where does the persona actually change what I see", and it is short.
Actions
What is waiting on a person
The persona layer is a small amount of code doing a specific job, and most of what is left undone here is undone on purpose. These are the parts that are not.
accounts that have never chosen a persona
They are not stranded: an account with nothing stored acts through the highest lens its role holds. But nobody chose that, so the landing page and the ordering they see were picked by a default rather than by them.
declared priorities no ordering on this platform acts on
Each persona declares what it wants put first. Most of those declarations are printed and then ignored: the list underneath is sorted the same way for every lens, or not sorted at all. A declaration that changes nothing is a label, and it is counted here as one.
page routes that now refuse a session below their floor
Each of these pages exists to do the thing its floor protects — spend, write or read another tenant. A session under the floor gets a screen that names the rule, the floor and what the session holds, rather than a blank page. Every other page route stays open, and the register says why.
persona-aware surfaces that run in the browser alone
Each one shapes what is offered before a request is sent. None of them is the boundary — every write they guard is refused again at the endpoint, by role, on the server.
Operations
What this desk is allowed to start
A surface that only reports is not operable. This is the work this page can set in motion, and the bound it runs into.
Trigger and bound
This page reads the account table twice and the endpoint register once. It writes nothing. The register is a declaration in source, so this page can say what each endpoint is meant to refuse and cannot say that no other endpoint exists. The surface list beneath it is kept by hand for the same reason: nothing running can be asked which components branch on a persona.
Live observability
What the record shows right now
The 11 endpoints named in the register, by the lowest role allowed to reach each one. Every one of them also requires a session before the floor is consulted.
Current distribution
11 endpoints
Is policy and strategy coming to fruition
Whether the written intent is holding here
Partly. The role is now enforced on pages as well as on writes, and the register names the reason for every route that carries a floor and every route that does not. What the persona itself changes is still small, and most of what it declares it never does.
Not holding on the record
The intent was that a person signing in should meet the platform through their own job rather than through one shared front door. That is now true in a narrow sense: the acting lens is stored on the account, read on the server, and used to choose where sign-in lands and what the front door puts first. It is not true in a wide one. 4 page routes now refuse a session below their floor and 0 are closed by the persona — the boundary is the role, and the persona is not one. The other 93 page routes are open, each under a stated reason rather than by omission. Of the 15 priorities the five lenses declare, 1 changes what a list actually does, 1 is an ordering every lens already gets, and 13 are declared and never exercised. Every one of the 97 page routes renders the same content whichever lens is acting — what a session can open is decided by the role — and 5 surfaces in the whole platform change with it — 1 of them on the server. The 7 floored endpoints and these 4 floored routes are where the boundary is actually held. A persona is an ordering and a landing page. It is not a permission, and this page exists so that nobody has to guess which of the two they are looking at.
What a persona still does not do
Four page routes are now closed to a session below the floor declared for them, and each one names its reason on the register. None of them is closed by the persona: the lens changes emphasis, ordering and the landing screen, and the role is what closes a route. A lens above the role ceiling still opens every page the role itself opens, so the lens named in the header is still not evidence of authority.
A lens above the role ceiling can still be looked through. That is deliberate — the estate is meant to be readable by everyone who works in it — but it means the lens named in the header is not evidence of authority. Every declared lens currently has at least one account acting through it.
The persona is stored on the account and read on the server, so it survives a new browser and cannot be forged from one. It is still a preference, not a credential: a stored persona above the role ceiling is quietly ignored in favor of the ceiling, and asking for one through the switcher is refused outright with the rule PERSONA-CEILING.