Permission codes
Authorization is expressed as permission codes. Every endpoint declares the codes it requires; a caller holding all of them is permitted, and one lacking any is refused with the missing codes named in the response.
Naming
Codes follow resource.action:
entity.read
match-profile.update
consent-record.create
The resource is the thing acted on; the action is what is done to it. Common
actions are read, create, update, and delete, with domain-specific ones
where the operation is not ordinary CRUD — entity.merge, entity.match.
The catalog is closed
Codes are defined by the platform, not invented by tenants. A tenant composes roles from the catalog; it cannot create a code the platform does not enforce.
This is what keeps authorization meaningful. A code nothing checks would be a permission that grants nothing while appearing to grant something.
New codes are reconciled into every tenant automatically when the platform adds them, so a tenant's catalog is never behind the software.
Resource families
| Family | Governs |
|---|---|
entity | Records, their source records, relationships, and merge lineage — entity.source-record.*, entity.relationship.*, entity.merge-history.* |
entity-type, attribute-def, relationship-type | The data model |
rdm | Reference data — lookup types, values, transcoding, hierarchies |
standardization-rule, standardize | Standardization configuration and execution |
auth | Authentication operations, including auth.impersonate |
dq | Data quality scores |
match-profile, match, potential-match, potential-overlay | Matching configuration, execution, and review |
relationship-resolution-rule, relationship-assertion | Relationship resolution |
search | Search |
bulk-job | Asynchronous jobs |
interaction, interaction-type | Interactions |
consent-record, consent-type, dsr | Consent and privacy requests |
audit | The audit log |
user, role, group, permission | Identity and role administration |
abac-policy, field-masking-rule | ABAC policies and masking |
identity-provider, session, system-token | Authentication and machine credentials |
webhook | Event delivery |
config-snapshot, tenant-ui-config, statistics, source-system | Tenant configuration and reporting |
platform | Cross-tenant administration |
me | The caller's own profile, inbox, and notifications |
assistant | Access to the in-app assistant |
The authoritative list is served by the platform. Query it rather than transcribing from here — a list copied into a document drifts.
Roles
A role is a named bundle of codes, composed per tenant. Users hold roles directly or through groups, and effective permissions are the union of all of them.
Union, not intersection: holding two roles grants everything either grants.
Resolution is live
Effective permissions are resolved per request, not baked into a token. A grant or revocation takes effect on the caller's next request.
Two independent mechanisms make it so. Changing a user's status invalidates their cached authorization context, so the next request is refused; and every token's identifier is checked against a revocation list on each request, so a revoked session is rejected outright.
You do not need to shorten token lifetimes to make deactivation effective.
Self-action guards
A user cannot act destructively on themselves — deactivating their own account, deleting themselves, or removing their own roles is refused even with every permission.
This is not paternalism. It prevents the last administrator locking the tenant out of its own user management, which is unrecoverable from inside the tenant.
Assistant access is not data access
assistant.access grants use of the in-app assistant. It grants no data
access — the user's other permissions already decided that, and the assistant
acts as the user.
Next
Last verified against commit e6fa3bb7 (2026-08-03)