Staff Room

Everything findex’s governance writes — the audit log, disputes, egress findings, the grant list, what people actually ask, and what somebody wants findex to learn — with a reader in front of it. Read-only over findex’s own stores, so it engages no database grant and reads no business data at all.

What you are looking at

Access here is a capability, resolved by the same gate as every question you ask. The nav shows the screens you hold. Hiding a link is a courtesy — the permission itself is checked on each route, every request, server-side.

Worth saying plainly: this is not “admin settings”. It is the ability to read what colleagues asked findex, because the audit log stores question text and questions name customers. That is why it is granted to named people rather than to a group.

Three of the nine are not viewers. Review queue and Knowledge proposals authorise an outcome — accepting, declining or parking what a colleague or an agent submitted — and Data knowledge, though read-only itself, shares the same gate for now. All three are granted on staffroom.learning separately from the viewer bundle above.

Knowledge proposals and Data knowledge are one loop, read in that order. The first is the inbox — machine-found candidates, none of which findex relies on. The second is the register — what a human has approved, which findex does. Accepting in the inbox is what moves a thing from one to the other, and nothing else does.

Where each screen actually is — nine built, one still a genuine absence

As of 2026-08-31, all nine screens the nav can show are built, tested and merged to dev. Every one of them has a route — the one remaining absence is narrower than a whole screen: the coverage half of Grants & coverage reads a build-time artifact rather than a request-time route, by design, and is called out below. If a screen you hold renders an empty table or an error instead of what is described below, that is a deployment gap, not one of these — a stale absence panel is a defect, an empty table on a working route is a different one, and this page cannot tell you which you are looking at.

Audit log: Built, tested and deployed (#33, #205). Ruled entry-only — the entry, never the words a colleague typed.
Usage: Built, tested and deployed (#131, #205), aggregate-only by construction.
Review queue: Flagged answers and learning requests, one queue, accept / decline / park (#144, #213, #282 Phase 1c) — this is where the old “Disputes” screen’s work landed. Gated on staffroom.learning, an outcome capability, not a viewer one, so it is not part of the bundle above. Whether a plain staffroom.disputes viewer (question shapes without the review actions) is still owed its own screen is #186, still open.
Egress findings: Persisted and readable (#29). The redacted value itself is never shown, only the finding.
Knowledge proposals: The inbox (#312). What the nightly warehouse crawl noticed and is asking about — accept / decline / park with a required note. Accepting is the whole approval: the reviewer edits the finding on the card and a scheduled job writes that exact text to docs/data-knowledge/findings/, gates it and commits it (#489, #503, D90). This row said the landing was “a human editing the finding by hand” until 2026-08-23, a day after that stopped being true — the same staleness this panel’s own header warns about, in the row describing the newest thing on the page.
Data knowledge: The register — what findex has actually learned and may rely on (#305/H7). Read-only by design: approving happens in the inbox above, and a write action here would be a second way to approve the same finding. Generated at build time, so one accepted today appears after the next deploy.
Grants & coverage: Two halves, and only one is still an absence. The allocations half — select a user, see and edit their allocation, scope and Staff Room capabilities — is a fully live, request-time API (#320): a real picker over GET/POST /v1/staffroom/allocations, writable in dev and read-only in every other stage. This row said “No API at all, by design” about that half until 2026-08-31, over two weeks after #320 shipped it (2026-08-16) — filed and corrected as #860. The coverage half — what Appendix A grants and whether the governance run passed — is still, deliberately, a build-time artifact rather than a route (#31): Appendix A is a document and the governance run is a CI run, so a request-time re-read would be a second copy of a control whose value is that it is reviewed in a diff. That half is the one genuine remaining absence named in this card’s title.
What we are connected to: The integration inventory (David, 2026-08-23): every data source findex is connected to, Findel and external, and whether reading it is live, on request or stored. Like the coverage half above, it reads a build-time artifact rather than a route — the same #31 reasoning applies, so this is not a second absence, it is the same one. Rides the staffroom.grants capability rather than a capability of its own; the artifact itself is public bytes.
People: User management (#471): add a person, get them signed in, and assign their worker-class group, Staff Room capabilities and allocation scope — three separate write paths kept as three labelled sections rather than one combined form. Gated on staffroom.people, its own capability, deliberately separate from staffroom.grants because creating a directory identity is a materially larger power than editing an existing one’s maps. Writable in dev; the same dev-only boundary as the allocations half above, rendered rather than hidden outside it.

None of these render an empty table or an error to mean “nothing built”. An empty table is a claim that findex looked and found nothing, and that claim would be false for any screen named above.