Document Type: Canonical Roadmap. Classification: The permanent implementation arc of the AAF Holdings Organization Operating System. Descends from CANONICAL_00, AAF_CONSTITUTION_V5-1, CANONICAL_MISSION_OS_DOCTRINE_V1. Folds CANONICAL_MISSION_OS_ROADMAP_V1 in as Phase 0 and supersedes every prior Organization OS roadmap draft.

This is the definitive roadmap by which AAF Holdings becomes a living organization that operates itself. It is written for organizational permanence, not implementation convenience: it must remain valid for years, across model generations and vendor changes, because it describes how the organization is structured — not how any technology of the moment is wired. It is architectural only. No code, no implementation, no database, no UI, no API; each pass decides those within itself, under the doctrine, and may change without amending this document.

Source-of-truth priority: (1) Organization Doctrine → (2) Mission Doctrine → (3) the implemented Mission OS → (4) prior roadmap. Where they conflict, doctrine always wins.

1 · EXECUTIVE SUMMARY

Mission OS is complete through HQ01 Mission Control and becomes Phase 0 — foundational, not to be redesigned, rewritten, or removed. The audit found exactly one structural defect: assignments are owned by the executive, but doctrine (CANONICAL_00 §270) requires them to be owned by a manager. This roadmap corrects that by inserting the Manager layer — additively — and then builds the remaining organism: the Executive Office as the unit of organization, the Manager as the compression layer that makes scale possible, the single-runtime intelligence architecture (Hermes / MemPalace / Honcho through LiteLLM, observed by Langfuse), Serena as code infrastructure, and the closed learning loop that lets organizational intelligence compound independently of any AI vendor.

The permanent design choices that make this roadmap durable:

There is no Department object. The Executive Office is the department; each Executive Office defines its own managers. Manager types are never hardcoded — they are owned entirely by the executive.
Managers are the compression layer. Workers execute; managers compress worker output into manager intelligence; executives consume manager intelligence; the organization compounds executive intelligence. This is what lets one CEO operate thousands of workers without context collapse.
AI models own nothing. Identity, work, evidence, reflection, current state, memory, and truth are all owned by organizational roles and runtimes. The model is disposable labor. Replace the model and the organization is unchanged.

The arc is four phases: Phase 0 Mission OS (done) → Phase 1 the Executive→Manager correction → Phase 2 the intelligence runtime → Phase 3 the living organization.

2 · FINAL ORGANIZATION HIERARCHY

CEO (Human)
  ↓ intent
External COO — IVAN
  ↓ coordinated motion
HQ01 Router
  ↓ classification
Executive Office        — the department; owns mission, strategy, architecture; defines its managers
  ↓ objective
Manager                 — persistent office; owns work, assignments, validation, acceptance; LEARNS
  ↓ assignment
Worker Template         — permanent, evolving definition (posture, tools, patterns, Hermes state)
  ↓ instantiation
Worker Instance         — ephemeral; one assignment; one report; terminates; owns no memory
  ↓ output
Report                  — owns evidence; full lineage
  ↓ exhaust
Honcho                  — reflection; reviews and recommends; edits nothing
  ↓ recommendation
Hermes                  — current organizational state; one runtime; always loaded; small
  ↓ promotion
MemPalace               — institutional memory; one runtime; organization-owned; searched, never fully loaded
  ↓ ratification
Doctrine                — permanent truth

Two cross-cutting runtimes sit beside this spine:

LiteLLM — the organizational model gateway (background intelligence routes through it; Claude CLI remains the execution engine).
Langfuse — observability over LiteLLM.
Serena — code intelligence infrastructure (indexing, navigation, precise edits); a worker tool, not organizational intelligence.

3 · PERMANENT LAWS

These are the laws every pass, every office, and every future operator is tested against. A capability that cannot locate itself within them is out of scope or in error.

Organizations own intelligence. Not workers, not models.
Executives own missions. They direct, decide, route, prioritize, accept, and communicate — they never assign work to workers and never review worker output individually.
Managers own work. Planning, assignments, orchestration, validation, acceptance, aggregation. Managers are persistent and they learn.
Workers own execution. One assignment, one report, then termination. No persistence, no memory.
Worker Templates are permanent and evolve. Instances inherit from them and die.
Reports own evidence. Work without a lineage-bearing report did not happen.
Honcho owns reflection. It recommends; it never edits organizational state.
Hermes owns current organizational state. Small, always loaded, present-tense.
MemPalace owns institutional memory. Organization-owned, append-only, searched not loaded.
Doctrine owns permanent truth. Proven learning ratified into law.
There is no Department object. Executive Offices are the departments; managers are defined by the executive, never hardcoded.
AI models own NOTHING. The organization's intelligence compounds independently of any vendor; replacing the model changes nothing the organization owns.

4 · OWNERSHIP MODEL

The Executive Office (the unit of organization — replaces any notion of Department)

Every Executive Office owns:

Executive Constitution — its charter, authority, and boundaries.
Executive Hermes — its current-state profile (owner type: Executive Office).
Managers — its roster of persistent manager offices, defined by it, open-ended, never a hardcoded type set.
Worker Templates — the versioned definitions its managers instantiate.
Skills, Tools, Metrics, Knowledge — its capability surface, its KPIs, and its scoped knowledge.

Examples (illustrative, never enumerated in code): Engineering Executive → Backend / Frontend / Database / QA / Documentation managers. Marketing Executive → Content / SEO / Campaign / Analytics managers. Finance Executive → Revenue / Forecast / Billing managers. Each executive owns a different roster.

Role ownership table

Role	Owns	Never
Executive Office	mission, strategy, architecture, manager roster, prioritization, mission acceptance, executive comms	assigns work to workers; reviews individual worker output
Manager	planning, assignment creation, worker orchestration, validation, acceptance, report aggregation, manager comms	executes assignments; persists nothing learned as private property
Worker Template	default execution posture, preferred tools, preferred patterns, Hermes state	executes (only its instances do)
Worker Instance	execution of one assignment, one report	persistence, memory, intelligence
Report	evidence and lineage	decisions
Honcho	reflection, recommendations	editing state, executing, storing memory
Hermes	current state	history, archive
MemPalace	institutional memory (organization-owned)	being fully loaded; being owned by any office
Doctrine	permanent truth	being set by anything but ratified promotion

5 · INTELLIGENCE MODEL

Worker Instance   — raw execution output (high volume, low compression)
      ↓ compressed by
Manager           — turns many worker reports into one manager-level outcome + lessons
      ↓ consumed by
Executive Office  — consumes manager intelligence, never raw worker output
      ↓ compounded by
Organization      — compounds executive intelligence into doctrine

Managers compress worker intelligence. This is their defining organizational function and the reason they are required: an executive cannot read ten thousand worker reports, but it can consume the manager-level compression of them.
Executives consume manager intelligence, not worker mechanics.
The organization compounds executive intelligence into permanent doctrine.
Purpose: minimize context usage and maximize scalability. Compression at each tier is what allows one human CEO to operate the whole organism without drift.

The three intelligence runtimes are distinct and never substitute for one another:

Hermes = the present (current state, always loaded, small).
MemPalace = the past (institutional memory, searched).
Honcho = reflection (recommends movement between the two and into doctrine; edits nothing).
Doctrine = permanent truth.

6 · LEARNING MODEL

The organization learns through one disciplined channel, so intelligence accumulates without bloating context:

Worker executes → Report (evidence)
      → Manager validates, accepts, aggregates → manager learns (Hermes manager profile gains current lessons)
      → Executive consumes aggregated outcome → executive learns (Hermes executive profile updates)
      → Honcho reflects over executive + manager + report + assignment activity
      → Honcho recommends:  Hermes updates  |  MemPalace promotions  |  Doctrine candidates
      → Governed evaluation + safety audit → ratified Doctrine
      → Worker Templates evolve from proven patterns

What learns and how:

Worker Templates evolve — proven patterns are promoted into the template, so the next instance starts smarter though the instance itself never persists.
Managers learn — their Hermes profile accumulates current lessons, preferred patterns, and known risks for their scope.
Executives learn — their Hermes profile reflects the compounded intelligence of their managers.
The organization learns — Honcho-recommended, governance-ratified doctrine becomes permanent truth.

Nothing in this loop depends on a particular model. The intelligence is owned by the organization and survives any vendor change — the permanence guarantee.

7 · DEPENDENCY GRAPH

PHASE 0  (complete)
  Mission Registry → Lifecycle → Objectives → Work Orders → Assignments
     → Execution Context → Reporting → Asset Ledger → Governance Instruments
     → Worker Templates → HQ01 Mission Control

PHASE 1  (correction; depends on Phase 0)
  P0 ─► 1.1 Executive Office ─► 1.2 Manager Assignment Engine ─► 1.3 Executive/Manager Operating Surfaces
                                     (validation + acceptance + aggregation live here)

PHASE 2  (intelligence runtime; depends on Phase 1 + P0 Reporting)
  2.1 Hermes ─┐
  2.2 MemPalace┼─► 2.3 LiteLLM ─► 2.4 Honcho ─► 2.5 Langfuse
              │      (gateway)      (via LiteLLM)   (observes LiteLLM)
  2.6 Serena (infrastructure; parallel; depends on P0 Templates + 1.2)

PHASE 3  (living organization; depends on Phases 1–2)
  3.1 Cross-Executive Communication ─► 3.3 Executive Council
  3.2 Organization Learning  (depends on 2.1 + 2.2 + 2.4)

Critical path: P0 → 1.1 → 1.2 → 2.1 → 2.2 → 2.3 → 2.4 → 3.2 → 3.3. Off-path / parallelizable: 1.3, 2.5 (Langfuse), 2.6 (Serena).

8 · FINAL CANONICAL ROADMAP

PHASE 0 — MISSION OS (complete — do not redesign, rewrite, or remove)

The eleven foundational capabilities: Mission Registry · Mission Lifecycle · Objectives · Work Orders · Assignments · Execution Context · Reporting · Asset Ledger · Governance Instruments · Worker Templates · HQ01 Mission Control. Every later phase composes with these. The only change touching Phase 0 is the additive re-seating of assignment ownership in Pass 1.2.

PHASE 1 — THE EXECUTIVE → MANAGER CORRECTION

Pass 1.1 — Executive Office

Purpose. Establish the Executive Office as the unit of organization that is a department head and owns its managers, with no Department object and no hardcoded manager types (CANONICAL_00 §53, §92, §171).
Deliverables. Each Executive Office owns: Executive Constitution, Executive Hermes profile, a self-defined manager roster (persistent offices, open-ended), Worker Templates, Skills, Tools, Metrics, Knowledge. Existing executives are extended into this richer office shape additively; existing worker templates are parented to their office.
Dependencies. Phase 0 (Executive Registry, Worker Templates).
Success criteria. An executive can define and retire managers as data, with no code change; every manager and template belongs to exactly one Executive Office; the executive owns its full surface (constitution, hermes, managers, templates, skills, tools, metrics, knowledge).
Estimated impact. Foundational. The container every later layer lives in.

Pass 1.2 — Manager Assignment Engine

Purpose. Insert the Manager between executive and worker and re-seat the existing assignment engine under managers — Executive → Manager → Assignment → Worker (CANONICAL_00 §270), additively.
Deliverables. Managers as persistent offices owning planning, assignment creation, worker-template selection, worker orchestration, validation, acceptance, and report aggregation. Assignment ownership moves from executive to manager (executive retained as routing/strategy authority). Returns flow worker → manager (validate → accept → aggregate) → executive, establishing the compression layer. Default-manager migration for existing assignments (see §9).
Dependencies. Pass 1.1; Phase 0 Assignments + Worker Templates + Reporting.
Success criteria. A worker instance is only ever dispatched by a manager; no assignment is executive-owned; the executive consumes manager-aggregated outcomes, not individual worker reports; validation and acceptance are recorded manager decisions.
Estimated impact. High + corrective. Makes the implementation doctrine-compliant and builds the compression layer.

Pass 1.3 — Executive / Manager Operating Surfaces

Purpose. The surfaces on which executives think and managers manage (CANONICAL_00 §250).
Deliverables. Executive surface: owned missions, manager roster and health, cross-manager coordination, prioritization, decision/acceptance queue, executive-to-executive communication. Manager surface: queue, active worker instances, assignments awaiting validation/acceptance, template selection, escalations. Both compose existing data; neither holds state.
Dependencies. Passes 1.1–1.2.
Success criteria. An executive runs a charter without touching worker mechanics; a manager runs a queue end-to-end from one surface.
Estimated impact. High. Turns the corrected structure into an operating cockpit.

PHASE 2 — THE INTELLIGENCE RUNTIME

(Plane-separated per AAF_CONSTITUTION §801; none faked. Hermes/MemPalace = internal systems to build; Honcho/LiteLLM/Langfuse/Serena = real OSS to deploy; all confirmed absent in the Infrastructure Bring-Up pass. Honcho and Serena carry blockers on record.)

Pass 2.1 — Hermes Runtime

Purpose. One Hermes runtime for current organizational state, owner types Executive Office, Manager, Worker Template (CANONICAL_00 §106).
Deliverables. Per owner: Identity, Current Objectives, Current Priorities, Current Constraints, Known Risks, Preferred Patterns, Current Lessons, Current Focus. Seeded from existing executive YAML; extended to managers and templates. Always loaded; intentionally small; never an archive.
Dependencies. Phase 1.
Success criteria. Executive, manager, and worker-template briefings load live Hermes state; Hermes holds the present only.
Estimated impact. High. Enables managers and executives to learn.

Pass 2.2 — MemPalace Runtime

Purpose. One organization-owned institutional memory (Agent Z Constitution).
Deliverables. Append-only, searchable store over the /srv/aaf corpus — architecture, research, chats, reports, projects, products, implementations, history, doctrine, institutional decisions. Searched, never fully loaded; linked from the Asset Ledger as each asset's permanent home.
Dependencies. Phase 0 Reporting + Asset Ledger.
Success criteria. Any report/decision/asset is retrievable verbatim; append-only; never auto-loaded.
Estimated impact. High. The organization stops re-paying for settled questions.

Pass 2.3 — LiteLLM

Purpose. The organizational model gateway (one-gateway rule, §720), without replacing Claude CLI as the worker execution engine.
Deliverables. A LiteLLM gateway for background/organizational intelligence — routing, cost ceilings, fallback chains, budget guards. Honcho and future background intelligence route through it; Claude CLI continues to execute worker assignments directly.
Dependencies. Phase 1; independent of Hermes/MemPalace.
Success criteria. Intelligence-tier model calls route through LiteLLM with logged routing/cost; worker execution unchanged.
Estimated impact. Medium-high. The vendor-independence substrate; the gateway Honcho needs.

Pass 2.4 — Honcho

Purpose. Organizational reflection — reviews and recommends, never executes, never stores, never edits state (CANONICAL_00 §106).
Deliverables. Honcho (Holdings plane; Postgres+pgvector per docs/infrastructure/honcho.md) periodically reviews executive activity, manager activity, reports, assignments, chats, and mission outcomes, and recommends Hermes updates, MemPalace promotions, and doctrine candidates into the governed pipeline. Model calls route through LiteLLM.
Dependencies. Passes 2.1, 2.2, 2.3; Phase 0 Reporting. Blocked on LLM-provider key + plane decision (on record).
Success criteria. Activity produces Honcho recommendations as proposals (never auto-applied), routed to the correct target.
Estimated impact. High. Where the organization begins to learn.

Pass 2.5 — Langfuse

Purpose. Observability over LiteLLM (§720).
Deliverables. Langfuse (Holdings plane) tracing LiteLLM — cost, latency, evaluations, background intelligence; datasets never shared across planes. Claude CLI execution remains independently observed until a future migration.
Dependencies. Pass 2.3.
Success criteria. Every intelligence-tier model call is observable; no untraced gateway call.
Estimated impact. Medium. Makes the intelligence runtime operable and auditable.

Pass 2.6 — Serena

Purpose. Code intelligence infrastructure for worker instances — repository indexing, symbol navigation, architecture awareness, precise edits (docs/infrastructure/serena.md). Explicitly not organizational intelligence.
Deliverables. A ratified, version-pinned Serena registered as an MCP server for engineering worker templates; available within the worker session. Claude CLI remains the execution engine; Serena is a tool within it.
Dependencies. Phase 0 Worker Templates; Pass 1.2. Blocked on ratifying the oraios/serena pin (on record).
Success criteria. An engineering worker invokes Serena within its assignment; Serena is pinned and reproducible.
Estimated impact. Medium. Sharpens worker execution; orthogonal to the intelligence triad.

PHASE 3 — THE LIVING ORGANIZATION

Pass 3.1 — Cross-Executive Communication

Purpose. Governed executive-to-executive communication (CANONICAL_00 §77, §83, §134).
Deliverables. Governed routing of work across charters; cross-executive disputes rising to the first common superior (COO/CEO) with written positions; the cross-OS boundaries stated and observed; Separation/Isolation Laws never crossed.
Dependencies. Phase 1; Pass 1.3.
Success criteria. An executive routes work to another's charter through a governed door; no responsibility duplicated; disputes escalate in writing.
Estimated impact. High. The organization coordinates as one body.

Pass 3.2 — Organization Learning

Purpose. Close the compounding loop (§6) end-to-end so intelligence becomes doctrine through one channel (CANONICAL_00 §17, §187).
Deliverables. Promotion loop: Honcho recommendations → evaluation → doctrine proposals with dossiers → scoped-executive enactment with safety audit; worker-template evolution from ratified patterns; loop-health and citation metrics in HQ01; governed autonomous proposal of missions (always into the approval gate, never self-approved).
Dependencies. Passes 2.1, 2.2, 2.4.
Success criteria. A proven lesson travels from one report to ratified doctrine through one channel; templates evolve; the organization can propose its own missions.
Estimated impact. Defining. Intelligence compounds, vendor-independently.

Pass 3.3 — Executive Council

Purpose. The coordination and review body chaired by the COO — never a voting body, no decision diluting individual accountability (CANONICAL_00 §77, §162).
Deliverables. The Council surface: every executive's state and KPIs; the COO's portfolio coordination; quarterly planning where strategy becomes missions; the cadence aligning the four hierarchies.
Dependencies. Passes 3.1, 3.2.
Success criteria. The Council convenes over real executive state; strategy becomes missions; individual accountability preserved.
Estimated impact. High. The top of the organism — one CEO operating the portfolio through missions.

9 · MIGRATION STRATEGY

Additive and reversible; the organization keeps operating throughout. No step requires a data rewrite.

Extend executives into Executive Offices (1.1). Add the richer office surface (constitution already exists; add hermes profile slot, manager roster, skills/tools/metrics/knowledge) without altering existing executive behavior.
Introduce managers alongside, not instead of (1.1–1.2). Managers are created as new persistent offices under their executive; nothing depends on them yet; executive-owned dispatch keeps running.
Default-manager backfill (1.2). Define one default manager per Executive Office; migrate every existing assignment to it via an additive ownership field; assignment records and history untouched — no orphans.
Flip the dispatch path (1.2). Make manager-owned dispatch the only path for new work; retire (do not delete) the executive→worker path, preserved read-only for audit.
Insert validation/acceptance/aggregation (1.2). Route new returns through the owning manager; already-accepted history stays accepted.
Layer intelligence last (Phase 2). Hermes/MemPalace read existing profiles and reports; LiteLLM precedes Honcho; Honcho only recommends; Claude CLI is never replaced.
Reversibility. Every step is gated and observable; the prior executive-owned path remains in the record and can be re-enabled while an issue is fixed.

10 · RISK ANALYSIS

Risk	Severity	Mitigation
Hardcoded manager types (a fixed enum)	High	Managers are executive-owned data; roster open-ended by construction (1.1). Any enum of manager types is a defect.
Re-introducing a Department object	High	Prohibited by law #11; Executive Offices are departments.
Executive still assigns/reviews workers	High	1.1 removes the worker surface from executives; 1.2 makes manager the sole dispatcher and reviewer; §270 vigilance permanent.
Compression skipped (executive reads raw worker output)	High	Returns flow through manager validation/acceptance/aggregation (1.2); executive consumes manager outcomes only.
Orphaned historical assignments in migration	Medium	Default-manager backfill before the dispatch flip (§9.3).
Honcho edits state directly	High	Honcho recommends into a governed pipeline (2.4); never writes Hermes/MemPalace/Doctrine.
Hermes bloats into history	Medium	Bounded to the eight current-state fields; history lives in MemPalace.
Workers accumulate memory	High	Instances are ephemeral and terminate; intelligence compresses upward, never retained at the worker.
Vendor lock-in	Medium	LiteLLM gateway (2.3) + organization-owned intelligence; law #12 — models own nothing.
Plane / separation breach	Halt-class	Every runtime plane-separated (§801); a mission crossing the separation halts.
Honcho / Serena infra blockers stall Phase 2	Medium	Blockers on record; Hermes/MemPalace (no external blocker) proceed first.
Unauthenticated HQ01 exposure	High (standing)	Traefik login gate — standing infrastructure obligation, independent of these passes.
Roadmap drift over years	Medium	Permanence-optimized: this document describes the organization, not the technology; passes may change implementation without amending it.

VALIDATION ✔

The resulting architecture satisfies every required property:

Executives think — 1.1 + 1.3 + 2.1: own mission, strategy, architecture; never assign or review workers.
Managers manage — 1.2: own planning, assignments, orchestration, validation, acceptance, aggregation.
Workers execute / terminate — 1.2 + 2.6: one assignment, one report, then gone.
Managers learn / Executives learn — 2.1 Hermes profiles + 3.2 loop.
Worker Templates evolve — 3.2: ratified patterns promoted into templates.
Hermes stores current organizational state — 2.1: one runtime, always loaded, small.
MemPalace stores institutional memory — 2.2: one runtime, organization-owned, searched.
Honcho recommends learning — 2.4: reflects and recommends, edits nothing.
Doctrine remains permanent truth — 3.2: promotion terminates in ratified law.
Organization intelligence compounds independently of any AI vendor — 2.3 LiteLLM + law #12 + the organization-owned loop.

CANONICAL ORGANIZATION OS ROADMAP — FINAL. The permanent implementation arc of the AAF Holdings Organization Operating System. Descends from CANONICAL_00, the Constitution, and the Mission OS Doctrine. Architectural, not technical. Phase 0 (Mission OS) complete. Optimized for organizational permanence. Supersedes all previous roadmap documents. Amendable by the CEO through the governance process. Governing the rollout until amended or completed.

root · /srv/aaf