---
name: Context operating guide
version: 0.2.0
status: draft
owner: Stoirm Arnold
last_updated: 15-Sep-2026
---

# Context operating guide

## Purpose

Context gives the system durable, structured understanding of an organisation, its organisational units and its people without requiring users to repeatedly explain stable information.

Foundational company context should contain relatively durable knowledge. Frequently changing operational information such as annual strategy, current priorities, active risks or short-term plans belongs in separate context sources rather than the foundational company context.

This module follows the deployed system manual for universal naming, metadata, versioning, ownership, change-control and changelog rules. This file defines only Context-specific behaviour.

## Module contract

- **Boundary** — Context owns durable structured knowledge needed for AI to understand the organisation, organisational units and people, together with the state needed to maintain that Context. It does not replace authoritative external sources, own Governance mechanics, or absorb fast-changing operating state merely because it may be useful to AI.
- **Outputs** — maintained Context records, local machine-readable representations where justified, and Context Register state.
- **Dependencies** — `arco-module-manual.md` for the universal module contract; `arco-system-manual.md` for maintained-file behaviour; authoritative organisational sources identified by the deployment; deployment/local configuration for paths, Register references and selected module controls; Governance for permissions and consent where required.
- **Access scope** — `Context` at module level; finer-grained access should use the stable Context IDs owned by the Context Register where those records exist.
- **Deployment/local requirements** — canonical Context storage, authoritative-source locations, enabled state, Context Register references and the selected module/governance configuration described below.
- **Lifecycle state** — **Early**, as recorded in `arco-modules.md`; existence in Core does not imply enablement in a deployment.
- **Maintenance route** — maintained Context files follow `arco-system-manual.md`; the universal module controls are inherited from `arco-module-manual.md`, while deployment/System Setup owns their selected values.

## Core principles

1. Context must not become a competing source of truth where an authoritative source already exists.
2. Authoritative sources are identified during deployment and remain authoritative unless explicitly replaced.
3. The system may maintain local machine-readable representations of authoritative sources for reliable use and routing.
4. Context must distinguish authoritative organisational fact, self-authored or self-verified context, private context and inference.
5. Unknown or unverified information should remain unknown or unverified rather than being plausibly inferred.
6. Context should be loaded selectively rather than as one large profile.
7. Every maintained context record should have observable accountability, freshness and verification state.
8. Context should become useful before every optional area is populated; optional gaps must not block setup.
9. Structural information derived from an authoritative source should not be manually duplicated unless the local copy is clearly identified as a maintained representation of that source.

## Deployment and storage

The deployment identifies canonical locations for Context and its authoritative sources.

If no deployment-specific location has yet been established:
- shared organisational Context should live in organisation-controlled storage accessible to its intended audience;
- private Context should live in the relevant individual's private workspace or another explicitly authorised private location.

Where a Context location, accountable party or authority cannot be resolved from the existing organisation or deployment, defer to the System Governor. Once resolved, record the decision so the same ambiguity does not recur.

Deployment-specific paths, identifiers, enabled state, authoritative-source locations and Register references belong in local deployment configuration, not in this Core standard.

## Organisation source of truth

For a new organisational deployment, the org chart is the default bootstrap source of truth for organisational structure.

The deployment identifies where the authoritative org chart lives. The system should then:
1. read the authoritative org chart;
2. create or refresh a local machine-readable Markdown representation for reliable use;
3. infer the organisation, organisational units, positions, people and reporting relationships;
4. surface material ambiguities to the System Governor before establishing the initial Context foundation;
5. periodically check the authoritative source for changes.

The default org-chart check cadence is no more frequent than weekly unless the deployment explicitly requires otherwise.

When the authoritative org chart changes, update the local representation and flag affected Context records for review where necessary. The local representation supports system use but does not silently replace the authoritative org chart.

## Foundational Context entities

### Organisation

Represents the organisation itself and relatively durable company information such as purpose, history and evolution, business model, customers and markets, locations and legal entities, culture and operating principles, and enduring organisational structure and governance.

Annual strategy, current priorities, transient risks and short-term plans are outside foundational Organisation Context.

### Organisational Unit

Represents a department, sub-department, function, team or equivalent grouping beneath the Organisation.

Structural facts such as hierarchy, leadership and membership should come from the authoritative org chart where available. The Context record adds durable information such as purpose, scope, responsibilities, important organisational interfaces, operating principles and relevant historical context.

### Person

Represents an individual in the organisation.

Authoritative identity, position, reporting and unit information should come from the org chart or another authoritative people source where available.

Additional Context may include organisational responsibilities not adequately represented in the source system, self-authored or self-verified working context, and separately governed private context.

## Shared, self-authored and private Context

The system must preserve the distinction between:
- organisational fact;
- self-authored or self-verified working Context;
- private relationship or assessment Context.

Private Context must never silently become organisational fact or employee-facing Context.

## Context Register

Every organisational deployment should maintain a structured Context Register once Context is enabled.

The Register records the state of the Context layer rather than duplicating the Context itself. At minimum it should identify:
- stable Context ID;
- entity;
- entity type;
- parent relationship where relevant;
- canonical Context record;
- accountable party;
- permitted maintainers where required;
- Context status;
- completeness;
- verification status;
- verified by;
- verified on;
- authoritative source where applicable;
- source-check or sync state where applicable.

A piece of information should not become its own registered Context record unless it needs an independent lifecycle, authority or verification state.

Detailed Register schemas should be defined separately if they become substantial enough to require their own operating specification.

## Verification and freshness

`last_updated` records when a maintained file changed under the universal system standard.

Verification records when an authorised person confirmed that the Context itself was correct. A record may therefore be updated without being re-verified.

To avoid unnecessary duplication, verification state should normally be maintained in the Context Register rather than repeated throughout Context files.

When a user engages with the system and an existing profile can be reliably identified, the system should allow that user to confirm or correct their relevant Context and record that verification.

For records backed by an authoritative external source, freshness should also reflect when that source was last checked.

## Completeness

Baseline Context defaults should be sufficient for the system to become useful without requiring every optional area to be populated.

A deployment may enable, disable or extend optional Context areas. Context areas may be treated as populated, partial, not populated, not applicable, inherited, or needing verification.

Optional or inherited areas must not block activation of otherwise useful Context.

## Changes and authority

Context defines who is authoritative for information and who is accountable for maintaining it.

Change proposals, approvals and execution use the universal change roles defined in the deployed system manual. This README does not redefine competing terminology.

If no clear authority exists, defer to the System Governor. Once resolved, update the maintained system so the decision becomes durable.

## Selective use

Load only the Context relevant to the task.

Structural facts should be derived from the authoritative organisational source or its current local representation. Additional Context should then be loaded only for the relevant Organisation, organisational units and people.

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 15-Sep-2026 | 0.2.0 | Aligned Context with the Module Manual by explicitly defining its boundary, outputs, dependencies, access scope, deployment requirements, lifecycle state and maintenance route while preserving its Early lifecycle state and authoritative-source model. | Stoirm Arnold | GPT-5.6 Sol |
| 14-Sep-2026 | 0.1.0 | Extracted the organisation-agnostic Context operating standard from the Stoirm Ltd draft while preserving authoritative-source, entity, verification, freshness, completeness, Register and selective-loading behaviour. | Stoirm Arnold | GPT-5.6 Sol (Medium) |