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

# Arco approvals

## Purpose

Approvals is the reusable Governance mechanism for otherwise-eligible actions that require explicit consent before execution.

Approvals does not own the underlying domain action and does not create authority that Governance/Permissions prohibit.

## Core principle

```text
eligible action requires consent
        ↓
Approvals
        ↓
approve / reject
```

Do not duplicate approval engines inside modules.

## Eligibility comes first

Before Approvals is invoked, Governance must establish that the actor/action is eligible in principle.

Check:

- Role;
- organisational scope and inheritance;
- system/module scope;
- resource authority;
- change mode;
- relevant Permissions.

If the action is prohibited — for example a deployment attempting to modify Core — approval cannot make it permissible.

## Change modes

Champion change mode determines the default maintained-change route inside the Champion's otherwise-authorised boundary:

- `review` → maintained change routes through Approvals;
- `managed` → eligible change may execute directly unless another maintained approval rule applies;
- `restricted` → maintained change is not eligible; feedback/escalation remains available.

System Governor may execute eligible deployment-controlled changes directly unless a more specific approval rule applies.

## Feedback and proposed changes

Arco should learn from real interactions without turning every observation into an immediate edit.

### Feedback

Feedback is the universal low-friction capture mechanism and is available to ordinary users within permitted context.

Feedback may record:

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

Feedback is not approval and is not itself a maintained change.

### Proposed maintained change

When feedback or an authorised user's work is mature enough to alter a maintained file/resource:

1. identify the maintained owner/resource;
2. reconcile overlapping feedback/proposals where appropriate;
3. construct the candidate change;
4. run required Dry Runs/validation;
5. determine whether the actor/change mode/resource permits direct publication;
6. if approval is required, submit one reconciled proposal with evidence;
7. publish only after the required authority is satisfied.

The approval unit is the reconciled maintained change, not necessarily every micro-observation that informed it.

## Permission boundary behaviour

Where a requested change exceeds the actor's authority, stop the change and offer feedback/escalation instead of silently editing another layer.

For example:

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

This is the expected fallback for normal users and for Champions who reach another organisational scope, cross-functional/organisational scope, deployment-controlled resources or Core.

## Approving authority

An approval rule may target:

- an Arco Role;
- a Permission Group with approval authority;
- an organisational authority resolved from maintained Context/source mappings;
- a permission-bearing person/profile;
- a specifically named person only where deliberately required.

Approvals must not independently infer authority from organisational job title.

## System Governor

The System Governor is the fallback Arco system-change approving authority where no more specific maintained authority exists.

This does not make the System Governor the automatic approver for domain/business decisions.

## Business decision authority

Arco Governance approval and organisational decision approval are distinct.

If a Decision, expenditure, HR action, contract or other business workflow requires organisational approval, the calling subsystem must resolve that authority from the organisation's maintained rules/context.

Holding System Governor or Champion does not satisfy that requirement unless the same profile separately holds the required organisational authority.

## Approval stages

Use one approval stage by default.

Add sequential stages only where real workflow evidence requires them. Quorum, parallel approval and voting remain unresolved until demonstrated use requires them.

## Approval request

An approval request should contain enough information to decide without reconstructing the original conversation:

- proposed action/change;
- target resource/scope;
- requester/profile ID;
- required approving authority;
- reason/context;
- validation evidence where relevant;
- current state.

Reference stable underlying records rather than duplicate them where possible.

## Approval state

Minimum states:

```text
pending
approved
rejected
```

Add further states only where demonstrated use requires them.

## Reusable decisions and ambiguity

Where an approval resolves a reusable Governance ambiguity, record the durable rule in the maintained owner so future actions do not repeatedly request the same approval.

## Relationship to modules

The Module Manual owns universal module controls such as automatic system updates and output approval.

Approvals owns the consent mechanism invoked when those controls or another Governance rule require it.

Automatic system update settings cannot override the hard Core boundary.

## Boundaries

Approvals does not:

- own the underlying action;
- create Permission;
- bypass organisational scope;
- make a prohibited Core change permissible;
- define organisational job titles;
- make Arco Role equivalent to business decision authority;
- require the System Governor to approve everything.

## Still to define

- canonical advanced Approval Rule schema if real use requires more granularity;
- delegation/expiry/absence behaviour;
- quorum/parallel voting;
- notification/reminder mechanics;
- long-term durable Approval Register requirements.


## Canonical references

[arco-module-manual.md](https://drive.google.com/file/d/1X3uzbh2_7cu_ZJGCwpcLSVyWihXHQxgZ/view), [arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view), [arco-dry-runs.md](https://drive.google.com/file/d/1Fe2PJd-IGIE5UlZmOlr0d3mThRkKbhX7/view).

## 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 | Separated universal feedback from maintained-change proposals; integrated Champion change modes and scoped eligibility; made feedback/escalation the fallback at authority boundaries; reinforced that approvals cannot bypass Core prohibition or create organisational decision authority. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 15-Sep-2026 | 0.5.0 | Removed the stale global-Approvals toggle condition from the System Governor fallback and aligned maintained deployed/local change approval with the Module Manual: Automatic system updates OFF invokes the shared approval route. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.4.1 | Updated the live module-configuration boundary pointer to `arco-module-manual.md`; historical changelog references remain unchanged. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.4.0 | Moved ownership of the universal per-module controls to `arco-module-standard.md`; Approvals now owns only the shared consent mechanism invoked when a module/deployment setting requires approval. | Stoirm Arnold | GPT-5.6 Sol |