--- name: Arco governance version: 0.1.0 status: draft owner: Stoirm Arnold last_updated: 15-Sep-2026 --- # Arco governance ## Purpose Governance defines how authority operates inside Arco. It establishes who may act, what they may access or change, when approval is required, and how authority is assigned without forcing every organisation to reproduce the same organisational structure. Governance should be simple by default and become more granular only where a deployment has a real need. ## Position in Arco Governance is a foundational Arco subsystem for organisational deployments. It is not a single permission list and should not absorb the detailed operating rules of the components beneath it. The governance waterfall is: ```text Governance ↓ Roles ↓ Permissions ↓ Approvals where required ``` Modules and operating components consume this governance layer rather than redefining authority themselves. For example: ```text Context ────┐ Skills ─────┤ Decisions ──┼──→ Governance Deployment ─┤ System ─────┘ ``` ## Minimum viable governance An organisational deployment must be able to operate with minimal configuration. At minimum: - one person must hold the System Governor role; - all users receive the deployment's default user permissions; - additional Arco roles are optional; - permission groups are optional; - organisational-role or job-title mappings are optional; - approval rules are defined only where an operation requires them. A deployment should not need to design a complex access-control model before Arco becomes useful. ## Roles A Role represents a named system responsibility or authority. Roles are distinct from organisational job titles. A person's organisational position may be used by deployment configuration to assign an Arco Role, but the position and the Arco Role remain separate concepts. ### System Governor System Governor is a required Arco Role for an organisational deployment. The System Governor is accountable for the governance and integrity of the Arco deployment, including matters that require system-level authority or resolution. The detailed permissions and approval responsibilities attached to the System Governor belong in the Roles, Permissions and Approvals definitions rather than being duplicated here. ### Champion Champion is an Arco Role for trusted users who help improve and maintain the system without holding full System Governor authority. A Champion may be allowed to propose maintained-system changes, contribute Context or other governed material, and perform other delegated actions. Where a Champion's proposed action requires approval, the Approvals mechanism determines the required approver. A deployment may require System Governor approval for particular Champion actions. Additional Roles may be defined by a deployment when they represent a genuine recurring responsibility. Do not create Roles merely to mirror every organisational job title. ## Permissions A Permission is an atomic right to perform an action against a governed resource or scope. Conceptually: ```text action + resource/scope ``` Examples include reading, proposing, editing, approving, publishing or configuring a governed resource. Permissions should reference stable resource identifiers owned by the relevant subsystem rather than repeat human-readable names or duplicate that subsystem's register. For Context, permissions should reference the stable Context ID owned by the Context Register. Example: ```text read → CTX-### edit → CTX-### ``` The human-readable Context name may change without requiring the permission definition to change. The same principle should apply to other governed resources when their owning subsystem maintains stable identifiers. The detailed permission model belongs in `arco-permissions.md`. ## Permission groups A Permission Group is a reusable bundle of permissions. Permission Groups allow deployments to grant a coherent set of rights without repeatedly assigning individual permissions. A group may be assigned: - explicitly to a person; - through an Arco Role; - through a deployment mapping from an organisational attribute such as job title, team or organisational unit; - by another mechanism deliberately defined by the deployment. Organisational attributes may therefore cause a Permission Group to be assigned, but they are not themselves the permission system. A deployment may operate with no custom Permission Groups and rely only on default user permissions plus defined Arco Roles. ## Effective permissions A user's effective permissions are the combined permissions that apply to them through the deployment's governance configuration. Potential sources include: ```text Default user permissions + Arco Roles + Permission Groups + explicit exceptions, if the deployment supports them ↓ effective permissions ``` Whether explicit per-person exceptions are supported should be resolved in the detailed Permissions design rather than assumed here. ## Source access and mediated use Permission to use information through Arco or an AI does not automatically imply permission to inspect the underlying source file directly. These are separate rights. For example, a user may be allowed to ask Arco a question that relies on Core or organisational Context while not having direct browse/read access to the underlying maintained files. Deployments should be able to govern mediated use and direct source access separately where the underlying platform permits it. ## Approvals Approvals is the reusable governance mechanism for operations that require consent before execution. Approvals does not own the domain action being approved. The calling subsystem owns the proposed action; Approvals owns how required approval is obtained and resolved. For example: ```text Decision requires approval ↓ Approvals Context change requires approval ↓ Approvals Skill publication requires approval ↓ Approvals ``` The detailed approval model belongs in `arco-approvals.md`. Approvals may target an Arco Role, a Permission Group, a permission-bearing individual or another authority defined by the governance model. Approvals should consume maintained organisational structure through the appropriate Context/authoritative source rather than independently creating a second people model. ## Relationship to organisational Context Context owns organisational facts such as people, organisational units, positions, reporting relationships and stable Context records. Governance consumes those facts when needed. Governance must not duplicate the org chart, person records or Context Register. Where permissions target Context, the stable Context ID from the Context Register is the authoritative resource identifier. Where deployment rules map organisational attributes to Roles or Permission Groups, the organisational fact remains owned by Context or its authoritative source; Governance owns only the mapping. ## Decisions Decisions is not part of the core Governance subsystem. It is an optional module that may consume Governance for access, authority and approval. Decisions owns decision detection, temporary decision candidates, promotion into durable decisions, decision identifiers, ownership, dependencies, parent/child relationships, state, rationale and permanent organisational decision memory. When a Decision requires approval, Decisions points to the Approvals mechanism rather than defining approval behaviour itself. ## Simplicity principle Governance should default to the smallest workable model. A simple deployment may have: ```text System Governor: one person Additional Roles: none Custom Permission Groups: none Default User permissions: enabled Custom approval rules: only where required ``` Complexity should be introduced only when real organisational use demonstrates the need. ## Boundaries Governance defines authority architecture. It does not: - duplicate the Context Register or org chart; - define the detailed behaviour of Context, Skills, Decisions or other modules; - maintain task lists; - create a second source of truth for organisational structure; - require every organisational job title to become an Arco Role; - assume that direct file access and AI-mediated use are equivalent rights. ## Still to define The first draft deliberately leaves these details to the component designs: - the canonical Role schema and deployment assignment model; - the detailed System Governor permission set; - the detailed Champion permission set; - the default user permission set; - the permission action vocabulary; - the stable resource-reference format outside Context; - whether explicit per-user permission exceptions are supported; - conflict/precedence rules when multiple permission sources apply; - the reusable Approval rule schema and execution flow; - how governance configuration is represented in system setup. ## Changelog | Date | Version | Change | Approved by | Changed by | |---|---|---|---|---| | 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 |