ℹ Status (2026-06-14). This Mission OS arc (M0–M9) is complete and is folded into CANONICAL_ORGANIZATION_OS_ROADMAP.md as Phase 0. That FINAL document is the canonical roadmap for the whole organization and supersedes this one. This file is retained only as the detailed pass-level record of the now-complete Mission OS foundation; consult the FINAL roadmap for current direction.

Document Type: Canonical Roadmap. Classification: Implementation Arc of the Operating System of Execution. Descends from CANONICAL_00 and from CANONICAL_MISSION_OS_DOCTRINE_V1.

This roadmap defines the arc by which Mission OS is brought into being inside AAF Holdings. It is governed by the Mission OS Doctrine: where the doctrine defines what is permanently true, this roadmap defines the sequence in which those truths are made real. It is architectural, not technical — it names passes, dependencies, risks, milestones, acceptance criteria, and the shape of future evolution. It does not describe implementation, interfaces, storage, services, or components; those are decided within each pass, under the doctrine, and may change without amending this document.

The roadmap is written to survive its own completion. Long after Mission OS v1 exists, this document should remain legible as the record of why the system was built in this order, what each pass depended on, and what was deliberately deferred — so that future operators extending Mission OS inherit the reasoning, not only the result.

PURPOSE AND PRINCIPLES OF THE ROLLOUT

Mission OS is introduced into a living organization that already executes. The rollout therefore obeys five principles:

Additive, never disruptive. Every pass adds the mission as the parent of work; no pass removes or rewrites the execution machinery that already runs. The organization keeps operating throughout.
Compose, never duplicate. Each pass integrates with an existing system — the Executive Router, Registry, Briefing Loader, Session Manager, the governance filesystem, the promotion loop — and adds only the belonging-to-a-mission those systems lack.
Govern before you scale. The governance of a mission (approval, ownership, state, traceability) is built before the volume of missions grows, so the organization never scales chaos.
Filesystem-first, doctrine-shaped. The mission record is established as governed organizational content before any heavier representation is considered, consistent with the principle that files are the source of truth.
Outcomes prove passes. Each pass is accepted on an observable organizational outcome — a mission can be approved, a report can be traced, an asset can be found — never on the existence of machinery.

THE CURRENT FOUNDATION

Mission OS is not built on bare ground. The following already exist and are the substrate every pass composes with:

The governance filesystem — canonical doctrine, constitutions, doctrine, roadmaps, templates, and assets, with managed creation and reading. This is where missions will live.
The Executive Registry — the source of truth for which executive offices exist and which are active.
The Executive Router — classifies an instruction and selects the office that owns the work, with approval-gated proposals for unstaffed offices.
The Briefing Loader — assembles an office's constitution, constraints, and report requirement into the context a session runs under.
The Session Manager — launches and supervises the temporary reasoning sessions that execute work.
The promotion loop, Hermes, Honcho, MemPalace — the knowledge architecture that preserves and elevates what work produces.
HQ01 — the operational headquarters surface.

Mission OS adds the layer above all of these: the mission as the governed parent that gives the work a reason, an owner, and a destiny in doctrine.

THE ARC IN BRIEF

The passes group into four milestones, each an observable change in how the organization operates:

Milestone A — Missions Exist (Passes M0–M1): a mission can be proposed, approved, and moved through its governed states.
Milestone B — Missions Execute (Passes M2–M4): missions decompose into objectives, bind real execution, and produce fully traceable reports.
Milestone C — Missions Compound (Passes M5–M7): missions own assets, are steered by their governance instruments, and close by promoting doctrine.
Milestone D — Missions Govern HQ01 (Passes M8–M9): HQ01 becomes Mission Control and the boundaries with every other operating system are made explicit.

The arc is strictly ordered by dependency: governance before execution, execution before compounding, compounding before the organization is re-centered on missions.

THE PASSES

Pass M0 — Mission Anatomy and Registry

Objective. Establish the mission as a governed organizational record with a permanent identity.

Scope. Define the canonical anatomy of a mission (Doctrine, Book III) as the shape every mission record carries. Establish a filesystem-first registry of missions with immutable Mission IDs that are never reused, and an append-only history for each mission. Establish that a record without complete anatomy is a Draft, not a mission.

Integrates with. The governance filesystem (missions live as governed content); the Executive Registry (owners and supporters are named by existing office identities).

Dependencies. The governance filesystem; the Executive Registry.

Risks. Premature richness — over-specifying the record before missions are run; mitigated by holding to the doctrine's anatomy and nothing more. Identity collision — mitigated by an immutable, never-reused ID scheme.

Acceptance criteria. A mission can be authored with full anatomy; it has a permanent ID; its history is append-only; an incomplete record is recognizably a Draft.

Milestone. A (Missions Exist).

Pass M1 — Mission Lifecycle and States

Objective. Make a mission a governed, gated lifecycle rather than a static record.

Scope. Implement the state set (Draft, Proposed, Approved, Planning, Active, Blocked, Review, Completed, Archived, Cancelled) and the transitions between them as governed acts. Enforce the two inviolable gates: no execution without CEO approval, no completion without met success criteria. Every transition records its authority and reason to the append-only history.

Integrates with. Governance OS (approval authority); the Executive Registry (the owning office).

Dependencies. Pass M0.

Risks. Gate bypass — an execution path that skips approval; mitigated by making the approval gate structural, not advisory. State drift — records whose state no longer matches reality; mitigated by transitions being the only way state changes, always recorded.

Acceptance criteria. A mission moves Proposed → Approved only by the CEO (or explicitly delegated authority); a mission cannot reach Completed without its success criteria; every transition is in the history with actor and reason.

Milestone. A (Missions Exist).

Pass M2 — Objectives

Objective. Introduce the objective as the measurable outcome layer between mission and work.

Scope. Establish objectives as outcomes (not work orders), each independently verifiable. Establish that objectives create work orders and that mission completion is the completion of its objectives' outcomes. Bind each objective to its mission and to the office accountable for it.

Integrates with. The Executive Registry (objective ownership); the universal execution model (objectives head the work).

Dependencies. Passes M0–M1.

Risks. Objective–work-order confusion — objectives written as activities; mitigated by requiring every objective to be stated as an observable outcome. Over-decomposition — too many trivial objectives; mitigated by the principle that an objective must be meaningful enough to matter and small enough to own.

Acceptance criteria. A mission carries objectives stated as outcomes; an objective can be completed independently; mission completion is computed from objective completion, not from work volume.

Milestone. B (Missions Execute).

Pass M3 — Mission Binding of Execution

Objective. Bind the existing execution chain to missions and objectives, so that all work executes on behalf of a mission.

Scope. Ensure that work orders, assignments, and sessions each carry their mission and objective lineage. Compose the Executive Router so that routing occurs on behalf of a mission and an authorized office (owner or supporter). Compose the Briefing Loader so that the mission context — mission, objective, owner, constraints — is part of every briefing. Compose the Session Manager so that every session belongs to a mission. Preserve the raw, mission-less use of these systems for exploratory work, while establishing that governed work belongs to a mission.

Integrates with. Executive Router, Briefing Loader, Session Manager.

Dependencies. Passes M0–M2; the existing router/briefing/session foundation.

Risks. Coupling — entangling Mission OS with the internals of the execution systems; mitigated by adding only the lineage link and never absorbing their responsibilities. Orphan work — sessions launched outside any mission; mitigated by making mission-bound dispatch the governed default while preserving an explicit, visible exploratory mode.

Acceptance criteria. A dispatched governed session names its mission and objective; a briefing carries mission context; the raw Session Manager still functions for exploratory use; no governed work is unattributable to a mission.

Milestone. B (Missions Execute).

Pass M4 — Reporting and Traceability

Objective. Make every report carry its full lineage and make traceability bidirectional and gapless.

Scope. Establish that every report references its mission, objective, work order, assignment, session, produced assets, recommendations, and doctrine candidates. Establish ascent (from any report to its mission) and descent (from any mission to all its reports) as guaranteed properties.

Integrates with. The reflection/promotion intake (recommendations and doctrine candidates flow onward); Knowledge OS.

Dependencies. Passes M0–M3.

Risks. The orphan report — work returned without lineage; mitigated by treating a lineage-less report as a recognized defect. Thin reports — returns of "done" with no recommendations or candidates; mitigated by the doctrine that a report's recommendations and candidates are required, not optional.

Acceptance criteria. From any report the mission can be named; from any mission every report can be enumerated; reports carry recommendations and doctrine candidates, not only completion.

Milestone. B (Missions Execute).

Pass M5 — The Asset Ledger

Objective. Make missions the accountable owners of the durable artifacts they produce.

Scope. Establish that every durable artifact a mission produces is registered as an asset of that mission, with exactly one originating mission. Establish that assets survive mission completion and remain available to the organization. Define the link between a mission's asset and its single home in the knowledge architecture, without duplicating storage or curation.

Integrates with. Knowledge OS and MemPalace (storage, curation, retrieval); the governance filesystem (where document-class assets live).

Dependencies. Passes M0–M4.

Risks. Duplication of Knowledge OS — Mission OS storing or curating assets; mitigated by Mission OS owning only the origin link, never the storage. Lost assets — durable artifacts never registered; mitigated by making asset registration part of the report's required return.

Acceptance criteria. Every durable artifact names its originating mission; assets persist after archive; an asset has one origin and one knowledge-architecture home, with a permanent link between them.

Milestone. C (Missions Compound).

Pass M6 — Governance Instruments: Risks, Decisions, Dependencies, KPIs

Objective. Give missions the instruments by which they are steered, bounded, and judged.

Scope. Establish risks (with severity and safety-class halting), decisions (with recorded reasons and authors), dependencies (the edges of the mission graph), and KPIs (measuring change, not effort) as first-class elements of a mission. Establish the Blocked state's grounding in unmet dependencies and unresolved risks, and the escalation of safety-class risks outside the normal path.

Integrates with. Governance OS (authority and recorded reasons); the escalation paths of Organization OS.

Dependencies. Passes M0–M2 (for state and ownership); benefits from M3–M4.

Risks. Instrument theater — risks and KPIs recorded but never used to steer; mitigated by binding them to real transitions (Blocked, escalation) and to mission review. Dependency cycles — mitigated by treating dependencies as a graph whose cycles are detectable defects.

Acceptance criteria. A mission can enter Blocked on a named dependency or risk; safety-class risks halt and escalate; decisions are recorded with reasons; KPIs measure outcome against success criteria.

Milestone. C (Missions Compound).

Pass M7 — Review, Completion, Archive, and Doctrine Promotion

Objective. Close the mission loop so that a completed mission leaves the organization permanently more capable.

Scope. Establish mission review against objectives and success criteria (outcomes, not effort); the governed completion act; the archive that confirms preservation of assets and entry of doctrine candidates into the pipeline; and the connection of mission closure to the promotion loop of CANONICAL_00, so that a mission's proven learning rises to ratified doctrine.

Integrates with. The promotion loop, Honcho (reflection), MemPalace (archive), Doctrine (ratified truth).

Dependencies. Passes M0–M6.

Risks. Completion-by-fatigue — declaring missions complete by effort rather than outcome; mitigated by review measuring success criteria only. Lost learning — archiving without promoting; mitigated by making doctrine-candidate intake a required step of archive.

Acceptance criteria. A mission completes only on met criteria; archive confirms asset preservation and doctrine-candidate intake; a completed mission's candidates are in the promotion pipeline; the mission's history is closed and append-only.

Milestone. C (Missions Compound).

Pass M8 — HQ01 as Mission Control

Objective. Re-center HQ01 on missions as its primary organizing principle.

Scope. Make the portfolio of missions the primary surface of HQ01, with each mission exposing status, progress against objectives, risks, executive owner, recent reports, and produced assets. Preserve sessions, executives, and the rest as the machinery beneath, reachable by descent from a mission but no longer the organizing principle.

Integrates with. HQ01 (Book IX of CANONICAL_00) and every prior pass (the data Mission Control surfaces).

Dependencies. Passes M0–M7.

Risks. Re-centering as cosmetics — a missions view that does not actually change how the company is operated; mitigated by making the mission the true entry point to all detail. Premature re-centering — building Mission Control before missions carry real data; mitigated by its position late in the arc.

Acceptance criteria. HQ01's primary view is Missions; each mission exposes the required elements; all execution detail is reachable by descent from a mission.

Milestone. D (Missions Govern HQ01).

Pass M9 — Cross-OS Orchestration Boundaries

Objective. Make explicit and enforce the boundaries between Mission OS and every other operating system, so that no responsibility is held in two places.

Scope. Formalize the relationships defined in the doctrine (Book XIV) with Organization, Development, Knowledge, Governance, Commerce, Runtime, Identity, and Agent OS. Establish that Mission OS orchestrates and composes, never duplicates, and that any place it does the work of another OS is a defect to be corrected.

Integrates with. All eight operating systems.

Dependencies. Passes M0–M8.

Risks. Silent duplication — Mission OS slowly absorbing a neighbor's responsibility; mitigated by an explicit boundary statement per OS and periodic boundary review. Separation breach — a mission reaching across the Platform/Holdings separation; mitigated by treating such reach as halt-class, per CANONICAL_00.

Acceptance criteria. Each of the eight boundaries is stated and observed; no responsibility is duplicated; the Separation and Isolation Laws are never crossed by a mission.

Milestone. D (Missions Govern HQ01).

CROSS-CUTTING RISKS

These risks span the whole arc and are managed continuously, not in a single pass:

The orphan. Work, assets, or reports that belong to no mission. Managed by making mission-belonging the governed default at every layer and treating orphans as recognized defects.
Duplication of a neighbor OS. Mission OS slowly reimplementing storage, identity, building, or operation. Managed by the compose-never-duplicate principle and the explicit boundaries of Pass M9.
Governance bypass. Execution that skips approval or completion that skips criteria. Managed by making the two inviolable gates structural rather than advisory.
Activity mistaken for outcome. Missions judged by effort. Managed by objectives-as-outcomes and review-against-criteria throughout.
Premature scale. Growing the volume of missions before their governance is sound. Managed by the strict milestone ordering: govern, then execute, then compound, then re-center.
Unauthenticated exposure of governed action. Surfacing mission approval, dispatch, or destructive action without access control. Managed as a standing infrastructure obligation, independent of Mission OS's own passes.

MILESTONES AND ACCEPTANCE OF MISSION OS V1

Milestone A — Missions Exist. A mission can be proposed and approved and moves through governed states with recorded history.
Milestone B — Missions Execute. Missions decompose into objectives, bind the existing execution chain, and produce fully traceable reports.
Milestone C — Missions Compound. Missions own assets, are steered by their governance instruments, and close by promoting doctrine.
Milestone D — Missions Govern HQ01. HQ01 is Mission Control and every OS boundary is explicit and observed.

Mission OS v1 is accepted when all of the following are observably true:

Every governed unit of work in the organization traces to a mission, and from any work the mission can be named.
No mission executes without approval, and none completes without meeting its success criteria.
Every report carries its full lineage, recommendations, and doctrine candidates, and traceability is bidirectional and gapless.
Every durable artifact is registered as an asset of its originating mission and survives the mission's archive.
Completed missions promote doctrine through the existing promotion loop.
HQ01's primary surface is Missions, with all detail reachable by descent.
Mission OS composes the other operating systems without duplicating any responsibility, and never crosses the Separation or Isolation Laws.

FUTURE EVOLUTION

Mission OS v1 establishes the spine; the decades that follow elaborate it. The roadmap anticipates, without committing to, the following directions, each of which must be built under the doctrine and across governed boundaries:

Portfolio governance. Planning, sequencing, and capital allocation across the full set of missions as a portfolio, on the Executive Council's cadence — strategy made to become missions, and missions reviewed against outcomes at scale.
Multi-company missions. Missions that span more than one company in the holding structure, with ownership and boundaries that respect each company's charter while sharing inherited intelligence.
The mission graph. Treating dependencies, assets, and promoted doctrine as a navigable graph, so the organization can reason about how its changes relate, which assets are most inherited, and where its doctrine came from.
Predictive and assisted routing of missions. Smarter selection of owning and supporting offices and smarter decomposition into objectives, introduced behind the existing interfaces without changing the governance.
Governed autonomous proposal. The organization proposing missions to the CEO from its own observed signals — always as proposals into the approval gate, never as self-approved execution, preserving the inviolable rule that intent is committed only by the CEO.
Inheritance acceleration. Making the start of a new mission ever more an act of inheritance — composing existing assets and doctrine — and ever less an act of construction, which is the long-term purpose the whole system serves.

Each evolution is subordinate to the Permanent Laws of Mission OS. A future capability that cannot locate itself within those laws is out of scope or in error.

CANONICAL_MISSION_OS_ROADMAP_V1. The implementation arc of the operating system of execution. Descends from CANONICAL_00 and the Mission OS Doctrine. Architectural, not technical. Amendable by the CEO through the governance process. Governing the rollout until amended or completed.

root · /srv/aaf