Conduir — Master Architecture (Compiled)

Conduir — Master Architecture (Compiled)

Date: 2026-05-16
Status: Compiled baseline. Merges five independent syntheses:

• _CLAUDE_2.md — the planning / spine-decision artifact (informs Part 0 below)
• TOP-LEVEL-ARCHITECTURE-DESIGN.md — the Gemini concise architecture baseline
• TOP-LEVEL-DESIGN.md — the Claude comprehensive top-level synthesis
• plan_GPT.md — the GPT execution / delivery plan
• GEMINI.md — the operational charter / Golden Rules with P0 enforcement framing (informs new Part 0.5 below)

Source corpus: maestro-platform/docs/living-system/ (snapshot 2026-05-14; timeline rework 2026-05-12).

Authority order (when docs disagree):
1. living-system/08-CONTRACT-SPECS.md (wire-level truth)
2. living-system/09-FINAL-C3-ARCHITECTURE-DESIGN.md (current C3 baseline)
3. This document (top-level architectural synthesis + delivery plan + Golden Rules)
4. SOLUTION-CAPABILITY-CONTRACTS.md (capability-domain contracts; SOL-0..SOL-12)
5. ANATOMICAL-SYSTEM-SPEC.md (organ membranes, lifecycle, mission walk-through)
6. ENGINEERING-VIEW.md (engineering containers), ARCHITECTURE.md (stakeholder anatomy)
7. living-system/CAPABILITY-INVENTORY-2026-05-14.md (capability rows of record)

Vision-side authority (separate column, since vision and execution can legitimately diverge):

1. VISION-TOP-DOWN-MAPPING.md (vision functions VF-1..VF-16 — what should exist)
2. LIVING-HUMAN-AI-VISION.md (body-system mapping — the metaphor and orphan-organ accounting)
3. AI-EVOLUTION-MORALITY-MORTALITY.md (long-horizon: AI sexual reproduction, conscience, five-scale mortality — agent · mission-team · tenant-relationship · instance · species)
4. This document (compiled view — wins on disputed fact; vision docs win on disputed framing or what should exist)

When the execution stack and the vision stack disagree on what is true today, the execution stack wins. When they disagree on what the platform should become, the vision stack wins. The two are reconciled quarterly through the cross-walk in §3.6.

Audience reading paths (one-stop entry point — pick yours):

PART 0 — Design Rationale (the why of this structure)

Distilled from _CLAUDE_2.md. This section records why the document is shaped this way so the choices don't quietly drift.

0.1 Vocabulary Decision — the spine

The corpus speaks five dialects: capabilities (CAP-N), suites (S0–S12), milestones (M1–M8), mini-caps (L2.x), handshakes (Hx/Bx/Gx/Nx). Forcing every reader to translate is the largest hidden cost in the existing docs.

Decision: substrate-first six-layer spine (Substrate · Identity & Privacy · Memory · Cognition · Governance · Surfaces), with explicit cross-walk to every other dialect (Part 3.6 below).

Why: it forces substrate primacy into the shape of the document, not just the prose — matching the lesson from CRITICAL-REVIEW.md and the recurring audit-cycle pattern of surface-first / substrate-back-fill.

0.2 What this document is NOT

Bounded scope keeps it useful:

• Not a re-write of the eight capabilities → 01.5-CAPABILITIES.md (source) + CAPABILITIES.md (synthesis).
• Not a re-write of substrate sequencing → SUBSTRATE-SEQUENCING.md is canonical (Part 3.4 cites it).
• Not a per-service spec → 09-FINAL-C3-ARCHITECTURE-DESIGN.md + 07-C3-COMPONENT-DESIGN.md are canonical.
• Not a roadmap → 02-ROADMAP.md + CAPABILITY-PHASE-SUMMARY-2026-05-14.md are canonical.
• Not marketing copy → MARKETING-RECONCILIATION.md is the gate.

This is the architectural skeleton + delivery plan; every other doc hangs from it.

0.3 Source-alignment discipline

Every structural claim in this document cites one of:

• 01.5-CAPABILITIES.md — the eight product capabilities
• 09-FINAL-C3-ARCHITECTURE-DESIGN.md — C3 containers + Pillar 0 contract ratchet
• 07-C3-COMPONENT-DESIGN.md — suites S0–S12, lanes A/B/C
• LEVEL-L2-EXECUTION-ORCHESTRATION-2026-05-13.md — L2.1–L2.12 mini-caps
• HANDSHAKE-INDEX-2026-05-13.md — ~85 handshakes
• AGENT-MATURITY-MODEL-2026-05-14.md — autonomy L1–L5 × trust tier 0–3
• CAPABILITY-INVENTORY-2026-05-14.md — sub-cap detail
• architectural-shifts (exploration/2026-05-14) — audit hash-chain, replay, reliability primitives, single substrate socket

Where the corpus is silent or contradictory, the document flags OPEN: rather than papering over.

0.4 Standing risks of any synthesis like this

PART 0.5 — The Golden Rules (Operational Charter)

Distilled from GEMINI.md. This Part is the in-flight quick-reference for any agent or engineer mid-task. It is the constitution: short, memorisable, P0-enforceable. The remaining Parts of this document are the reference material that explains why these rules hold. If you only read one Part of this document while writing code, read this one.

0.5.1 The Three Inviolable Membranes

Each membrane below is a contract. Violations are P0 incidents.

0.5.2 The Sequencing Mandate (re-stated as a rule)

The substrate seams close in this order. No deviation.

1. Phase S0 — SUB-9.2 (ActorContext) and SUB-9.3 (OutcomeEvent) land together.
2. Phase S1 — SUB-9.4 (Tenant RLS) and SUB-9.6 (JWT) begin only after S0 is closed.
3. Phase S2 — SUB-9.14 (Path-maturity) begins only after S0 and S1 are closed.

Do not build surface features (higher CAPs) on partial substrate. If you cannot point to closed seams, you cannot claim the feature is complete.

0.5.3 Coding Standards (P0-enforceable)

0.5.4 Vitality — How We Measure (not up/down, 0–100)

0.5.5 The Six Non-Negotiables (one-line each)

When you are about to take an action and you are not sure, run it through these:

1. CAP-9 is the floor, not a peer — substrate primacy is not optional.
2. Identity on every action — ActorContext is mandatory.
3. Canonical signal — OutcomeEvent is the single learning bus.
4. Tier-Forbidden floor is constitutional — never AI-mutated.
5. Codegen-only contracts — no hand-mirrors.
6. AUTONOMY by default (amended 2026-06-17 — see CONDUIR-CONSTITUTION.md §I.6.6; was "HITL by default, autonomy by opt-in"). The org acts/decides by default, escalating only on critical-under-doubt or regulatory/compliance; production + governance/charter mutation stay approval-gated until a signed GatePolicy delegates them; even auto-approve tiers respect Tier-Forbidden.
7. Strict Substrate Purity (The SOL-0 Test) — Product logic (personas, routing strategies) is forbidden from the substrate. If it fails the "neutral carrier" test, it belongs in lib/ or services/.

0.5.6 If You Are About To…

0.5.7 The One-Sentence Summary of the Charter

Every action carries identity, every step emits canonical signal, every change has a rollback, every mutation respects the Tier-Forbidden floor — and the substrate seams close in order S0 → S1 → S2 before any higher claim is honest.

If you can hold that sentence in your head while writing code, you will not violate the architecture.

PART 1 — Foundation

1.1 Architecture Thesis (one paragraph)

Conduir is a multi-tenant, multi-agent, governed learning platform. A substrate floor (identity, privacy, governance, event fabric, storage, compute) carries a multi-LLM cognition layer (Symposium, Gateway, dynamic teams), fed by per-agent and per-user memory (AgentDNA, DecisionMemory, Digital Twin), sensing via narrow typed channels (Mission UI, MCP, code-ops), signalling over an event fabric (NATS + canonical contracts), protected by an immune system of AuthN/Z + RLS + PrivacyScope, regulated by an autonomic watchdog (regression_watcher + auto-revert + path-maturity), and acting through API/MCP/EvolutionApplier muscles. The system improves task-over-task within governed-autonomy boundaries the operator controls; the Tier-Forbidden floor (governance, audit, identity) is permanently off-limits to AI mutation. Until the five substrate seams close in the order S0 → S1 → S2, every higher capability is anatomically present but not yet alive.

The highest-level shape:

governed execution
  → canonical evidence
    → scoped memory and learning
      → explainable adaptation
        → bounded self-improvement
          → audited governance

1.2 Non-Negotiable Architecture Principles

Inherited from 09-FINAL-C3-ARCHITECTURE-DESIGN.md §2, reaffirmed here and load-bearing for every later section.

1.3 What Conduir Is — and Is Not

Is:

• A layered learning organism — every task improves the next, bounded by identity, privacy, rollback, governance.
• A governed-autonomy platform — humans set policy, AI acts within tiers, every action is replayable.
• A model-agnostic fabric — gateway routes between providers; we do not train foundation models.
• A multi-tenant SaaS with strict isolation and per-row policy enforcement.
• A code+API actuator — body = APIs, code, data. Nothing mechanical, nothing physical.

Is not (see NON-GOALS.md for the full list):

• A coding IDE, a foundation-model trainer, a robotic platform, an AGI / consciousness product, a replacement for human judgement, or an undifferentiated-cost orchestrator.
• A system where AI mutates its own governance, audit, or identity machinery — the Tier-Forbidden floor is permanent.

PART 2 — The Top-Level Architecture

2.1 System Context (C4 Level 1)

flowchart LR
    User[Users · delivery teams]
    Admin[Org board · platform admins]
    Auditor[Auditor · compliance reviewer]
    Conduir[Conduir Platform]
    LLM[LLM Providers<br/>Anthropic · OpenAI · etc.]
    Tools[External Tools<br/>GitHub · Jira · Slack · Confluence · IDEs · Figma · MCP]
    Manthan[Manthan exploration<br/>side-lane partner — M7]
    IdP[Identity Provider<br/>SSO · OIDC]
    Data[Customer Data Sources<br/>codebases · DBs · docs · artifacts]

    User --> Conduir
    Admin --> Conduir
    Auditor --> Conduir
    Conduir --> LLM
    Conduir <--> Tools
    Conduir <--> Manthan
    Conduir <--> IdP
    Conduir <--> Data

Boundary rules.

• Customer data does not leave its logical isolation boundary except through governed adapters.
• LLM calls are gateway-mediated; raw provider APIs are not exposed to tenant workloads.
• External tools are reached via the integration plane (CAP-13), not directly from cognition.

2.2 The Six-Layer Spine

The primary structural vocabulary. Every other dialect (capabilities, suites, planes, milestones, mini-caps, handshakes) cross-walks to this in §3.6.

╔═══════════════════════════════════════════════════════════════════╗
║  LAYER 6 — SURFACES & INTEGRATION                                  ║
║    Mission UI · Code-ops · MCP · external adapters · BFF           ║
║    CAP-13 snap-in plane · CAP-8 Living Blueprint (deferred)        ║
╠═══════════════════════════════════════════════════════════════════╣
║  LAYER 5 — GOVERNANCE & EVOLUTION                                  ║
║    Tier-Forbidden floor · MoveProposal · RollbackRecord ·          ║
║    EvolutionApplier · SideLaneEnvelope · GovernanceState · Audit   ║
║    CAP-5 · CAP-6                                                   ║
╠═══════════════════════════════════════════════════════════════════╣
║  LAYER 4 — COGNITION                                               ║
║    Symposium · LLM Gateway · dynamic team · A2A · quorum · debate  ║
║    Epic-Graph · Tool-Bridge · CAP-1                                ║
╠═══════════════════════════════════════════════════════════════════╣
║  LAYER 3 — MEMORY                                                  ║
║    DecisionMemory · AgentDNA (CAP-2) · Digital Twin (CAP-7) ·      ║
║    PrivacyScope · path-maturity (CAP-4 via SUB-9.14)               ║
╠═══════════════════════════════════════════════════════════════════╣
║  LAYER 2 — IDENTITY, PRIVACY & TENANCY                             ║
║    OIDC · JWT (SUB-9.6) · ActorContext (SUB-9.2) ·                 ║
║    Tenant RLS (SUB-9.4) · ConsentAxes (5)                          ║
╠═══════════════════════════════════════════════════════════════════╣
║  LAYER 1 — SUBSTRATE FLOOR (CAP-9)                                 ║
║    Mission lifecycle · OutcomeEvent (SUB-9.3) · NATS · Postgres ·  ║
║    Vector memory · Object storage · Vault · audit chain · replay   ║
╚═══════════════════════════════════════════════════════════════════╝

Reading rule. Higher layers bias lower layers — Governance sets the priority register, Cognition deliberates within those priorities, Memory feeds context, Identity gates every hop, Substrate carries the structure. Substrate is a backplane, not a "tenth plane at the bottom" — all layers touch it.

Per layer, the contract is the membrane; the components below are what live in the layer; the substrate seam is the dependency.

2.3 Engineering Container View (C4 Level 2)

flowchart TB
    subgraph Z1["Zone 1 — DMZ"]
        WEB[Web UI<br/>Next.js]
        BFF[API / BFF<br/>Node · port 44100]
    end
    subgraph Z2["Zone 2 — Application Services"]
        SYM[Symposium<br/>Python · port 48010]
        GATE[LLM Gateway<br/>Python · port 48003]
        EG[Epic-Graph<br/>Python · port 49805]
        TB[Tool-Bridge<br/>Python · port 48060]
        LEARN[Nous · OutcomeRouter ·<br/>RegressionWatcher · Manthan]
    end
    subgraph Z3["Zone 3 — Data Plane"]
        PG[(PostgreSQL<br/>Prisma · RLS)]
        REDIS[(Redis<br/>cache)]
        NATS[(NATS<br/>event bus)]
        S3[(Object Storage<br/>replay tapes)]
        VEC[(Vector Memory<br/>DecisionMemory · Twin · DNA)]
    end
    subgraph Z4["Zone 4 — Substrate & Privileged"]
        VAULT[(Vault<br/>secrets · JWT)]
        GOV[Governance YAMLs<br/>Tier-Forbidden floor]
        AUDIT[Audit log<br/>immutable]
    end

    WEB --> BFF
    BFF --> SYM
    BFF --> GATE
    BFF --> PG
    BFF --> REDIS
    SYM --> GATE
    SYM --> EG
    SYM --> TB
    SYM --> NATS
    SYM --> PG
    SYM --> VEC
    LEARN --> NATS
    LEARN --> PG
    LEARN --> VEC
    LEARN --> GOV
    GATE --> VAULT
    BFF --> VAULT
    SYM --> AUDIT
    LEARN --> AUDIT
    BFF --> IdP[(Identity Provider<br/>OIDC)]:::ext
    GATE --> LLM[(LLM Providers)]:::ext
    TB --> EXT[(External Tools)]:::ext

    classDef ext fill:#eee,stroke:#666,color:#000

Dataflow rule. All inter-container communication goes through (a) the BFF (request-shaped), (b) NATS (event-shaped), or (c) shared storage. No direct service-to-service HTTP outside this pattern.

2.4 The Stakeholder Rendering (anatomy view)

Same six layers, retold for pitch / sales / board. (Source: ARCHITECTURE.md; this is not a separate design — it is a different audience rendering of Part 2.2.)

¹ Critical-review caveat: "senate" cognition is fictional — Conduir's multi-LLM is a committee with committee pathologies (deadlock, conformity, hidden hierarchy). Mitigated by quorum, debate, peer-review, escalation.
² RAG is not a hippocampus — it's fixed-embedding retrieval. The metaphor flatters the mechanism.
³ Nervous + Circulatory collapse into one event fabric in engineering vocabulary (NATS + Postgres + object storage). Splitting them was biological accuracy at design clarity's expense.

2.5 Trust Zones, Security & Privacy

ZONE 0 — UNTRUSTED EXTERNAL     internet · browsers · LLM providers · tools
ZONE 1 — DMZ                    BFF · Web UI · AuthN · tenant resolve · WAF
ZONE 2 — APPLICATION            Symposium · Gateway · Nous · Manthan · Tools
ZONE 3 — DATA PLANE             Postgres · Memory · NATS · Object Storage
ZONE 4 — SUBSTRATE & PRIVILEGED Vault · IAM · audit log · governance config
                                (Tier-Forbidden floor — never AI-mutated)

Hop controls (each hop adds AuthN + AuthZ + audit + rate limits):

Privacy primitives:

• PrivacyScope on every memory write with 5 consent axes
• GDPR Article 15 (export) — surfaced via AmigoConsentService; CAP-7 user-facing surface in M5
• GDPR Article 17 (delete) — cascading erasure across twin, agent memory, traces (NOT audit log — legal-hold policy)
• Audit log is policy-protected — cannot be deleted by user erasure without legal-hold-aware override

Threat model summary:

• Inside attacker → audit + RLS + minimal privilege
• Tenant data exfiltration → trust zones + RLS + egress allow-list
• Prompt injection → output validation + tool-call schema + Tier-Forbidden floor
• Supply chain → dependency pinning + SBOM + signed commits
• Insider mutation of governance → Tier-Forbidden floor + Zone-4 break-glass only

PART 3 — The Capability Map, Substrate, Contracts, Cross-Walk

3.1 The Capability Map (CAP-1 .. CAP-13)

              ┌────────────────────────────────────────────┐
              │  PRODUCT CAPABILITIES (CAP-1 .. CAP-8)     │
              └────────────────────────────────────────────┘
                                 │
                                 ▼
            ┌──────────────────────────────────────────────┐
            │  CROSS-CUTTING (CAP-10 economics, CAP-11     │
            │  observability, CAP-12 compliance, CAP-13    │
            │  integration) — wrap every CAP-1..8          │
            └──────────────────────────────────────────────┘
                                 │
                                 ▼
            ╔══════════════════════════════════════════════╗
            ║  CAP-9 SUBSTRATE FLOOR — not a peer          ║
            ║  Identity · Privacy · Governance · Audit ·   ║
            ║  Event fabric · Storage · Compute · Runtime  ║
            ╚══════════════════════════════════════════════╝

CAP-2 vs CAP-7 boundary (CAPABILITIES.md §3): the subject of the memory is the dividing line. CAP-2 stores memory about agents (track record, AgentDNA); CAP-7 stores memory about users (Digital Twin, editable, forget-able). Both share substrate (OutcomeEvent + ActorContext); the subject distinguishes them.

3.2 The Contract Backbone (Pillar 0)

The architecture only works if shared contracts remain canonical across all containers. Contracts ratchet forward milestone by milestone; no breaking change without a versioned migration window (see ENGINEERING-VIEW.md §8).

Non-negotiable contract consumers:

Contract rules:
1. All cross-service contracts live in shared/contracts/ and codegen FE / BE / Python types — no hand-mirrors (CON-3331).
2. Schemas are JSON Schema Draft-07 with Pydantic and TypeScript types generated.
3. Versioning is additive — a new field is always optional in v_{n+1}; breaking changes require a v_{n+1} schema and a migration window.
4. Identity flows on every hop — no service-to-service call without ActorContext.

3.3 The Three Loops (the dynamic view)

The platform is best understood as three loops, not one feature tree. Each loop sits on the substrate floor and emits canonical OutcomeEvents.

3.3.1 Loop A — Mission Execution (M1–M2 backbone)

sequenceDiagram
    participant U as User
    participant W as Web UI
    participant A as API/BFF
    participant S as Symposium
    participant G as LLM Gateway
    participant T as Tools/MCP
    participant E as Event Bus
    participant N as Nous/OutcomeRouter
    participant M as DecisionMemory
    participant P as PathMaturity/Twin

    U->>W: Start mission / give instruction
    W->>A: Authenticated request
    A->>A: Resolve tenant + ActorContext
    A->>S: Dispatch mission with ActorContext
    S->>G: Model calls through gateway
    S->>T: Tool calls through adapters
    G-->>S: Model result
    T-->>S: Tool result
    S->>E: Emit OutcomeEvent with ActorContext
    E->>N: Route and validate event
    N->>M: Write decision and outcome memory
    N->>P: Update path maturity and twin signals
    P-->>S: Preferred route / personalization signal
    S-->>A: Runtime result and trace
    A-->>W: SSE / response / replay

The reflex arc: PERCEIVE → DELIBERATE → DECIDE → ACTUATE → OBSERVE → EMIT → AGGREGATE → STRENGTHEN.

3.3.2 Loop B — Learning, Personalisation, Twin (M3–M5 arc)

flowchart LR
    OE[OutcomeEvent] --> NATS
    NATS --> OR[OutcomeRouter]
    OR --> OS[ObjectiveScore]
    OR --> DM[DecisionMemory]
    DM --> Pref[Preference Learner]
    Pref --> Twin[Twin Aggregator · APIs]
    DM --> Rec[Recommendation · Explanation]
    Twin --> Rec

The learning system is a federation, not one model: canonical capture → score → memory → preference → twin → recommendation/explanation.

3.3.3 Loop C — Governed Change (M6–M8 arc)

flowchart LR
    Detect[Runtime detector<br/>learning or regression signal]
    Propose[MoveProposal]
    Review[Improvement inbox<br/>human or policy review]
    Side[Side-lane experiment<br/>budgeted isolation]
    Score[ObjectiveScore]
    Apply[EvolutionApplier<br/>dry-run apply rollback]
    Watch[RegressionWatcher]
    Audit[Audit chain]
    Rollback[RollbackRecord]
    Gov[GovernanceState<br/>tiers budgets protected paths]

    Detect --> Propose
    Propose --> Review
    Review --> Side
    Side --> Score
    Score --> Propose
    Review --> Apply
    Gov --> Review
    Gov --> Side
    Gov --> Apply
    Apply --> Watch
    Apply --> Audit
    Watch --> Rollback
    Rollback --> Audit
    Watch -->|regression| Apply

Loop-C rules:

• No proposal without MoveProposal.
• No apply without RollbackRecord.
• No mutation of protected paths.
• No side-lane graduation without governance review.
• No autonomous loop without audit and regression watching.

M6 / M7 / M8 are one continuous loop: propose → isolate → govern → audit → rollback. Side-lane winners graduate by emitting a MoveProposal, not by bypassing M6 governance.

3.4 Substrate Sequencing — The Critical Path

(Authoritative source: SUBSTRATE-SEQUENCING.md.)

Five substrate seams were previously listed in parallel; they are not the same kind of work, and they have a real dependency order.

flowchart TD
    S0a[SUB-9.2<br/>ActorContext]:::p
    S0b[SUB-9.3<br/>OutcomeEvent]:::p
    S1a[SUB-9.4<br/>Tenant RLS]:::i
    S1b[SUB-9.6<br/>JWT resolution]:::i
    S2[SUB-9.14<br/>Path-maturity]:::d

    S0a --> S1a
    S0a --> S1b
    S0a --> S2
    S0b --> S2
    S0b -. signal carries .-> S0a

    classDef p fill:#ffe4c4,stroke:#a16207,color:#000
    classDef i fill:#ffd6d6,stroke:#b91c1c,color:#000
    classDef d fill:#d6e8ff,stroke:#1f6feb,color:#000

The one paragraph that matters. Until SUB-9.2 + SUB-9.3 close, every higher capability operates on partial data. Audit cycles will keep catching the gap. Marketing claims will keep outrunning reality. Close S0. Then S1. Then S2. Do not try all three at once. Do not ship higher-CAP surfaces against partial substrate.

3.5 Latency Budgets, Failure Modes, Observability

3.5.1 Latency budgets (steady-state, from ENGINEERING-VIEW.md §4)

If a plane consistently breaches its hard ceiling, it page-alerts. Budget breaches without alerts mean the observability plane (CAP-11) is failing.

3.5.2 Failure modes & degradation

3.5.3 Observability commitments (CAP-11, Phase-1 non-optional)

• W3C trace context propagated across every hop, alongside ActorContext (who + what)
• 100% sampling of mission-step events; 1% for sub-step internal calls
• Structured JSON logs always carrying trace_id, mission_id, tenant_id, actor_id
• Audit log: append-only, immutable, queryable, Zone 4
• Every mission is replayable on a snapshot of system state at its time
• Alert tiers: P0 (customer-facing outage / cross-tenant leak / secret leak), P1 (substrate regression / vitality < 40), P2 (SLO burn / capability claim invalidated)

3.6 The Vocabulary Cross-Walk (keystone table)

Every dialect, one row per capability. This table earns the document its keep — it eliminates "which doc is right?" forever.

Suite (S) numbers map to 07-C3-COMPONENT-DESIGN.md; L2.x mini-caps to LEVEL-L2-EXECUTION-ORCHESTRATION-2026-05-13.md; anatomy organs to ANATOMICAL-SYSTEM-SPEC.md; substrate seams to SUBSTRATE-SEQUENCING.md; VF-N to VISION-TOP-DOWN-MAPPING.md; SOL-N to SOLUTION-CAPABILITY-CONTRACTS.md.

How to use this table.

• Picking a vocabulary: when writing a new doc, pick one dialect as primary, then use this table to cross-reference. The dialect choice depends on audience: VF for vision/exec; SOL for capability owners; CAP for status; layer for engineering structure; suite for implementation owners.
• Detecting orphans: a row missing an "anatomy organ" mapping is either a true cross-cutting capability or an orphan in need of an owner. Liver, Excretory, Lymphatic, and Conscience are the four current orphans.
• Detecting drift: a CAP/VF/SOL whose substrate dep changes is a structural signal — the cross-walk row must be updated before the change ships.

PART 4 — Execution Plan

Distilled from plan_GPT.md. This is the substrate-first delivery plan that turns the design above into an executable platform. Optimised for GPT/Codex-assisted implementation and review, but the workstreams, phases, and gates apply to any executor.

4.1 Delivery Rules (non-negotiable for executors)

4.2 Workstreams

4.3 Phase Plan (P0 → P8)

Phase P0 — Architecture Baseline & Work Intake

Goal: Make work executable by agents without losing the architecture thread.

Deliverables:

• Confirm this document is the top-level architecture baseline.
• Build a seam-indexed backlog from HANDSHAKE-INDEX-2026-05-13.md.
• Split backlog by workstream and dependency order.
• Mark each item with proof required: unit, integration, e2e, replay, audit, or screenshot.
• Define "claim gates" for capability status updates.

Exit: every immediate task maps to a seam, contract, capability, and proof artifact. No task described only as "improve X" without testable behavior.

Phase P1 — S0 Substrate: Identity + Signal

Goal: Close SUB-9.2 + SUB-9.3 together.

Scope: ActorContext propagated BFF → Gateway → Symposium → Tool-Bridge → Nous → audit; canonical OutcomeEvent emitted at every mission-step boundary, carrying actor, tenant, trace, route, status, cost, latency, evidence refs, PrivacyScope; producers on canonical NATS subjects; consumers validate with shared schemas and quarantine invalid events.

Seam targets: B5 (actor propagation chain) · G2 / G3 / G16 (gateway actor + learning emit) · H2 (exec → memory audit) · N1 (OutcomeRouter pipeline) · S9 (Symposium learning registry emit).

Proof: contract parity tests (TS + Python) · BFF → Symposium → Gateway integration test carrying same ActorContext · NATS consumer test accepting valid events, quarantining malformed · metric: ActorContext coverage > 99%, OutcomeEvent emission ≥ 1 per mission step.

Exit gate: No higher learning / twin / self-improvement feature can be called complete until this phase is green.

Phase P2 — S1 Substrate: Isolation + Trust

Goal: Close SUB-9.4 + SUB-9.6 after S0 is stable.

Scope: Tenant RLS enforced on tenant-sensitive Postgres tables; Prisma repos run under tenant context or scoped query contracts; cross-tenant reads fail in tests and production; JWT secret resolution centralised through Vault (or decided secret manager); rotation runbook and coverage exist.

Seam targets: H8 (governance + system-properties cross-cut) · H12 / G15 (gateway / Express JWT shared secret) · B2 (route → service → repo tenant plumbing) · B4 (privacy guard chain).

Proof: cross-tenant test harness for all affected repo paths · JWT rotation test with old + new keys · negative tests for missing tenant / invalid ActorContext · security note documenting fail-closed behaviour.

Exit gate: CAP-7 twin and CAP-4 personalisation cannot ship to users until tenant isolation is proven.

Phase P3 — Learning Loop & Preferred Path

Goal: Turn canonical events into route learning.

Scope: OutcomeRouter subscribes to canonical outcome subjects · DecisionMemory write path records scoped outcomes · path-maturity aggregation reads OutcomeEvent + DecisionMemory · route choice consumes path maturity before selecting agent / model / tool / protocol · why-this-route rationale available to UI and audit / replay.

Seam targets: H3 (memory → decision read-back) · N3 (bandit strategy) · N4 (route-choice contract) · B3 (preference consult) · W3 (recommendation with explanation).

Proof: fixture event updates DecisionMemory + changes a subsequent routing score · route decision returns rationale with evidence refs · replay demonstrates event → memory → route chain · metrics: DecisionMemory write rate, recall hit rate, route-rationale coverage.

Exit gate: CAP-4 remains GAP / PARTIAL until route choice demonstrably changes from scoped prior evidence.

Phase P4 — User Memory & Digital Twin

Goal: Make per-user memory inspectable, editable, consented, forgettable.

Scope: PrivacyScope enforced on memory writes + reads · TwinProfile / TwinAttribute APIs use canonical contracts · user can view / edit / export / forget twin data · forget cascades through twin / memory / eligible traces while preserving audit policy · twin signals influence route choice through P3.

Seam targets: W5 (twin audit / edit / forget) · CAP-7 H2 closure · B4 (privacy guard chain) · N6 (twin pipeline).

Proof: twin API contract tests · consent-axis tests for allowed + blocked memory reuse · forget cascade test with before / after evidence · UI / API proof for inspect / edit / export / delete.

Exit gate: CAP-7 cannot be claimed delivered until interaction → memory → twin → route influence is closed.

Phase P5 — Governed Self-Improvement

Goal: Replace status-flip self-improvement with real, audited apply + rollback.

Scope: MoveProposal + RollbackRecord canonical and schema-validated · EvolutionApplier supports dry-run, apply, rollback, idempotency, audit emission · protected paths and Tier-Forbidden floor enforced before side effects · kill switch blocks all mutation entrypoints · RegressionWatcher consumes real RegressionSignal producers.

Seam targets: H5 (L4 mutation loop e2e) · B8 (improvements inbox → applier) · N5 (regression-watcher signal chain) · M2 (mutator dispatch) · SUB-5.13 (EvolutionApplier) · SUB-5.14 (platform kill switch) · SUB-5.15 (replayable rollback proof) · SUB-5.17 (EvolutionGovernanceEvent) · SUB-5.19 (authoritative four-tier resolver).

Proof: dry-run proof for a proposal · apply proof showing real file / config / doc change · rollback proof showing byte-identical pre-state or equivalent invariant · audit chain entries for submit / approve / apply / rollback / kill-switch · regression signal triggers rollback in a controlled test.

Exit gate: CAP-5 remains DEAD-WIRE until apply applies and rollback rolls back.

Phase P6 — Side-Lane Exploration & Graduation

Goal: Run isolated experiments without contaminating main-lane learning.

Scope: SideLaneEnvelope wraps OutcomeEvent without changing inner contract · exploration budget enforced from GovernanceState · Manthan bridge emits typed side-lane outcomes · side-lane bandit state isolated from main-lane state · winning experiments graduate by creating MoveProposal records.

Seam targets: H6 (side-lane invocation) · N7 (federation router → publisher) · CAP-6 ObjectiveScore + SideLaneEnvelope rows · MoveProposal v1 experiment-graduation bridge.

Proof: side-lane event routed separately from main lane · budget exhaustion blocks additional exploration · winning side-lane outcome creates MoveProposal · main-lane route weights unchanged until governance approval.

Exit gate: CAP-6 remains CONTRACT-ONLY until a production caller + consumer exist.

Phase P7 — Governance Control Plane

Goal: Make governance state operator-editable without code changes.

Scope: GovernanceState composes direction, current state, tiers, protected paths, exploration budget · governance loader validates + hot-reloads state · runtime consumers invalidate caches on governance update events · governance UI supports direction / current / tier / budget / audit views · RBAC limits edits to platform admins, org board, named owners.

Proof: invalid governance file fails closed · valid edit hot-reloads + changes runtime behaviour · unauthorised edit rejected · audit log records who changed what + what version became active.

Exit gate: Phase 3 cannot be claimed honest until governance controls are runtime-active.

Phase P8 — Productisation, Metrics, Claim Reconciliation

Goal: Tie architecture to measurable business + operational claims.

Scope: per-plane vitality metrics from METRICS-BASELINE.md · cost attribution by tenant / mission class / model / route · dashboards for trace coverage, event drop rate, RLS coverage, memory write rate, route-rationale coverage, rollback proof · update MARKETING-RECONCILIATION.md when claims become supported · keep CAP status current only after independent proof.

Proof: dashboard / metric export per active plane · self-cert vs auditor delta reported per compliance cycle · marketing claims table maps each claim to a metric or removes the claim.

4.4 First 10 Task Slices (immediate executable backlog)

Execute in order unless a dependency changes.

4.5 Acceptance Gates per Capability

4.6 Operating Cadence

4.7 Immediate Next Step

Start Phase P1 with two read-only inventory tasks (slices #1 + #2 above):

1. Map every current ActorContext implementation and propagation hop.
2. Map every current OutcomeEvent producer, NATS subject, consumer, and schema variant.

Do not begin path-maturity, twin influence, or self-improvement-apply work until this map exists. Those systems depend on scoped canonical evidence.

PART 5 — Milestone Progression

Stance: treat M1–M5 as the fixed base, M6 as the active extension, M7 + M8 as bounded additions — not redesigns.

PART 6 — Operations: KPIs, Risks, Open Decisions

6.1 KPI Baseline (replaces alive / partial / dead)

(See METRICS-BASELINE.md for the full per-plane tables.)

Every plane has a throughput, quality, cost, and latency metric. A plane without all four is unmonitored. Anchor targets:

• ActorContext coverage > 99% (Layer 1 / Identity)
• OutcomeEvent emission ≥ 1 per mission step
• Recall hit rate > 75% (Memory)
• Quorum convergence first round > 70% (Cognition)
• RLS-enforced query share > 99% (Identity)
• Cross-tenant data leak incidents = 0 (Immune — zero is the only acceptable number)
• Audit pass rate > 80%
• Self-cert ↔ auditor delta < 10 pts (meta-metric for process bypass)
• Platform Vitality Index > 60 by end Phase 1, > 75 by end Phase 2, > 85 by end Phase 3

6.2 Risk Register

From CRITICAL-REVIEW.md + MARKETING-RECONCILIATION.md + plan_GPT.md §7:

6.3 Open Architectural Decisions (ADRs to write)

PART 7 — End-State Architecture: Architecture Definition of Done

By the end of M8, the architecture is real, not aspirational, when:

1. A user can run work and inspect execution
2. The platform records outcomes canonically (ActorContext + OutcomeEvent everywhere)
3. A mission can be replayed from canonical events with identity and tenant scope intact
4. A routing decision can explain which evidence changed the choice
5. A twin field can be traced back to source events and forgotten by policy
6. The platform can propose bounded improvements with rollback (dry-run, approved, applied, rolled back, audited)
7. A side-lane experiment cannot contaminate main-lane learning until it graduates through governance
8. A cross-tenant read fails in tests and production, not just by convention
9. Governance state can be edited without code changes
10. The Tier-Forbidden floor remains immutable
11. Every marketing claim about learning, isolation, governance, self-improvement maps to a measured platform signal

This is the correct M8 definition of bounded Level-3 autonomy for this platform.

Until then, Conduir has meaningful substrate and a strong design, but not yet the full self-evolving platform promise.

PART 8 — Maintenance & Cross-Reference Index

8.1 Maintenance Contract

• Owner: architecture working group.
• Refresh trigger: capability status change, milestone completion, marketing-page change, audit-cycle outcome, contract version bump.
• Cadence: quarterly minimum (aligned to CAPABILITY-PHASE-SUMMARY refresh); ad-hoc on material change.
• Authority rule: when this doc disagrees with wire-level contracts (08-CONTRACT-SPECS.md) or current C3 baseline (09-FINAL-C3-ARCHITECTURE-DESIGN.md) on fact, the source wins and this doc is updated within one working day.
• Drift detection: quarterly cross-walk table (§3.6) audit; any CAP that has shifted suite, layer, or seam dependency triggers an update.

8.2 What This Doc Supersedes / Defers To

8.3 Conduir-evolution finalised corpus (this workspace)

8.4 Living-system source of truth (maestro-platform/docs/living-system/)

End of compiled master architecture. When this document supersedes its four source drafts, retain the drafts for provenance — they are part of the audit trail of how the architecture was reached.