--- name: Arco version: 1.3.0 status: active owner: Stoirm Arnold last_updated: 15-Sep-2026 --- # Arco **Arco is what the AI runs on.** Arco is an operating system for working with AI. It provides the maintained context, capabilities, perspectives, rules and configuration that allow humans and AI to work consistently inside an individual or organisation. Arco is not an AI model, assistant or application. It is the operating layer around them. > **Arco is the operating layer through which humans and their AI work inside an organisation.** ## Purpose AI is increasingly involved in everyday work: answering questions, giving advice, performing workflows and making or supporting decisions. Without a shared operating layer, each AI interaction can depend on whatever context happens to be available in that conversation. Important knowledge becomes fragmented across chats, instructions become inconsistent, and different people can receive different answers to the same organisational question. Arco provides a maintained system outside individual conversations so that AI can answer four fundamental questions: 1. **What is true?** → Context 2. **How do we do things?** → Skills 3. **How should the system think or review?** → Personas 4. **What is the system allowed to do?** → Governance `Governance` is a foundational Arco subsystem for organisational deployments. It owns the authority model and routes to Roles, Permissions and Approvals; it is not a normal optional module. The objective is not to create more systems. It is to give AI a dependable operating layer through which existing organisational knowledge, tools and processes can be used coherently. ## Core and deployments Arco separates the reusable operating system from the organisation that uses it. ```text Arco Core ↓ deployed Organisation readme-X.md ↓ Organisation readme-X-local.md ``` ### Arco Core **Arco Core** contains reusable, organisation-agnostic operating rules. Core files use stable `arco-*.md` filenames. Examples: ```text arco-system-manual.md arco-skills.md arco-personas.md arco-context.md ``` Core should contain behaviour that can reasonably apply across deployments. It must not contain private organisational state, organisation-specific paths, local identifiers or configuration that only makes sense in one deployment. ### Deployed operating files When a Core operating file is deployed into an organisation, it becomes a local operating copy using the corresponding `readme-*.md` convention. For example: ```text Arco Core: arco-skills.md Organisation: readme-skills.md ``` The deployed file is the **runtime source of truth** for that organisation. Runtime operation must not depend on access to the upstream Arco Core repository. Each deployed Core-derived README records one upstream Core source so that future maintenance can compare the deployed version with its source and identify updates or divergence. The upstream source is therefore an **update reference**, not a runtime dependency. ### Local configuration Where a module requires deployment-specific configuration, that configuration should be isolated in a small `readme-*-local.md` companion file. For example: ```text readme-skills.md ↓ readme-skills-local.md ``` Local configuration may contain things such as: - paths; - file or register identifiers; - local storage locations; - enabled state; - authoritative local sources; - deployment-specific inventory. Do not create a local companion file unless local configuration is actually required. ## Singular pointers Paths, identifiers and other system references should have one authoritative home. A higher-level file should point to the next layer rather than duplicating everything beneath it. For example: ```text readme-ai-guide.md ↓ readme-skills.md ↓ readme-skills-local.md ↓ Skills Register / local paths ``` `readme-ai-guide.md` should not also contain the Skills Register identifier. This reduces reference drift and allows parts of the system to change without requiring unrelated files to be updated. ## The AI guide Every deployment has its own `readme-ai-guide.md`. The AI guide is the deployment's first-hop router. It directs AI to the smallest relevant set of enabled operating sources for the task. It is intentionally deployment-specific because different organisations may enable different Arco modules. For example, one deployment might route to: ```text System Manual Skills Personas ``` while another might route to additional enabled operating sources such as Context, Decisions or governance-related components once those components are sufficiently defined and deployed. The AI guide should contain routing, not duplicate the operating rules belonging to those components. Arco Core may provide a deployment template for constructing an AI guide, but there is no universal Core AI guide used directly at runtime. ## Core operating structure Arco combines universal operating layers with optional modules. ### System Manual The System Manual is the universal standard for maintaining Arco operating files. It governs shared rules such as naming, metadata, versioning, changelogs, archives, change control and maintenance behaviour. It is a Core operating layer, not an Arco module. ### Modules Modules separate different kinds of durable system knowledge and behaviour so that each can evolve without becoming one large instruction file. `arco-module-manual.md` defines the universal contract every module inherits. Individual module READMEs define only module-specific behaviour and do not repeat the universal module contract. A deployment only needs the modules that provide real value. #### Skills Repeatable maintained capabilities. Skills describe **how work is performed**. #### Personas Reusable perspectives or modes of thinking. Personas influence **how AI thinks, interprets or reviews**, rather than defining a workflow. #### Context Durable personal and organisational knowledge that helps AI understand the environment in which it is operating. Context describes **what is true or useful to know**. Context exists in Core but remains an Early module while its organisational deployment model continues to develop. A module can exist in Core without being enabled in a particular deployment. ### Defrag Defrag is Arco's live internal architecture-maintenance function. It reviews Core and deployed Arco structures for coherence, drift and unnecessary complexity while consuming—rather than duplicating—the rules owned by the System Manual, Module Manual, Governance and other canonical sources. Defrag is not a module or Skill. Material corrections discovered by Defrag still follow the Dry Run validation gate before promotion. Its canonical definition is `arco-defrag.md`. ### Governance and emerging operating areas Governance is a foundational Core subsystem for organisational deployments. Its top-level definition is `arco-governance.md`, with `arco-roles.md`, `arco-permissions.md` and `arco-approvals.md` owning the detailed Governance components. The **System Governor** is a required Arco Role for organisational deployments. **Champion** is an optional Arco Role. Neither is a standalone module. Other areas remain under active development, including Decisions and deployment configuration. Decisions is currently an optional module candidate and is expected to consume Governance rather than redefine authority or approval. The current module catalogue and maturity states are maintained separately in `arco-modules.md`. ## Deployment configuration Different deployments can use different combinations of Arco modules and governance. The system therefore needs a way to distinguish: ```text what Arco supports ``` from: ```text what this deployment has enabled ``` A small deployment configuration or `system-setup` record is currently being developed for this purpose. Its likely responsibilities include recording enabled modules and allowing deployment routing to be checked against actual configuration. The exact structure, filename and automation mechanism are not yet canonical. An AI reading this file should not invent a `system-setup` schema or assume that one has already been deployed. ## Source of truth Durable Arco behaviour belongs in maintained sources of truth, not individual chat threads. Chats are working sessions. They can produce: - corrections; - decisions; - evidence; - new requirements; - improvements. But if something needs to affect future behaviour, it should be incorporated into the maintained source that owns it. The same principle applies to organisational data. Arco does not require ordinary business information to be moved into an Arco repository. Existing systems can remain authoritative. Arco should connect to, route to or maintain appropriate representations of those sources rather than unnecessarily replacing them. ## Adaptation Arco is designed to improve through real use. Adaptation should be **evidence-driven**, not speculative. Useful evidence can include: - an explicit correction; - a workflow producing the wrong result; - a repeated friction point; - a material organisational change; - a recurring requirement; - evidence that an existing rule or process no longer reflects reality. When evidence exposes a durable improvement, change the part of the system that owns the behaviour. A generic improvement should normally flow: ```text Arco Core ↓ deployed operating copies ``` An organisation-specific improvement should remain local unless there is a deliberate decision to generalise it into Core. If nothing material has been learned, nothing needs to change. ## Design principles Arco follows these principles: 1. **Durable state lives outside chat.** Important context, capabilities and operating rules should survive individual conversations. 2. **Core is organisation-agnostic.** Reusable operating behaviour belongs in Core; private organisational state does not. 3. **Deployments are runtime-independent.** An organisation should continue operating even if the upstream Core source is unavailable. 4. **One responsibility, one source of truth.** Rules, paths and identifiers should live with the component that owns them. 5. **Load only what is relevant.** AI should receive the smallest useful context set rather than loading the whole operating system. 6. **Use existing sources of truth.** Arco should not create replacement systems merely to bring information under its own control. 7. **Local configuration stays small.** Separate deployment-specific configuration from reusable operating behaviour. 8. **Real use drives evolution.** Build from demonstrated need rather than speculative completeness. 9. **Do not build empty architecture.** A possible future requirement is not enough reason to create another module, file, register or process. 10. **Changes are traceable.** Maintained operating files are versioned and meaningful changes have history. 11. **Governance is deployment-sensitive.** A personal deployment and a large organisation should not be forced into the same approval model. 12. **Remain provider-agnostic where practical.** Arco should not unnecessarily depend on one AI model, provider or interface. 13. **Less systems, not more.** Arco should simplify how humans and AI work together rather than become another layer of administrative overhead. ## Core repository The Arco Core repository contains the maintained reusable operating system. Its intended structure is: ```text /Arco ├── arco-readme.md ├── arco-design.md ├── arco-development.md ├── arco-modules.md ├── arco-module-manual.md ├── arco-system-manual.md ├── arco-dry-runs.md ├── arco-defrag.md ├── arco-deployment.md ├── arco-governance.md ├── arco-roles.md ├── arco-permissions.md ├── arco-approvals.md └── modules/ ├── skills/ │ └── arco-skills.md ├── personas/ │ └── arco-personas.md └── context/ └── arco-context.md ``` The deployment AI-guide template remains an emerging distribution/deployment concern until its canonical Core location and publication route are deliberately resolved; do not infer a live `/Arco/templates/` path from the concept alone. Only sufficiently mature operating behaviour should be promoted into Core. Unresolved architecture, experiments and provisional ideas belong in development material until they have been deliberately resolved. ## Public Core and private state Arco Core is intended to be distributable. An organisation's deployment is not. This creates a deliberate boundary: ```text Public / distributable Arco Core ↓ Private Organisation deployment ↓ Organisation data and state ``` Core can therefore evolve as a reusable operating system without becoming a repository for the private knowledge of organisations using it. Future external deployments are expected to receive Core updates from a machine-readable distribution source such as `arco.stoirm.co.uk`, while the editable canonical Core remains separately maintained. The distribution mechanism itself is still under development. ## Evolution Arco will continue to evolve. Version `1.0.0` establishes the foundational operating model: - reusable Core; - local deployment; - optional local configuration; - runtime independence; - modular operating sources; - deployment-specific routing; - singular pointer ownership; - evidence-driven adaptation. It does not mean that every Arco module or governance mechanism has been designed. Unresolved architecture should remain outside this README until it is sufficiently proven to become part of the operating system. `arco-development.md` holds that development work. `arco-modules.md` records the current module catalogue and maturity. `arco-design.md` is Arco's architectural memory. It records **why** major architectural choices were made, including meaningful alternatives deliberately rejected or avoided, while this README remains the definition of **what Arco is and how its major parts fit together**. Canonical operating files continue to own behaviour. ## Changelog | Date | Version | Change | Approved by | Changed by | |---|---|---|---|---| | 15-Sep-2026 | 1.3.0 | Promoted `arco-defrag.md` as the live Core maintenance function for internal architecture coherence, explicitly outside the module/Skill catalogue and using Dry Runs for material corrections. | Stoirm Arnold | GPT-5.6 Sol | | 15-Sep-2026 | 1.2.2 | Corrected the Core repository index to match the canonical Governance, validation, deployment and Development files now present in `/Arco`, and removed the unimplemented template/development-folder paths from the live tree. | Stoirm Arnold | GPT-5.6 Sol | | 15-Sep-2026 | 1.2.1 | Updated live architecture pointers to the renamed canonical module contract `arco-module-manual.md`; historical changelog references remain unchanged. | Stoirm Arnold | GPT-5.6 Sol | | 15-Sep-2026 | 1.2.0 | Added `arco-module-standard.md` as the single universal contract inherited by all modules and future Module Builder work, while preserving `arco-system-manual.md` as the sole owner of maintained-file construction/maintenance rules and `arco-readme.md` as the owner of the singular-pointer architecture. | Stoirm Arnold | GPT-5.6 Sol | | 15-Sep-2026 | 1.1.0 | Reconciled the Core definition with the established Governance subsystem and the promotion of `arco-design.md` as Arco's architectural-memory artifact; clarified System Governor, Champion and Decisions relationships without moving detailed rules into the README. | Stoirm Arnold | GPT-5.6 Sol | | 15-Sep-2026 | 1.0.0 | Established the first Core definition of Arco based on the proven Core → deployed → local architecture; defined runtime independence, deployment-specific routing, singular pointers, modularity, adaptation and the public-Core/private-deployment boundary; clarified that Governance is not yet a standalone module and that the System Manual is a universal Core layer rather than a module. | Stoirm Arnold | GPT-5.6 Sol |