---
name: Arco roles
version: 0.1.0
status: draft
owner: Stoirm Arnold
last_updated: 15-Sep-2026
---

# Arco roles

## Purpose

Roles define named responsibilities and authority inside Arco.

A Role describes an ongoing system responsibility. It is not the same thing as an organisational job title and it is not merely a bundle of permissions.

Roles sit beneath `arco-governance.md` and work with `arco-permissions.md` and `arco-approvals.md`.

## Core principles

1. Roles represent recurring Arco responsibility or authority.
2. Organisational job titles remain organisational facts and should not automatically become Arco Roles.
3. A deployment may map organisational attributes such as job title, team or organisational unit to an Arco Role where useful.
4. A person may hold more than one Arco Role.
5. A deployment should define as few Roles as it genuinely needs.
6. Roles may grant permissions or approval authority, but Permissions and Approvals own those mechanics.
7. A Role assignment should be visible in deployment configuration so Arco can resolve responsibility without repeatedly asking.

## Required Role

### System Governor

Every organisational Arco deployment must have a System Governor.

The System Governor is the accountable system-governance Role for the deployment.

The System Governor is the fallback authority when Arco cannot resolve a system-level owner, authority, governance rule, canonical location or source-of-truth ambiguity from existing maintained configuration.

Typical responsibilities include:

- confirming or resolving system-level governance ambiguities;
- approving governance changes where required;
- confirming authoritative sources where they are not already established;
- resolving unclear ownership or accountability that would otherwise block the system;
- overseeing deployment-level governance configuration;
- acting as the fallback approver where a more specific authority is not defined.

The System Governor should not become the automatic approver for every action. Where another maintained authority or approval rule exists, that rule should be used.

The detailed permission set attached to the System Governor belongs in Permissions. Approval responsibilities belong in Approvals.

## Established optional Role

### Champion

Champion is an optional Arco Role for trusted users who help improve, maintain and evolve the system without holding full System Governor authority.

A Champion may be allowed to:

- propose maintained-system changes;
- propose Context changes;
- contribute to Skills, Personas or other governed areas;
- identify system gaps or improvements;
- participate in testing or validation;
- perform other delegated actions defined by the deployment.

A Champion does not automatically gain authority to publish or approve every proposed change.

Where a Champion action requires approval, the action should use the Approvals mechanism. A deployment may require System Governor approval for particular Champion actions.

## Organisational roles versus Arco Roles

An organisational title such as `Client Operations Coordinator` is an organisational fact.

It may be used by deployment configuration to assign:

- an Arco Role;
- a Permission Group;
- or neither.

The job title itself should not be treated as an Arco Role unless the deployment deliberately maps it.

Example:

```text
Organisational title:
Client Operations Coordinator

Deployment mapping:
→ Permission Group: Client Operations Context Maintainers
```

No Arco Role is required in that example.

## Role assignment

Role assignments are deployment state.

The deployment should record:

- Role;
- current holder or holders;
- status;
- effective date where relevant;
- delegation or temporary assignment where supported.

The exact storage format belongs to system setup / deployment configuration.

## Default user

Default User is not necessarily a special Role.

Every user receives the deployment's default user permissions through the Permissions model.

A simple deployment may therefore have:

```text
System Governor: one person
Champion: none
Additional Roles: none
Everyone else: default user permissions
```

## Relationship to Permissions

Roles may grant one or more permissions.

Roles do not define the permission vocabulary themselves.

Example:

```text
Role: Champion
        ↓
Permissions
- propose maintained-system change
- propose permitted Context change
```

The authoritative permission definitions belong in `arco-permissions.md`.

## Relationship to Approvals

An approval rule may refer to a Role.

Example:

```text
Action:
publish maintained-system change

Approval rule:
System Governor approval required
```

Roles identify the authority category. `arco-approvals.md` owns how the approval is requested and resolved.

## Boundaries

Roles does not:

- recreate the org chart;
- define organisational job titles;
- define the detailed permission vocabulary;
- define approval workflow mechanics;
- create a Role for every team or job title;
- automatically grant authority merely because a person is senior in the organisation.

## Still to define

- delegation and absence rules;
- whether some Roles may be held by systems rather than people;
- assignment/removal approval rules;
- role history requirements;
- whether any Role beyond System Governor must ever be mandatory;
- the final Role Register or system-setup representation if scale requires one.

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 15-Sep-2026 | 0.1.0 | Established the Core Roles model beneath Governance, including required System Governor, optional Champion, separation from organisational job titles, default-user behaviour, and routing to Permissions and Approvals. | Stoirm Arnold | GPT-5.6 Sol |