---
name: Deployment operating guide
version: 0.4.2
status: draft
owner: Stoirm Arnold
last_updated: 15-Sep-2026
---

# Deployment operating guide

## Purpose

This draft captures the emerging design for deploying the system to an individual or organisation before the deployment model is ready for use.

A deployment is a configured instance of the system for a particular person, organisation or environment. It determines which system capabilities are in use and how they connect to local sources, storage, roles and governance.

For universal maintained-file conventions, follow the deployment's System Manual.

## Confirmed decisions

- Deployment configuration is distinct from universal system rules and from module-specific operating rules.
- Arco Core operating files use `arco-*` naming; normal deployed operating copies use `readme-*` naming.
- `arco-readme.md` is the Core definition of Arco. If an external deployment needs a local copy of that definition, the deployed name is `readme-arco.md`; it does not become `readme-readme.md`.
- An organisation that is also the editable home of Arco Core may use the relevant Core definition directly where Core is intentionally the runtime source of truth. Do not create a redundant deployed copy solely to mirror the same file inside the same operating environment.
- A deployment should identify which modules are enabled and which are not in use.
- Deployment ownership and any required system roles should be configured according to the Roles model once those responsibilities are sufficiently resolved.
- Deployment should identify authoritative external sources required by enabled modules.
- Deployment should identify canonical storage locations required by enabled modules rather than allowing each session to rediscover them.
- Approval policy is a deployment-level setting even though individual modules may have specific requirements.
- When an organisational Context module is deployed, the org chart is the default bootstrap source of truth for organisational structure.
- During setup, the system should infer as much as practical from authoritative sources, then surface material ambiguities to the deployment's configured responsible role or human owner before implementing the foundations.
- Local machine-readable copies may be maintained for system use without silently replacing authoritative external sources.
- Shared organisational information should default to organisation-controlled shared storage when no more specific location has been configured. Private information should default to an appropriately private workspace.

## Provisional direction

- Deployment is likely to require a small canonical configuration record that other modules can read.
- The configuration may need to distinguish system core files from deployment-specific settings and local customisation.
- Module enablement may eventually support states such as active, disabled, draft, beta or testing.
- Deployment setup should aim to be guided and largely inferred rather than requiring users to understand the underlying file architecture.
- The role responsible for resolving setup ambiguity should be determined by the eventual Roles and governance model rather than assumed here.
- Deployment configuration may eventually support central system updates without overwriting local context or organisation-specific choices.


## Module setup during onboarding

Deployment onboarding should instantiate the universal module controls defined by `arco-module-manual.md` for each enabled module.

Do not restate those controls here.

Deployment owns the System Governor-facing setup experience and the selected local values; the Module Manual owns which universal controls exist; Governance owns Permission and Approval mechanics.

Normal onboarding should remain plain-language and simple. Any future advanced controls should remain hidden unless deliberately enabled.

## Open questions before v1

- What is the minimum deployment configuration schema?
- Where does the canonical deployment configuration live?
- How are module enablement and module-specific settings represented?
- How should Roles and Approvals be referenced without duplicating their rules?
- What is the installation or onboarding sequence for a new deployment?
- How are local overrides distinguished from reusable system defaults?
- How should deployments receive, review and adopt future core updates?
- What compatibility checks are required before applying an update?
- How should deployment health or structural drift be surfaced?

## Boundaries

Deployment configures the local instance of the system. It should not duplicate the operating rules of enabled modules, define organisational truth that belongs in Context, or reproduce approval and role logic owned by their respective subsystems.

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 15-Sep-2026 | 0.4.2 | Corrected the remaining live terminology from Module Standard to Module Manual in the onboarding ownership boundary; no deployment behaviour changed. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.4.1 | Updated the live deployment pointer to the renamed canonical module contract `arco-module-manual.md`; historical changelog references remain unchanged. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.4.0 | Replaced duplicated per-module approval-control definitions with a single pointer to `arco-module-standard.md`; Deployment now owns only onboarding/selected values while the Module Standard owns the universal controls. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.3.0 | Added the simple per-module onboarding model for approval configuration: Automatic system updates ON by default plus a separate Output approval question, with granular controls hidden behind future advanced settings. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.2.1 | Removed the remaining premature System Governor setup reference identified during dry-run verification; setup ambiguity now routes to the deployment's configured responsible role or human owner until Roles architecture is resolved. | Stoirm Arnold | GPT-5.6 Sol |
| 15-Sep-2026 | 0.2.0 | Aligned deployment naming with the proven Core → deployed convention, clarified the special deployment name for `arco-readme.md`, allowed the Core-hosting organisation to avoid redundant deployed copies, and removed premature assumptions about System Governor ownership. | Stoirm Arnold | GPT-5.6 Sol |
| 11-Sep-2026 | 0.1.0 | Captured the initial design-stage model for deployments, including module enablement, System Governor assignment, authoritative sources, canonical locations and unresolved configuration questions. | Stoirm Arnold | GPT-5.6 Sol (Medium) |