--- name: Arco permissions version: 0.2.0 status: draft owner: Stoirm Arnold last_updated: 15-Sep-2026 --- # Arco permissions ## Purpose Permissions define what an actor may access, propose, change, approve, publish, configure or otherwise do inside an Arco deployment. Permissions sit beneath `arco-governance.md`. A Permission is an atomic right applied to a governed resource or scope. Conceptually: ```text action + resource/scope ``` ## Core principles 1. Permissions should be as simple as possible. 2. Permissions are atomic rights; Permission Groups are reusable bundles of those rights. 3. Roles may grant permissions but do not redefine them. 4. Governed resources should be referenced by stable identifiers owned by the relevant subsystem wherever such identifiers exist. 5. Permissions must not create a second resource catalogue. 6. Organisational facts may drive permission assignment, but they remain owned by Context or the authoritative organisational source. 7. Permission to use information through AI does not automatically mean permission to inspect the underlying source directly. 8. Default user permissions should make a basic deployment usable without custom configuration. ## Permission model A Permission consists of: - an action; - a resource or scope; - any necessary constraint defined by the owning subsystem or deployment. Examples of actions may include: ```text read use propose edit approve publish configure assign ``` This vocabulary is intentionally provisional in v0.1.0. Only actions demonstrated by real use should become canonical. ## Stable resource references Permissions should reference resources through stable identifiers rather than human-readable names wherever the owning subsystem maintains such identifiers. For Context, the Context Register owns the stable Context ID. Example: ```text read → CTX-### edit → CTX-### ``` If the Context record is renamed, the permission remains valid because the stable ID has not changed. Permissions must not maintain its own duplicate Context ID list. The same pattern should be used by other subsystems when they maintain stable identifiers. ## Permission Groups A Permission Group is a named reusable bundle of permissions. Example: ```text Permission Group: Client Operations Context Maintainers Contains: - read → relevant Client Operations Context IDs - propose → relevant Client Operations Context IDs - edit → selected Client Operations Context IDs ``` Permission Groups are useful when several people need the same rights or when rights should follow an organisational attribute. A Permission Group may be assigned: - directly to a person; - through an Arco Role; - through a deployment mapping from job title; - through a deployment mapping from team or organisational unit; - through another deliberately configured assignment mechanism. ## Default user permissions Every deployment should define a default user permission set. Users who hold no additional Roles or Permission Groups still receive those default permissions. The default should be sufficient for ordinary safe use of Arco without exposing unnecessary system-management rights. The exact default permission set is deployment configuration and should not be hard-coded globally before real deployment evidence establishes a useful baseline. ## Effective permissions Effective permissions are the combined rights that apply to the actor. Conceptually: ```text Default user permissions + Role-granted permissions + Permission Group permissions + explicit exceptions, if supported ↓ effective permissions ``` The precedence model for conflicting grants or restrictions is not yet canonical. A deployment should not support per-user exceptions by default unless there is a demonstrated need. ## Organisational mappings Governance may map organisational attributes to Roles or Permission Groups. Example: ```text Context / authoritative people source: Job title = Client Operations Coordinator Deployment governance mapping: → Permission Group: Client Operations Context Maintainers ``` The job title remains owned by Context or the authoritative people source. Permissions owns only the resulting rights. ## Context permissions Context-specific permissions should target stable Context IDs from the Context Register. The Context Register remains authoritative for: - Context ID; - entity; - canonical Context record; - accountable party; - permitted maintainers where required; - verification and source state. Permissions determines what the actor may do against that registered Context resource. ## Mediated use versus direct source access These are separate permissions: ```text May use information through Arco/AI ≠ May directly open or inspect the source file ``` A deployment may allow users to ask AI questions that rely on governed Context or Core material while preventing direct browse/read access to the underlying maintained files. Direct source access should be separately configurable where the underlying platform supports enforcement. For Core and maintained-system files, direct human access should not be assumed merely because the user is allowed to use Arco. ## Relationship to Roles Roles express responsibility. Permissions express rights. A Role may grant permissions. Example: ```text Role: Champion ↓ Permission: propose → permitted maintained-system resources ``` A Permission Group may grant the same permission without assigning the Champion Role. This allows responsibility and access rights to remain distinct. ## Relationship to Approvals Permissions defines **who is authorised for a module, resource or action and what that authorised population may do**. Approvals defines whether an otherwise-authorised action requires a further consent step before execution or publication. This distinction is important for module configuration: ```text Permissions = who is in the authorised population? ↓ Approvals = does that authorised population need a second gate? ``` Example: ```text Policies module ↓ Permission Group: People Operations ↓ approvals: false ↓ any authorised People Operations user may update eligible Policy content without further approval ``` A user outside the Policies Permission scope does not gain access because approvals are off. Equally, holding a Permission does not bypass an approval requirement when the relevant module/action has `approvals: true`. Conceptually: ```text requested action ↓ permission check ↙ ↘ not authorised authorised ↓ ↓ stop approval required? ↙ ↘ no yes ↓ ↓ execute Approvals ``` Permission denial and approval-required are therefore different states. ## Permission changes Changing Roles, Permission Groups or governance permissions may itself be a governed action. The deployment should use Approvals where the relevant governance rule requires consent before those changes take effect. ## Boundaries Permissions does not: - own Context IDs; - own Skills, Personas, Decisions or other domain resource registers; - recreate organisational structure; - define Role responsibilities; - define approval workflow; - assume every organisational job title maps to permissions; - require complex Permission Groups in a simple deployment. ## Still to define - canonical action vocabulary; - resource-reference conventions for subsystems without stable IDs; - conflict and precedence rules; - whether explicit per-user exceptions are supported; - baseline default user permissions; - baseline System Governor permissions; - baseline Champion permissions; - enforcement behaviour when a platform cannot technically hide underlying files; - permission-change audit requirements. ## Changelog | Date | Version | Change | Approved by | Changed by | |---|---|---|---|---| | 15-Sep-2026 | 0.2.0 | Clarified Permissions as the owner of authorised module/resource populations and separated that from Approvals as the secondary consent gate; added department-scoped module behaviour such as People Operations-only Policies with approvals disabled. | Stoirm Arnold | GPT-5.6 Sol | | 15-Sep-2026 | 0.1.0 | Established Permissions as atomic action-plus-resource rights beneath Governance, defined Permission Groups, default/effective permissions, stable resource references through owning subsystem registers, Context Register integration, organisational mappings, mediated versus direct source access, and the handoff to Approvals. | Stoirm Arnold | GPT-5.6 Sol |