Codex 4 — People, User Types, and Permissions
One canonical Person; user types, roles, and scoped membership.
- Authority rank
- 3
- Version
- v1.1
- Adopted
- unrecorded
- Held by
- Stewardship Office
- System
- SYS-01
Source · docs/codices/CODEX-4-people-and-roles.md
The canonical person
There is one Person per human being in the institution, forever. Every relationship — student, advisor, founder, investor, employee — is a membership attached to that person, not a separate account. A person may hold many memberships simultaneously and across decades. This is the single most important structural rule in the institution: it is what makes a lifetime record possible.
User types
Each type is a membership, with what they see, what they own, and what they must never see.
| Type | Sees | Owns | Never sees |
|---|---|---|---|
| Member | Own capability record, public knowledge | own profile, goals | others' private records |
| Scholar (student) | Enrolled curriculum, own progress, cohort surface | submissions, portfolio | others' grades, unpublished assessments |
| Mentor | Assigned mentees' shared progress | mentoring notes | mentees' unrelated records |
| Advisor | Assigned engagements, client workspace | engagement artifacts | unassigned clients |
| Researcher | Sources, pipeline, anonymized outcome data | drafts, methodology | identifiable member data |
| Fellow | Research pipeline, faculty commons | own research | administrative data |
| Founder | Own venture record, program surface | venture artifacts | other ventures, investor internals |
| Investor | Portfolio and reports shared with them | own investor profile | founder private material, other investors |
| Enterprise client | Own organization's cohorts and aggregate capability | organization settings | individual employee detail beyond agreed scope |
| Partner institution | Shared programs and agreed reporting | partner configuration | member-level data |
| Employee | Role-scoped internal tooling | own work | anything outside role scope |
| Executive | Institutional dashboards | targets, allocation | raw member content without cause |
| Steward | Doctrine, commitments, trust metrics | Codices, amendments | operational member content |
| Administrator | Operational state, support surfaces | configuration | member content without a logged, justified reason |
Permission model
- Roles are data, not code. Roles live in a dedicated table keyed to person and scope. They are never a column on a profile.
- Permissions are derived from roles, checked server-side, and re-checked at the data layer. A hidden UI element is not a permission.
- Scope is explicit. Every role grant carries a tenancy scope: individual, cohort, organization, division, or institution.
- Least privilege by default. New surfaces start closed.
- Elevated access is logged. Any administrator or steward read of member content produces an audit record with a stated reason.
- Delegation is time-bounded. Temporary access expires; it is never granted indefinitely.
- Separation of duties. The person who authors a credential standard is not the sole person who issues credentials against it.
Identity
Authentication is separate from identity. A person may have several sign-in identities (email, institutional SSO, social provider) bound to one Person. Enterprise and university partners must be able to attach SSO without changing the person model.
Lifecycle
Join, active, dormant, alumni, departed, deceased. A person's capability record persists through all of them, subject to their deletion rights. Dormancy never deletes a record silently; departure never erases the institution's obligation to honour issued credentials.