---
name: Arco permissions
version: 0.3.1
status: draft
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---

# Arco permissions

## Purpose

Permissions define what an actor may access, propose, change, approve, publish, configure or otherwise do inside an Arco deployment.

A Permission is an atomic right applied to a governed resource or scope.

```text
action + resource/scope
```

## Core principles

1. Keep permissions as simple as possible.
2. Permissions are atomic rights; Permission Groups are reusable bundles.
3. Roles may grant permissions but do not redefine them.
4. Resource and person references use stable IDs from their owning systems.
5. Governance does not create a second organisational or resource catalogue.
6. Organisational scope inheritance is explicit and resolves through the authoritative organisational hierarchy.
7. Permission to use information through AI is separate from direct source access.
8. Permission does not imply organisational decision authority.
9. No permission available inside a deployment can permit direct modification of Arco Core.

## Permission actions

Baseline actions may include:

```text
read
use
submit-feedback
propose
edit
approve
publish
configure
assign
```

Only actions demonstrated by real use should become canonical additions.

## Stable resource references

Permissions reference stable identifiers owned by the relevant subsystem or the deployment Governance Resource Register.

For Context, use Context IDs. For maintained deployment resources that need Governance classification, use the Resource Register identifier/reference rather than duplicating the file catalogue here.

## Organisational scope

A scoped permission references a `scope_id` from the deployment Governance Scope Register.

That scope points to an authoritative organisational unit/source.

Where `inherit_descendants=true`, the permission applies to eligible descendant organisational units resolved from the authoritative hierarchy.

Inheritance does not apply upwards or sideways.

An explicit later restriction model may narrow inheritance, but restrictions are not introduced by default.

## Permission Groups

A Permission Group is a reusable bundle of permissions.

Where practical, Permission Groups should align to existing organisational units or maintained organisational groups.

Membership may resolve from:

- an authoritative organisational unit/group source;
- a provider-native group source where supported;
- explicit/manual membership where no reliable source exists.

The Permission Group should reference the source rather than repeatedly copy member names where that source can be resolved reliably.

Organisational membership and Champion authority remain separate. Membership of a unit may grant ordinary module access without granting permission to maintain Arco for that unit.

## Default user permissions

Every deployment should provide ordinary safe use without custom assignment.

Baseline default-user capability is:

- use/read resources the deployment otherwise permits;
- submit feedback about Arco behaviour within permitted context.

Default users do not receive maintained-system edit/publish/configure authority.

## Champion baseline

A Champion may receive the baseline rights needed to propose and, where their Role assignment is `managed`, directly edit eligible deployment/local resources.

Champion effective change authority is always limited by:

```text
Role
+ assigned organisational scope
+ scope inheritance
+ system/module scope (max unit)
+ change mode
+ resource authority
```

A Champion cannot use permission inheritance to cross into a sibling unit, cross-functional/organisational scope, deployment-wide resource or Core.

## System Governor baseline

The System Governor may configure and change deployment-controlled resources where no more specific Governance rule applies, including eligible runtime/adaptor and deployment configuration resources.

System Governor permission does not permit direct Core modification and does not override independent business approval rules.

## Resource authority

Before executing a maintained-system change, resolve the target through the Governance Resource Register where one applies.

At minimum distinguish:

- Core authority — change prohibited from deployment;
- deployment authority — System Governor or configured deployment authority;
- scope-bound local authority — eligible Champion/System Governor according to scope/change mode.

Core lineage may be recorded separately for update comparison. A deployed resource with Core lineage remains a deployed resource and is reconciled by Updater rather than being treated as the upstream Core source.

## Effective permissions

Effective permissions combine the applicable baseline and maintained assignments:

```text
Default user permissions
+ Role-granted permissions
+ Permission Group permissions
+ organisational scope/inheritance
+ resource authority
= effective permission boundary
```

Change mode and Approvals then determine whether an eligible change can execute immediately.

Do not support ad-hoc per-user exceptions by default.

## Permission denial

Permission denial and approval-required are different states.

Where the actor is not authorised to make the maintained change, Arco should not silently attempt another resource or layer.

If feedback is permitted, offer to capture the issue/improvement for the appropriate maintained owner.

## Mediated use versus direct source access

```text
May use information through Arco/AI
≠
May directly open or inspect the source
```

Deployments may govern these separately where the provider supports enforcement.

## Relationship to Approvals

Permissions answers whether the actor is eligible.

Approvals answers whether an eligible action needs an additional consent step.

```text
requested action
      ↓
permission + scope + resource check
  ↙                     ↘
not eligible             eligible
    ↓                       ↓
feedback/escalate      approval required?
                        ↙          ↘
                       no          yes
                        ↓           ↓
                     execute    Approvals
```

Approval cannot create authority that Permissions/Governance prohibits.

## Boundaries

Permissions does not:

- own organisational hierarchy;
- own Context IDs;
- define Role responsibilities;
- define approval workflow;
- make every organisational unit member a Champion;
- grant Core modification authority;
- infer business decision authority.

## Still to define

- conflict precedence if explicit deny/restriction rules are introduced;
- permission-change audit requirements beyond existing maintained-file/Register history;
- provider-specific enforcement where underlying files cannot technically be hidden.


## Canonical references

[arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view).

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 0.3.1 | Restored canonical provider-link references. | Stoirm Arnold — Defrag invocation | Codex Work |
| 22-Sep-2026 | 0.3.0 | Defined inherited organisational scope, baseline User/Champion/System Governor permission behaviour, Permission Group membership sourcing, Resource Register resolution, Core prohibition and feedback fallback at permission boundaries. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 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 |