Meta-Evolution Program: Canonical Overview

Meta-Evolution Program: Canonical Overview

> This document tells the full story of the meta-evolution program: how disconnected evo-cube research was collapsed into a governed architecture program, why that collapse was necessary, and how the wave-based application model replaced unbounded cube generation. It is the entry point for anyone who needs to understand the program without reading the 8+ source files it synthesizes.

What the Meta-Evolution Program Is

The meta-evolution program is the system that governs how architectural research gets generated, organized, and applied to the live codebase. It replaced an earlier mode where evo-cubes (multi-stage architecture analysis documents) were generated as isolated outputs. That earlier mode produced valuable research but no mechanism for turning research into architecture changes. The meta-evolution program exists to close that gap.

The program's control plane lives in `Desktop/evo-cube-output/meta-candidate-mining/` and `Desktop/evo-cube-output/mega-cube-registry.md`. Its operational policy is defined in `architecture-application-roadmap.md`. Its execution history is recorded in the stage files (stage0 through stage3) and the backlog directories.

The Collapse Path: 114 Candidates to 25 Mega-Cubes

Origin: The Stage 0 Survey

The program began with an exhaustive fact inventory of the entire codebase. Stage 0 surveyed 70+ projects, 106 Prefect flows, 34 Claude hook directories, 15 MCP servers, 46+ iOS/macOS apps, 141 Supabase tables, and infrastructure spanning 5 physical machines plus a cloud VM. That survey identified 114 distinct evo-cube candidates across 14 categories: individual apps, backend services, data pipelines, infrastructure, AI/ML systems, knowledge and memory, monitoring, integration layers, revenue surfaces, creative systems, security, developer tooling, cross-system architectures, and additional high-potential threads.

The 114 candidates were not hypothetical. Each had file paths, line counts, gap analysis, and cross-system dependency notes. The survey also identified 10 critical fleet-wide gaps: no canonical source for 12+ projects, no unified event schema, no production deployment map, no continuous ML training loop, no graduation lifecycle, no cross-app progression, no flow dependency graph, no credential rotation, no knowledge graph analytics, and a 30

Why 114 Individual Cubes Was Unworkable

Each evo-cube runs a 4-stage pipeline (research, divergent exploration, compound synthesis, expand + master plan) and produces 9 stage files. Running 114 individual cubes would have produced over 1,000 stage files, taken years, and generated mountains of analysis with no mechanism to reconcile overlapping findings. Many candidates were different angles on the same underlying system. BodyBeat, KineticTheater, Motion+Music, SecuriClaw pose detection, and SkateForge were all asking versions of the same question about a shared motion intelligence substrate. Running them as 5 separate cubes would have produced 5 separate architecture plans for what should be one system.

The Clustering Decision (Stage 2)

Stage 2 collapsed the 114 candidates into 25 mega-cubes by theme. Each mega-cube absorbs 3 to 8 original candidates that share a common architectural question. The clustering was not arbitrary grouping. It followed the principle that candidates should merge when they propose modifications to the same underlying substrate. Every one of the original 114 candidates has an assigned mega-cube in the full registry (recorded in stage3-expand-master-plan.md).

The 25 mega-cubes are:

1. Unified Motion Intelligence
2. Creative Content Platform
3. Voice Intelligence Mesh
4. Agent Economics
5. Knowledge Lifecycle
6. Multi-Agent Protocol
7. App Fleet Lifecycle
8. Comp-Core Production Map
9. Creative Intelligence Triad
10. CRM + Revenue Pipeline
11. Observability + Healing
12. OpenClawHub Next Gen
13. Mesh Infrastructure
14. Data Harness Intelligence
15. Design Intelligence
16. Philosophical Meta-Decision
17. Pane Orchestration
18. Graph + Vector Intelligence
19. Discovery + Trend Intelligence
20. Security + Credentials
21. B2B Product Suite
22. Exo Cluster Intelligence
23. Developer Tooling
24. Dream Journal + Garden
25. Vision + Camera Stack

Each mega-cube has a scope statement defining what candidates it covers, what the unified output should describe, and what the key architectural question is. Each is also tagged with a status (backfilled, partial, or queued) indicating how much usable output already exists.

Tiering by Revenue Distance

Stage 2 also assigned the 25 mega-cubes to 6 priority tiers based on revenue distance and foundational leverage:

• Tier 1 (Revenue + Lifecycle): CRM, App Fleet, Creative Content, Serenity
• Tier 2 (Foundation): Multi-Agent Protocol, Comp-Core, Graph+Vector, Mesh
• Tier 3 (Intelligence): Creative Triad, Voice, Knowledge, Data Harness
• Tier 4 (Platform): OpenClawHub, Pane Orchestration, Discovery, Agent Economics
• Tier 5 (Specialized): Motion, CC-DJ, Design, B2B, Vision
• Tier 6 (Research): Philosophical, Developer Tooling, Dream Journal, Security, Exo Cluster

This tiering was the original execution schedule. Tier 1 and Tier 2 would run in parallel, then Tier 3 and 4, then Tier 5 and 6, across a 12-week timeline producing approximately 225 stage files and 72 SFT training examples.

Why the System Stopped Generating Disconnected Cubes

The tier-based execution plan was sound but it stalled. It stalled because the control-plane files it depended on were never created: no registry file, no priority override mechanism, no cross-synthesis template, and no SFT extraction scaffold. Without these files, each new evo-cube session started from scratch, reconstructed the same context from chat history, and produced output that landed in a folder but never connected to anything else.

Meanwhile, a separate research effort was running. The code4AI backlog mined 54 YouTube videos through the evo3 pipeline, processing 10 full cubes against the live codebase and extracting 334 tasks across approximately 282 hours of estimated effort and 9,330 lines of new code. That effort produced the most important finding in the entire meta-evolution program.

The Code4AI Convergence: Three Independent Bug Discoveries

Three of the 10 code4AI cubes independently discovered the same three critical bugs in the KARL trajectory learning loop:

BUG-1: Null Outcome Signals. 100

BUG-2: Missing Skill Labels. KARL trajectories had no skill labels because no skill inference function existed in trajectory_tap.py. Three cubes (System 3, FlowRL, CARL-KARL) each identified this gap.

BUG-3: Zero Cortex Corrections. The correction_detector never fired, meaning the entire correction feedback path was dead. Cube 5 estimated a 60

This convergence was the inflection point. Three separate research threads, analyzing different external material, all pointed at the same root cause: the learning loop was blind. Every downstream improvement, whether to reward models, routing policies, twin training, or evaluation frameworks, was contaminated because the system could not observe its own corrections or label its own skill usage.

The Architecture Application Decision

The convergence made the answer obvious. The system did not need more cubes. It needed to apply the research it already had. The `architecture-application-roadmap.md` document formalized this as a policy:

> Do not keep generating disconnected cubes. Collapse the research into a linear application program: map completed cubes onto the 25 mega-cube registry, extract only the findings that improve shared architecture, apply those deltas in waves, resume automated cube generation only after the control plane and learning loop are stable.

The roadmap defined four tests for what counts as applicable research:

1. It improves a shared substrate used by multiple systems.
2. It repairs a broken feedback loop, data path, or evaluation path.
3. It removes duplicated architecture by collapsing multiple outputs into one primitive.
4. It unblocks revenue-facing or fleet-facing product surfaces.

If a finding is interesting but does not change a shared substrate, it stays as reference material. This rule converted external research from a folder generator into a routing input.

The Wave-Based Application Model

The roadmap replaced the original tier-based execution plan with a wave-based application model. Waves are not research phases. They are architecture change campaigns. Each wave targets specific files and systems, has defined entry and exit gates, and is sequenced so that later waves consume the primitives created by earlier ones.

Wave 0: Control Plane Recovery

Purpose: Turn meta-mining from a historical plan into an operational program.

Deliverables:
- `mega-cube-registry.md` (the canonical registry of all 25 mega-cubes with status, wave assignment, and output anchors)
- `priority_override.json` (runtime priority surface so new research can change execution order without rewriting the registry)
- `cross-synthesis-template.md` (review scaffold for collapsing completed cube output into shared architecture)
- `extract.py` (SFT extraction entrypoint for converting evo output into training corpus rows)
- A current mapping from existing cube outputs to the 25 mega-cubes

Why it had to come first: The original plan stalled precisely because these files did not exist. Without a registry, every session rebuilt context from chat history. Without a priority override, reprioritization required rewriting the entire plan. Without extraction tooling, completed cube output sat in folders instead of flowing into training data. Wave 0 is infrastructure for the program itself.

Status: Complete.

Wave 1: Learning Loop Integrity

Purpose: Apply the highest-signal external research to the architecture where the stack is currently blind.

Primary source cubes:
- Cube 1: CARL-KARL Trajectory RL
- Cube 4: System 3 Reward-Free RL
- Cube 5: RL2F Cognitive Twin Training
- Cube 9: FlowRL-KARL Integration

Target files:
- `[home-path]`
- `[home-path]`
- `[home-path]`
- `[home-path]`
- `[home-path]`
- `[home-path]`
- `[home-path]`

Exit gate: Corrections are captured, skill labels exist on trajectories, reward calculation uses multiple signals instead of a single narrow metric, and evaluation and export paths are coherent enough to trust.

Why KARL/Cortex came first: This is the central design decision of the wave model and it deserves full explanation.

The code4AI backlog discovered three convergent critical bugs (null outcomes, missing skill labels, zero corrections) all pointing at the same root cause: the learning loop was blind. KARL could record trajectories but could not observe whether they succeeded. Cortex could detect patterns but could not feed corrections back into training data. The bridge between them did not function.

This blindness was not a local problem. It was a systemic contamination source. Every system downstream of the learning loop, including reward models, SFT export, twin fine-tuning, routing policies, and evaluation frameworks, was operating on data that lacked outcome signals, skill labels, and correction feedback. Fixing any of those downstream systems first would have been wasted work because they would still consume blind data.

Additionally, three cubes proposed modifications to `reward_engine.py` from different angles (verification signals, process fingerprints, entropy bonuses). Two cubes proposed modifications to `sft_exporter.py` (quality filtering, distribution-proportional sampling). These overlapping proposals had to be reconciled into unified implementations before any of them could be applied. Reconciliation only makes sense after the data quality bugs are fixed, because otherwise you are reconciling reward models that score null inputs.

Wave 1 is the foundation. Every later wave assumes the learning loop works.

Wave 2: Shared Runtime Primitives

Purpose: Apply cube findings that should become shared runtime layers instead of remaining local experiments.

Primary mega-cubes: Multi-Agent Protocol (#6), Comp-Core Production Map (#8), Observability + Healing (#11), Mesh Infrastructure (#13), Pane Orchestration (#17), Graph + Vector Intelligence (#18), Security + Credentials (#20).

Key rule: When two cubes propose modifications to the same substrate, merge them into a single primitive before touching product surfaces.

Exit gate: One transport story, one infrastructure map, one pane scheduler story, one security observation layer, one retrieval and memory substrate story.

Wave 3: Product Architecture Roll-Forward

Purpose: Apply shared substrates to the product and revenue surfaces that already have meaningful output anchors.

Primary mega-cubes: Creative Content Platform (#2), App Fleet Lifecycle (#7), Creative Intelligence Triad (#9), CRM + Revenue Pipeline (#10), OpenClawHub Next Gen (#12), Dream Journal + Garden (#24).

Key rule: No product wave invents a new substrate that Wave 1 or Wave 2 was supposed to own. Product waves consume shared primitives. They do not replace them.

Wave 4: Factory Activation

Purpose: Only after Waves 1-3 are real, resume automation around meta-mining.

What gets activated: The evo_cube_factory.py flow, scheduled cross-synthesis reviews, SFT corpus export from approved outputs, and priority overrides driven by new research intake.

Key rule: Factory output is draft quality until it passes the same cross-synthesis and architecture-fit checks as manual outputs.

The Broader Backlog

The meta-evolution program is not the only source of architecture tasks. The broader evo-cube backlog consolidates tasks from all 11 completed evo-cubes (the original 10 plus meta-candidate mining itself): 382 total tasks spanning approximately 11,540 lines of new code. The code4AI batch adds another 334 tasks from its 10 cubes. Together, these backlogs represent over 700 actionable tasks, but the wave model governs which ones get applied and in what order.

The backlogs are organized into multiple views: all tasks by cube, tasks grouped by priority tier, and quick wins (tasks completable in under one day). The quick wins file is particularly important because it contains the 77 code4AI tasks (approximately 62.75 hours) that can be executed immediately, including the 3 critical learning loop bugs that justified starting with Wave 1.

How New Research Enters the System

The roadmap defines a 5-step intake rule for any new video, transcript, or external research:

1. Ingest the transcript into the research archive.
2. Map the insight to an existing mega-cube.
3. If it changes execution order, write an entry in `priority_override.json`.
4. If it changes shared architecture, record it in the next cross-synthesis review.
5. Only create a brand-new cube if no existing mega-cube can absorb it cleanly.

This makes external research a routing input, not a folder generator. The goal is not more cubes. The goal is a better architecture.

Canonical File Index

For quick orientation, these are the files that define the current operating state of the meta-evolution program:

Summary

The meta-evolution program went through three phases:

1. Unbounded generation (pre-collapse). Evo-cubes were generated as isolated architecture analyses. Each produced 9 stage files. 10 cubes were completed, producing 90 stage files and 382 extracted tasks. The output was valuable but disconnected. Nothing governed how findings became architecture changes.

2. Survey and collapse (stage 0 through stage 3). A comprehensive survey identified 114 candidates across the entire codebase. Those candidates were clustered into 25 mega-cubes by theme. A tiered execution plan was proposed. That plan stalled because the control-plane files it depended on were never created.

3. Wave-based application (current). The code4AI backlog found three convergent critical bugs proving the learning loop was blind. That convergence triggered the policy decision: stop generating cubes, start applying architecture deltas. Wave 0 created the control plane. Wave 1 targets the learning loop. Waves 2 and 3 build shared runtime primitives and product surfaces. Wave 4 re-enables automated generation only after the architecture is stable enough to benefit from it.

The system evolved from producing research to applying it. That is the meta-evolution.