---
name: Context operating guide
version: 1.5.2
status: active
owner: Stoirm Arnold
last_updated: 30-Sep-2026
---

# Context operating guide

## Purpose
Context gives Arco durable, standardised understanding of an organisation, its units, positions and people without repeatedly re-explaining stable information.

Core defines the canonical structures. A deployment normalises its own source material into those structures and keeps local paths, sources, permissions mappings and enabled controls in `readme-context-local.md`.

Context owns the information, its factual state and its verification lifecycle. Governance owns access and change authority around the Context runtime; factual verification is not an Approvals action.

When source material is deliberately ingested into Context, the resulting canonical Arco Context becomes the maintained runtime authority for that information. The source file is evidence of origin, not a competing runtime source. Once ingestion has been verified, mark the superseded source clearly with an `ARCHIVE` prefix or equivalent deployment-approved archive treatment so normal search and discovery do not mistake it for live Context.

A connected operational system may still provide fresh source data where Local explicitly configures a continuing source relationship. That source feeds Context through the defined update/verification process; it does not become a parallel runtime Context layer.

Foundational Context should remain useful beyond a single planning cycle. Annual strategy, current priorities, active risks and other fast-changing state remain outside foundational Context unless deliberately modelled elsewhere.

## Deployment pattern

```text
Arco Core
arco-context.md
      ↓
deployed operating copy
readme-context.md
      ↓
local configuration
readme-context-local.md
      ↓
context-register
organisation/
units/
positions/
people/
```

The deployed `readme-context.md` is the runtime operating copy. `readme-context-local.md` stores deployment-specific configuration such as storage paths, authoritative sources, enabled Context areas, naming conventions, source-check cadence and Governance mappings. Organisation-specific Context stays in the Context records, not in the local README.

The Context Register should sit at the Context root alongside the entity folders rather than inside a register-only folder.

## Core record templates
Core provides:
- [arco-context-organisation-template.md](https://drive.google.com/file/d/1HMowQOACVXAh8W1qXBzeSz_79h7Io1a-/view)
- [arco-context-unit-template.md](https://drive.google.com/file/d/1Mi9CBnk4SYuevwJEw-Q9fsd1g2VFqZKU/view)
- [arco-context-position-template.md](https://drive.google.com/file/d/1CPnlWn7vI8h8KIEl1ImQDFjPOd0NTw5T/view)
- [arco-context-person-template.md](https://drive.google.com/file/d/1NPGo-OlLtqhdjWiRc3KfsVQ62OP0ja2X/view)
- [arco-context-register-template.md](https://drive.google.com/file/d/12_MMZPTct0KvoLLp0iwFSvDNAg8-BtSJ/view)

Person Working Context is part of the Person record and no longer requires a separate canonical file.

## Core and Local

### Core owns
- canonical Organisation, Organisational Unit, Position and Person structures;
- the Context Register schema;
- stable Context ID and alias-resolution principles;
- completeness, provenance, verification and freshness semantics;
- organisational verifier-eligibility rules;
- selective loading;
- the boundary with Governance.

### Local owns
- storage paths and register location;
- organisational and people source locations;
- source precedence where more than one continuing source feeds the same Context;
- onboarding/ingestion method;
- enabled Context components;
- local naming conventions;
- Context-to-Governance permission mappings;
- selected module controls;
- source-check cadence and local extensions.

## Organisational structure source
An organisational deployment should identify the organisational-structure source or sources used to establish and maintain Context. A source may be an org chart, HR system, spreadsheet or equivalent.

If material is supplied as a one-off ingestion source, normalise it into Context, preserve provenance, verify the resulting Context, then archive or clearly mark the superseded input so it cannot compete with canonical Context in later discovery.

If a connected operational source continues to feed structural changes, record that continuing relationship and its check/update state in the Context Register. The source remains an input to maintained Context rather than a parallel runtime Context authority.

## Foundational entities

### Organisation
Durable organisation-level Context such as:
- identity;
- purpose;
- business model and markets;
- culture and operating principles;
- history and evolution;
- organisational structure source.

### Organisational Unit
A department or sub-department beneath the Organisation.

A Unit stores:
- identity and parent Unit ID;
- `unit_type`, constrained to `department` or `sub-department`;
- accountable Position ID;
- child Unit IDs;
- Position IDs belonging to the Unit;
- purpose and scope;
- durable responsibilities;
- history;
- unresolved Context.

Do not create synonymous Unit types such as `team`, `sub-team` or `function`; normalise them to `department` or `sub-department`.

Do not duplicate names beside linked IDs in the canonical relationship. Resolve display names from the linked record.

### Position
A Position is the reusable organisational role definition represented by a canonical job title.

If multiple people have the same job title, assume they occupy the same Position unless a later demonstrated need requires differentiation. Unit-specific differences can be represented in Unit Context rather than creating duplicate Positions.

A Position stores:
- canonical title;
- owning Unit ID;
- reporting Position ID where applicable;
- organisational level where useful;
- status;
- purpose/remit;
- durable responsibilities.

Occupancy is represented canonically through Person → Position assignments rather than by creating one Position record per individual or maintaining a second occupant list in the Position record. To answer who currently holds a Position, reverse-resolve Person organisational-relationship Context against that Position ID through the Context Register.

### Person
A Person record represents the individual and contains:
- Identity;
- Engagement;
- Organisational relationship;
- History;
- Working Context;
- Unresolved Context.

Working Context belongs inside Person rather than a second profile.

`engagement_type` distinguishes at least:
- employee;
- full-time-consultant;
- ad-hoc-consultant.

Consultants intentionally have lighter Person Context. Employee-only Context components are `not applicable` for consultants and do not reduce completeness.

Employing/contracting entity and work location are separate source-backed facts. Do not infer one from the other unless Local explicitly defines a deterministic rule.

Engagement may include `start_date` and `end_date`. A blank date means the source-backed date is not currently held; do not replace a missing structured value with explanatory prose or an inferred date. An open/blank `end_date` must not be interpreted as a confirmed active engagement without the wider record state supporting that conclusion.

Manager-oriented strengths, inferred expertise, development interests, behavioural evidence, coaching and performance context remain outside foundational Person Context and belong to the emerging People Management module.

## Record ownership and record cleanliness
The maintained-file `owner` identifies the person or system responsible for maintaining that record; it is not automatically the person who created or generated the file.

For a Person record, the person represented should normally be the owner where the deployment allows that individual to maintain their own Context. Organisation, Unit and Position records use the locally accountable maintainer resolved through Context/Governance rather than defaulting to the migration operator.

Canonical Context records contain Context, not reusable operating instructions. Rules such as linking behaviour, assignment semantics, inheritance, inference boundaries and lookup behaviour belong in this operating guide or another higher owning source, not repeated inside each generated record.

Use the smallest non-duplicative record presentation. A Position record, for example, should not repeat `Position Context` in its YAML name, title and first content heading when the canonical position title already identifies the record.

## Linking rules
Use stable IDs for canonical relationships.

Do not store both an ID and a duplicated human-readable label where the label can be resolved from the linked record. Renaming the linked record must not require updates across every dependent record.

Canonical structure:

```text
Organisation
  ↓
Organisational Unit
  ↓
Position
  ↓
Person assignment
```

## Context Register
Every organisational deployment should maintain a structured Context Register. Its storage format follows [arco-system-manual.md](https://drive.google.com/file/d/1doS7QXRtShzT45wHC13Vx0zxputK50l-/view).

The Register has two roles:
1. pre-load lookup from canonical names/aliases to stable Context IDs and records;
2. lifecycle/completeness/accountability tracking at Context-component level.

Each independently maintainable Context component should have its own row where it needs separate completeness, accountability, source or verification state.

Examples for a Person:
- Identity
- Engagement
- Organisational relationship
- History
- Working Context

Examples for an Organisation:
- Identity
- Purpose
- Business model and markets
- Culture and operating principles
- History and evolution
- Organisational structure source

The parent record's completeness is derived from its applicable child Context components.

### Component Context IDs
Every independently registered child Context component uses a stable machine-safe suffix appended to its parent ID. Use uppercase three-letter suffixes without spaces, punctuation or colons.

For Person Context, the baseline suffixes are:
- `IDE` — Identity
- `ENG` — Engagement
- `ORG` — Organisational relationship
- `HIS` — History
- `WOR` — Working Context

Example: `TT-P-0001-IDE`.

Equivalent three-letter suffixes should be defined for Organisation, Unit and Position components when instantiated. Do not reuse a suffix for two different components under the same parent.

### Completeness
Child components are binary for completeness:
- `complete` = 100%
- `incomplete` = 0%
- `not applicable` = excluded from the denominator

Parent completeness is:

```text
complete applicable child components
÷
all applicable child components
```

Verification is separate from completeness.

## Identity and alias resolution
Aliases must resolve before the canonical record is loaded.

```text
canonical name / alias
        ↓
Context Register
        ↓
stable Context ID
        ↓
canonical record
```

Aliases may include preferred names, shortened names, previous names, acronyms and recurring dictation variants.

## Governance relationship
Context does not define Permission Groups or approval rules.

Permissions determines who may access or change Context within a governed scope. Organisational attributes such as Unit membership or Position may be mapped by Governance into Roles or Permission Groups.

A permitted Context change does not require an Approvals step merely because it changes Context. New or changed factual Context may instead enter the runtime with `verification_status: pending` until an eligible verifier confirms it.

Approval and verification are distinct:
- **approval** = consent for an otherwise eligible governed action where the owning domain requires an additional authority gate;
- **verification** = factual confirmation that Context reflects reality.

Context owns factual verification. Governance may supply identity, permission or group resolution where needed, but it does not turn verification into an Approvals workflow.

## Context changes and verification

When a permitted user supplies new or changed factual Context:

1. preserve provenance, including who supplied it and the source where available;
2. write or update the relevant Context record/component;
3. set verification to `pending` when the statement is not already verified by an authoritative source or eligible verifier;
4. optionally assign a verifier target;
5. surface pending verification to the configured orchestration/Daily Scan;
6. when an eligible verifier confirms it, set `verified`, `verified_by` and `verified_on`.

Pending Context is provisional, not absent. It may be used where useful if its status is preserved, but it must not silently override conflicting verified Context or be presented as equally certain.

### Eligible verifiers for organisational Context

Where the deployment has the canonical Unit → Position → Person structure, verifier eligibility is resolved deterministically from the Context hierarchy.

For Context scoped to an Organisational Unit, an eligible verifier is:

1. a person whose active Person → Position assignment places them inside that Unit;
2. the holder of the Unit's accountable Position;
3. the holder of each Position reached by following the accountable Position's reporting chain upward.

Eligibility does not inherit sideways to sibling Units and does not make every member of a parent Unit eligible.

For Context scoped to a Position or Person, use the most specific relevant Unit and accountable/reporting chain rather than inventing a separate hierarchy.

If the required organisational relationships cannot be resolved deterministically, do not guess. Leave verification pending and use an explicit assigned verifier or local escalation rule.

A lightweight or personal deployment that does not maintain organisational Unit/Position hierarchy may use explicit verifier assignment, self-verification where appropriate, source-backed verification, or a local rule. It does not need to recreate organisational Context merely to use verification.

### Assigned verifier

`Assigned verifier` is optional orchestration state for a pending verification.

It may point to:
- an individual Person/Profile ID;
- a Position ID;
- an Organisational Unit/scope ID;
- a Governance Permission Group ID where the deployment uses one.

Store the stable identifier, not a free-text name, once the target can be resolved.

A group assignment means any person who resolves as a current member of that target is eligible to complete the verification. For an Organisational Unit such as Client Operations, membership resolves from current Person → Position → Unit relationships. For a Permission Group, Governance resolves current membership from its authoritative membership source.

Reassignment changes the verification target, not the underlying Context statement or its provenance.

## Verification and freshness
Verification confirms current accuracy. `last_updated` records file change, not factual verification.

Source-backed Context should record when the source was last checked. Missing source-of-truth information should remain explicitly missing.

## Selective use
Load only relevant Context. Context should normally influence answers invisibly rather than narrating background facts merely because they are available.


## Canonical references

[arco-governance.md](https://drive.google.com/file/d/1JmdNUNPVJLxFbNQKYS3cJTnDPJ6hRvxb/view).

## Changelog

| Date | Version | Change | Approved by | Changed by |
|---|---|---|---|---|
| 30-Sep-2026 | 1.5.2 | Restored canonical provider-link references; Rolled the live changelog to five entries with archived history. | Stoirm Arnold — Defrag invocation | Codex Work |
| 25-Sep-2026 | 1.5.1 | Corrected Context operating-guide lifecycle metadata from draft to active to match the Core module catalogue, which has classified Context as Live since v1.0.0 promotion. No runtime behaviour changed. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 25-Sep-2026 | 1.5.0 | Replaced Context approval/proposal routing with factual verification: permitted Context changes can enter as pending, verifier eligibility resolves from Unit membership and the accountable/reporting Position chain, sibling authority is excluded, and optional Assigned verifier may target a person, Position, Unit/scope or Permission Group by stable ID. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 22-Sep-2026 | 1.4.0 | Clarified ingestion authority: verified Arco Context becomes the maintained runtime authority for ingested information; superseded source files must be visibly archived so search cannot treat them as live Context; continuing operational sources remain configured inputs to the Context update process rather than a parallel Context layer. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |
| 21-Sep-2026 | 1.3.0 | Removed Context-level Register-format hardcoding so the Context Register inherits the universal Register storage standard from the System Manual. | Stoirm Arnold | ChatGPT Chat — GPT-5.6 Sol (Medium) |