---
name: Arco roles
version: 0.6.1
status: draft
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---

# Arco roles

## Purpose

Roles define recurring responsibilities and authority inside Arco.

A Role is not an organisational job title and is not merely a bundle of permissions. Roles work with [arco-permissions.md](https://drive.google.com/file/d/1dSRRfHv8Bz3aDBy8OxiP-IjnuskCEVy5/view) and [arco-approvals.md](https://drive.google.com/file/d/1-LpCSwdAQliIM6bnnUrQCl8ywk5cVGP-/view) beneath [arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view).

## Core principles

1. Roles express recurring Arco responsibility or authority.
2. Organisational job titles remain organisational facts.
3. A person may hold more than one Role where required.
4. Role assignments use stable person/profile codes, not names as the authoritative reference.
5. Role authority may be bounded by organisational scope and change mode.
6. Roles may grant Permissions or approval authority, but those mechanics remain owned by Permissions and Approvals.
7. Deployment Roles never grant authority to modify Arco Core.

## User

User is the baseline actor state rather than a special deployment assignment.

Every user receives the deployment's default user permissions.

A User may use permitted Arco capability and submit feedback. A User does not gain maintained-system change authority merely through ordinary membership of an organisational unit.

## System Governor

Every organisational deployment must have exactly one System Governor assignment unless a later maintained rule deliberately changes that requirement.

The System Governor runs the local Arco deployment and is the fallback authority for deployment-level Governance ambiguity where no more specific maintained authority exists.

Typical responsibilities include:

- resolving deployment Governance ambiguity;
- maintaining deployment Governance configuration;
- approving changes that exceed Champion authority;
- promoting eligible deployment-level system changes;
- maintaining deployment-controlled runtime/adaptor resources;
- resolving authority/source-of-truth ambiguity that would otherwise block the deployment.

The System Governor may directly change eligible deployment-controlled resources where Governance does not require another approval.

The System Governor cannot modify Arco Core and does not automatically acquire organisational decision authority.

## Champion

Champion is an optional Role for trusted users who improve and maintain Arco within a bounded organisational scope.

A Champion assignment must identify its organisational scope and change mode.

Champion system/module scope follows:

```text
personal → multi-user → unit → cross-functional → organisational
```

A Champion may work up to **unit** scope inside their assigned organisational scope.

Cross-functional and organisational changes require System Governor authority unless a more specific maintained rule exists.

A Champion cannot modify Core.

### Scope inheritance

Where the assigned Governance scope is configured with descendant inheritance, a Champion's authority applies to eligible descendant units resolved from the authoritative organisational hierarchy.

Authority does not inherit to parent or sibling units.

### Change modes

- `review` — Champion may develop/propose eligible changes, but maintained publication requires approval.
- `managed` — Champion may directly change eligible deployment/local resources inside scope.
- `restricted` — no maintained-system change authority; feedback remains available.

Change mode does not widen organisational scope or resource authority.

## Creator

Creator is the upstream Arco Core stewardship Role.

Creator is deliberately unnamed in deployment Governance.

It is not assigned through a deployment Roles Register and must not be inferred from a deployment user's identity, organisational seniority or historical involvement with Arco.

Where a deployment identifies a Core-level improvement, it may submit/escalate the improvement for Creator review. It may not modify Core itself.

## Organisational roles versus Arco Roles

Organisational titles or membership may be used as inputs to Governance mappings, but do not themselves become Arco Roles.

For example, membership of Client Operations may place someone inside a Permission Group while only selected profile IDs receive Champion assignments for that scope.

This allows an organisation to have many users in a unit but only a small number of people able to maintain Arco within it.

## Role Assignments Register

Role assignments are deployment state owned by Governance.

An organisational deployment should maintain a Role Assignments Register using the universal Register standard.

Baseline columns:

```text
assignment_id
profile_id
role
scope_id
change_mode
status
effective_from
effective_to
display_name
```

Rules:

- `profile_id` is the authoritative person/profile reference;
- `display_name` is convenience only;
- `scope_id` references the Governance Scope Register where the Role is scope-bound;
- System Governor may use the deployment root scope where useful;
- Creator must not appear as a deployment assignment;
- inactive/ended assignments remain as historical rows through status/effective dates rather than being silently deleted.

Where deployment-specific Register locations are required, `readme-roles-local.md` should hold the single pointer.

## Relationship to Permissions

Roles may grant one or more Permissions but do not own the permission vocabulary.

A Champion Role plus a scope/change mode determines the boundary within which the relevant Champion Permissions may be exercised.

## Relationship to Approvals

Approvals decides whether an otherwise eligible action needs additional consent.

A `review` Champion normally routes maintained changes to Approvals. A `managed` Champion may execute eligible in-scope deployment/local changes directly.

Neither mode can bypass the hard Core boundary or create organisational decision authority.

## Boundaries

Roles does not:

- recreate the org chart;
- define organisational job titles;
- define atomic Permissions;
- define approval workflow mechanics;
- make every member of a unit a Champion;
- grant Core authority from a deployment assignment;
- infer business decision authority from Arco responsibility.

## Still to define

- delegation and absence rules;
- Role assignment/removal approval rules;
- whether any future Role may be held by a system rather than a person.


## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 0.6.1 | Restored canonical provider-link references; Rolled the live changelog to five entries with archived history. | Stoirm Arnold — Defrag invocation | Codex Work |
| 22-Sep-2026 | 0.6.0 | Added User and unnamed Creator boundaries; made Champion authority organisationally scoped and descendant-inheritable; added review/managed/restricted change modes; separated System Governor authority from Core and business decision authority; defined the stable-ID Role Assignments Register schema. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 21-Sep-2026 | 0.5.0 | Removed Role-level Register-format hardcoding so the Roles Register inherits the universal Register standard from the System Manual. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 21-Sep-2026 | 0.4.0 | Aligned Champion responsibilities with shared Development: Champions may create, own, join, contribute to and test Development items, while shared-system promotion remains governed by the System Governor unless another maintained rule applies. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 21-Sep-2026 | 0.3.0 | Moved organisational Role assignments out of System Setup and into a provider-native Roles Register owned by Governance, with deployment-specific register pointers held in `readme-roles-local.md`. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |