---
name: Arco governance
version: 0.2.1
status: draft
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---

# Arco governance

## Purpose

Governance defines how authority operates inside Arco: who may act, what they may access or change, when approval is required, how authority is bounded, and what happens when someone reaches that boundary.

Governance should be simple by default and become more granular only where a deployment has a demonstrated need.

## Position in Arco

```text
Governance
    ↓
Roles
    ↓
Permissions
    ↓
Approvals where required
```

Roles define recurring Arco responsibilities. Permissions define rights against governed resources/scopes. Approvals supplies an additional consent gate only where one is required.

Modules and operating components consume this layer rather than redefining authority themselves.

## Four authority concepts

Governance must keep these separate:

1. **Governance role** — what responsibility someone holds inside Arco.
2. **Permission** — what they may access or do against a governed resource/scope.
3. **Change authority** — whether an authorised change may be applied directly or must be reviewed.
4. **Organisational decision authority** — whether the person may approve the underlying business decision/action.

An Arco Role never automatically grants organisational decision authority. A System Governor may be able to update a runtime file while still requiring another organisational approver for a business decision handled through that runtime.

## Core boundary

Arco Core cannot be modified from a deployment.

This is a hard boundary, including for the System Governor.

The upstream Core-stewardship Role is **Creator**. Creator is deliberately unnamed in deployment Governance and is not assigned through a deployment Roles Register.

Where a deployment identifies a Core improvement, it may capture and escalate the improvement for upstream review. It must not rewrite Core directly.

## Roles

Governance supports four baseline actor categories:

- **User** — uses permitted Arco capability and can submit feedback.
- **Champion** — may improve eligible deployed/local Arco within an assigned organisational scope and change mode.
- **System Governor** — runs the local deployment and may change eligible deployment-controlled resources.
- **Creator** — upstream Core authority only; unnamed inside deployments.

Detailed Role behaviour belongs in [arco-roles.md](https://drive.google.com/file/d/1FaKj8DJygVGb0MTfoyF5lOe-K7Igw4vg/view).

## Organisational scope

Governance scope is based on stable organisational-unit identifiers owned by Context or another deliberately configured authoritative people source.

Governance must not recreate the org chart.

A deployment Governance Scope Register selects the organisational units that may be used as governed scopes and records whether authority inherits to descendants.

Example:

```text
scope: business-operations
inherit_descendants: true
```

A Role assignment to that scope therefore applies to eligible child units resolved from the authoritative organisational hierarchy. Authority does not inherit sideways to sibling units or upwards to parents.

## Change modes

A deployment may apply a change mode to a Role assignment.

The baseline modes are:

- `review` — work/proposals are allowed within scope, but maintained changes require approval;
- `managed` — eligible deployment/local changes may be made directly within scope;
- `restricted` — no maintained-system change authority; feedback remains available.

A change mode never expands the Role's organisational or resource boundary.

## Resource authority

Governance must distinguish the authority of the governed resource from the human Role acting on it.

A deployment Resource Register classifies maintained Arco resources sufficiently to determine:

- the resource reference;
- its resource type;
- whether authority is Core, deployment or scope-bound;
- its lineage/provenance where relevant;
- its owning organisational scope where relevant;
- its current status.

This is required because a runtime/adaptor file, deployment configuration file and Core source file can all affect Arco while having different change authority.

### Core

Upstream reusable Arco source. Deployment modification is prohibited.

### Deployment-controlled

Deployment-level configuration/system/runtime resources that the System Governor may update directly where no more specific rule applies.

### Scope-bound local

Module/local resources whose change authority is bounded by organisational scope and the actor's Role/change mode.

A deployed resource may also record Core lineage for update comparison without becoming Core itself. Lineage and local change authority are therefore separate facts.

## Permission groups

Permission Groups remain reusable bundles of permissions.

Where practical, group membership should resolve from existing organisational units/groups rather than repeating person lists inside Arco.

A Permission Group may therefore reference an authoritative external membership source plus a stable organisational/scope ID. Manual membership remains a fallback where no reliable external source exists.

## Universal feedback

Feedback is available to every user within the information they are permitted to use.

When a user identifies a material problem or improvement but lacks authority to make the maintained change, Arco should offer behaviour equivalent to:

> You can't make this change directly, but I can capture what went wrong and submit it as feedback.

Feedback is not a maintained-system change and does not itself require change authority.

The system should capture enough context to make the feedback useful, such as:

- intended task;
- observed behaviour;
- expected behaviour;
- affected module/function/resource where known;
- relevant system/runtime context;
- proposed improvement where clear.

Feedback may later be reconciled into a proposed maintained change under Approvals.

## Deployment applicability

Governance may define which organisational scopes a deployment's operational layer applies to.

Coverage uses the same stable organisational scope IDs and descendant inheritance model. A deployment can therefore include a parent scope without enumerating every child unit.

A user outside operational coverage is not automatically denied shared Context. Instead, normal deployment/module routing stops at the coverage boundary while any separately permitted shared Context remains available.

Deployment-specific coverage values belong in local Governance configuration, not Core.

## Registers

An organisational deployment should maintain the minimum Governance Registers required by its configuration:

- **Role Assignments Register** — profile/person code → Role → scope → change mode;
- **Governance Scope Register** — governed scope code → authoritative organisational unit/source → descendant inheritance;
- **Governance Resource Register** — maintained resource → authority class/type/lineage/scope.

All follow the universal CSV Register standard in [arco-system-manual.md](https://drive.google.com/file/d/1doS7QXRtShzT45wHC13Vx0zxputK50l-/view).

Human-readable names may be retained as display fields but must not replace stable profile, scope or resource identifiers.

## Approvals and business authority

Approvals governs consent for an otherwise eligible Arco action.

An approval cannot make a prohibited Core change permissible and must not create organisational decision authority merely because the approver holds an Arco Role.

Where a business action requires organisational approval, the calling domain must resolve that authority independently of Arco system-governance Roles.

## Minimum viable governance

A small organisational deployment may operate with:

```text
System Governor: one assignment
Champions: optional
Governance scopes: only those actually used
Resource classifications: only maintained resources requiring governance resolution
Custom approval rules: only where required
All other users: default permissions + feedback
```

Do not introduce per-user exceptions, complex approval engines or redundant group structures until demonstrated use requires them.

## Boundaries

Governance does not:

- recreate the Context Register or org chart;
- make organisational job titles into Arco Roles automatically;
- make System Governor synonymous with organisational decision-maker;
- allow any deployment Role to modify Core;
- require every organisational unit to become a Governance scope;
- require permission membership to be duplicated where an authoritative external source can be resolved.

## Still to define

- delegation and absence rules;
- conflict precedence where explicit restrictions are later introduced;
- whether any system-held Roles are required;
- advanced approval semantics such as quorum/parallel voting;
- long-term external group-resolution mechanisms across providers.


## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 0.2.1 | Restored canonical provider-link references. | Stoirm Arnold — Defrag invocation | Codex Work |
| 22-Sep-2026 | 0.2.0 | Made Governance operational: added the immutable Core/unnamed Creator boundary, separated Arco authority from business decision authority, established scoped/inherited Role authority and change modes, defined resource authority classification, universal feedback fallback, deployment applicability and the three deployment Governance Registers. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 15-Sep-2026 | 0.1.0 | Created the first Arco Governance draft, establishing Governance as the foundational authority subsystem; defining the minimum viable model, System Governor and Champion roles, the distinction between Roles, Permissions and Permission Groups, stable resource references through owning subsystem registers, mediated versus direct source access, Approvals as a reusable mechanism, and Decisions as an optional downstream module. | Stoirm Arnold | GPT-5.6 Sol |