Mission Control doc

Operating Protocol

mission-control-operating-protocol.md

Mission Control Operating Protocol — Pre-Funnel → Mission Control → ADE Factory → Execution → Feedback

Date: 2026-05-12 Status: Operating-model spec / keystone Purpose: The connecting tissue between research intake (Pre-Mission Control), Mission Control (3 dynamic docs), ADE Factory Pipeline (val-forge execution), and the feedback loop back to intake. This was the original purpose of d_mission-control/ — orchestrate the build from idea to execution.

Companion to:

vertical-fusion-checklist.md — Mission Control current-state inventory
milestones-manifesto.md — Mission Control forward-build sequencing
fusion-layer-integration-matrix.md — Mission Control cross-cutting connections
v_platform/PLATFORM.md — Baseline live status + Blueprints-as-a-Service lifecycle

Terminology lock (per operator 2026-05-12): ADE Factory Pipeline = val-forge (the dev factory engine). ADE is not a separate concept; it is the role val-forge plays in the operating protocol. Throughout this doc + sibling MC docs, "ADE Factory" + "val-forge" + "ADE Factory Pipeline" + "val-forge pipeline" are synonymous. Per ADR-011 + ADR-025 val-forge owns the 4-scope multi-repo ADE.

The Concept

Mission Control = the orchestration layer between research and execution. Not a destination; a coordination plane.

Research happens (operator drops URL / transcript / customer-engagement-learning surfaces / market scan reveals new tool). The output is signal — not yet executable. Execution happens (val-forge pipeline branches build engines + libraries + blueprints + skills). The input is committed-and-decided architecture — not exploratory.

Mission Control sits between. It transforms research signal into commit-ready architectural decisions and tracks them to execution.

Without Mission Control, research piles up as undirected pipeline + execution starts on whatever the loudest signal happens to be that day. With Mission Control, every executable item came from triaged research, locked architecture, sequenced milestones, and verified cross-cuts.

The Flow — Full Cycle

┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│   [1] PRE-MISSION CONTROL FUNNEL                                             │
│   ────────────────────────────────                                           │
│   Intake new research / ideas / bookmarks / customer learnings               │
│                                                                              │
│   Triggers:                                                                  │
│   - Operator drops URL / transcript / idea                                   │
│   - Pipeline gap surfaces ("need to scope X")                                │
│   - Customer engagement reveals new requirement                              │
│   - Market scan surfaces new tool / pattern / competitor                     │
│   - Cross-vertical pattern emerges                                           │
│                                                                              │
│   Triage Protocol (4 outcomes):                                              │
│   (a) Skip — note in passing; no doc                                         │
│   (b) Append — small finding to existing doc                                 │
│   (c) New research doc — substantive depth                                   │
│   (d) New spec / ADR — concrete architectural decision                       │
│                                                                              │
│   Location: d_mission-control/research/                                      │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    │ Promote when ready
                                    ↓
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│   [2] MISSION CONTROL (3 dynamic docs)                                       │
│   ─────────────────────────────────────                                      │
│   ┌─────────────────────────────────────────────────────────────────────┐    │
│   │ vertical-fusion-checklist.md  ← current state (16 layers; status)   │    │
│   │ milestones-manifesto.md       ← forward build (13 × ~110 × ⏸️)      │    │
│   │ fusion-layer-integration-matrix.md ← cross-cutting (interfaces +    │    │
│   │                                       physical AI + company lens +   │    │
│   │                                       capabilities)                  │    │
│   └─────────────────────────────────────────────────────────────────────┘    │
│                                                                              │
│   Dynamic interactions:                                                      │
│   - State flip in checklist → update milestone status in manifesto           │
│   - Milestone progression → update matrix density                            │
│   - Matrix reveals cross-cut → surface in milestone sub-tasks                │
│   - New vertical integration → new row in checklist + new milestone + new    │
│     row in matrix                                                            │
│                                                                              │
│   Plus supporting infrastructure:                                            │
│   - 16 ADR drafts in d_mission-control/specs/                                │
│   - 3 rules + 2 policies + 9 engine/feature specs                            │
│   - 40 research docs in d_mission-control/research/                          │
│   - Memory entries in operator memory directory                              │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    │ Lock + sequence
                                    ↓
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│   [3] ADE FACTORY PIPELINE = val-forge                                       │
│   ────────────────────────────────────                                       │
│   val-forge IS the ADE; owns ephemeral pipeline branches per CLAUDE.md:      │
│                                                                              │
│      pipeline/<type>/<YYYY-MM-DD>-<slug>                                     │
│                                                                              │
│   Pipeline types:                                                            │
│   - pipeline/spec/        ADR or spec authoring                              │
│   - pipeline/engine/      new engine implementation                          │
│   - pipeline/library/     new shared library                                 │
│   - pipeline/blueprint/   new blueprint (Ring 3 universal or Ring 4 client)  │
│   - pipeline/feature/     cross-engine feature work                          │
│   - pipeline/integration/ Microsoft-stack / external-tool integration        │
│                                                                              │
│   Lifecycle per PLATFORM.md Blueprints-as-a-Service:                         │
│                                                                              │
│   Author    ← val-fab authors per skills + meta rules                        │
│       ↓                                                                      │
│   Promote   ← val-forge dev-factory pipeline gates promotion                 │
│       ↓                                                                      │
│   Install   ← v_platform/skills/system/ (Ring 3) or                          │
│              v_clients/<client>/blueprints/ (Ring 4)                         │
│       ↓                                                                      │
│   Run       ← pulse fires → val-bay executes / val-orchestrator drives       │
│       ↓                                                                      │
│   Retire    ← val-fab marks superseded; old version → d_archive/             │
│                                                                              │
│   Pipeline branches are pipeline-managed only — humans never check out       │
│   manually. Auto-deleted on merge or block per CLAUDE.md.                    │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    │ Build + verify + smoke
                                    ↓
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│   [4] EXECUTION LAYER                                                        │
│   ────────────────────                                                       │
│   Code + artifacts land:                                                     │
│   - v_source/fusion-engines/engines/<name>/  (new engine)                    │
│   - v_source/fusion-engines/libraries/<name>/ (new library)                  │
│   - v_source/apps/<name>/                    (new shell or app)              │
│   - v_source/ops/<area>/                     (dev/ops tooling)               │
│   - v_source/installers/<name>/              (install assets)                │
│   - v_platform/skills/<area>/<skill>.md      (new skill)                     │
│   - v_platform/<grounding-doc>.md            (canonical platform doc edit)   │
│   - v_clients/<client>/blueprints/<...>/     (Ring 4 client blueprint)       │
│                                                                              │
│   Verification:                                                              │
│   - PLATFORM.md baseline rows update (smoke green)                           │
│   - system.inspector.v1 skill clean walk                                     │
│   - baseline-coral.jsonl appends (probe history)                             │
│   - smoke-baseline.sh all green                                              │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘
                                    │
                                    │ Lessons / gaps / patterns
                                    ↓
┌──────────────────────────────────────────────────────────────────────────────┐
│                                                                              │
│   [5] FEEDBACK LOOP                                                          │
│   ─────────────────                                                          │
│   Execution outputs feed back to research:                                   │
│   - New patterns observed → potential new ADR (back to Pre-Mission Control)  │
│   - Failed sub-milestones → re-triage (back to Pre-Mission Control)          │
│   - Customer engagement learnings → new memory entries                       │
│   - Cross-vertical patterns → new cross-vertical capability layers           │
│   - Production-scale learnings → ADR amendments                              │
│                                                                              │
│   Closes the cycle: execution-derived signal becomes next-round research.   │
│                                                                              │
└──────────────────────────────────────────────────────────────────────────────┘

[1] Pre-Mission Control Funnel — Research Intake Protocol

Purpose: All new research / ideas / bookmarks land here first. Triaged into one of four outcomes before entering Mission Control orchestration.

When intake fires

Trigger	Source
Operator drops URL / transcript / image / idea	Cowork chat
Pipeline gap surfaces ("we should scope X")	Research-doc internal
Customer engagement reveals new requirement	SBR / New Era IT / future-client engagement
Market scan surfaces new tool / pattern / competitor	Industry feeds / partner network / news
Cross-vertical pattern emerges	Mission Control matrix analysis
Execution failure surfaces gap	ADE Factory pipeline failure → reroute to intake
Customer support reveals operational pattern	Operator-team field reports

Triage Protocol — 4 outcomes

Per F167 strategic frame triage protocol (used throughout 2026-05-11 pipeline):

Outcome (a) — Skip

Not relevant to ValOS scope OR already covered OR low signal
Action: brief acknowledgment; no doc
Cost: ~30 seconds
Example: tangential bookmark without architectural relevance

Outcome (b) — Append

Substantive but small; fits within existing doc
Action: finding (F-numbered) appended to existing research / spec / ADR
Cost: ~5-10 minutes
Example: Wazuh production-scale data appended to doc 25 F166 (15M endpoints / 30M downloads / Cisco / NASA customers)

Outcome (c) — New research doc

Substantive depth; warrants dedicated treatment
Action: spin new doc at d_mission-control/research/<YYYY-MM-DD>.<slug>.md
Cost: ~30-60 minutes (substantial; 10-25 KB doc)
Example: doc 27 memory-substrate-competitive-landscape (Automaton + Basic Memory deep analysis)

Outcome (d) — New spec / ADR

Concrete architectural decision required
Action: ADR draft at d_mission-control/specs/adr-NNN-<slug>.md OR spec at d_mission-control/specs/<feature>.md
Cost: ~30-90 minutes
Example: 16 ADR drafts (ADR-007 through ADR-023) authored 2026-05-12

Triage decision criteria

Question	If YES
Is this already covered in pipeline?	(a) Skip OR (b) Append
Does this surface a net-new architectural surface?	(d) ADR/spec
Does this provide cross-vertical pattern depth?	(c) Research doc
Does this require operator strategic decision?	(c) Research doc with operator-decision section
Does this reinforce existing pattern with new corroboration?	(b) Append with corroboration count update
Does this conflict with locked decision?	(c) Research doc surfacing conflict + (d) ADR-amendment proposal

Promotion to Mission Control

Once intake item is committed (any outcome a/b/c/d), assess Mission Control implications:

vertical-fusion-checklist — does this add new row to a layer? Update layer.
milestones-manifesto — does this add new milestone or sub-milestone? Add it.
fusion-layer-integration-matrix — does this add new vertical integration or interface subtype? Add row / column / cell.

Multi-doc propagation: state flips frequently cascade across all 3 Mission Control docs. Update together; commit together.

[2] Mission Control — 3 Dynamic Docs

Purpose: The orchestration core. 3 docs working as a system to track current state + forward build + cross-cutting connections.

Doc 1: vertical-fusion-checklist.md (Current State)

What it tracks:

16 architectural layers (Ring 0 substrate → Substrate primitives → Endpoints → Peer Services → Shells → Libraries → Policy → Capability layers → MSP toolstack → External integration → Pipelines → Cores archive → Cross-vertical → Operator surfaces → Enforcement → Observability)
Per-item status (✅ / 🔧 / ❌ / 📋 / 🎯)
Per-item source references (PLATFORM.md baseline + ADRs + research docs)

When it updates:

An engine / library / blueprint compiles + smokes green → ✅
ADR proposed → 🎯
Spec drafted → 📋
Build started but not green → 🔧
Item retired → moved to d_archive/ + checklist line crossed out

Doc 2: milestones-manifesto.md (Forward Build)

What it tracks:

13 milestones (M0-M12) — sequenced by technical dependency + operator gating + commercial pressure
~110 sub-milestones (MX.Y) — each with goal + killer items + acceptance + dependencies + owner + status
13 pause points (MX.P) — verification gates between milestones

When it updates:

Killer item completes → check the box
Sub-milestone all-killer-items done → status flip
Pause point passes → next milestone unlocked
Milestone complete → archive milestone; memory entry

Doc 3: fusion-layer-integration-matrix.md (Cross-Cutting)

What it tracks:

8 fusion-layer interfaces (WorkSpace / Asset / Site / Conversation / Engagement / Operator / Document / Schedule)
Per-vertical-integration matrix rows (~50 verticals × 4 dimensions: interfaces + physical AI + company lens + capabilities)
Reverse map per interface (which verticals use each)
Integration density heatmap
Fusion examples (same logic across many subtypes)

When it updates:

New vertical integration added → new row
New concrete subtype identified (e.g., new endpoint class) → coral growth on subtype list
Cross-cut discovered → matrix cell updated
Capability gains physical AI dimension → physical AI cross-cut updated

Dynamic Interaction Patterns

The 3 docs are not independent. State flips propagate across all 3. Examples:

Pattern A: New milestone sub-task triggers

milestones-manifesto sub-milestone added (MX.Y new killer item)
→ vertical-fusion-checklist layer updated (new row)
→ fusion-layer-integration-matrix (cross-cuts mapped)

Pattern B: Engine ships

Engine smoke green → checklist ✅
→ manifesto sub-milestone done
→ matrix capability + interface coverage updated

Pattern C: New vertical integration scoped

New row in matrix (e.g., when MSP-vertical scopes per M9)
→ milestones-manifesto MX.Y sub-milestones expand
→ checklist new layer items added

Pattern D: ADR locked

ADR status flip 🎯 → ✅
→ checklist L1.N status flip
→ manifesto MX.Y verification ⏸️ pause point pass
→ matrix cell density update (capability + interface confirmed)

Update Protocol (mandatory discipline)

When any state flips:

Update all affected docs (not just the originating one)
Cross-reference in commit message
Memory entry if strategic-commitment scope
Pause-point verification if applicable

Multi-doc commit pattern (per pipeline batch convention):

docs: <area> — <change> — flipped <N> items across vertical-fusion-checklist + milestones-manifesto + fusion-layer-integration-matrix

Affected:
- vertical-fusion-checklist: L<N>.<M> ❌ → 🔧
- milestones-manifesto: M<N>.<M> killer item completed
- fusion-layer-integration-matrix: cell <vertical>×<interface> confirmed

Source: <research doc / ADR / engagement learning>

[3] ADE Factory Pipeline (= val-forge) — Execution Mechanics

Purpose: val-forge IS the ADE Factory Pipeline. Executes Mission Control items via ephemeral pipeline branches per CLAUDE.md.

Pipeline branch naming (per CLAUDE.md locked 2026-05-01)

pipeline/<type>/<YYYY-MM-DD>-<slug>

Pipeline types (extends CLAUDE.md baseline):

Type	Purpose	Example
`pipeline/spec/`	ADR or spec authoring	`pipeline/spec/2026-05-12-adr-019-cores`
`pipeline/engine/`	New engine implementation	`pipeline/engine/2026-06-01-val-policy`
`pipeline/library/`	New shared library	`pipeline/library/2026-05-15-val-canvas`
`pipeline/blueprint/`	New blueprint (Ring 3 or Ring 4)	`pipeline/blueprint/2026-07-01-debt-recovery-au`
`pipeline/feature/`	Cross-engine feature work	`pipeline/feature/2026-06-15-val-bay-hot-reload`
`pipeline/integration/`	External-tool integration	`pipeline/integration/2026-06-20-business-central-mcp`
`pipeline/docker/`	New Ring 0 docker	`pipeline/docker/2026-05-20-hocuspocus`
`pipeline/shell/`	New shell / app	`pipeline/shell/2026-07-15-val-atlas`
`pipeline/research/`	Promote research → spec	`pipeline/research/2026-08-01-promote-qms-doc-29-to-spec`
`pipeline/release/`	Canonical Ring 3 release OR per-client cascading upgrade (per ADR-025)	`pipeline/release/2026-06-15-upgrade-vN`

ADE scope routing (per ADR-025 multi-repo ADE):

val-forge operates across 4 ADE scopes; Decision Cards (per ADR-024 val-up engine) carry ade_scope field routing pipeline branches to correct repo:

ADE scope	Repo	Pipeline branch namespace	Promoter approval
Dev-workspace ADE	`valos-next`	`pipeline/<type>/<date>-<slug>` (current CLAUDE.md baseline)	Valtience operator-team
Canonical ADE	`ValOS` (canonical published platform)	`pipeline/release/<version>-<slug>`	Valtience operator-team (platform release gate)
Per-client ADE	`valos-<client>` (one per client engagement)	`pipeline/<type>/<date>-<slug>`	Valtience operator-team + (optionally) client-side reviewer
Per-tenant val-up ADE	val-up internal storage (no git branch)	`up.<tenant_id>.<type>.<date>-<slug>`	Per-tenant scope; Valtience operator-team superset access

val-up → val-forge → multi-repo dispatch flow:

val-up emits Decision Card with ade_scope field (per master-decision-card-spec)
val-up MCP dispatch to val-forge (mcp/sync.pipeline.spawn.v1)
val-forge routes pipeline branch to correct repo per ade_scope
Pipeline branch executes killer items
Per-scope promoter approval workflow
Merge + auto-delete branch
val-forge status streams back to val-up
val-up Decision Card status flip per execution outcome

Pipeline-managed only — humans never check out manually. Auto-deleted on merge or block.

Lifecycle (per PLATFORM.md Blueprints-as-a-Service)

Stage 1: Author

val-fab (Ring 1) authors content per skills + meta/TAXONOMY rules
Validates against locked invariants (val-policy capability bindings; skill format)
Output: candidate artifact (engine code / library / blueprint / skill / spec)

Stage 2: Promote

val-forge gates promotion to Ring 3 (universal) or Ring 4 (per-client)
Promoter approval required (operator-team review window)
Smoke tests must pass (smoke-baseline.sh + inspector clean walk)

Stage 3: Install

Blueprint dropped into v_platform/skills/system/ (Ring 3) or v_clients/<client>/blueprints/ (Ring 4)
val-bay registry picks it up automatically (per file watcher)
Pulse → registry → executable

Stage 4: Run

Pulse fires → val-bay executes skill (single-pulse) or val-orchestrator drives multi-step Mission
b_facts emitted per execution (cost / outcome / parent_fact_ids chain)
Outcomes feed back through OODA loops

Stage 5: Retire

val-fab marks superseded
Old version moves to d_archive/
Git history authoritative; folders preserved for revival via git mv back per CLAUDE.md

Pipeline-to-Mission-Control sourcing

Every pipeline branch sources from a Mission Control item:

Source	Pipeline branch
ADR 🎯 Proposed → ✅ Accepted	`pipeline/spec/` for ADR draft + implementation kickoff
Sub-milestone MX.Y starts	`pipeline/feature/` (or engine/ / library/ / blueprint/) for the work
Cross-doc state flip	Multi-pipeline-branch coordination (rare but happens for cross-locked ADRs like ADR-010 + ADR-022 + ADR-023)
Pre-Mission Control intake outcome (d)	`pipeline/spec/` for ADR / new spec authoring

[4] Execution Layer — What Gets Built Where

Purpose: ADE Factory pipeline output lands in v_source/ + v_platform/ per CLAUDE.md repo layout discipline.

v_source/ (production code; our IP)

Directory	What lands here	From
`v_source/fusion-engines/engines/<name>/`	New engines (val-policy / val-fab / val-track / val-host / val-ingest / etc.)	pipeline/engine/
`v_source/fusion-engines/libraries/<name>/`	New shared libraries (val-canvas / val-editor / val-block-renderer / etc.)	pipeline/library/
`v_source/apps/<name>/`	New shells + apps (val-desk extensions; val-atlas; val-workbench)	pipeline/shell/
`v_source/ops/<area>/`	New dev/ops tooling (smoke / status / lint)	pipeline/feature/ (ops scope)
`v_source/installers/<name>/`	New install assets (scripts / systemd units / caddy / Windows install)	pipeline/feature/ (installer scope)
`v_source/docker/<name>/`	New Ring 0 docker build contexts	pipeline/docker/

v_platform/ (canonical platform documentation + skills; ships)

Directory	What lands here	From
`v_platform/skills/system/<area>/<skill>.md`	New system skills	pipeline/blueprint/ + pipeline/spec/
`v_platform/skills/meta/<meta-skill>.md`	New meta governance (operator-edited only; agents read-only)	Operator manual edit + pipeline/spec/ for review
`v_platform/skills/routines/<routine>.md`	New routines	pipeline/blueprint/
`v_platform/skills/genies/<genie>.md`	New genies	pipeline/blueprint/
`v_platform/skills/personas/<persona>.md`	New personas	pipeline/blueprint/
`v_platform/skills/catalogs/<catalog>.md`	New catalogs	pipeline/blueprint/
`v_platform/<grounding-doc>.md`	Canonical platform doc edit (IDENTITY / SOUL / AGENTS / PLATFORM / README)	pipeline/spec/ with explicit operator approval

v_clients/ (per-client; filtered per-deployment)

Directory	What lands here	From
`v_clients/<client>/blueprints/<operator>/<device>/`	Per-client Ring 4 blueprints	pipeline/blueprint/ (Ring 4 scope)

d_mission-control/ (Mission Control; never ships)

Directory	What lands here	From
`d_mission-control/specs/<adr-N>.md`	ADRs	pipeline/spec/
`d_mission-control/specs/<feature-spec>.md`	Feature/engine specs	pipeline/spec/
`d_mission-control/research/<YYYY-MM-DD>.<slug>.md`	Research docs	pipeline/research/ + Pre-Mission Control
`d_mission-control/rules/<rule>.md`	Locked invariants	pipeline/spec/ with operator lock
`d_mission-control/policies/<policy>.md`	Behavior governance	pipeline/spec/
`d_mission-control/baseline-coral.jsonl`	Append-only coral log (probe history)	Automated by smoke-baseline.sh

Verification at execution-stage

Compile — cargo check --workspace (or scoped -p <crate>) for Rust; ts-check for TS
Smoke — engine-specific health endpoints + v_source/ops/status.sh
Inspector — system.inspector.v1 skill clean walk (no hardcoded skill lists; no bus-library bypass; missing-vs-orphan entity check)
Baseline — smoke-baseline.sh all exits 0
Coral log — append-only entry to baseline-coral.jsonl
PLATFORM.md baseline — row status updated (✅)
Mission Control update — checklist + manifesto + matrix all reflect new state

[5] Feedback Loop — Closing the Cycle

Purpose: Execution outputs feed back to research / Mission Control / ADRs. Closes the cycle.

Feedback patterns

Pattern 1: New pattern observed during execution

During pipeline/engine/ work, a recurring pattern emerges (e.g., "every engine needs X")
→ New ADR candidate (back to Pre-Mission Control outcome (d))
→ Mission Control milestone added (new MX.Y in manifesto)

Pattern 2: Failed sub-milestone

Sub-milestone fails verification at pause point
→ Re-triage in Pre-Mission Control (what was missing?)
→ New killer items or re-sequenced sub-milestone or de-scoped milestone
→ Memory entry capturing the lesson

Pattern 3: Customer engagement learning

Engagement Core lifecycle captures learnings (per ADR-019)
Knowledge nodes synthesize patterns across runs (per doc 32 F210)
→ Surface in Vertical Core when patterns cross-engagement
→ Update vertical blueprint (Ring 3) via pipeline/blueprint/

Pattern 4: Cross-vertical pattern

Pattern emerges across multiple vertical engagements
→ Promote to cross-vertical capability layer (per doc 18 / 29 / 34 pattern — 3 base blueprints to date)
→ Update fusion-layer-integration-matrix with new cross-cut
→ Possibly ADR for new substrate primitive

Pattern 5: Production-scale learning

ValOS production deployment surfaces operational truth
→ Memory update (e.g., per-deployment cost-envelope per doc 23 F130 + doc 24 F136 cost data)
→ ADR amendment if architectural assumption violated
→ Mission Control re-prioritization

Operational Discipline — Cadence

Daily

Pre-Mission Control intake — process bookmark / URL drops; apply 4-outcome triage
Mission Control state check — any in-flight items flip state? Update docs.
ADE Factory branch check — pipeline branches progressing? Promotion-ready branches reviewed.

Weekly

Mission Control review — are sub-milestones on track? Pause points approaching?
Memory updates — strategic-commitment captures; lessons learned
Pipeline batch commit + push + SCP — multi-doc batches committed together

Monthly

Full Mission Control audit — state across all 3 docs aligned? Cross-cuts consistent?
ADE Factory throughput — branches per week / per month
Re-sequence milestones — if commercial pressure or technical blocker shifts
Retire archived items — items in d_archive/ stable for 30 days = retired

Quarterly

Strategic review — vertical-fusion-checklist Layer counts; milestone progression metric
FORCE deck refresh — per current state (per doc 17 + Milestone M12)
Memory cleanup — outdated entries removed; new strategic commitments captured

Examples — Concrete Walk-Throughs

Example 1: Operator drops Tactical RMM URL

Intake: operator drops github.com/amidaware/tacticalrmm URL
Triage (outcome c): new research doc; depth warranted given NATS architectural alignment surface
Output: doc 35 tactical-rmm-reference-shape-for-msp-rmm.md authored
Mission Control propagation:
- vertical-fusion-checklist L8.2 RMM row updated with reference shape
- milestones-manifesto M9.3 cross-platform Rust agent sub-milestone references doc 35
- fusion-layer-integration-matrix RMM row populated with interfaces + physical AI + capabilities
Operator clarification: "build native; borrow patterns" → doc 35 rewritten with borrow-only-patterns framing
ADE Factory readiness: M9.3 cross-platform Rust agent → pipeline/engine/ branch when MSP vertical scopes

Example 2: ADR-019 Context Cores moves from Proposed → Accepted

Mission Control update: ADR-019 status 🎯 → ✅ in d_mission-control/specs/
Propagation:
- vertical-fusion-checklist L1.7 ✅
- milestones-manifesto M1.4 sub-milestone passes; M1.P three-way cross-lock verification queued
- fusion-layer-integration-matrix Cores row confirmed
Cross-ADR coupling: ADR-019 + ADR-020 cross-lock at M2.P
ADE Factory: pipeline/spec/ branch closes (ADR drafting complete); pipeline/feature/ branch opens for Engagement Core lifecycle implementation
Memory: project_business_central_sor.md updated with ADR-019 dependency reference

Example 3: Failure at M3.P substrate library smoke

Execution attempt: val-canvas library compiles but smoke fails (round-trip Canvas → archetype layout → Canvas inconsistent)
Failure protocol: halt M3 progression; document failure
Re-triage in Pre-Mission Control:
- Outcome (b) append: small finding to doc 26 — layout-algorithm-determinism gap
- Or outcome (c) new research doc on Canvas layout convergence
Mission Control update: M3.1 status 🔧 → ❌ (regressed); failure-log entry added
ADE Factory: pipeline/library/ branch held; fix attempt OR re-scope OR de-prioritize
Operator decision: per failure-cause; either fix-fix-fix or re-scope sub-milestone

Example 4: SBR engagement reveals new pattern

Customer engagement learning: SBR debt-recovery complex-case workflows reveal "co-debtor reconciliation" pattern not initially scoped
Engagement Core knowledge-nodes synthesis: pattern observed 3+ times
Feedback to Pre-Mission Control: new research doc proposal — co-debtor-reconciliation-pattern.md
Triage outcome (c): spin new research doc
Pattern recognition: cross-vertical (also applies to manufacturing joint-vendors + healthcare guarantor relationships)
Promote: cross-vertical capability layer extension OR new ADR for entity-resolution variant
Mission Control update:
- matrix new row for entity-resolution-cross-cut
- manifesto new sub-milestone for cross-vertical pattern
- checklist new layer item if needed
ADE Factory: pipeline/feature/ branch for cross-vertical pattern when scoping starts

The Original Purpose of d_mission-control/

Per CLAUDE.md repo layout:

"d_mission-control/ — Documents only — future input to the Policy-as-Code engine. Categories: rules/ (locked invariants), policies/ (behavior governance), specs/ (design + implementation), research/ (exploration, audits, vendor evals). No scripts, no installers, no systemd units, no binaries."

Mission Control = the bridge between research (exploration) and execution (val-source / val-platform code). This protocol formalizes how the bridge operates:

Pre-Mission Control intake — research/ + intake protocol (this doc §1)
Mission Control orchestration — 3 dynamic docs (vertical-fusion-checklist + milestones-manifesto + fusion-layer-integration-matrix) + ADRs + rules + policies (this doc §2)
ADE Factory — val-forge pipeline branches (this doc §3)
Execution — v_source / v_platform / v_clients (this doc §4)
Feedback — back to research (this doc §5)

Future Policy-as-Code engine will consume d_mission-control/ programmatically. Today, the discipline is operator-team + Claude-Cowork-team-driven via this protocol.

Discipline Principles

Every executable item came from triaged research. No spontaneous execution; always traceable to Mission Control item.
Every Mission Control item came from intake. No spontaneous architectural decisions; always triaged into ADR / spec / research doc first.
State flips propagate. Update all 3 Mission Control docs together; commit together.
Pause points are non-negotiable. Verification gates before advancing.
Pipeline branches are pipeline-managed. Humans never check out manually.
Feedback loop closes. Execution outputs feed back to research; pattern emergence triggers new ADRs.
Discipline beats memory. Public, versioned, wrong until proven right (per SOUL.md Checklist Manifesto mindset).

Cadence Summary Table

Frequency	Activity	Documents touched
Daily	Pre-Mission Control intake; Mission Control state check; ADE Factory branch check	All 3 Mission Control docs + research/ + specs/
Weekly	Mission Control review; pipeline batch commit	All 3 + git commits
Monthly	Full Mission Control audit; ADE Factory throughput; re-sequence	All 3 + PLATFORM.md baseline + memory
Quarterly	Strategic review; FORCE deck refresh; memory cleanup	All 3 + FORCE deck + memory

References

Doc / File	Purpose
vertical-fusion-checklist.md	Mission Control current-state inventory (16 layers)
milestones-manifesto.md	Mission Control forward-build sequencing (13 × 110 × ⏸️)
fusion-layer-integration-matrix.md	Mission Control cross-cutting matrix (interfaces × physical AI × company lens × capabilities)
`v_platform/PLATFORM.md`	Baseline live status + Five Rings + Blueprints-as-a-Service lifecycle + Pulse Lifecycle (anomaly pipeline)
`v_platform/IDENTITY.md` + `SOUL.md` + `AGENTS.md`	What ValOS IS + who it serves + how it behaves
`CLAUDE.md`	Cowork dev rules + repo layout + val-forge ephemeral pipeline branches
16 ADRs (`d_mission-control/specs/adr-NNN-*.md`)	Architectural decisions sourced from Mission Control
40 research docs (`d_mission-control/research/2026-05-11.*.md`)	Pre-Mission Control intake output ready for promotion
3 rules + 2 policies + 9 specs (`d_mission-control/rules/` + `policies/` + `specs/`)	Locked invariants + behavior governance + design+implementation
Memory (`C:\Users\ClydeNelsen\.claude\projects\...\memory\`)	Persistent strategic commitments (9+ pending updates)
`baseline-coral.jsonl`	Append-only coral log (probe history; smoke harness output)
`valos-reference.md`	Engine + capability + vocabulary register

Closing — The Mission Control Operating Model

Mission Control is alive when:

Pre-funnel intake captures every new signal (URL / transcript / customer-learning / market-scan)
3 Mission Control docs stay synchronized (state flips propagate)
ADE Factory pipeline branches flow continuously (every sub-milestone has a branch when ready)
Execution outputs feed back to research (pattern emergence → ADRs)
All 5 stages cycle continuously (no stage stops; no stage skips)

Mission Control is dead when:

Bookmarks pile up unprocessed (intake clogged)
3 docs drift out of sync (state flip in one not reflected in others)
Pipeline branches stall (no promotion-ready commits)
Execution happens without Mission Control sourcing (sponotaneous "let me just hack this")
Feedback loop broken (lessons learned vanish into operator memory but never reach research)

The discipline above keeps Mission Control alive. Public, versioned, wrong until proven right.

Mission Control Operating Protocol — keystone connecting Pre-Mission Control funnel + Mission Control 3 dynamic docs + ADE Factory pipeline + Execution layer + Feedback loop. The original purpose of d_mission-control/. Cowork-side composition. 2026-05-12.