---
name: Operating Model - Taxonomy and Process (working draft)
description: First-pass diagrammatic taxonomy of the operating-model entities and the process flow that connects them. Pre-deployment artifact that makes the model legible before mapping it to substrates, runtimes, and integration points. Lives in brainstorming/ until validated; then promotes to a kit-side standard or a deployed-instance artifact.
type: brainstorming-artifact
---

# Operating Model - Taxonomy and Process

- **Last reviewed:** 2026-05-01
- **Review cadence:** ad-hoc (working draft until validated; then promote to standard with proper cadence)
- **Status:** draft

## What this document is

A diagrammatic representation of the operating model the deployment kit teaches. The kit ships substantial prose (BOOTSTRAP-BRIEF, TERMS.md, PHILOSOPHY.md) but no single artifact diagrams how the named entities relate or how the process flows. This document fills that gap so downstream work (substrate mapping, runtime mapping, integration design) operates from a model rather than from prose.

Two halves:

1. **Taxonomy** — the entities and their relationships (what exists, how it composes)
2. **Process** — the phases and their flows (how the entities move through time)

After validation, the third step (mapping where processes can happen) and fourth step (integration points) become straightforward annotations on top of these diagrams.

Diagrams use Mermaid for portability — render natively in GitHub, Confluence (with plugin), most modern Markdown readers; text-source so they version + diff cleanly.

## Conventions

- **Boxes** are entities (pods, artifacts, skills, runtimes).
- **Solid arrows** are composition or containment ("X contains Y").
- **Dotted arrows** are relationships ("X mirrors Y", "X inherits from Y").
- **Bidirectional arrows** are interop ("X projects into Y and reads from Y").
- Layers are L0-L7 throughout; never path-pattern-matched to folder structure.

---

## Section 1: Taxonomy

Three views of the same model: what's inside one pod, how pods compose, how pods touch the outside world.

### 1.1 A pod's anatomy

What a single pod contains. Same shape for every pod (kit, org-pod, function-pod, instance-pod) — pods compose recursively because they share this anatomy.

```mermaid
graph TB
    POD[POD]

    POD --> LAYERS[Layers L0-L7]
    POD --> GOV[Governance artifacts]
    POD --> SKILLS[Skill set]
    POD --> CLASS[Classification]
    POD --> RELS[Cross-pod relationships]

    LAYERS --> L0[L0 Strategy]
    LAYERS --> L1[L1 Brand / Posture]
    LAYERS --> L2[L2 Philosophy]
    LAYERS --> L3["L3 Framework Contract<br/>(includes Telemetry Envelope)"]
    LAYERS --> L4[L4 Platform Kit]
    LAYERS --> L5[L5 Instance]
    LAYERS --> L6[L6 Per-instance refinement]
    LAYERS --> L7[L7 Cross-Platform Glue]

    L3 --> TE[Telemetry Envelope]
    TE --> RQ["Reproducibility Quadruple<br/>(model / prompt / tool-set / data-snapshot version)"]
    TE --> COST[Cost per-call estimate]
    TE --> LAT[Latency breakdown]
    TE --> QUAL[Quality signal]
    TE --> GT[Guardrail trips]

    GOV --> OM[OPERATING-MODEL.md]
    GOV --> BL[BACKLOG.md + RESCAFFOLD-TRIGGERS]
    GOV --> DEC[decisions/ ADR archive]
    GOV --> SES[sessions/ logs]
    GOV --> HND[HANDOFF.md custody]
    GOV --> MS[MATURITY-SCORECARD.md]
    GOV --> LA[LOCALIZATION-ANSWERS.md]
    GOV --> POL[policies/]
    GOV --> INB[inbox/ + outbox-topology.md]

    SKILLS --> KB[Kit-bundled]
    SKILLS --> OL[Org-local]
    SKILLS --> LO[Locally authored]

    CLASS --> FM[Function-mode]
    CLASS --> POST[Platform-kit posture]
    CLASS --> MAT[Maturity per layer]

    RELS --> INH[Inheritance from parent pod]
    RELS --> MIR[Mirror from kit / source]
    RELS --> IO[Inbox-outbox pairs]
    RELS --> HO[Handoff envelopes]
```

**Reading this diagram:**

- Every pod has all five top-level branches; absence of any branch is a finding.
- Layers L0-L7 are eight slots, each landing at a maturity (none / stubbed / partial / mature). L1 has a fifth state (`N/A-explicit`) for internal-only functions.
- Governance artifacts are the pod-membership test: a directory without these is a folder, not a pod.
- Skill set is the union of three sources, with precedence: org-local > kit-bundled when both exist.
- Cross-pod relationships are how this pod touches its parent, the kit, peer pods, and downstream pods.

### 1.2 Pod composition (recursive)

Pods nest. A deployment is itself a pod that contains other pods that contain other pods.

```mermaid
graph TB
    KIT["Kit Pod<br/>(self-fractal source-of-truth)"]

    ORG["Org-Pod<br/>(L0-L4 + L7 backbone)"]

    FN1[Function-Pod A]
    FN2[Function-Pod B]
    FN3[Function-Pod C]

    INST_A1[Instance-Pod A.1]
    INST_A2[Instance-Pod A.2]
    INST_B1[Instance-Pod B.1]
    INST_C1[Instance-Pod C.1]
    INST_C2[Instance-Pod C.2]

    KIT -. mirror, one-way .-> ORG

    ORG -. inheritance .-> FN1
    ORG -. inheritance .-> FN2
    ORG -. inheritance .-> FN3

    FN1 -. inheritance .-> INST_A1
    FN1 -. inheritance .-> INST_A2
    FN2 -. inheritance .-> INST_B1
    FN3 -. inheritance .-> INST_C1
    FN3 -. inheritance .-> INST_C2

    FN1 <-. inbox-outbox .-> FN2
    FN2 <-. inbox-outbox .-> FN3

    INST_A1 <-. handoff envelope .-> INST_B1
    INST_B1 <-. handoff envelope .-> INST_C1
```

**Reading this diagram:**

- The Kit Pod is the source-of-truth. It mirrors one-way into deployed instances. Updates flow downstream at sync time.
- Each level supersedes inherited decisions only by writing a new ADR (immutable supersession; old ADR stays on record).
- Inbox-outbox pairs handle async coordination between sibling pods. They are typed, dated, owned on both sides, drained on cadence.
- Handoff envelopes carry runtime context between instance-pods (e.g., a sales instance hands off a qualified lead's context to a customer-success instance).
- The hierarchy is not fixed at three levels. A deployment may use two (Kit → Org-Pod with no function-pods) or four (Kit → Org-Pod → Cluster-Pods → Function-Pods → Instance-Pods).

**Mirror vs. fork posture.** The arrow from Kit Pod to Org-Pod is shown as `mirror, one-way` because that is the kit's default discipline (per ADR-0002 + the kit-mirror skill's refusal posture). A *fork* is structurally different: it copies once, then accepts divergence; learnings may flow back upstream but no obligation. Forks are not the kit's default; they require an explicit ADR at the deploying pod. When a deployment is a fork (not a mirror), the relationship arrow re-labels to `forked from, divergence accepted` and the receiving pod owns its own source-of-truth from that point forward. This is a real choice that the deploying operator must make consciously.

### 1.3 External integration surfaces

How a pod touches the outside world. This is where deployment-specific decisions (substrate, runtime, integration points) attach to the model.

```mermaid
graph LR
    POD["A Pod<br/>(any level)"]

    POD <-->|projects-into| RT_HG[Runtime: Hyperagent]
    POD <-->|projects-into| RT_CL[Runtime: Claude]
    POD <-->|projects-into| RT_CR[Runtime: Cursor]

    POD <-->|manifests-in| SUB_AT[Substrate: Airtable]
    POD <-->|manifests-in| SUB_GH[Substrate: GitHub]
    POD <-->|manifests-in| SUB_CF[Substrate: Confluence]

    POD <--|pulls-from| OLR[Org-local skill repository]
    POD --|constrained-by| REG[Regulatory regimes<br/>SOC 2 / GDPR / HIPAA / etc.]
    POD --|uses| EXT[External tooling stack<br/>Slack / SSO / observability / etc.]
```

**Reading this diagram:**

- **Projects-into a runtime** means the pod's skills, agents, memories, and rubrics are *available to operate inside* that runtime. Bidirectional because the runtime feeds back state (agent runs, memory captures, rubric scores, telemetry).
- **Manifests-in a substrate** means the pod's artifacts (ADRs, BACKLOG, scorecard, etc.) are *stored and readable* in that substrate. Bidirectional because operators author into the substrate; the pod reads back.
- A pod can project into multiple runtimes simultaneously; a pod can manifest in multiple substrates simultaneously (with explicit per-artifact-type allocation, per the substrate decision).
- Org-local skill repository is a *one-way pull* (skills flow into the pod's skill set; the pod does not push back without explicit ADR authorization).
- Regulatory regimes constrain L2 + L3 + L7. They do not contain artifacts; they impose obligations.
- External tooling stack is the plumbing that L7 cross-platform glue uses (consent flow, identity, alerting, monitoring base).

### 1.4 Behavior triggers (named "when X, do Y" rules)

The kit prefers behavior triggers (pattern-match-plus-action) over aphorisms (general principles). Triggers fire on observable patterns; the operator does not have to remember the principle. The current set:

```mermaid
flowchart TB
    BT([Behavior Triggers])

    BT --> S1["When you start any session<br/>→ read brief + scorecard + recent sessions<br/>→ check rescaffold queue<br/>→ state two-sentence opening"]
    BT --> S2["When asked to make a 2+-real-options decision<br/>→ write an ADR"]
    BT --> S3["When asked to create an artifact<br/>→ add Doc Lifecycle frontmatter"]
    BT --> S4["When asked to assess maturity<br/>→ apply four-step scale per layer"]
    BT --> S5["When you encounter a relationship you cannot verify<br/>→ mark declared-but-inactive"]
    BT --> S6["When asked 'is this done?'<br/>→ refuse single word; state per layer"]
    BT --> S7["When two sessions are concurrent on same instance<br/>→ apply lock-on-write protocol"]
    BT --> S8["When user asks you to skip<br/>→ comply only if user names the clause"]
    BT --> S9["When asked a question whose answer is unknown<br/>→ capture honest unknown OR ask follow-up<br/>OR declare rescaffold trigger"]
    BT --> S10["When you encounter context that may invalidate the scaffold<br/>→ mark a rescaffold trigger"]
    BT --> S11["When emitting AI output<br/>→ pin the reproducibility quadruple<br/>→ emit the full telemetry envelope"]
    BT --> S12["When a concept cannot be tied to a layer or relationship<br/>→ flag as floating concept; map or rename"]
```

**Reading this diagram:**

- Each trigger is a standing rule. Operators do not have to remember principles; the trigger fires on the pattern.
- Triggers live in three places: BOOTSTRAP-BRIEF §V (the canonical list), each kit-native skill's "When to invoke" rules, and embedded in failure-mode descriptions (each names its own trigger).
- A trigger that exists in prose but not in any skill or checklist is effectively *memory-resident* (a finding per validate). Triggers must be encoded structurally to fire reliably.
- S11 (telemetry envelope on AI output) is the trigger that makes the L3 obligation in 1.1 enforceable at runtime.

### 1.5 Failure modes (named patterns to detect)

Seven named failure modes the kit watches for. Each has a trigger (how you recognize you are about to commit it) and a correction (what to do instead).

```mermaid
flowchart LR
    FM([Failure Modes])

    FM --> F1["Path-to-layer<br/>pattern matching"]
    FM --> F2["Binary existence<br/>checks"]
    FM --> F3["Missing L7<br/>awareness"]
    FM --> F4["Static inventory<br/>vs. assessment"]
    FM --> F5["Overclaimed<br/>completeness"]
    FM --> F6["Floating<br/>concepts"]
    FM --> F7["Untested<br/>relationships"]

    F1 --> F1T["TRIGGER: layer classification in &lt;5 sec"]
    F1 --> F1C["CORRECTION: read the artifact; ask what decision it makes"]
    F2 --> F2T["TRIGGER: words 'exists / missing / yes-no'"]
    F2 --> F2C["CORRECTION: replace with 4-step maturity scale"]
    F3 --> F3T["TRIGGER: audit table has &lt;8 rows OR L7 says N/A unjustified"]
    F3 --> F3C["CORRECTION: add L7 row; populate or justify"]
    F4 --> F4T["TRIGGER: output looks like 'find . -type f'"]
    F4 --> F4C["CORRECTION: redo as maturity table with gaps + retrofit risk"]
    F5 --> F5T["TRIGGER: words 'deployed / complete / done / shipped / ready'"]
    F5 --> F5C["CORRECTION: state maturity per layer first"]
    F6 --> F6T["TRIGGER: noun cannot map to L0-L7 or named relationship"]
    F6 --> F6C["CORRECTION: map it or rename it"]
    F7 --> F7T["TRIGGER: present indicative ('inherits / mirrors / drains')"]
    F7 --> F7C["CORRECTION: demote to 'declared to inherit / mirror / drain' until verified"]
```

**Reading this diagram:**

- Each failure mode has *three* parts: name (the failure), trigger (the moment you might commit it), correction (the alternative).
- Triggers are *self-detection cues* — they fire on observable patterns in the operator's own work.
- The validate skill scans for the triggers across the deployed instance's artifacts and flags matches.
- The catalog evolves. V1.1 added two observation-failures (wrong-altitude discipline, V1-V2 burden misallocation) per RECURSION-PATTERNS §7; future deployments may add more.

### 1.6 Vocabulary key

Every box in the diagrams maps to a defined term in TERMS.md. The protected vocabulary (used precisely throughout):

| Term | Meaning |
|------|---------|
| Pod | Self-contained governance unit with the anatomy in 1.1 |
| Layer | One of L0-L7 |
| Maturity | Four-step scale: none / stubbed / partial / mature |
| Live | Relationship verified end-to-end within its reasonable window |
| Declared-but-inactive | Relationship documented but not verified |
| ADR | Immutable record of a 2+-real-options decision |
| Mirror | One-way-synced copy with `MIRRORED FROM` header |
| Inheritance | Parent-pod's decisions flow to child-pod by default |
| Inbox-outbox | Typed, dated, owned async coordination channel between pods |
| Handoff envelope | Runtime-cross context transfer between instance-pods |
| Function-mode | Pod's primary working stance (building / operating / deciding / creating / mixed) |
| Posture | Pod's L4 platform-kit relationship (greenfield / partial-internal / mature-internal-mirror / mature-external-mirror / mirror-this-kit) |
| Honest unknown | Captured `unknown - {reason}` answer; first-class; produces rescaffold trigger |
| Rescaffold trigger | Captured event warranting revisit of some scope |

---

## Section 2: Process

The taxonomy describes what exists. The process describes how the entities move through time. Five phases; one cycle.

### 2.1 Phase state machine

```mermaid
stateDiagram-v2
    [*] --> Bootstrap

    Bootstrap --> Discovery: brief loaded; orientation set
    Discovery --> Scaffold: base set + follow-ups answered;<br/>honest unknowns captured
    Scaffold --> Operate: initial scaffold rendered;<br/>maturity scorecard produced
    Operate --> Operate: drain / log / ADR /<br/>validate / mirror sync
    Operate --> Rescaffold: trigger fires
    Rescaffold --> Operate: affected scope addressed;<br/>scorecard updated; trigger archived
```

**Reading this diagram:**

- **Bootstrap** is short. Load the brief; state intent; orient.
- **Discovery** runs the recursive question discipline (see 2.2). First-scaffold discovery is intense (30-90 min); rescaffold-mode discovery is targeted (10-30 min).
- **Scaffold** renders templates against captured answers. First scaffold is full; subsequent scaffolds touch only the layers where context shifted.
- **Operate** is the steady state. The pod runs the function it was deployed for. Sub-loops fire on cadence (see 2.3).
- **Rescaffold** is event-driven. Triggers fire (see 2.4); the affected scope is revisited; the prior MATURITY-SCORECARD archives; a new one is produced.
- The arrow from Operate to itself is the most-traveled path. Most sessions are operate-mode.
- The arrow back from Rescaffold to Operate is mandatory. Rescaffold is a phase, not a destination.

### 2.2 Discovery sub-loop (recursive question discipline)

```mermaid
flowchart TD
    START([Discovery starts])
    Q[Ask next base question Q1-Q10]
    ANS[Capture answer]
    EVAL{Answer reveals<br/>another gap?}
    FOLLOW[Spawn follow-up question]
    UNK[Capture honest unknown<br/>+ rescaffold trigger]
    NEXT{More base<br/>questions?}
    DONE([Initial scaffold context complete])

    START --> Q
    Q --> ANS
    ANS --> EVAL
    EVAL -->|Yes, information gap| FOLLOW
    EVAL -->|Yes, decision gap| UNK
    EVAL -->|No| NEXT
    FOLLOW --> ANS
    UNK --> NEXT
    NEXT -->|Yes| Q
    NEXT -->|No| DONE
```

**Reading this diagram:**

- The base set is approximately ten questions; the actual count is variable because follow-ups are first-class.
- Information gaps spawn follow-ups (loop back into ANS).
- Decision gaps that the operator cannot answer become honest unknowns (captured + rescaffold trigger queued; layer lands as `none`).
- Discovery completes when all base questions are answered or unknown-marked. It does not require all questions to be answered to complete.

### 2.3 Operate sub-loops

The pod has multiple cadence-driven loops that fire during operate mode.

```mermaid
flowchart LR
    OP((Operate))

    OP --> DRAIN[Drain inbox<br/>weekly to biweekly]
    OP --> ADR[Write ADR<br/>on 2+-real-options decision]
    OP --> LOG[Log session<br/>at end of state-changing session]
    OP --> VAL[Run validate<br/>quarterly minimum + on demand]
    OP --> SYNC[Mirror sync<br/>biweekly]
    OP --> SKILL[Author / refine skill<br/>opportunistically]
    OP --> LIFE[Doc Lifecycle staleness check<br/>per artifact cadence]
```

**Reading this diagram:**

- Each loop has its own cadence and trigger. Some are calendar-driven (drain, validate, mirror sync, lifecycle check); some are event-driven (ADR on decision, session log on state change, skill authoring on need).
- Each loop produces evidence (drained inbox; new ADR; session log; updated scorecard; sync record; new/refined skill; staleness flag). Evidence accumulates and feeds the next validate run.
- A loop that does not fire at its expected cadence is itself a finding (the kit's validate skill flags this).

### 2.4 Rescaffold trigger taxonomy

When does a rescaffold become warranted? Six trigger families:

```mermaid
flowchart TB
    RT([Rescaffold Triggers])

    RT --> VF[Validate findings<br/>of layer-level scope]
    RT --> RES[Resolution events]
    RT --> STR[Structural shifts]
    RT --> SP[Sponsor change]
    RT --> KV[Kit version bump]
    RT --> CAL[Calendar cadence<br/>quarterly minimum]

    VF --> VF1[L4 mirror drift]
    VF --> VF2[L7 concern demoted]
    VF --> VF3[Behavior trigger lapsed]
    VF --> VF4[Failure-mode hit in production]

    RES --> RES1[Honest unknown answered]
    RES --> RES2[New platform online]
    RES --> RES3[Org-local skill repo updated]

    STR --> STR1[Function-mode shifted]
    STR --> STR2[Regulatory regime activated]
    STR --> STR3[Scope pivoted]

    SP --> SP1[L0 strategy revisit cascades]
    KV --> KV1[Kit V1.x to V1.y patch]
    CAL --> CAL1[Drift detection: layers reported mature 90+ days ago]
```

**Reading this diagram:**

- A trigger is *captured*, not immediately *acted on*. Capture goes into the rescaffold trigger queue (BACKLOG section or RESCAFFOLD-TRIGGERS.md).
- The next rescaffold session reads the queue and addresses what is reachable. Operate-mode sessions can also opportunistically address triggers.
- Sponsor change is a special case: it cascades down (L0 revisit forces L1-L7 to reconsider).
- Kit version bump cascades through the mirror chain.
- Calendar cadence is a floor — quarterly minimum even if no other trigger fired. Drift detection demotes `mature` layers to `partial` if they have not been operated against in 90+ days.

---

## Section 3: Mapping points (placeholder; populated after model validation)

After Sections 1 + 2 are validated, this section maps the model's entities and processes onto deployment-specific surfaces:

- **Per-substrate map.** Which artifacts (from 1.1) live in which substrate (from 1.3). The substrate decision (Airtable / GitHub / Confluence / hybrid) attaches here.
- **Per-runtime map.** Which skills (from 1.1) and which agents project into which runtime (from 1.3). The format-target translation attaches here.
- **Per-pod-level map.** Which artifacts live at org-pod level vs. function-pod level vs. instance-pod level. The pod composition decision (Option A/B/C/D) attaches here.
- **Per-process-phase map.** Which phases happen in which substrate / runtime. (Discovery in Hyperagent threads? Scaffold in GitHub PRs? Operate split across runtimes by user role?)

These maps become ADR-ORG decisions once locked.

## Section 4: Integration points (placeholder; populated after mapping)

After Section 3 is mapped, this section enumerates the cross-system integration points required:

- **Substrate-to-substrate sync** (if hybrid substrate). Direction, cadence, conflict-resolution.
- **Runtime-to-substrate links.** How a Hyperagent agent reads a kit-canonical skill from substrate of choice; how Claude Code does the same.
- **Runtime-to-runtime interop.** Cross-runtime artifact sharing (skills, memories, rubrics).
- **External tool integrations.** Slack inbox-outbox routing; SSO; observability; alerting.
- **Org-local skill repository integration.** Pull mechanism; precedence handling.

Each integration becomes an ADR with explicit reproducibility note.

---

## What this document does not yet have

Resolved in this revision: items 3, 4, 5 from the prior list (behavior triggers diagrammed in 1.4; failure modes diagrammed in 1.5; reproducibility quadruple surfaced as the L3 Telemetry Envelope in 1.1).

Working assumptions locked: three pod levels (org / function / instance); three runtimes (Hyperagent, Claude, Cursor); deployment posture for the Airtable instance is *fork* (not mirror).

Honest unknowns still open:

1. The "manifests-in substrate" arrow in 1.3 is currently per-pod. If the substrate decision is hybrid-by-artifact-type, the arrow becomes per-artifact-type. Revise after the substrate decision lands.
2. The fork-vs-mirror posture for the Airtable deployment (per the callout under 1.2) needs an ADR-ORG: when may learnings flow back upstream; what divergence is OK; who owns the source-of-truth from the fork point forward.
3. The deidentification scrub pass on the forked kit needs a concrete checklist (every ADR's Deciders field; CLAUDE.md references; any operator-personal paths or domains). Becomes part of the fork's first session log.
4. The fork lives at... a path TBD. The kit is currently at an operator-personal location; the fork's home must be deidentified.

## Cross-references

- `BOOTSTRAP-BRIEF.md` Sections II (layers), III (maturity), IV (relationships), VII (ADR), IX (concurrent-session), XVII (rescaffold)
- `TERMS.md` Categories 1 (architecture), 2 (maturity + relationships), 3 (decision artifacts), 4 (governance scaffolding), 5 (behavior mechanisms), 6 (failure modes)
- `PHILOSOPHY.md` "Why pods, not folders"; "Why continuous rescaffolding"; "Why one-way mirror"
- `QUESTIONS.md` for the Q1-Q10 base set referenced in 2.2
- `RECURSION-PATTERNS.md` for parametric vs. structural patterns that the mapping in Section 3 will need to respect
- `brainstorming/airtable-adaptation.md` for the deployment-specific brainstorming this model serves
