---
name: Operating Model - Patterns and Persistence (Batch 2 source content)
description: Mermaid source for the 22 visual assets in §C (work patterns), §D (shared persistence layers), §E (persistence-respect mechanism), and §F (roll-up topology) from the visual-assets-checklist. Each diagram has a brief reading aid. Sibling to operating-model.md (which holds the foundational taxonomy + process diagrams). Drafted as input to the Gemini polish pass.
type: brainstorming-artifact
---

# Operating Model - Patterns and Persistence

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

## What this document is

The Batch 2 source content for the visual assets checklist. Twenty-two diagrams across four families:

- **Section C** — work patterns (how individual operators and teams do work day-to-day; 8 diagrams; C9 skipped as decision-blocked)
- **Section D** — shared persistence layers (what persists where, on what cadence, with what scope; 4 diagrams)
- **Section E** — persistence-respect mechanism (how shared state is honored; 5 diagrams)
- **Section F** — roll-up topology (how state, decisions, evidence, unknowns flow upward; 5 diagrams; F5 skipped as decision-blocked)

Sibling to `operating-model.md` (which holds the foundational taxonomy in §1 and the process diagrams in §2). After Gemini polish, the polished versions slot back into the appropriate places in the canonical operating-model documentation.

Vocabulary, arrow conventions, and entity names match `operating-model.md` and `TERMS.md` throughout.

---

## Section C: Work patterns

How individual operators and teams do work in the system day-to-day.

### C1. Typical operate-mode session, single operator

```mermaid
flowchart TD
    START([Operator starts session])
    READ1[Read BOOTSTRAP-BRIEF]
    READ2[Read OPERATING-MODEL.md]
    READ3[Read recent 2 session logs]
    READ4[Read MATURITY-SCORECARD]
    READ5[Check rescaffold trigger queue]
    OPEN["State 2-sentence opening:<br/>what the instance is, where on maturity,<br/>whether triggers fired"]
    TRIG{Rescaffold trigger fired?}
    BRANCH["Decide: defer to operate<br/>OR enter rescaffold mode"]
    OP[Do work in operate mode]
    DEC{2+-real-options decision arose?}
    ADR["Invoke architect-adr;<br/>write ADR to decisions/"]
    STATE{State changed?}
    LOG["Write session log to<br/>sessions/YYYY-MM-DD-purpose.md"]
    KICK{Next session needs mid-stream pickup?}
    UPD[Update kickoff doc]
    END([Session ends])

    START --> READ1 --> READ2 --> READ3 --> READ4 --> READ5 --> OPEN --> TRIG
    TRIG -->|No| OP
    TRIG -->|Yes| BRANCH
    BRANCH --> OP
    OP --> DEC
    DEC -->|Yes| ADR --> STATE
    DEC -->|No| STATE
    STATE -->|Yes| LOG --> KICK
    STATE -->|No| KICK
    KICK -->|Yes| UPD --> END
    KICK -->|No| END
```

**Reading this:** the opening five reads + 2-sentence opening is mandatory per BOOTSTRAP-BRIEF §V. The trigger check at OPEN is the load-bearing branch — silent ignoring is the V1 failure mode V1.1 closed. State-changing sessions always log; trivial sessions skip per architect-handoff's refusal condition.

### C2. Typical rescaffold-mode session

```mermaid
flowchart TD
    START([Operator starts rescaffold session])
    OPEN[Read brief, scorecard, recent sessions]
    QUEUE[Read rescaffold trigger queue]
    NAME[Name fired triggers explicitly]
    SCOPE[Identify affected layer scope]
    REASK["Re-run discovery on affected scope:<br/>targeted Q-subset + follow-ups"]
    UNK{New honest unknowns surfaced?}
    QTRIG[Queue new rescaffold triggers]
    RENDER[Re-render affected layer templates]
    NEWMS[Produce new MATURITY-SCORECARD]
    ARCH["Archive prior scorecard:<br/>MATURITY-SCORECARD-history/YYYY-MM-DD.md"]
    LOG["Session log: triggers fired,<br/>layers touched, layers skipped"]
    UPDQ["Update rescaffold queue:<br/>mark resolved + add new"]
    END([Rescaffold ends])

    START --> OPEN --> QUEUE --> NAME --> SCOPE --> REASK --> UNK
    UNK -->|Yes| QTRIG --> RENDER
    UNK -->|No| RENDER
    RENDER --> NEWMS --> ARCH --> LOG --> UPDQ --> END
```

**Reading this:** rescaffold is event-driven and targeted. A rescaffold that touches every layer is a signal something fundamental shifted (sponsor change, major regulatory). The prior scorecard always archives — the deployed instance traces its own learning by reading the scorecard history end-to-end.

### C3. Discovery follow-up flow

```mermaid
flowchart LR
    BASE[Base question Q-N answered]
    GAP{Answer reveals gap?}
    INFO{Information gap or decision gap?}
    FOLLOW[Spawn follow-up question]
    ASK[Ask follow-up]
    ANS[Capture answer]
    NESTED{Follow-up's answer reveals further gap?}
    UNK["Capture honest unknown<br/>+ rescaffold trigger"]
    DONE[Return to base set]

    BASE --> GAP
    GAP -->|No| DONE
    GAP -->|Yes| INFO
    INFO -->|Information| FOLLOW --> ASK --> ANS --> NESTED
    INFO -->|Decision| UNK --> DONE
    NESTED -->|Yes| FOLLOW
    NESTED -->|No| DONE
```

**Reading this:** distinct from B2 (the loop) — this is one follow-up's lifecycle. Information gaps recurse (a follow-up can spawn its own follow-up). Decision gaps the operator cannot resolve become honest unknowns rather than blocking the discovery from completing.

### C4. ADR write-on-decision flow

```mermaid
flowchart TD
    OBSERVE[Operator observes:<br/>2+-real-options decision needed]
    CHECK{"Meets ADR criteria? (2+ true)<br/>2+ real options<br/>not trivially reversible<br/>future operator will wonder why<br/>cross-team or cross-product impl<br/>regulatory/privacy/cost factor"}
    SKIP[Document inline; not ADR-worthy]
    INVOKE[Invoke architect-adr skill]
    NUM[Get next ADR number from decisions/ archive]
    DRAFT["Draft ADR with required fields:<br/>Date, Status, Reversibility, Deciders, Scope,<br/>Context, Decision, Options, Rationale, Consequences"]
    REVIEW[Review options + rationale; tradeoffs explicit]
    ACCEPT{Status: accepted?}
    PROP["Set Status: proposed; iterate"]
    SAVE[Save to decisions/ADR-NNNN-title.md]
    NOTIFY[Notify relevant inbox-outbox pairs<br/>if cross-pod implications]
    DONE([ADR archived])

    OBSERVE --> CHECK
    CHECK -->|Two or more true| INVOKE --> NUM --> DRAFT --> REVIEW --> ACCEPT
    CHECK -->|Fewer than two| SKIP --> DONE
    ACCEPT -->|Yes| SAVE --> NOTIFY --> DONE
    ACCEPT -->|No| PROP --> REVIEW
```

**Reading this:** the criteria gate prevents ADR proliferation (not every decision warrants one). Once accepted, the ADR is immutable; revisions happen via supersession. The notify step is what makes the ADR cross-pod-relevant rather than just locally archived.

### C5. Inbox drain pattern

```mermaid
flowchart TD
    START([Drain cycle begins: cadence-driven])
    READ[Read inbox/]
    LOOP{Any open entries?}
    PICK[Pick next entry]
    TYPED{"Typed shape complete?<br/>date, source, type, state, priority, target close"}
    FIX[Add missing fields;<br/>flag to source if unresolvable]
    CLASS{Classify next move}
    ACK["State: acknowledged"]
    ACT["State: actioned-here"]
    ESC[Escalate to ADR via architect-adr]
    BL[Move to BACKLOG.md]
    PING[Ping other side's owner if needed]
    NONE["FINDING: drain produced no state changes<br/>either no traffic or read-only-glance"]
    END([Drain logged])

    START --> READ --> LOOP
    LOOP -->|Yes, more entries| PICK --> TYPED
    LOOP -->|No, none drained this cycle| NONE --> END
    LOOP -->|No, all done| END
    TYPED -->|Yes| CLASS
    TYPED -->|No| FIX --> CLASS
    CLASS -->|acknowledge| ACK --> PING
    CLASS -->|actioned-here| ACT --> PING
    CLASS -->|escalate| ESC --> PING
    CLASS -->|backlog| BL --> PING
    PING --> LOOP
```

**Reading this:** drain is cadence-driven (typically weekly to biweekly). The "no state changes" branch is itself a finding — either traffic dried up (worth investigating) or operators are skimming without acting (failure mode). PING ensures the other side knows their entry was processed.

### C6. Skill authoring + refinement pattern

```mermaid
flowchart TD
    OBS[Operator observes:<br/>recurring task pattern]
    JUDGE{"Worth a skill?<br/>2+ uses expected<br/>codifiable steps<br/>refusal conditions clear"}
    SKIP[Do task inline; not skill-worthy]
    INVOKE[Invoke skill-creator]
    DRAFT["Draft SKILL.md:<br/>frontmatter, when-to-invoke triggers,<br/>refusal conditions, step-by-step process,<br/>examples"]
    TEST[Test against the observed task]
    PUBLISH[Publish to pod's skill set]
    MIRROR{Cross-pod relevance?}
    PUSH[Mirror to relevant pods]
    USE[Use in operate mode]
    REFINE_TRIG{"Refinement suggestion arose?<br/>from runtime suggestions, operator notice,<br/>or validate finding"}
    PROPOSE[Draft refinement]
    REVIEW{Accept refinement?}
    ACCEPT["Merge refinement;<br/>increment version;<br/>update Last-reviewed"]
    DISMISS[Dismiss refinement; note rationale]

    OBS --> JUDGE
    JUDGE -->|Yes| INVOKE --> DRAFT --> TEST --> PUBLISH --> MIRROR
    JUDGE -->|No| SKIP
    MIRROR -->|Yes| PUSH --> USE
    MIRROR -->|No| USE
    USE --> REFINE_TRIG
    REFINE_TRIG -->|Yes| PROPOSE --> REVIEW
    REFINE_TRIG -->|No| USE
    REVIEW -->|Yes| ACCEPT --> USE
    REVIEW -->|No| DISMISS --> USE
```

**Reading this:** captures the kit's "skills improve with use" property. Hyperagent's "system suggests refinements you accept or dismiss" is one source of refinement triggers; operator notice and validate findings are others. Always-accept and always-dismiss are both findings — refinement should be an actual review, not a rubber stamp or a black hole.

### C7. Cross-pod handoff (runtime envelope)

```mermaid
flowchart LR
    IA[Instance-Pod A produces output]
    PACK["Package handoff envelope:<br/>type, payload, source-pod, target-pod,<br/>timestamp, context"]
    REPRO["Pin reproducibility quadruple:<br/>model / prompt / tools / data"]
    ROUTE[Route via L7 handoff protocol]
    IB[Instance-Pod B receives envelope]
    VALID{"Envelope valid?<br/>schema OK, quadruple complete,<br/>source authenticated"}
    REJECT[Reject + log to outbox back to A]
    ACK[Acknowledge receipt]
    CONSUME[B consumes payload; continues workflow]
    OUT[B produces downstream output]

    IA --> PACK --> REPRO --> ROUTE --> IB --> VALID
    VALID -->|No| REJECT
    VALID -->|Yes| ACK --> CONSUME --> OUT
```

**Reading this:** handoff is the runtime-envelope crossing between instance-pods. Reproducibility quadruple travels with the envelope so B can audit "what produced this." The reject path is mandatory — silent acceptance of malformed envelopes is the named "untested relationship" failure mode at runtime.

### C8. Concurrent-session lock-on-write

```mermaid
sequenceDiagram
    participant Op1 as Operator 1
    participant Art as Shared Artifact
    participant Op2 as Operator 2

    Op1->>Art: Begin edit (acquire soft lock)
    Op2->>Art: Detect: artifact in-edit by Op1
    Op2->>Op2: Pause, do not proceed
    Op2->>Op2: Write session log, collision detected and waiting
    Op1->>Art: Commit edit
    Op1->>Op1: Write session log describing change
    Art->>Op2: Lock released
    Op2->>Art: Resume edit on updated state
    Op2->>Op2: Continue session
```

**Reading this:** the second operator pausing is mandatory; silent overwrite is the named failure mode this defeats. Both operators write session logs — Op2's log explains the collision (so future audit knows why there was a wait); Op1's log describes the change (so Op2 understands what they're now operating on top of).

### C9. Nontechnical author session vs. technical author session

**Status: DECISION-BLOCKED.** Source not drafted; depends on the substrate decision (ADR-ORG-substrate) and the format-target translation decision (ADR-ORG-format-target). Will draft once those locks are in place — the diagram needs concrete substrates to be meaningful.

---

## Section D: Shared persistence layers

What persists where, on what cadence, with what scope.

### D1. Persistence map by layer

```mermaid
graph TB
    subgraph L0[L0 Strategy]
        L0A[Strategy artifact:<br/>sponsor, metric, posture]
        L0M["Mutability: revisable on sponsor change<br/>Scope: pod-local with inheritance<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L1[L1 Brand / Posture]
        L1A[Brand posture artifact OR<br/>N/A-explicit marker]
        L1M["Mutability: revisable on rebrand<br/>Scope: pod-local<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L2[L2 Philosophy]
        L2A[Red lines, PII rules, HITL placement]
        L2M["Mutability: append-on-incident<br/>Scope: pod-local with inheritance<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L3[L3 Framework Contract]
        L3A[Telemetry envelope, eval thresholds,<br/>cost ceilings, auth model]
        L3M["Mutability: revisable per ADR<br/>Scope: pod-local with inheritance<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L4[L4 Platform Kit]
        L4A[Skills, prompts, evals,<br/>guardrails, telemetry plumbing]
        L4M["Mutability: mirror-controlled<br/>Scope: shared via mirror chain<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L5[L5 Instance]
        L5A[Per-instance dossiers]
        L5M["Mutability: instance-team-owned<br/>Scope: instance-local<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L6[L6 Per-instance refinement]
        L6A[Per-instance UX details]
        L6M["Mutability: instance-team-owned<br/>Scope: instance-local<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph L7[L7 Cross-Platform Glue]
        L7A[Shared memory, identity, handoff,<br/>consent, alerting, monitoring]
        L7M["Mutability: cross-cutting team<br/>Scope: org-wide shared<br/>Substrate: TBD per ADR-ORG"]
    end
    subgraph GOV[Governance Layer]
        GOVA[ADRs, sessions, BACKLOG, HANDOFF,<br/>scorecard, localization-answers]
        GOVM["ADRs immutable<br/>Sessions append-only<br/>BACKLOG mutable<br/>Scorecard versioned"]
    end
```

**Reading this:** every layer has its own mutability profile + scope + substrate. The "Substrate: TBD" annotation is intentional — it pins the dependency on ADR-ORG-substrate so this diagram can be re-rendered concretely once substrate locks. Governance layer is shown separately because its artifacts cut across layers.

### D2. Persistence map by runtime

```mermaid
graph TB
    subgraph HG[Hyperagent Runtime]
        HG_S[Skills shared at workspace]
        HG_M["Memories: global + agent-pinned"]
        HG_R[Rubrics per agent]
        HG_L[Library: deliverables across runs]
        HG_T[Threads: persistent within workspace]
        HG_A[Agents: configured workers]
        HG_C[Command Center metrics + logs]
    end
    subgraph CL[Claude Runtime]
        CL_S[Skills: SKILL.md files in skills/]
        CL_M[Cowork memory entries]
        CL_T[Conversation transcripts]
        CL_P[Project context per project]
        CL_K[Claude Code .claude/ state]
    end
    subgraph CR[Cursor Runtime]
        CR_R[Rule files .cursorrules]
        CR_M[MCP server state]
        CR_C[Per-repo context]
        CR_S[Internal skill bundles if any]
    end
    subgraph SHARED[Cross-runtime durable]
        SHARED_K[Kit-canonical skills source-of-truth]
        SHARED_A[ADR archive]
        SHARED_S[Sessions logs]
        SHARED_T[Telemetry envelopes]
    end

    HG_S -. derived from .-> SHARED_K
    CL_S -. derived from .-> SHARED_K
    CR_S -. derived from .-> SHARED_K
    HG_M -. references .-> SHARED_S
    CL_M -. references .-> SHARED_S
```

**Reading this:** each runtime has its own native persistence; the cross-runtime durable set is the kit's source-of-truth that every runtime derives from. The dotted "derived from" arrows are where format-target translation happens (Q3 territory). Memories in any runtime can reference the shared session log archive (so a captured insight ties back to the moment it was learned).

### D3. Persistence map by substrate

```mermaid
graph TB
    subgraph AT[Airtable]
        AT_R[Records in tables]
        AT_F[Fields with typed values]
        AT_V[Views: filtered + sorted]
        AT_A[Attachments]
        AT_AU[Audit log per record]
        AT_AT[Automations + scripts]
        AT_PR[Per-base/table/view permissions]
    end
    subgraph GH[GitHub]
        GH_F[Markdown files in repos]
        GH_GH["Git history: commits, diffs, blame"]
        GH_I[Issues with labels + assignees]
        GH_PR[Pull requests + reviews]
        GH_R[Releases + tags]
        GH_W[Workflows + Actions]
        GH_PER[Per-repo/team permissions]
    end
    subgraph CF[Confluence]
        CF_P[Pages in space hierarchy]
        CF_PH[Page history + versions]
        CF_C[Comments + mentions]
        CF_T[Templates]
        CF_AT[Attachments]
        CF_PER[Space + page permissions]
    end
```

**Reading this:** each substrate's native persistence vocabulary. The substrate decision (per artifact-type, per Option 1/2/3) attaches by mapping kit-artifact-types onto substrate primitives (e.g., ADRs → GitHub markdown files; BACKLOG → Airtable records; narrative summaries → Confluence pages).

### D4. Durability tier diagram

```mermaid
flowchart TB
    T1["TIER 1: Session-ephemeral<br/>scope: within one thread or conversation<br/>examples: scratch buffer, in-progress edits<br/>lifetime: minutes to hours<br/>decay: cleared on session end"]
    T2["TIER 2: Session-durable<br/>scope: within one project or workspace<br/>examples: thread history, project context,<br/>conversation transcripts<br/>lifetime: days to weeks<br/>decay: kept until project archived"]
    T3["TIER 3: Pod-durable<br/>scope: across sessions for one pod<br/>examples: BACKLOG, sessions/, decisions/,<br/>HANDOFF, MATURITY-SCORECARD<br/>lifetime: weeks to quarters<br/>decay: doc-lifecycle staleness flags"]
    T4["TIER 4: Cross-pod-durable<br/>scope: shared across pods<br/>examples: kit canonical skills, org-scope ADRs,<br/>L7 cross-platform glue, shared memories<br/>lifetime: persistent<br/>decay: never; immutable or append-only"]

    T1 -->|"promote on judgment<br/>(worth keeping past this session)"| T2
    T2 -->|"promote on judgment<br/>(worth keeping past this project)"| T3
    T3 -->|"promote on judgment<br/>(worth sharing across pods)"| T4
```

**Reading this:** the four-tier model captures the mental discipline of "where does this belong?" Promotion is always a judgment call upward, not automatic. A captured Hyperagent Memory starts at T2 (workspace-durable) and is candidate for T4 promotion if it represents a pattern worth sharing across pods. An ADR starts at T3 (pod-durable) and may surface to T4 if cross-pod-relevant per F1.

---

## Section E: Persistence-respect mechanism

How shared persistent state is honored across operators / sessions / pods / runtimes.

### E1. Respect-mechanism overview

```mermaid
flowchart TB
    SS([Shared Persistent State])

    SS --- D1[One-way mirror discipline]
    SS --- D2[Inheritance + supersession]
    SS --- D3[Refusal conditions in skills]
    SS --- D4[Reproducibility quadruple emission]
    SS --- D5[Doc Lifecycle staleness flags]
    SS --- D6[Lock-on-write protocol]
    SS --- D7[ADR immutability]
    SS --- D8[Live vs. declared-but-inactive]

    D1 --> D1E[Enforces: source-of-truth integrity<br/>across mirror chain]
    D2 --> D2E[Enforces: parent decisions flow<br/>unless superseded with rationale]
    D3 --> D3E[Enforces: skills refuse violations<br/>structurally, not by hope]
    D4 --> D4E[Enforces: AI output is reproducible<br/>and auditable]
    D5 --> D5E[Enforces: artifacts revisited on cadence]
    D6 --> D6E[Enforces: concurrent sessions<br/>do not silently overwrite]
    D7 --> D7E[Enforces: decision history<br/>is unchangeable trail]
    D8 --> D8E[Enforces: relationships are<br/>verified, not assumed]
```

**Reading this:** eight named disciplines, each guarding shared state from a specific failure shape. None is sufficient alone; together they form defense-in-depth. The validate skill audits all eight per pod.

### E2. One-way mirror discipline detail

```mermaid
flowchart TB
    K["Kit Pod<br/>SOURCE-OF-TRUTH"]
    INST["Deployed Instance<br/>MIRROR"]
    SUB["Sub-platform<br/>MIRROR of MIRROR"]

    K -->|"one-way sync<br/>biweekly cadence"| INST
    INST -->|"one-way sync<br/>biweekly cadence"| SUB

    INST --- LOC["Locally-owned components:<br/>NO MIRRORED FROM header,<br/>not subject to sync,<br/>locally evolved"]
    INST --- BD["Bidirectional sync REFUSED<br/>without explicit ADR<br/>per architect-kit-mirror skill"]
    INST --- FORK["FORK posture (alternative):<br/>copies once, accepts divergence,<br/>no sync after fork point,<br/>requires explicit ADR"]
```

**Reading this:** mirror is one-way by default. Locally-owned components live alongside mirrored content; absence of `MIRRORED FROM` header is the boundary. Bidirectional sync is a refusal condition; fork is an explicitly-authorized divergence (the Airtable deployment is taking the fork posture per the ADR-ORG queued earlier).

### E3. Inheritance + supersession flow

```mermaid
flowchart TD
    PD["Parent-Pod ADR<br/>Status: accepted"]
    CHILD[Child-Pod inherits decision]
    USE[Child operates per parent decision]
    NEED{Child needs different decision?}
    OK[Continue inheriting]
    SUPER["Child writes new ADR<br/>Status: accepted"]
    LOCAL_OK["Local override active in child;<br/>parent ADR unaffected"]
    IMMUT["Parent ADR remains immutable<br/>on record forever"]
    AUDIT["Audit trail preserved:<br/>both ADRs visible,<br/>rationale for divergence captured"]

    PD --> CHILD --> USE --> NEED
    NEED -->|No| OK --> USE
    NEED -->|Yes| SUPER --> LOCAL_OK
    PD -.- IMMUT
    SUPER -.- AUDIT
```

**Reading this:** inheritance flows by default; supersession is the only legitimate way to deviate. The parent ADR stays on record even after child-supersession — the audit trail is the value. This is what makes inheritance trustable across pod hierarchy depth.

### E4. Refusal-condition map

```mermaid
flowchart LR
    DEPLOY[deploy skill] -->|refuses| DR[silent skip of localization questions]
    VALIDATE[validate skill] -->|refuses| VR[marking layer mature without evidence]
    KMIR[architect-kit-mirror] -->|refuses| KR[bidirectional sync without ADR]
    INBOX[architect-inbox-flow] -->|refuses| IR[declaring pair without named owner]
    COMPL[architect-compliance] -->|refuses| CR[regime posture without named owner per regime]
    HAND[architect-handoff] -->|refuses| HR[trivial sessions]
    ADR[architect-adr] -->|refuses| AR[editing accepted ADR; supersession only]
```

**Reading this:** refusal-encoded skills are stronger than guidance-only because they catch the failure structurally. The operator does not have to remember the discipline; the skill enforces it. Each refusal corresponds to a named failure mode the kit is designed to defeat.

### E5. Reproducibility-quadruple enforcement flow

```mermaid
flowchart TD
    AI[AI-producing component generates output]
    EMIT["Component emits telemetry envelope:<br/>model_version, prompt_version,<br/>tool_set_version, data_snapshot_version,<br/>cost, latency, quality_signal, guardrail_trips"]
    STORE[Telemetry written to L3-designated store]
    AUDIT[validate skill scans telemetry]
    CHECK{All four pins present?}
    PASS[Mark relationship live on next audit pass]
    FAIL["Flag as finding:<br/>incomplete telemetry envelope<br/>= reproducibility broken"]
    BACK[Add to BACKLOG OR escalate to ADR<br/>depending on severity]

    AI --> EMIT --> STORE --> AUDIT --> CHECK
    CHECK -->|Yes| PASS
    CHECK -->|No| FAIL --> BACK
```

**Reading this:** the L3 obligation made enforceable at runtime. Two-of-four pins is not reproducible. This is the runtime-time sibling of the C7 reproducibility check (which validates at handoff time). Together they ensure no AI output crosses a pod boundary without the four pins.

---

## Section F: Roll-up topology

How state, decisions, evidence, and unknowns flow upward from instance-pods to function-pods to org-pod.

### F1. Decision roll-up (ADR cascade)

```mermaid
flowchart TB
    INST_ADR["Instance-Pod ADR<br/>e.g., 'Use prompt template X<br/>for Salesforce-bound emails'"]
    SCOPE_INST{Stays instance-scope?}
    INST_OK[Remains local; no cascade]
    FN_RELEVANT{Relevant to other instances<br/>in same function?}
    FN_ADR["Function-Pod ADR<br/>e.g., 'All sales-pod instances<br/>use prompt template X'"]
    ORG_RELEVANT{Relevant to other functions?}
    FN_DONE[Function-scope cascade only]
    ORG_ADR["Org-Pod ADR<br/>e.g., 'All instances org-wide<br/>use template X for customer-facing email'"]
    CASCADE["Org-Pod ADR cascades:<br/>function-pods supersede their local ADRs<br/>OR retain via local supersession ADR with rationale"]

    INST_ADR --> SCOPE_INST
    SCOPE_INST -->|Yes| INST_OK
    SCOPE_INST -->|No| FN_RELEVANT
    FN_RELEVANT -->|No| INST_OK
    FN_RELEVANT -->|Yes| FN_ADR --> ORG_RELEVANT
    ORG_RELEVANT -->|No| FN_DONE
    ORG_RELEVANT -->|Yes| ORG_ADR --> CASCADE
```

**Reading this:** ADRs are not all created equal in scope. The decision tree at each level (instance / function / org) gates whether the ADR cascades up. Cascading down (org → functions) is mandatory but with a child's-supersession-with-rationale escape valve — preserving the audit trail per E3.

### F2. Evidence roll-up (MATURITY-SCORECARD aggregation)

```mermaid
flowchart BT
    I1[Instance-Pod 1.1 scorecard]
    I2[Instance-Pod 1.2 scorecard]
    I3[Instance-Pod 2.1 scorecard]
    I4[Instance-Pod 3.1 scorecard]
    I5[Instance-Pod 3.2 scorecard]

    F1S[Function-Pod 1 scorecard<br/>aggregates I1, I2]
    F2S[Function-Pod 2 scorecard<br/>aggregates I3]
    F3S[Function-Pod 3 scorecard<br/>aggregates I4, I5]

    ORGS[Org-Pod scorecard<br/>aggregates F1, F2, F3]
    PORTS[Portfolio scorecard<br/>aggregates org-pods if applicable]

    AGG["Aggregation rule:<br/>per layer, per pod,<br/>weakest-child-state-wins<br/>OR named exception with rationale"]

    I1 --> F1S
    I2 --> F1S
    I3 --> F2S
    I4 --> F3S
    I5 --> F3S
    F1S --> ORGS
    F2S --> ORGS
    F3S --> ORGS
    ORGS --> PORTS
    AGG -.- ORGS
```

**Reading this:** scorecards roll up recursively. The default aggregation rule is weakest-child-state-wins (a function-pod whose worst-instance is `partial` rolls up as `partial` at the function level for that layer). The named-exception escape valve handles cases where weighted-average or specific-instance-priority is more honest.

### F3. Honest-unknowns roll-up

```mermaid
flowchart TB
    INST_U["Instance-Pod honest unknown<br/>e.g., 'eval baseline TBD by 2026-06-15'"]
    R1{Resolves at instance level by closes-by date?}
    INST_RES[Resolved; rescaffold trigger fires at instance level]
    PERSIST{Same pattern persisting<br/>across multiple instances?}
    FN_U["Promote to Function-Pod unknown:<br/>'eval baseline pattern unclear<br/>across all instances in this function'"]
    R2{Resolves at function level?}
    FN_RES[Resolved at function level; cascades back down]
    ORG_U["Promote to Org-Pod unknown:<br/>broad strategic ambiguity"]
    ORG_ADDR["Org-pod must address via ADR or escalation;<br/>cascades down to all functions"]

    INST_U --> R1
    R1 -->|Yes| INST_RES
    R1 -->|No, persists| PERSIST
    PERSIST -->|No, isolated| INST_U
    PERSIST -->|Yes| FN_U --> R2
    R2 -->|Yes| FN_RES
    R2 -->|No, persists across functions| ORG_U --> ORG_ADDR
```

**Reading this:** honest unknowns at instance level may resolve quietly. Patterns of unresolved unknowns across instances escalate the unknown to function-pod scope. Patterns across functions escalate to org-pod scope, where they become strategic concerns requiring ADR or sponsor escalation.

### F4. Memory promotion (Hyperagent-specific roll-up)

```mermaid
flowchart TB
    AGENT_M["Agent-pinned memory<br/>e.g., 'this agent treats Salesforce<br/>account name as canonical key'"]
    R1{Pattern observed across agents?}
    LOCAL[Stays agent-pinned]
    GLOB[Promote to global memory<br/>visible to all threads + agents]
    R2{Pattern crosses function/team boundaries?}
    GLOB_OK[Stays global within workspace]
    ORG_M[Promote to org-level memory<br/>shared across teams]
    R3{Pattern is decision-shaped<br/>not just preference?}
    MEM_ONLY[Remains memory only]
    ADR_ESC["Escalate: also write ADR<br/>memory captures the 'what',<br/>ADR captures the 'why' + rationale"]

    AGENT_M --> R1
    R1 -->|No| LOCAL
    R1 -->|Yes| GLOB --> R2
    R2 -->|No| GLOB_OK
    R2 -->|Yes| ORG_M --> R3
    R3 -->|No| MEM_ONLY
    R3 -->|Yes| ADR_ESC
```

**Reading this:** Hyperagent's memory promotion ladder maps onto the kit's pod hierarchy. Distinct from F1 because memories capture the "what" (what is true about the environment) while ADRs capture the "why" (why we chose X with multiple options). Decision-shaped memories should escalate to ADR so the decision lineage is recoverable.

### F5. Inbox-outbox topology (deployed instance, full org)

**Status: DECISION-BLOCKED.** Source not drafted; depends on Option A/B/C/D pod decomposition + first-wave function-pod selection. The reference shape is `examples/martech-mature-instance/inbox-topology.md`. Will draft once the decomposition + first-wave decisions land.

### F6. Trigger cascade

```mermaid
flowchart TB
    SRC{Trigger fired at what level?}
    INST_T[Instance-Pod trigger:<br/>e.g., L4 mirror drift in this instance]
    INST_SCOPE[Stays within instance:<br/>rescaffold instance only]
    FN_T[Function-Pod trigger:<br/>e.g., function adopts new platform]
    FN_SCOPE[Stays within function:<br/>rescaffold function-pod and its instance-pods]
    CROSS{Cross-cutting impact?}
    FN_END[Done within function]
    FN_ESCALATE[Escalates to org-pod if cross-cutting]
    ORG_T[Org-Pod trigger:<br/>sponsor change, regulatory regime activation,<br/>kit version bump]
    ORG_CASCADE["Cascades down:<br/>all function-pods rescaffold L0/L2/L3<br/>all instance-pods inherit changes"]

    SRC -->|instance-level| INST_T --> INST_SCOPE
    SRC -->|function-level| FN_T --> FN_SCOPE --> CROSS
    SRC -->|org-level| ORG_T --> ORG_CASCADE
    CROSS -->|No| FN_END
    CROSS -->|Yes| FN_ESCALATE --> ORG_T
```

**Reading this:** triggers stay at their level by default; escalation upward requires cross-cutting evidence. Org-level triggers always cascade down — this is what makes the rescaffold protocol propagate strategic shifts to the whole pod hierarchy.

---

## What this draft does not yet have

- C9 and F5 are deliberately stubbed (DECISION-BLOCKED). Will draft when the relevant ADR-ORG decisions land.
- Reading aids are deliberately brief. Gemini polish may surface a need for richer captions; revisit at that point.
- Visual vocabulary is Mermaid-default. Gemini polish establishes the house style; future drafts inherit it.
- Some diagrams (D1, D2, D3) are dense by design — they encode large fact-sets. Gemini polish should preserve the density rather than oversimplify; the goal is operator reference cards, not stakeholder summaries.
- The H-series reading aids (vocabulary key, layer/maturity legend, arrow legend) are not in this batch. They wait until the visual vocabulary is established.

## Cross-references

- `OPERATING-MODEL.md` — sibling artifact holding the foundational taxonomy + process diagrams (A and B series)
- `brainstorming/visual-assets-checklist.md` — the punchlist this artifact serves
- `BOOTSTRAP-BRIEF.md` §V (behavior triggers, source for C1), §IX (concurrent-session protocol, source for C8), §XII (reproducibility quadruple, source for E5), §XVII (rescaffold protocol, source for C2 + F6)
- `TERMS.md` Categories 4 (governance scaffolding) + 5 (behavior mechanisms)
- `examples/martech-mature-instance/inbox-topology.md` — reference shape for F5
