Skip to content

OPERATOR-CLIENT-FILE-USERS-VIEW-01 — Design Note

Type: Design note (capture artefact — NOT a brief) Status: Parked / deferred behind People Phase 1.5 Author: Claude · Date: 2026-06-14 References: PC-SPEC-01 v0.3 (two-layer identity model; Open Question "Admin→Team surface ownership"), ADR-020, ADR-038, ADR-040, OPS SURFACE RULE, HARD SEPARATION RULE

Why this note exists

Surfaced 2026-06-14 while scoping the People Phase 1.5 floor. The question raised: do the client's users appear on the operator (T3) surface, and how do they wire to the client card?

Investigation (live, admin.rtopacks.dev, as operator) established the actual state — recorded here so the model is not lost and the future operator-side build has something to reference. This note does not authorise build. It is deferred behind the Phase 1.5 floor (person-record edit path). It belongs in the same canon decision as the spec's open question on Admin→Team surface ownership.

Verified current state (2026-06-14, live)

Two distinct operator surfaces exist:

  1. Organisation record — /organisations/{rto_code} (e.g. /organisations/45329). The TGA view of any RTO in the market — client or not. Live, read-only, regulator-sourced, keyed by RTO code. Tab strip: Summary / Contacts / Addresses / Scope Overview / Qualifications / Skill Sets / Units / Courses / Interactions / Radar.

  2. Client file — "golden record" — /client-file/{cli_key} (e.g. /client-file/cli_eacf1ad4-...). The org record lifted out and frozen into client-db at the point UCCA became a client. Self-labelled Client file · golden record, provenance RTOpacks-created, minted 2026-06-06. Carries the regulator data (org record, 5 addresses, 9 contacts, 106-row scope, classifications) plus the client layer: client_id (cli_ key), "Restricted" marking, condition-of-registration (historical). Footer states explicitly: "Render-only operator view · client-db (read-only) · edit/corrections layer deferred."

Dashboard tile "RTOpacks Clients" reads "Provisioning not yet live." /clients 404s — there is no client list/index route yet; the client file is reachable directly by key.

Bottom line: the operator client surface is render-only today. No users, no seats, no billing are surfaced on it. The "edit/corrections layer" is explicitly deferred. This view is net-new build on a surface still in its first posture.

The model (the decision this note records)

The client file is the correct home to surface (not store) a client's users and billing, as a new tab — the operator's single join view across all four data domains:

CLIENT FILE (operator T3 view, keyed by cli_)
│
├─ Regulator golden record   ← client-db (read-only)      [exists today]
├─ Users / logins            ← identity-db (users, tier_grants)
├─ Seats / billing posture   ← ops-db (seat_limit, consumption, billing)
└─ Linked workforce          ← workspace-db (pc_persons, via user_id soft-link)

The join key chain: client-db.cli_ → org_id → identity-db.users + tier_grants → pc_persons.user_id soft-link (ADR-040) → extended-identity (People) records. Seats read from ops-db keyed to the same client.

What the new tab is

A Users & Seats tab on the client-file tab strip: - Users: each login on the client — display name, email, tier grant(s) (T4 / T4A / T4B), passkey/last-login, and whether soft-linked to a pc_persons record (the same user_id link the client-side Team↔People work surfaces, seen here from the operator side). - Seats: seat_limit / consumed / free, read from ops-db. T4A consumes; T4 role and T4B do not (PC-SPEC-01 v0.3 §Seats). - (Later) Billing tab: payment/plan posture, ops-db.

Posture: render-only first

Matches the surface's current state ("edit/corrections layer deferred"). The Users & Seats tab is a read view first. Any operator action (mint a login, change a seat) is a later, separately-scoped capability and must still obey the Admin-Only Mint Rule semantics — minting is an administrative act, whether performed by a client T4 admin or a T3 operator acting on the client's behalf. To be settled when the action layer is specced; not in scope for the read view.

Rule boundaries (why this model is clean)

  • OPS SURFACE RULE — holds. ops-db is never surfaced to RTOs or end users. The operator (T3) is the one party legitimately permitted to read ops-db. Surfacing seats/billing on the operator client file is the correct, permitted place for it. Hard constraint: this view and its ops-db reads must never propagate to, or be reachable from, any T4 (client-side) surface. The client-side People seat monitor (PC-SPEC-01 v0.3 §Seats) reads seat posture via a boundary that carries no financial data (ADR-038) — that remains the client-side path; the operator client-file view is separate and richer.
  • HARD SEPARATION RULE — holds. This is a cross-database read join (client-db + identity-db + ops-db + workspace-db) within one regulated-tenant context. It does not mix regulated training corpus (rto-nrt-db) with ops or micro data. Reads only; no write crosses a boundary.
  • ADR-038 — holds. identity-db carries no financial data. Seats/billing come from ops-db, joined at render time on the operator surface only.
  • ADR-040 — consistent. The pc_persons.user_id soft-link is the conduit; this view reads it, does not auto-materialise or merge.

Dependency / sequencing

Deferred behind People Phase 1.5. Rationale:

  1. Different surface (operator admin app) and different consumer (cross-client T3) from the Phase 1.5 arc (client-side T4 experience). Shares the underlying join, not the surface.
  2. The client file is explicitly render-only with corrections deferred — adding a Users tab is net-new operator-app build on a surface that has not yet got its own edit/corrections layer.
  3. The Phase 1.5 floor (person-record edit path) is the floor under this too. This tab is a view of person records joined to logins. Until person records can be edited, the view shows the same read-only stubs as the client-side People register. Build the floor; the views light up on both sides.

Slots into: PC-SPEC-01 v0.3 Open Question — "Where does the Admin→Team surface canonically live." Both questions are about where identity is read and by whom; they should be settled together. This note is the operator-side half of that decision.

Open questions this note does not resolve

  • Surface ownership / spec home. Does the operator admin app get its own spec (operator-admin-spec), with this view a section of it? Likely yes — the operator surface is now substantial (org records, client files, corpus sync, regulatory feed) and is outgrowing being documented only as a dependency inside module specs.
  • Action layer. When (if) the operator can act on a client's users/seats from this view, the Admin-Only Mint Rule and operator-impersonation model (ADR-022) need to be reconciled — is an operator minting a client login an impersonation act, an operator-authority act, or forbidden (client must self-administer)? Out of scope here; flagged for the action-layer spec.
  • Client list/index. /clients 404s; provisioning "not yet live." A client index route is implied before this scales beyond direct-key access, but is independent of this note.

Capture artefact. Records the model so it survives to the operator-side build. Not a brief. Deferred behind People Phase 1.5.