---
name: core-operating-model
type: core
description: The canonical reference for how Aled's AI operating layer is structured — the six layers (inputs, skills, scheduled, agents & operators, workflows, governance), what each is, and the rules that distinguish them. Read this before building, modifying, or proposing any skill, task, routine, agent, operator, workflow, playbook, or governance artefact, and to apply the classify-by-nature test. Supersedes the prior skill/task/routine/agent model.
---

# Operating model

The canonical description of how the os.Claude operating layer is structured: the layers, what each is, and the rules that distinguish them. This is the system's self-model — read before building, modifying, or proposing any skill, task, routine, agent, operator, workflow, playbook or governance artefact.

## The stack

| Layer | Name | What it is | Nature |
|---|---|---|---|
| 0 | **Inputs** | Sources, data, memory, and the absorbed standards & conventions | Read — descriptive ("what is") |
| 1 | **Skills** | A repeatable behaviour — *what* to do | Runs |
| 2 | **Scheduled** | Tasks (cadence) and Routines (execution) | Runs, on a clock |
| 3 | **Agents & operators** | Named collections with a mission — functional agents and vertical operators | Organises |
| 4 | **Workflows** | A standing process work flows through | Runs |
| 5 | **Governance** | Principles, policies, standards, conventions, playbooks | Read — normative ("what ought") |

Two ends bracket the behavioural middle: **Layer 0 is descriptive** (the facts read into work), **Layer 5 is normative** (the rules that guide it). Layers 1–4 are behaviour.

Classify by **nature, never by shape**. A sequence (A→Z) and a surface are *shapes and axes* that appear across many layers; they never decide which layer something is in. The decider is always: does it **run** (behaviour) or is it **read** (input or governance)?

## Layer 0 — Inputs

Everything the behavioural layers consume:

- **Sources & data** — the working materials a job needs.
- **Memory** — what is known: the decision logs, project / people / database state.
- **Standards & conventions, absorbed** — the operational rules and their concrete applications, held here as consumable reference.

Standards and conventions are **owned by governance (L5) but read as input (L0)**: authorship sits in L5, while the absorbed, consumable form is read at L0. Owning a rule and consuming it are different acts, placed in different layers.

## Layer 1 — Skills

A `SKILL.md` that encodes a repeatable behaviour — *what* to do, with a trigger, loop and guardrails. Skills are behavioural only; the old "contextual skill" variety is retired — reference material now lives in Layer 0. A skill is loadable in a session and carries no schedule and no surface of its own. The moment something only runs on a clock, it is a Layer 2 deployment of a skill, not a skill. Naming: the `skill-` prefix, no role or agent qualifier.

## Layer 2 — Scheduled

Both forms are scheduled and can be run by hand. They are distinguished by **surface and intent**.

**The wrapper model — artefact is canon, config is a loader.** A scheduled job is *two artefacts*: a `task-*` / `routine-*` canon `SKILL.md` that holds the instructions (the single source of truth, saved and edited like any skill), and a static **loader config** in the Cloud Routine / Cowork settings that does nothing but read and follow it — `Read .claude/skills/<artefact-name>/SKILL.md and follow it verbatim`. After a one-time config edit the loader is frozen; every future change flows through the artefact and the save-skill loop. This removes the second source of truth Claude cannot reach: under the old self-contained model the config carried its own full prompt, so canon and config drifted with no way for Claude to fix it (worked case: the coordinate task ran stale wording while the skill canon had moved on, and ops-sync faithfully mirrored the stale config to the repo, 2026-06-25). The config is a loader; the artefact is canon.

**Tasks** — scheduled jobs on the Cowork / connector surface. They reproduce the *cadence* of a team (standup, triage, reports, hygiene) and live here because that surface holds the connector access they need. A scheduled job splits into two artefacts **only when its behaviour has genuine independent (ad-hoc) reuse**: a reusable `skill-*` with a thin `task-*` loader over it (triage, plan, coordinate, ops-sync, pipeline-qualify, pulse-retro→skill-ops-retro), or a `task-*` orchestrator over a reusable engine skill (pipeline-sweep over skill-pipeline-sweep). Where the behaviour is *inherently the scheduled job* with no independent use, it is self-contained in the `task-*` with no `skill-*` (daily-report, pipeline-graduation). The test: would you ever run this behaviour ad hoc, outside the schedule? Yes → `skill-*` + thin `task-*`; no → `task-*` only. Naming: the `task-` prefix.

**Routines** — scheduled executions on the Claude Code surface, where the repos are. They exist to *execute*, explicitly because there is no team — night runs intake the day's tickets, use cheap tokens, drain backlog, and move toward 24/7 delivery; trigger-driven execution is the intended future. A routine can **sequence** skills into a loop (the delivery loop) rather than wrap one, holding the driver behaviour in the `routine-*` artefact itself while the Cloud Routine config stays a thin loader. Naming: the `routine-` prefix.

## Layer 3 — Agents and operators

Layer 3 holds **named collections of skills, tasks and routines with a mission** — an organising shape that makes the system legible and accountable, not an execution event. Two classes live here, split by **scope**, exactly as Layer 2 splits scheduled work into tasks and routines:

- **Agent** (`agent-` prefix) — *functional, horizontal*. Owns one capability across every vertical.
- **Operator** (`operator-` prefix) — *vertical*. Owns one venture end-to-end, commanding the functional fleet to reach the vertical's outcome and coordinating with peer operators.

An agent is narrow in scope but deep in a capability; an operator is thin in *labour* — it executes nothing itself — but singular in **accountability** for its vertical's outcome. Each declares name, role, mission, objectives, goals and remit; a skill may belong to several. The profile *format* for both classes lives in `convention-artefact-format` — there is no template artefact, and `agent-operator` would be a category error, since an operator is a peer class to an agent, not a kind of agent.

Names are **abstract, with the functional role declared underneath** — an addition to the ways of working, not a person replaced. No human names.

### Functional agents

Each functional agent carries a name in two forms:

- **Written form** — the plain name used in descriptions and all canon prose: *Relay*, *Forge*, *Prism*, *Scout*, *Pulse*, *Atlas*.
- **Branded form** — the droid-style name used for the Linear `agent` label value **and** the public agents site card: *R3-LAY*, *F0-RGE*, *PR-1SM*, *SC-0UT*, *PUL-5E*, *ATL-4S*.

The executor axis is the single-select Linear label **group `agent`**, whose *value* is the agent in branded form (e.g. value `F0-RGE`, shown `agent:F0-RGE`); lookups query the group's value, never a flat label string. **Only the named functional fleet carries a branded label** — the other executor values (`human`, the lowercase `operator-*` values, and other-model agents like `claude` / `codex`) stay lowercase, which makes the class obvious on the board at a glance. Labels are model-agnostic. Naming: the `agent-` prefix for the profile.

**The fleet:** Relay (delivery management), Forge (implementation), Prism (review), Scout (pipeline), Pulse (ops). Atlas (planning) is a future addition. Profiles are held in the agent roster.

### Operators, and the tiering

An operator owns a vertical (BARA, A1, careerOS, app.fitness, os.Claude) end-to-end. Its label value is lowercase `operator-<venture>` (e.g. `operator-bara`), a domain role distinct from the branded functional fleet. The first instance is `operator-bara`. Three tiers stack, top to bottom:

- **Owner** — the human at the top (Aled). Sets and confirms each operator's mandate, arbitrates across verticals, and gates two hard anchors: a **strategic pivot** and **budget allocation**. This tier is *added above* the operator; it does not rename it.
- **Operator** — owns a vertical within a granted mandate. The slot is usually filled by the Owner today; making it an AI is the thing under test (`operator-bara`). The "operator is the gate" principle is unchanged — the operator gates delivery within its vertical.
- **Functional fleet** — the agents, invoked by the operator via Relay and the others.

**The mandate — the autonomy lever.** Each operator is granted a mandate: a goal, a timeframe, and a resource/budget envelope. Owner and operator set the *what* (goal and objectives) together; the operator works the *how* with Atlas and brings the approach and upcoming plans back for a light Owner review before proceeding. It then acts fully autonomously *within* the envelope — every tactical and day-to-day choice (which campaign, which acquisition channel, how to spend inside the envelope) is the operator's. It escalates only at the mandate's edge, on three anchors: a **strategic pivot** (a change to positioning or strategy, not a tactic — high-end craft → low-end dropship, even where it would hit a number); a **budget-envelope breach** (spending beyond the agreed figure); and a change to the **goal set** itself. "As autonomous as possible within allocated resources" is literally the size of the envelope — widen it as trust and proof grow. An operator does not replace Prism's review gate or the delivery-loop merge gate; it decides *what* to pursue and *why*, not how each merge is approved.

**The layered gate.** The delivery loop's selective gating, one tier up: unflagged work proceeds autonomously within the vertical (the operator is the gate); only the three anchors go up to the Owner, always with a recommendation. Cross-vertical contention for the shared fleet (one Forge per repo, finite capacity) is resolved by **Atlas**, which prioritises *across* operators for the Owner — a sharpening of Atlas's remit. Peer coordination between operators (shared makers, the brand house) is event-driven, not a standing committee.

**Thin, not a duplicate.** An operator composes Atlas (planning) and Relay (delivery flow); it must not re-implement them. An operator that starts doing its own planning or delivery-management is a refactor signal.

## Layer 4 — Workflows

A workflow **runs**: the standing process that work flows through to reach an outcome, composing behaviour (Layers 1–3) — humans and/or agents applying skills, firing tasks and running routines across surfaces — and visualised so the system can be seen working. The delivery loop is the type case: every build ticket flows through it; the venture operating loop is the operator-tier equivalent. Naming: the `workflow-` prefix, authored as Mermaid then visualised.

A workflow is a *composition of behaviour* (Layers 1–3). It is distinct from a playbook, which is a composition of governance — see below.

## Layer 5 — Governance

The normative layer: the principles, policies and controls that guide everything below and ensure work is done accurately. It does not execute; it constrains and directs. It holds **atomic rules** and **composite playbooks built from them**.

Atomic rules, abstract to concrete:

- **Principle** — the guiding intent. "The operator is the gate" (within a vertical); "the Owner is the gate" for the hard anchors — a strategic pivot and budget allocation. The *why*.
- **Policy** — a control or boundary that enacts a principle. "Propose-only." "Never merge your own work."
- **Standard** — a quality bar the work must clear, independent of tools. "A ticket embeds acceptance criteria." You can *pass or fail* it.
- **Convention** — an arbitrary-but-shared choice where only consistency matters. Label taxonomy; branch naming. You can only *diverge* from it.

The test: if two sensible people could each choose differently and it wouldn't matter which as long as they agree → **convention**; if one choice is better → **standard**. The distinction is load-bearing: conventions are checked by consistency and auto-fixed, and change freely; standards are checked by judgement and change deliberately.

Composite artefact:

- **Playbook** — a reusable, prescribed response to a recurring *scenario* ("when X, run these steps"). Unlike a workflow, a playbook is **read and followed, not run**: it composes governance (standards, conventions and judgement), can be entirely human, and *uses* workflows for whatever parts are automated — as it automates it sheds steps into a workflow rather than becoming one. Naming: the `playbook-` prefix.

**How governance propagates.** A principle set here shows up as standards and conventions absorbed into Layer 0, as controls embodied in workflows (Layer 4), and as the discipline ensuring accurate execution of Layers 1–3. It is set by the Owner, enforced by the Ops agent (propose-only), and embodied in workflows — the layers interlock, not merely stack.

## Changing canon

How a change to this operating layer is **applied** — distinct from how it is authored.

**Three lanes — which is this work in?** Before planning any os.Claude change, place the work in exactly one lane; the trap is bundling a repo-native edit into a canon change, or vice versa (worked case 2026-06-25: a `CLAUDE.md` edit bundled into a canon ticket, later split out).

| Work type | Lane | Executor | How it lands |
|---|---|---|---|
| Canon content — a skill, convention, agent or operator profile, task, or routine | Canon | Pulse → operator | Produced as a `.skill`, saved via the button |
| Repo-native file — `CLAUDE.md`, `build-manifest.ts`, site code | Repo | Forge | A PR, merged by the operator |
| Publishing saved canon to the repo | Publish | ops-sync | Automatic and downstream — never planned by hand |

Canon is saved, the repo is a PR, publishing is automatic. The rest of this section is the canon lane in detail; `convention-linear` binds the lanes to Linear labels.

Canon lives Claude-side as the saved skills; the `claude-ops` repo is a downstream mirror brought up to canon afterwards by `skill-ops-sync`. A change to any skill, convention, agent or operator profile, task or routine is therefore applied **into the Claude skills store — never the repo, and never the read-only session cache**.

The mechanism is the **save-skill feature**. A proposed change is produced as a complete, one-click-saveable `.skill` artefact (a zip of the skill directory containing its `SKILL.md`), which the operator saves into the store in a single step. The operator is the gate: Claude never edits canon in place. A ticket is never raised to **apply** a canon change — that is a downstream-first inversion — but a Pulse **capture** note (a `FRICTION:` ticket on `agent:PUL-5E`) is the correct, expected intake from any surface that cannot reach the save button (Claude Code, headless, scheduled runs): it records the observation for the drain to assess, and never routes a canon edit to Forge.

**Why intake funnels through one queue.** A skill spotting friction is rarely running where a `.skill` can be saved, and per-session saves fail two ways: a package buried in one of many sessions is easily missed, and concurrent autonomous sessions saving canon would clobber one another. So all canon-improvement intake is captured to the single Pulse friction queue (`skill-ops-retro` capture mode); `task-pulse-retro` drains it in batch, consolidating everything that touches one artefact into a single update built on the latest canon, and surfaces the set in one place for the operator to save. Only then does `skill-ops-sync` raise the publish ticket carrying canon to the repo. The capture note and the publish ticket are the two legitimate tickets in this flow; an apply-via-Forge ticket is not.

**The package must carry the skill's exact name** — the `.skill` filename and the directory inside it match the target skill's `name` (and its existing directory) precisely. A qualifier such as `-updated`, `-final`, `-v2` or `-new` does **not** update the skill; it installs a *second, separate* skill alongside the original, leaving the real one untouched. To update an existing skill, name the package exactly as that skill; never append a version or status suffix.

**Always build the update from the latest canon.** An update starts from a fresh read of the target skill's *current* `SKILL.md` in the Claude skills store — never from memory, an earlier draft, or the `claude-ops` repo (a downstream mirror that can lag canon). The change is then a precise diff against what is live. If the skill may have been re-saved in another session since this one loaded, re-read it before packaging, so the update does not silently revert a newer change. Tickets are downstream of canon and belong to ops-sync's publish step — raising one to *apply* a canon change is a downstream-first inversion (the reflex `skill-ops-retro` exists to catch).

**Routine and task content is ordinary canon.** A `routine-*` / `task-*` artefact is saved into and read from the skills store as a `.skill`, exactly like any other artefact — it is not an exception to the `.skill` form. The one pasted-prompt exception is the thin **loader config** in the Cloud Routine / Cowork settings (`Read .claude/skills/<artefact-name>/SKILL.md and follow it verbatim`): it is frozen after a one-time edit, carries no behaviour, and is therefore the one part of a scheduled job applied as a config edit rather than a skills-store install.

**Spotting is not authoring — the split is positive, not just a guardrail.** A session that *spots* a canon change files a `FRICTION:` capture note to the Pulse queue and **stops there**. Only the Pulse drain (`skill-ops-retro` drain / `task-pulse-retro`) authors the artefact. Authoring the proposed wording — even framed as a "draft for review" rather than a saved edit — **is a drain activity**, not something a spotting session does ahead of the drain: it is the drain's job done in the wrong place, and it pre-empts the batch consolidation and the assess-against-current-canon step that the drain exists to run. The pull to finish is strong (a session that has fully reasoned out a change feels the natural close is to write it), so state the boundary as a rule: spot → capture-and-stop; the drain authors and packages. (Worked case: a triage session authored the full canon wording as a ready-to-save document after converging on a change, when its job was only to capture — 2026-06-30, APP-403.)

**Authoring is gated to an explicit drain — there is no discretionary "produce it now" exception.** The trigger for authoring canon is an explicit drain instruction, nothing else: `task-pulse-retro`, or Aled giving an explicit "drain / author this now". There is no "the operator asked in this session, so author it directly" carve-out — that discretion is exactly what keeps failing, because a session rationalises a concluded design or planning conversation as a direct-enough request and authors ahead of the drain (worked case: 2026-07-06, after a locked fleet-dispatch design, a session offered to draft the `.skill` packages rather than capture to Pulse). So the rule is unconditional: absent an explicit drain instruction, every working, design, planning, or autonomous session captures the change to the Pulse queue and **stops** — however concluded the conversation feels, and however directly the change was discussed. Aled keeps full control to get something made immediately by giving the drain instruction; the session never *decides* to author on its own read of intent. (The always-loaded tripwire that makes this rule fire without recall of this doc, and the memory update behind it, are Aled's to place — the project custom instructions and Claude's memory, both outside canon.)

**"Never a ticket" is about the *apply-via-Forge* ticket, not the capture note.** The rule that a canon change is never filed as a ticket forbids two specific routes — a delivery ticket routed to Forge, and an in-place `SKILL.md` edit — and nothing more. The `PUL-5E` **capture** note is the correct, expected intake and is never what "never a ticket" rules out. Read flat, the line can wrongly discourage the legitimate capture note and nudge a session toward authoring the artefact directly instead; the two are different things, and only the delivery-ticket and in-place-edit routes are forbidden.

So: to propose a canon change, produce the full updated artefact and package it as a `.skill` to save — do not edit the cache, and do not file a delivery ticket. Capturing a `FRICTION:` note for the drain is the right move from any surface that cannot reach the save button. The only config edit that remains is the one-time loader line, set when a scheduled job is first wired to its artefact.

## Cross-cutting and unnamed

- **Surface** is an axis, not a layer — it defines the Task/Routine cut and the interfaces. Cowork connectors, Claude Code + repos, Linear.
- **Interfaces** (coming soon) — where humans steer: Linear today, broadening to dashboards and a portal.
- **Implementation is not named.** Schedulers are platform mechanism beneath Layer 2; state is Layer 0 memory; automation is behaviour already placed. The model names what we author and operate, not the platform's runtime — unless we build our own triggers, at which point a thin "triggers" concern becomes real.

## The delivery workflow and its loop

The worked example. The **workflow** is the whole path; the **loop** is the inner cycle.

```
Backlog → Relay (triage) → Todo
        → Forge (implement, PR) → In Review
        → Prism (review verdict) → approve path
        → operator (gate) → Relay (merge) → Done
                    └── inner loop: Forge → Prism → gate → merge → pick up next ticket
```

State is the lock: Todo = ready, In Progress = running, In Review = awaiting review or approval. No separate lock labels.

The operator tier has its own standing workflow one level up — `workflow-venture-operating-loop` — where an operator reads its vertical's goal and KPIs, decides the next best actions, dispatches through Relay to the functional fleet, escalates only at the mandate's edge, and reports status. The delivery loop is what the fleet runs; the operating loop is what drives the fleet toward a vertical's outcome.