Membership Authorization Model
Authorization Boundary
Protected Membership requests pass through Platform authentication, application access, licensing and workspace availability before the declared operation authority and record guards apply. Public module health responses expose operational health rather than customer records. Partner functions, database claims and scheduled jobs use trusted machine authority; an absence of a human permission key does not make those entry points public.
Console operations are for customer staff. Routes admitted to portal access also serve authorized console users, but a portal member receives only the powers actually granted. Unit officers and personal self-read users therefore have different boundaries. Platform owns authentication, roles, policies, assignments and the recorded entry grants for Rhythm staff. HQ status does not itself grant access to Membership customer records.
Scopes
Customer-wide Platform assignments can contribute workspace authority. Membership evaluates the application gate and workspace-level operations in the addressed workspace. Configuration, structure, billing, direct staff term changes and status processing do not accept unit-only authority.
Officer-capable permissions declare organizational-unit scope. Grants reach the selected unit and descendants, and service checks resolve the relevant membership chain or affected units. An exact-unit-only grant type is not implemented. Reporting datasets retain workspace-level query authority and do not provide officer row filtering.
Personal self-read uses the account’s linked contact. That contact relationship is a service guard, not an arbitrary record grant. Trusted service execution is a separate boundary governed by cloud roles, registered service functions and database execution grants.
Roles
The first five profiles in this model are proposed permission bundles for the responsibilities described by the area's actors. They are not built-in role declarations, deployed assignments or new authorization policies. Customers compose and assign their actual roles in Platform. A migration producer, scheduled worker or connected application is a machine execution identity rather than another human role.
Platform supplies shared customer roles and generates application policies by permission tier. Its role and policy contracts remain authoritative for that composition; this examination does not assert their deployed Membership entitlements. The Membership service declares one built-in portal policy with application access and personal self-read. Platform must attach it to the Portal Member role before that declaration produces access.
Permission Catalogue
The assignable keys below come from the service catalogue and the keys named by capabilities and operations. Frontmatter records operation identifiers, surfaces and additional rule references. API access declarations establish eligible channels; they do not establish a built console or portal screen. The current console member list is a synthetic prototype with no Membership permission enforcement.
| Permission | Intent |
|---|---|
membership.affiliations.manage | Maintain dated membership connections within the evaluated unit scope. |
membership.application.access | Open Membership in an available, licensed workspace. |
membership.billing.manage | Administer and execute renewal templates, runs and recurring definitions. |
membership.billing.read | Inspect renewal templates, runs, planned actions and recurring definitions. |
membership.configuration.manage | Administer membership offer configuration, application processes and area settings. |
membership.configuration.read | Inspect membership offer configuration, application processes and area settings. |
membership.lifecycle-events.query | Query workspace membership lifecycle records through the shared query layer. |
membership.member-contact.update | Request allowed contact-field changes for a member within the evaluated unit scope. |
membership.members.read | Inspect memberships and related facts within the evaluated unit scope. |
membership.membership-snapshot-affiliations.query | Query unit connections in published monthly reporting copies. |
membership.membership-snapshot-counts.query | Query movement and standing counts in published monthly reporting copies. |
membership.membership-snapshot-dimensions.query | Query captured characteristics in published monthly reporting copies. |
membership.membership-snapshot-members.query | Query members in published monthly reporting copies. |
membership.membership-terms.query | Query workspace membership periods through the shared query layer. |
membership.memberships.create | Establish a membership and its initial committed period without an order. |
membership.memberships.enroll | Request an enrolment order for a member within the evaluated unit scope. |
membership.memberships.history | Inspect recorded membership and term revisions with additional read authority. |
membership.memberships.query | Query workspace membership records through the shared query layer. |
membership.memberships.suspend | Suspend or restore principal membership standing. |
membership.operations.run | Request an immediate workspace status refresh. |
membership.programs.manage | Administer membership programs and their unit requirements. |
membership.programs.read | Inspect membership programs and their unit requirements. |
membership.rosters.export | Capture and retrieve a roster export within authorized scope. |
membership.self.read | Inspect the holdings associated with the signed-in member’s linked contact. |
membership.structure.manage | Administer association units, hierarchy, links and local financial context. |
membership.structure.read | Inspect association units, hierarchy, links and local financial context. |
membership.term-affiliations.query | Query workspace dated unit connections through the shared query layer. |
membership.terms.correct | Correct a committed membership period while preserving recorded values. |
membership.terms.create | Add a committed period without an order. |
membership.terms.renew | Request a renewal order for a membership within the evaluated unit scope. |
membership.terms.terminate | Close a committed membership period with a reason. |
The frontmatter also preserves exact compound and no-key declarations from the existing service contracts because conformance compares those values literally. These entries describe requirements and trust boundaries; none is an additional permission that a role can grant. A compound history declaration requires both of its keys. A dataset declaration requires the key of the selected dataset, rather than every listed dataset key.
Role Entitlement Matrix
The columns show proposed profiles before scope, conditions, explicit denies, application availability and record guards. A dash supplies no grant. The portal column shows the declared policy's contribution, conditional on Platform attachment. No column proves a deployed role.
| Permission | Setup administrator | Coordinator | Analyst | Setup reader | Unit officer | Portal Member |
|---|---|---|---|---|---|---|
membership.affiliations.manage | — | Workspace | — | — | Unit | — |
membership.application.access | Workspace | Workspace | Workspace | Workspace | Workspace | Workspace |
membership.billing.manage | Workspace | — | — | — | — | — |
membership.billing.read | Workspace | — | Workspace | — | — | — |
membership.configuration.manage | Workspace | — | — | — | — | — |
membership.configuration.read | Workspace | — | — | Workspace | — | — |
membership.lifecycle-events.query | — | — | Workspace | — | — | — |
membership.member-contact.update | — | — | — | — | Unit | — |
membership.members.read | — | Workspace | Workspace | — | Unit | — |
membership.membership-snapshot-affiliations.query | — | — | Workspace | — | — | — |
membership.membership-snapshot-counts.query | — | — | Workspace | — | — | — |
membership.membership-snapshot-dimensions.query | — | — | Workspace | — | — | — |
membership.membership-snapshot-members.query | — | — | Workspace | — | — | — |
membership.membership-terms.query | — | — | Workspace | — | — | — |
membership.memberships.create | — | Workspace | — | — | — | — |
membership.memberships.enroll | — | — | — | — | Unit | — |
membership.memberships.history | — | Workspace | — | — | — | — |
membership.memberships.query | — | — | Workspace | — | — | — |
membership.memberships.suspend | — | Workspace | — | — | — | — |
membership.operations.run | Workspace | — | — | — | — | — |
membership.programs.manage | Workspace | — | — | — | — | — |
membership.programs.read | Workspace | — | — | Workspace | — | — |
membership.rosters.export | — | — | — | — | Unit | — |
membership.self.read | — | — | — | — | — | Own contact |
membership.structure.manage | Workspace | — | — | — | — | — |
membership.structure.read | Workspace | — | — | Workspace | — | — |
membership.term-affiliations.query | — | — | Workspace | — | — | — |
membership.terms.correct | — | Workspace | — | — | — | — |
membership.terms.create | — | Workspace | — | — | — | — |
membership.terms.renew | — | — | — | — | Unit | — |
membership.terms.terminate | — | Workspace | — | — | — | — |
Protected Actions
Operation permission does not finish the authorization decision. Officer contact changes use the contributing roles' field allow-lists. Officer renewals and enrolments use the scoped ordering guards and purchase preparation. Affiliation mutations check the units affected by the change. Roster generation captures authorized membership identifiers at request time, and retrieval also checks the requester or workspace-wide authority.
History has an additional permission requirement and remains a workspace-staff timeline in the examined implementation. Personal lifecycle information comes through the member's self-read. Configuration and direct staff mutations retain their own reference, state, version and lifecycle guards, recorded in the permission catalogue's rule references. No examined Membership operation establishes a second-approver requirement. Rhythm staff entry uses Platform's separately recorded customer-access mechanism.
Guards Distinguished From Permissions
A permission is an assignable power. A guard tests the record or proposed action after that power has been evaluated. Unit reach, linked-contact ownership, contact-field allowance, request ownership, current state, valid references and versions are guards. These checks cannot supply a missing permission or override a deny. The catalogue cites the owning rules rather than creating another home for their requirements.
Membership derives scope checks from the request's evaluated grant slice and current record context. It holds no additional local access cache, but Platform's gateway decision can remain cached for sixty seconds and signed context can remain valid for thirty seconds beyond that. Appointment validity is evaluated at request time. Grant withdrawal must not be presented as an immediate cutoff, and an already captured export is not recalled automatically.
What People See When Refused
The API distinguishes missing authority from record invisibility. A missing required key produces a forbidden response. A membership outside the caller's unit reach appears absent. A visible membership with an impermissible changed unit produces a scope refusal, and a contact-field refusal identifies the disallowed fields. Validation and state conflicts explain the rejected request; stale writes identify the version conflict.
The application boundary provides refusal codes for unavailable access or licensing through Platform. Partner adapters that are not wired can fail even after authorization succeeds; those failures are not permission refusals. The prototype member list shows loading, empty results, query errors and action notifications, but provides no Membership-driven refusal or read-only state. This model therefore describes observed API refusals without claiming a connected screen experience.