Skip to content

uid: T-192 title: Org chart β€” standing and reporting lines, separate from what badges permit status: todo area: user-management created: 2026-07-27 assignee: unassigned owner: girafeev1 related: T-190, T-188, T-151

T-192 β€” Who is senior to whom, and who sits where

UID note: claimed as T-191 on 2026-07-27; renumbered to T-192 on merge after Accounting (Diagnostics) landed their T-191 first. Renumber-on-merge rule, per the board README.

Why

Two things the system cannot currently answer, both of which it is now being asked to:

  • "Anyone above the requester may approve" (T-190) is not computable. The roles are super_admin, admin, auditing_accountant, bookkeeper, project_admin, pending. Only the first two are ordered relative to each other; a bookkeeper and a project administrator are lateral peers, not senior and junior. Any ranking the code invented here would become policy without anyone having decided it.
  • "Who manages whom" has one weak answer β€” lineManagerUid, a single named person whose absence is a hard refusal (see T-190) β€” and no notion of a branch or unit at all.

There is a job title (Individual.system.position), but it is free text and explicitly documented as not an access surface. "Senior Bookkeeper" does not order itself against "Bookkeeper".

Owner, 2026-07-27 (verbatim): "as this some sort of human capital system, I'm wondering if we should create an organization chart of some sort, so that we always know which level of position we're handling so that people on a certain branch or people above this level can manage whom"

The governing model (owner, 2026-07-27)

Owner, verbatim: "let's think that badge is system-wide and Org Chart is personnel-wide"

Stated as a rule that decides cases:

  • A badge answers "what may I do?" β€” it names an ability and never names a person.
  • The chart answers "to whom?" β€” it names a relationship and never grants an ability.
  • A permitted action needs both: the badge supplies the verb, the chart supplies the object.

The safety property this buys, and the one to protect: seniority can never widen what someone may do. A branch head with no user-management badge manages nobody; the badge grants the ability, and the chart only narrows which people it may be exercised on. Without that ordering the chart becomes a back door into access, and the system ends up with two competing answers to "am I allowed?" β€” the exact failure already corrected twice in T-188 (two job titles that disagreed) and T-162 (hidden code recipient lists competing with visible configuration).

Worked cases, for whoever builds this:

Question Answered by
May I open Accounting? badge β€” a capability, no person named
May I approve Nan's expense? chart β€” a relationship
May I invite a new user? badge (admin)
May I invite someone senior to me? chart
Who is alerted about Nan's invoice? Notification Hub tokens, which the chart can extend ("their manager")
May I sign a WOPC? neither β€” the director facet, a governance fact about company directorship. Out of scope; do not absorb it.

One genuine grey area to settle before building: may a bookkeeper edit the bank details of someone outside their branch? The badge says they may edit bank details at all. Whether the chart narrows that to their own branch is a policy choice, not a technical one.

Scope (proposed, pending the owner's answers below)

  1. Rank on the position β€” one ordinal per person. This alone unblocks T-190 and replaces the single line manager. Smallest useful increment; everything below is optional on top of it.
  2. Org units / branches β€” only if "branch" means something the system does not already carry (see the open question).
  3. The visual chart last. A chart is the output of a stored hierarchy, not the mechanism. Drawing it first produces a picture nothing enforces.

Storage belongs on the directory record, beside position β€” where the company's assertions about a person already live, and which T-188 makes the single home for person-facts. Not on the account record: contractors, directors and external auditors have standing without ever having a login.

Open questions (owner)

  • How many people is this describing? The code still carries comments calling this a two-person app. For a handful of staff, a rank field alone is right and org units are ceremony. If contractors, session musicians and external auditors belong in the chart too, the shape changes.
  • Is a "branch" a subsidiary, or a function within one? A branch dimension already half-exists: every user has a primary (employer) subsidiary plus an access list β€” it simply is not used for management rights. If branch means ERL vs EPL vs MEL, most of this is already stored. If it means Finance vs Projects vs Records within a subsidiary, that is genuinely new.
  • Does subsidiaryAccess stay a badge-side concern? It scopes data, not people, so it reads as system-wide under the rule above β€” but it is the closest existing thing to a branch and should be ruled on explicitly rather than left ambiguous.

Sequencing

Should land before T-190, which cannot be built without a computable notion of seniority. Preview-gated like all UI work on this estate.

Source

Owner conversation 2026-07-27 while reviewing the invitation document structure; the model quote is from the same exchange. Findings verified against lib/rbac/types.ts (role list), lib/individuals/types.ts (system.position, director facet) and pages/api/approvals/index.ts. Source: User Management Β· https://claude.ai/code/session_01GGT5n9vCxKWoUQSRAfMSiW