Master Decision Card Spec — Mission Control Ledger + Fact Stream + Institutional Knowledge

Date: 2026-05-12 Status: Spec / primitive definition Purpose: Every Mission Control action item gets a Master Decision Card capturing context + options + decision + outcome + audit chain. Cards accrete in the Mission Control Ledger (durable storage); each card emits to the Mission Control Fact Stream (b_fact + l_fact). Cumulative output = ValOS institutional knowledge — the durable organizational memory. Companion to:

• vertical-fusion-checklist.md — current state (16 layers)
• milestones-manifesto.md — forward build (13 × 110 × 13 gates)
• fusion-layer-integration-matrix.md — cross-cutting
• mission-control-operating-protocol.md — operating model

Terminology lock (per operator 2026-05-12): ADE Factory = val-forge throughout this doc and sibling MC docs. ADE Factory Pipeline = val-forge pipeline branches per CLAUDE.md ephemeral pattern + ADR-011 + ADR-025 multi-repo scope.

• v_platform/PLATFORM.md — Decision Card primitive (Part 2 Master Checklist) + val-ledger + Pulse Lifecycle
• v_platform/SOUL.md Non-Negotiables — "Humans stay in command on consequence; platform compresses orient + decide-options; human picks"

---

The Concept — Institutional Knowledge as First-Class Substrate

Problem without Master Decision Cards:

• Operator strategic commitments scattered across memory + chat logs + commit messages
• Architectural decisions captured but rationale + alternatives lost
• Cross-vertical pattern emergence invisible (no aggregation surface)
• Re-discovering "why did we decide X" requires archeology
• Institutional knowledge dies when operator team changes or memory grows stale

Solution — every decision is a fact:

• Each Mission Control action item produces a Decision Card
• Cards stored in Mission Control Ledger (append-only; coral growth pattern per skill-frontmatter-spec.md §3)
• Each card emits to the Mission Control Fact Stream (b_fact for terminal decisions; l_fact for in-flight)
• Cumulative card stream = institutional knowledge — durable, queryable, pattern-detectable organizational memory

Two-tier Decision Card system:

Tier	Scope	Source PLATFORM.md primitive
Operator Decision Card (runtime)	Per-engagement operational decisions on Engagement entities (3-option interaction grammar per click semantics)	PLATFORM.md Part 2 Master Checklist (❌ pending implementation)
Master Decision Card (this spec)	Mission Control orchestration decisions (ADRs / sub-milestones / strategic commitments / pipeline-branch outcomes)	New primitive — institutional-knowledge scope

Both share the same schema base; different scopes. Both feed val-ledger; both contribute to institutional knowledge.

---

Decision Card Schema

Required fields

# Master Decision Card v1
id: <SEID>                                     # UUIDv7 per Non-Negotiable #9 (stable_entity_id)
type: <card-type>                              # see Card Types below
title: <one-line summary>                      # operator-readable
status: <Proposed | Decided | Executed | Verified | Retired | Failed>
date_drafted: <ISO 8601>
date_decided: <ISO 8601 | null>
date_executed: <ISO 8601 | null>
date_verified: <ISO 8601 | null>

context:
  trigger: <what triggered this decision>
  source: <where the trigger came from>       # operator-drop / pipeline-gap / engagement-learning / etc.
  research_refs: [doc-N / ADR-N / etc.]       # cross-pipeline references
  affected_mission_control:                    # which MC docs / items this affects
    checklist: [L<N>.<M>, ...]                # vertical-fusion-checklist rows
    manifesto: [M<N>.<M>, ...]                # milestones-manifesto sub-milestones
    matrix: [<vertical>×<interface>, ...]     # fusion-layer-integration-matrix cells

options:                                       # per PLATFORM.md Decision Card primitive (3 options)
  - id: a
    label: <option a label>
    description: <option a description>
    pros: [...]
    cons: [...]
  - id: b
    label: <option b label>
    description: <option b description>
    pros: [...]
    cons: [...]
  - id: c
    label: <option c label>
    description: <option c description>
    pros: [...]
    cons: [...]

recommendation:                                # Claude Cowork lean
  option: <a | b | c>
  rationale: <why this lean>
  confidence: <low | medium | high>            # confidence-gating per pipeline-pattern (8 corroborations)

decision:                                      # operator's actual choice
  option: <a | b | c | custom>                 # custom = operator chose something not in the 3 options
  rationale: <operator rationale; brief>
  decided_by: <operator | operator-team-member>
  decided_at: <ISO 8601>

execution:                                     # what happened after the decision
  pipeline_branches: [pipeline/<type>/<date>-<slug>, ...]  # ADE Factory branches spawned
  affected_artifacts: [v_source/.../, v_platform/.../, ...] # files / engines / libraries affected
  outcome_b_facts: [<b_fact-id>, ...]          # outcome facts emitted

verification:                                  # outcome check
  smoke_results: <pass | fail | partial>
  inspector_clean_walk: <yes | no>
  baseline_row_updated: <PLATFORM.md row N>
  notes: <verification notes>

audit_chain:                                   # provenance per Non-Negotiable + AGENTS.md parent_fact_ids
  parent_card_ids: [<parent-card-SEID>, ...]   # decisions this card depends on
  parent_fact_ids: [<parent-b_fact-id>, ...]   # facts this card was triggered by
  child_card_ids: [<child-card-SEID>, ...]     # decisions triggered by this card (back-populated)

institutional_knowledge:                       # pattern observation
  cross_vertical_pattern: <pattern name | null> # if this card contributes to a cross-vertical pattern
  corroboration_count: <integer>               # if this is Nth corroboration of pattern X
  memory_entry: <memory-file | null>           # if this card prompted a memory update
  learning_loop_candidate: <yes | no>          # if 3+ similar cards → candidate skill

cross_references:                              # cross-doc cross-cuts
  adrs: [ADR-NNN, ...]
  research_docs: [doc-N, ...]
  rules: [rule-name, ...]
  policies: [policy-name, ...]
  specs: [spec-name, ...]

Optional fields (per card type)

• engagement_id — for engagement-scoped decisions (SBR / future clients)
• vertical — for vertical-scoped decisions (MSP / QMS / manufacturing / etc.)
• urgency — operator-priority for in-flight decisions
• cost_estimate — for cost-impactful decisions (per doc 23 F130 + doc 24 F136 cost envelope)
• affected_interfaces — fusion-layer interfaces involved (per fusion-layer-integration-matrix)
• physical_ai_dimension — embodied / on-site / hardware aspects
• company_lens_variant — per-deployment / per-vertical specifics

val-up + val-forge integration fields (per ADR-024 + ADR-025)

• tenant_id — per-tenant scoping in val-up multi-tenant SaaS (Valtience operator-team OR per-client tenant); enforces per-tenant ledger isolation via Entra OAuth + val-policy ABAC
• ade_scope — pipeline-branch repo routing per ADR-025 multi-repo ADE:
  • dev-workspace — pipeline branch in valos-next
  • canonical — pipeline branch in ValOS canonical
  • per-client (requires client_repo field) — pipeline branch in valos-<client>
  • per-tenant-val-up — val-up internal storage (no git branch)
• client_repo — required when ade_scope: per-client; references valos-<client> repo
• promoter_approval_required — boolean; routes to per-scope approver matrix per ADR-025
• client_side_reviewer — optional; per-client engagement opt-in for client oversight on per-client ADE

These fields are critical for val-up's multi-tenant Decision Card emission + val-forge's multi-repo dispatch.

---

Card Types

11 distinct Master Decision Card types corresponding to Mission Control orchestration scope:

Type	Description	Example
adr	Architectural Decision Record (16 drafted 2026-05-12)	ADR-019 Context Cores accepted Proposed → ✅
sub-milestone	Sub-milestone activation / completion	M3.1 val-canvas library complete
pause-point	Pause-point verification gate	M1.P three-way block-schema cross-lock verified
strategic-commitment	Operator strategic commitment	"Business Central as System of Record" 2026-05-11
intake-triage	Pre-Mission Control 4-outcome triage	"Tactical RMM URL → outcome (c) new research doc"
state-flip	Cross-doc state propagation	"Vaultwarden adoption → 3 docs updated"
pipeline-branch	ADE Factory pipeline branch lifecycle	"pipeline/engine/2026-06-01-val-policy opened"
engagement-decision	Per-engagement choice (SBR / future clients)	"SBR engagement core v1 captured"
vertical-decision	Per-vertical strategic choice	"MSP-vertical scoping triggered by New Era IT engagement"
failure-recovery	Failure protocol response	"M3.P failed → re-triage in Pre-Mission Control"
memory-update	Memory entry creation / update	"project_business_central_sor.md created"

---

The Mission Control Ledger

Storage: d_mission-control/ledger/

Per CLAUDE.md repo layout: d_mission-control/ is documents only — future input to Policy-as-Code engine. The ledger fits cleanly as a 5th category alongside rules/ + policies/ + specs/ + research/.

Proposed structure:

d_mission-control/ledger/
├── README.md                                  # ledger conventions + indexing
├── index.jsonl                                # one-line-per-card index (id / type / title / status / date)
├── <YYYY-MM>/                                 # month-bucket subdirs (avoids one-folder-with-thousands-of-files)
│   ├── card-<id-truncated>-<slug>.yaml        # one file per card
│   └── ...
└── streams/                                   # JetStream-style append-only fact streams
    ├── decisions.jsonl                        # all decisions terminal-status (Decided / Verified / Retired)
    ├── in-flight.jsonl                        # all in-flight cards (Proposed / Executed / waiting-Verify)
    └── failures.jsonl                         # failure-recovery cards

Indexing:

• By type — query "all adr cards" / "all strategic-commitment cards"
• By status — query "all Verified" / "all Failed"
• By date — chronological + date-range
• By affected-MC-doc — "all cards affecting milestones-manifesto M4.x"
• By vertical — "all cards affecting SBR engagement"
• By cross-reference — "all cards referencing doc 38"

Coral growth pattern (per skill-frontmatter-spec.md §3):

• Append-only — cards never overwritten
• Schema accretes additively (new fields optional)
• Old cards with missing new fields render correctly with sensible defaults

---

The Mission Control Fact Stream

Each Decision Card emits to val-ledger b_fact stream (or l_fact for in-flight). Connects Mission Control orchestration to ValOS native fact substrate.

Fact subjects (per Non-Negotiable + AGENTS.md)

valos.mc.decision.<type>.<state>.<short-id>

Examples:

valos.mc.decision.adr.proposed.adr-019
valos.mc.decision.adr.decided.adr-019
valos.mc.decision.adr.verified.adr-019
valos.mc.decision.sub-milestone.completed.m3-1
valos.mc.decision.pause-point.verified.m1-p
valos.mc.decision.strategic-commitment.decided.business-central-sor
valos.mc.decision.intake-triage.decided.tactical-rmm-url
valos.mc.decision.state-flip.executed.vaultwarden-adoption
valos.mc.decision.pipeline-branch.opened.engine-val-policy
valos.mc.decision.engagement-decision.executed.sbr-core-v1
valos.mc.decision.failure-recovery.decided.m3-p-fail

Fact retention

Per v_platform/SOUL.md three-class fact taxonomy (locked 2026-05-03):

• b_fact for terminal Decision Card states (Decided / Verified / Retired / Failed) — forever retention with policy exceptions
• l_fact for in-flight states (Proposed / Executed before Verified) — bounded retention; audit-relevant

Replay capability

Per PLATFORM.md baseline row 36 ("Facts replay — 100 facts on the bus can be replayed in order without loss"):

• Mission Control Fact Stream replayable for audit / institutional-knowledge reconstruction
• Pattern detection across replay reveals cross-vertical patterns
• Failure root-cause analysis via card-chain walk-back

---

Card Lifecycle

5-state lifecycle (with optional Failure recovery branch):

                ┌─────────────────────────────────────────────┐
                │                                              │
[Triggered] → [Drafted] → [Proposed] → [Decided] → [Executed] → [Verified] → [Retired]
                                            │            │
                                            └─────┐      └─────┐
                                                  ↓            ↓
                                              [Failed]    [Failed]
                                                  │            │
                                                  └────────────┴───→ [Failure Recovery]
                                                                              │
                                                                              ↓
                                                                      [back to Pre-Mission Control]

State transitions

From	To	Trigger
(none)	Triggered	Intake event / Mission Control state flip / pipeline-branch event
Triggered	Drafted	Claude Cowork drafts card (filling context + options + recommendation)
Drafted	Proposed	Card pushed to ledger; operator review queued
Proposed	Decided	Operator decision recorded (chose option a/b/c or custom)
Decided	Executed	ADE Factory pipeline branch starts; affected_artifacts begin updating
Executed	Verified	Smoke + inspector + baseline-row update green
Verified	Retired	Card superseded by newer decision OR scoped-end reached
(any)	Failed	Verification fails OR pipeline branch blocked OR operator-rejected
Failed	(Failure Recovery)	Re-triage in Pre-Mission Control → new Triggered card

Time scales (typical)

• Drafted → Proposed: minutes (Claude Cowork drafts)
• Proposed → Decided: hours to days (operator review window)
• Decided → Executed: minutes to weeks (depends on scope)
• Executed → Verified: minutes to weeks (depends on smoke + verification scope)
• Verified → Retired: weeks to months to never (some decisions are permanent invariants)

---

Card Templates (5 Common Patterns)

Template 1 — ADR Decision Card

type: adr
title: "ADR-019: Context Cores — Packageable Engagement Bundles"
status: Proposed
context:
  trigger: "TrustGraph external URL surfaced packaging-unit concept; pipeline gap identified"
  source: operator-drop
  research_refs: [doc 22, doc 32 F210 knowledge-node granularity, doc 38 F254 Core archive structure]
  affected_mission_control:
    checklist: [L1.7]
    manifesto: [M1.4]
    matrix: ["Cores × all 8 interfaces"]
options:
  - id: a
    label: "Accept ADR-019 as drafted"
    description: "12-directory archive; 6 lifecycle Missions; Engagement / Vertical / Brand Core types"
    pros: ["13 cross-pipeline surfaces aligned", "Cross-lock with ADR-020 heartbeat", "ADR-022 + ADR-023 block-schema cross-lock compatible"]
    cons: ["Substantial implementation surface", "Storage cost for archive bundles"]
  - id: b
    label: "Defer; capture as research surface"
    description: "Keep doc 22 in research/; revisit when first concrete engagement scoping triggers"
    pros: ["No premature architectural commitment"]
    cons: ["Loses pipeline cross-doc updates already made (5 directory extensions)"]
  - id: c
    label: "Accept but split into 2 ADRs"
    description: "Split Cores primitive from Core lifecycle Missions into ADR-019 + ADR-019b"
    pros: ["Tighter ADR scoping"]
    cons: ["Cross-lock complexity grows; archive structure unchanged"]
recommendation:
  option: a
  rationale: "ADR-019 is broadest cross-cutting commitment in pipeline; deferring loses pipeline momentum + cross-doc work already done"
  confidence: high
decision:
  option: <pending operator review>
audit_chain:
  parent_fact_ids: [<doc 22 commit fact-id>]

Template 2 — Sub-Milestone Decision Card

type: sub-milestone
title: "M3.1 — val-canvas Rust library scaffolding"
status: Executed
context:
  trigger: "ADR-022 Canvas substrate-primitive accepted; M3 substrate-library build-out activated"
  source: pipeline-gap-resolution
  research_refs: [doc 26, ADR-022, M1.5 verified]
  affected_mission_control:
    checklist: [L3.15 (val-canvas library)]
    manifesto: [M3.1]
    matrix: ["Canvas × all 5 known consumer engines"]
options:
  - id: a
    label: "Build val-canvas as standalone Rust library"
    description: "v_source/fusion-engines/libraries/val-canvas/ with 6 layout algorithms + 8 archetypes"
    pros: ["Consistent with library/engine split", "Reusable across val-forge + val-desk + Cores + val-block-renderer + val-ontology"]
    cons: ["Adds to library count (currently 19)"]
  - id: b
    label: "Embed Canvas logic inside val-forge engine"
    description: "Single-engine approach; val-forge owns Canvas authoring directly"
    pros: ["Fewer surfaces"]
    cons: ["Other consumers (val-desk / val-block-renderer / Cores) can't reuse without engine dependency"]
  - id: c
    label: "Defer Canvas substrate implementation"
    description: "Skip M3.1; revisit when first Canvas consumer demands it"
    pros: ["Reduce M3 scope"]
    cons: ["Breaks M3.P substrate-library smoke gate; cascades to M4"]
recommendation:
  option: a
  rationale: "Library/engine split convention; multi-consumer reuse pattern"
  confidence: high
decision:
  option: a
  decided_by: operator
  decided_at: 2026-05-15T10:30:00Z
execution:
  pipeline_branches: ["pipeline/library/2026-05-15-val-canvas"]
  affected_artifacts: ["v_source/fusion-engines/libraries/val-canvas/"]
  outcome_b_facts: [<emitted on smoke green>]
verification:
  smoke_results: <pending>

Template 3 — Strategic Commitment Decision Card

type: strategic-commitment
title: "Business Central as ValOS System of Record"
status: Decided
context:
  trigger: "Operator strategic clarification 2026-05-11 batch 6"
  source: operator-drop (chat)
  research_refs: [doc 38, doc 7 (Microsoft-stack ecosystem)]
  affected_mission_control:
    checklist: [L8.14, L9.1]
    manifesto: [M5 (8 sub-milestones)]
    matrix: ["Business Central SoR × 5 interfaces"]
options:
  - id: a
    label: "Microsoft Dynamics 365 Business Central as SoR"
    description: "Integrate-with Microsoft-stack-aligned ERP; val-cargo MCP bridge"
    pros: ["Microsoft-stack-aligned with Defender/Intune/Entra (6 surfaces total)", "Battle-tested SMB ERP", "Predictable pricing"]
    cons: ["Per-tenant Microsoft licensing cost (~$92/user/month)", "Microsoft-stack dependency at ERP layer"]
  - id: b
    label: "Open-source ERP (Odoo / ERPNext)"
    description: "Self-hostable open-source alternative"
    pros: ["Substrate-ownership at ERP layer", "No per-tenant licensing fees"]
    cons: ["Less SMB-mature than Business Central", "Doesn't align with Microsoft-stack positioning"]
  - id: c
    label: "Build ValOS-native ERP"
    description: "Custom financial GL + invoicing + inventory engine"
    pros: ["Full substrate-ownership"]
    cons: ["ERP is deep CS; not ValOS differentiation; reinventing well-trodden territory"]
recommendation:
  option: a
  rationale: "Microsoft-stack-aligned positioning consistent with Defender (doc 37) + Intune (doc 35) + Entra; per-tenant licensing pass-through commercial model viable"
  confidence: high
decision:
  option: a
  decided_by: operator
  decided_at: 2026-05-11
  rationale: "'business central as our system of record' — direct operator commitment"
audit_chain:
  parent_fact_ids: [<chat fact-id 2026-05-11>]
  child_card_ids: [<future ADR amendments + sub-milestone cards>]
institutional_knowledge:
  cross_vertical_pattern: "Microsoft-stack alignment"
  corroboration_count: 6  # 6 Microsoft surfaces integrated (per doc 38 F251)
  memory_entry: project_business_central_sor.md

Template 4 — Intake Triage Decision Card

type: intake-triage
title: "Tactical RMM URL — research-doc decision"
status: Verified
context:
  trigger: "Operator dropped github.com/amidaware/tacticalrmm URL"
  source: operator-drop (chat)
  research_refs: []  # net-new intake
  affected_mission_control:
    checklist: []  # pre-MC; not yet propagated
    manifesto: []
    matrix: []
options:
  - id: a
    label: "Skip — note in passing"
    description: "Not relevant to ValOS scope"
    pros: ["No doc creation"]
    cons: ["Loses architectural depth signal — NATS protocol alignment"]
  - id: b
    label: "Append to doc 25 (MSP vertical)"
    description: "Add finding to existing doc"
    pros: ["Tight; reuses existing structure"]
    cons: ["Substantive content (NATS protocol + 5 RMM capability dimensions + 8-entity model) doesn't fit append"]
  - id: c
    label: "Spin new research doc"
    description: "doc 35 tactical-rmm-reference-shape-for-msp-rmm.md"
    pros: ["Depth captured", "First MSP-toolstack sibling per F167 protocol"]
    cons: ["Adds to doc count"]
recommendation:
  option: c
  rationale: "NATS architectural alignment is killer fit; warrants depth"
  confidence: high
decision:
  option: c
  decided_by: claude-cowork-with-operator-pattern-confirmation
  decided_at: 2026-05-11
execution:
  affected_artifacts: ["d_mission-control/research/2026-05-11.tactical-rmm-reference-shape-for-msp-rmm.md"]
verification:
  smoke_results: pass  # doc landed; committed; SCP'd
  notes: "Subsequent operator correction (mesh-not-NATS; zerotouch.ai primary) triggered doc 35 rewrite — but original triage outcome (c) verified correct"

Template 5 — Pause-Point Verification Decision Card

type: pause-point
title: "M1.P — Three-way block-schema cross-lock verification"
status: Proposed
context:
  trigger: "M1.5 + M1.6 + M1.7 sub-milestones all completed (3 ADRs accepted)"
  source: milestones-manifesto state-flip
  research_refs: [doc 9, doc 26, doc 31]
  affected_mission_control:
    checklist: [L1.10 + L1.11 (Canvas + Editor substrate primitives)]
    manifesto: [M1.5, M1.6, M1.7 → M1.P → M3 unlocked]
    matrix: ["Canvas × Editor × val-block-renderer block-schema convergence"]
options:
  - id: a
    label: "Verify block-schema written in single canonical location; PASS"
    description: "Block schema spec authored; 3 ADRs reference same spec; schema versioning locked"
    pros: ["M3 substrate-library build-out unlocked"]
    cons: ["Schema versioning discipline required ongoing"]
  - id: b
    label: "Pause — block-schema spec not yet written"
    description: "M1.P fails; halt M3 advancement"
    pros: ["Honors discipline — verification before progression"]
    cons: ["M3 substrate-library build-out delayed"]
  - id: c
    label: "Partial verification — proceed with caveats"
    description: "Some sub-schemas converged; others pending"
    pros: ["Some M3 work unblocked"]
    cons: ["Risks mid-build schema-divergence; expensive rework"]
recommendation:
  option: <pending block-schema spec status>
audit_chain:
  parent_card_ids: [<M1.5 card>, <M1.6 card>, <M1.7 card>]

---

Institutional Knowledge Patterns

Cross-vertical pattern emergence

When 3+ Decision Cards across different scopes share a pattern (per SOUL.md Learning Loop mindset: "don't create a skill the first time something works; wait for the pattern; three observations = candidate skill"):

Example: Reflection-as-consolidation pattern

• Card 1: doc 21 Compound Engineering compound-step extraction
• Card 2: doc 23 Coral heartbeat consolidate-skills trigger
• Card 3: doc 32 K4D reflection step
• Card 4: doc 34 Hivemind annealment loop

Pattern detection: 4 corroborations of "reflection cycles produce consolidated knowledge"

Action: Pattern promoted to ADR-020 (heartbeat watchdog primitive — 3+1=4 corroborations as of card 4)

Memory entry promotion

Cards with institutional_knowledge.memory_entry field set automatically prompt memory update:

• 9 pending memory updates as of 2026-05-12 (per milestones-manifesto M0.4)
• Each memory update is itself a Decision Card (type: memory-update)
• Memory captures cross-card institutional learnings

ADR amendment triggers

When card stream reveals an ADR is operating outside its locked scope:

• Card 1: ADR-019 Cores adoption (Decided / Verified)
• Card 2..N: Multiple cards reference Cores in unexpected ways
• Pattern: ADR-019 scope creep OR ADR-019 understatement
• Action: New ADR-amendment card proposing scope clarification

Failure-pattern recognition

Multiple failure-recovery cards on same root cause:

• Card 1: M3.P fails (val-canvas smoke)
• Card 2: M3.P fails again (val-editor smoke)
• Card 3: M3.P fails (Hocuspocus smoke)
• Pattern: substrate-library smokes systematically failing
• Action: Architectural-failure card promoted to research → reconsider M3 substrate-library approach

---

Decision Card Authority Model

Who drafts, decides, executes, verifies per card type:

Card Type	Drafts	Decides	Executes	Verifies
adr	Claude Cowork	Operator (+ operator-team review)	Claude Cowork (implementation)	Smoke + Inspector
sub-milestone	Claude Cowork	Operator (at pause point)	Claude Cowork + operator-team	Smoke + Inspector
pause-point	Claude Cowork	Operator (mandatory operator gate)	n/a (verification only)	Smoke + Inspector + operator confirmation
strategic-commitment	Operator (originates from chat)	Operator (records to ledger via Claude Cowork capture)	Cascades to multiple cards	Pattern-emergence verification
intake-triage	Claude Cowork	Claude Cowork (with operator pattern-confirmation)	Claude Cowork	Output artifact existence
state-flip	Claude Cowork	Auto (state derived from sub-milestone or ADR state)	Auto	Cross-doc reference consistency
pipeline-branch	val-forge	val-forge	val-forge	Smoke + Inspector + promoter approval
engagement-decision	Operator-team	Operator (or delegate)	Operator-team	Per-engagement metrics
vertical-decision	Operator	Operator	Operator-team + Claude Cowork	First-engagement gate
failure-recovery	Operator-team	Operator	Cascades to new Triggered cards	Re-triage outcome
memory-update	Claude Cowork	Auto (when source card field set)	Claude Cowork	Memory file existence + index update

---

Card Density + Volume Projections

Estimated card volume across 2026-05-11 pipeline + forward build

Source	Card count
16 ADR decisions (2026-05-12 batch)	16
~110 sub-milestones × ~5 killer items each	~550
13 pause points	13
10+ operator strategic commitments (batch 5-6)	10
~50 pre-Mission Control intake triage outcomes (per 40 research docs + 10 appends + 5 skips)	~55
Cross-doc state-flips (estimated 2-3 per sub-milestone)	~250-350
Pipeline branches (~1 per sub-milestone)	~110
Engagement decisions (SBR first; future clients add)	10-50 per engagement
Vertical decisions (per vertical scoping)	5-10 per vertical
Failure-recovery (estimated 5-10% of sub-milestones)	~50-100
Memory updates (9 pending + ongoing)	~20-40

Estimated total card volume (lifetime to v1 production): ~1100-1400 cards.

Storage footprint: ~5-10 MB at YAML serialization (cards average 5-10 KB each).

---

Storage Architecture

File-per-card pattern (recommended)

d_mission-control/ledger/
├── README.md                                          # ledger conventions
├── index.jsonl                                        # one-line-per-card index
├── 2026-05/
│   ├── card-019adr-context-cores.yaml
│   ├── card-007adr-missions.yaml
│   ├── ...
├── 2026-06/
│   ├── card-m31-val-canvas-scaffolding.yaml
│   ├── ...
├── streams/
│   ├── decisions.jsonl                                # terminal-status fact stream
│   ├── in-flight.jsonl                                # in-flight fact stream
│   └── failures.jsonl                                 # failure-recovery fact stream
└── queries/                                           # saved queries for common access patterns
    ├── by-type-adr.md
    ├── by-status-failed.md
    ├── by-vertical-sbr.md
    └── by-affected-manifesto-m4.md

index.jsonl format

{"id":"<SEID>","type":"adr","title":"ADR-019: Context Cores","status":"Proposed","date":"2026-05-12","file":"2026-05/card-019adr-context-cores.yaml"}
{"id":"<SEID>","type":"strategic-commitment","title":"Business Central as SoR","status":"Decided","date":"2026-05-11","file":"2026-05/card-strategic-bc-sor.yaml"}
...

Fact stream format (decisions.jsonl)

{"id":"<SEID>","subject":"valos.mc.decision.adr.decided.adr-019","payload":{...full card snapshot...},"timestamp":"2026-05-15T10:30:00Z"}
{"id":"<SEID>","subject":"valos.mc.decision.strategic-commitment.decided.business-central-sor","payload":{...},"timestamp":"2026-05-11T15:45:00Z"}
...

Query patterns (operator + Claude Cowork)

Query	Pattern
"Why did we decide X?"	grep index.jsonl for title; open card file; read rationale + alternatives
"All cards affecting M4"	filter index.jsonl by affected_mission_control.manifesto contains M4
"All cards from operator strategic-commitment batch"	filter by type + date range
"Failed cards last quarter"	filter by status=Failed + date range
"Cards forming pattern X"	filter by institutional_knowledge.cross_vertical_pattern
"Cards with confidence=low"	filter by recommendation.confidence for potential re-review

---

Cross-Cuts to ValOS Substrate

val-ledger b_fact emission

Per AGENTS.md Non-Negotiable + Pulse Lifecycle Path 2:

• Every Decision Card terminal-status flip → b_fact emitted to valos.mc.decision.<...> subject
• b_fact carries stable_entity_id (card SEID) + parent_fact_ids chain
• val-ledger registry persists for forever-retention

val-ontology entity

Master Decision Cards are val-ontology entities (per locked storage routing):

• Entity kind: MasterDecisionCard
• Edges: affected_artifact → engines/libraries/blueprints; references → research docs / ADRs / rules; parent_card → audit chain
• Components: from Decision Card schema fields (status / type / title / context / etc.)
• Dimensions: trust / provenance / sensitivity per locked dimensions layer

Engagement Cores integration

Per ADR-019 Context Cores design:

• Per-engagement Decision Cards bundle into Engagement Core decisions/ directory (13th Core archive directory addition)
• Cores transferable across deployments preserve institutional knowledge
• Vertical Cores accrete cross-engagement Decision Card patterns

Update ADR-019 Core archive structure to add decisions/ directory:

core.engagement.<client>.<engagement>.v<version>.zip
├── manifest.json
├── ontology/
├── embeddings/
├── facts/
├── policies/
├── provenance/
├── canvases/                 (per doc 26 R158)
├── knowledge-nodes/          (per doc 33 R203)
├── backup-state/             (per doc 36 F247)
├── mdr-state/                (per doc 37 F247)
├── bc-references/            (per doc 38 F254)
├── password-mgmt-state/      (per doc 39 F260)
├── psa-state/                (per doc 40 F271)
└── decisions/                ← NEW (this spec)
    ├── decision-card-001.yaml
    ├── decision-card-002.yaml
    └── ...

Core archive structure total: 13 directories (was 12; decisions added).

Knowledge nodes synthesis

Per doc 32 F210 knowledge-node granularity hierarchy:

• Cross-card pattern detection → synthesized knowledge node
• Knowledge node represents distilled institutional learning
• Cores carry knowledge nodes alongside Decision Cards
• Background-curation Missions (per doc 32 F202) maintain knowledge-node accretion

Heartbeat watchdog cross-cut (per ADR-020)

Long-running Missions can be Decision Cards (type: sub-milestone with extended execution):

• Heartbeat trigger fires reflection on Decision Card progress
• Pattern detection across heartbeat-emitted cards reveals stuck-state OR plateau
• Plateau trigger fires escalation Decision Card (type: failure-recovery if stuck)

Compounding-knowledge integration (per doc 34 F228)

Per Problem-Solving base blueprint three-tier knowledge accretion:

• Tier 1: per-run b_facts (Decision Card execution outcomes)
• Tier 2: knowledge-nodes (cross-card synthesized insights)
• Tier 3: Engagement Cores (per-engagement decision-card history bundle)

---

Examples — Concrete 2026-05-11 Pipeline Decisions

Example A: 16 ADR Decisions (2026-05-12 batch)

Each ADR draft = 1 Decision Card. 16 cards in Proposed status as of 2026-05-12.

When operator-team reviews + accepts each, status flips to Decided. Execution flips to Executed when implementation begins. Verified when smoke green.

Card-stream pattern: high-density ADR decision cluster reveals architectural-pause moment + substantive forward-build commitment.

Example B: Operator Strategic Commitments (Batch 5-6)

10+ commitments captured durably:

1. Business Central as SoR (doc 38)
2. zerotouch.ai as RMM reference (doc 35)
3. Mesh-default + NATS-on-prem transport (doc 35 F234)
4. MDR via Microsoft Defender for Business (doc 37)
5. VPS / DNS / Web Hosting (val-host engine candidate)
6. Voice / Comms own provider + carrier partner (val-switch)
7. Bitwarden / Vaultwarden for password management (doc 39)
8. Kopia + Duplicati both for backups (doc 36)
9. val-track first-party engine (work-tracking — doc 30)
10. Microsoft-stack-aligned positioning (6 surfaces — doc 38 F251)

10 Decision Cards with status Decided + corresponding child_card_ids cascading to multiple sub-milestones, ADRs, and pipeline branches.

Example C: Pre-Mission Control Triage (40 Research Docs)

40 research docs × 1 intake-triage card each = 40 intake-triage Decision Cards. Each card captures the 4-outcome triage (a/b/c/d) + recommendation + decision + outcome.

Card-stream pattern: outcome (c) "new research doc" most common (40 of 40 in this case; pipeline-batch convention); outcome (d) "new spec / ADR" surfaced 16 ADRs from research.

Example D: Failure-Recovery (Doc 35 Rewrite)

doc 35 originally framed Tactical RMM as primary RMM reference + NATS as killer architectural fit. Operator corrected 2026-05-11:

1. zerotouch.ai is the RMM reference
2. mesh transport not NATS unless on-prem

Failure-recovery card spawned: original framing invalidated; doc 35 rewritten.

Card audit chain shows: original intake-triage card (outcome c new doc) → research-doc card (doc 35 first draft) → failure-recovery card (operator corrections) → re-framed research-doc card (doc 35 rewrite).

Institutional knowledge insight: even strong-signal research can be wrong-direction; operator corrections are first-class data. Pattern surfaces "early-framing fidelity" as a learning loop candidate.

Example E: Memory Updates (9 Pending)

9 memory entries pending as of 2026-05-12 (per M0.4 milestone):

Each pending memory entry = 1 type: memory-update Decision Card in Drafted status.

When operator-team applies the memory updates (or Claude Cowork commits them):

• Card flips Drafted → Decided → Executed → Verified
• memory file exists + indexed in MEMORY.md
• Verification: memory file present in operator memory directory

---

Implementation Phases (Pipeline Mapping)

This spec drives pipeline-branch work per ADE Factory Pipeline (per mission-control-operating-protocol.md):

Phase 1: Schema + Ledger Setup (Pre-Mission Control supporting infrastructure)

• Create d_mission-control/ledger/ directory structure
• Author d_mission-control/ledger/README.md with conventions
• Define YAML schema validator (val-fab capability)
• Implement index.jsonl auto-maintenance
• Create 5 template files

Phase 2: Existing-Decision Backfill (institutional knowledge from pipeline batch 1-5)

• 16 ADR backfill cards (status Proposed)
• 10 operator strategic-commitment cards (status Decided)
• 40 intake-triage cards (status Verified)
• ~5 failure-recovery cards (Doc 35 rewrite, Doc 26 capability-vs-substrate-primitive, etc.)

Phase 3: Forward-Card Generation (going forward from 2026-05-12)

• Card-emission discipline locked in mission-control-operating-protocol
• Every state flip → card
• Every pipeline branch → card
• Every operator commitment → card

Phase 4: Fact-Stream Integration (val-ledger emission)

• Decision Card → b_fact emission protocol
• Fact subject pattern locked (valos.mc.decision.<type>.<state>.<short-id>)
• Replay capability verified

Phase 5: Query + Pattern-Detection (institutional knowledge queries)

• CLI queries for common patterns
• Cross-card pattern detection (3+ corroborations → candidate skill)
• Operator-team dashboard for ledger browsing

Phase 6: Engagement Core integration (per ADR-019)

• decisions/ directory added to Core archive (13th directory)
• Decision Cards bundled into Engagement Core per mission.core.build.v1
• Cross-engagement card-pattern detection via Vertical Cores

---

Discipline Principles

1. Every action item is a card. No undocumented decisions.
2. Cards are append-only. Coral growth pattern; never overwrite.
3. State flips emit facts. Card terminal-status changes → val-ledger b_fact emit.
4. Audit chains preserve. parent_card_ids + parent_fact_ids form lineage.
5. Operator gates explicit. Strategic-commitment + pause-point + vertical-decision cards require operator signoff.
6. Confidence captured. Recommendation field includes confidence level (per pipeline confidence-gating pattern — 8 corroborations).
7. Pattern emergence honored. 3+ similar cards → learning-loop candidate per SOUL.md Learning Loop mindset.
8. Cards die only when retired. Even Failed cards stay in ledger (visible failure history is institutional knowledge).
9. Cross-doc state propagation traceable. Every state-flip card references affected MC docs explicitly.
10. Institutional knowledge grows like coral. Cards accrete additively; old cards remain valid; pattern detection surfaces emergent insights.

---

Cadence

Frequency	Activity
Per pipeline-batch commit	Generate cards for every change in the batch; update ledger index
Per pause-point verification	Emit verification card (Proposed → Decided per outcome)
Per ADR review	Card per ADR (16 currently Proposed)
Per operator strategic commitment	Card immediately upon commitment recording
Daily (in active build phase)	Card audit: any in-flight cards stalled? Any verifications overdue?
Weekly	Cross-card pattern detection scan; institutional knowledge review
Monthly	Failure-pattern analysis; ADR-amendment candidates surfaced
Quarterly	Ledger health check; index reconciliation; archive policies

---

References

Doc	Purpose
vertical-fusion-checklist.md	Mission Control current-state inventory (16 layers)
milestones-manifesto.md	Mission Control forward-build sequencing (13 × 110 × 13 gates)
fusion-layer-integration-matrix.md	Mission Control cross-cutting matrix
mission-control-operating-protocol.md	Mission Control operating model (Pre-Funnel → MC → ADE Factory → Execution → Feedback)
adr-019-context-cores.md	Cores archive structure extended with decisions/ directory
adr-020-heartbeat-watchdog.md	Heartbeat triggers consolidation across long-running Decision Cards
v_platform/PLATFORM.md	Decision Card primitive (Part 2 Master Checklist) + val-ledger + Pulse Lifecycle + auto-close fact loop
v_platform/SOUL.md	Three-class fact taxonomy (b_fact / s_fact / l_fact) + Non-Negotiables (#9 SEID atomic universal; #11 nothing hardcoded) + Mindsets (Learning Loop + Caveman + OODA + Checklist Manifesto)
v_platform/AGENTS.md	Autonomy gates + Caveman tiers
CLAUDE.md	Cowork dev rules + repo layout + val-forge ephemeral pipeline branches
16 ADRs (d_mission-control/specs/adr-NNN-*.md)	Each ADR = 1 Decision Card
40 research docs (d_mission-control/research/2026-05-11.*.md)	Each = 1 intake-triage Decision Card
Memory (C:\Users\ClydeNelsen\.claude\projects\...\memory\)	9+ pending memory-update Decision Cards
baseline-coral.jsonl	Append-only probe history (parallel pattern to Decision Card ledger fact stream)
doc 32 F210 knowledge-node granularity	Cross-card pattern → knowledge node synthesis
doc 34 F228 compounding knowledge	Three-tier accretion (b_fact + knowledge-nodes + Cores)

---

Closing — Institutional Knowledge as First-Class Substrate

Why this primitive matters:

ValOS engagement-team turnover happens. Operator team grows + changes. Claude Cowork sessions are ephemeral. Without institutional knowledge captured durably, every decision rationale dies with the next context-window expiry or team change.

Master Decision Cards solve this:

• Every architectural decision survives.
• Every operator strategic commitment captures rationale + alternatives + audit chain.
• Every sub-milestone outcome — success or failure — feeds pattern detection.
• Cross-engagement institutional knowledge accretes across years.
• 3+ years from now, querying "why did we decide Business Central as SoR" returns the original card with full context — operator quote + alternatives considered + recommendation rationale + execution + verification.

The ledger is ValOS's organizational memory. Cards are the atoms; the ledger is the substrate; the fact stream is the timeline; the knowledge nodes are the synthesized wisdom; the Engagement Cores carry it across deployments.

Mission Control orchestration becomes durable. ValOS's own substrate-primitive pattern applies to ValOS's own institutional knowledge: same coral growth + same provenance + same OODA-driven accretion.

This was the original purpose of d_mission-control/. The Master Decision Card primitive makes it permanent.

---

Master Decision Card Spec — institutional knowledge primitive. Mission Control Ledger + Fact Stream. Cowork-side composition. 2026-05-12. Cards accrete; institutional knowledge grows like coral.