3. `resource:action` keys; scope lives on the assignment
Permission keys are resource:action, split on the first colon (actions may contain colons, as in read:reason for field-level permissions).
Context
The team's existing pattern is roles, role permissions and user-role mappings with resource:action permissions. Real organisations also need the same role at different reach ("manager of this team", "HR for these units").
Decision
Permission keys are resource:action, split on the first colon (actions may contain colons, as in read:reason for field-level permissions). A role's permission has a mode: inherit takes the assignment's scope; self and global fix it. The scope (built-in global/self, product prefix or set types) is on the assignment, with IDs for set scopes and an optional validity window.
Consequences
- One
line_managerrole serves every team; no per-team roles. - Products define their own scope types in the manifest; the SDKs, policies and SQL translation handle any prefix or set type.
- Prefix scopes need materialised paths ending in
/and a resolver that supplies the principal's path.