Phase Roadmap: When the World Comes Alive

Colibri evolves through eight phases, each adding new concepts and new guarantees. This document maps the journey from Phase 0 (execution core) through Phase 8 (persistent identity). For each phase, it describes which concepts activate, which tools appear, what code is written, and what the world gains.

Phase 0: Execution Core (R75, sealed 2026-04-18)

Status: Complete. Sealed: 2026-04-18 at R75 (5 rounds ahead of the planned R75–R80 range).

Concepts active: α β γ δ ε ζ η · ν (partial)

What it does:

Phase 0 is the bootstrap. The MCP server boots, the database initializes, and a single executor (Claude) can run tasks from start to finish. Every task flows through the β FSM, every decision is recorded in ζ, and every session is sealed with a Merkle proof.

Code targets (28 tasks):

Task	Concept	Target files	Effort
P0.1	Infrastructure	`package.json`, `tsconfig.json`, `jest.config.ts`, `.github/workflows/ci.yml`	4 subtasks
P0.2	α System Core	`src/server.ts`, `src/db/`, `src/middleware/`	4 subtasks
P0.3	β Task Pipeline	`src/domains/tasks/fsm.ts`, `schema.ts`, `tools.ts`, `writeback.ts`	4 subtasks
P0.4	γ Lifecycle	`src/server.ts` boot/shutdown, tests	2 subtasks
P0.5	δ Router stub	`src/domains/router/` (Claude-only, constant scoring)	2 subtasks
P0.6	ε Skills	`src/domains/skills/loader.ts`, `dispatcher.ts`, `hooks.ts`	3 subtasks
P0.7	ζ Decision Trail	`src/domains/trail/`, hash-chained records	3 subtasks
P0.8	η Proof Store	`src/domains/proof/`, SHA-256 tree	3 subtasks
P0.9	ν Integrations	GitHub Desktop + Obsidian sync bridges	3 subtasks

Total: 28/28 subtasks shipped in 9 groups, all in R75 (1 round vs the planned 6).

Group-level completion:

✅ P0.1 Infrastructure (package.json, tsconfig.json, jest.config.ts, CI)
✅ P0.2 α System Core (src/server.ts, src/db/, inlined 5-stage middleware)
✅ P0.3 β Task Pipeline (src/domains/tasks/)
✅ P0.4 γ Lifecycle (boot/shutdown + mode detection)
✅ P0.5 δ Router stub (src/domains/router/ — library-only Phase 0 stubs per ADR-005 §Decision; router_* MCP tools + multi-model logic deferred to Phase 1.5)
✅ P0.6 ε Skills (src/domains/skills/ — loader + dispatcher + hooks + capability index)
✅ P0.7 ζ Decision Trail (src/domains/trail/ — hash-chained records)
✅ P0.8 η Proof Store (src/domains/proof/ — SHA-256 Merkle tree)
✅ P0.9 ν Integrations (library-only starters)

Key deliverables:

MCP server that boots and connects to an MCP client
SQLite database with low-tens-table schema (not the 78-table AMS donor figure)
Total MCP tool surface shipped: 14 MCP tools (β × 5, ε × 1, ζ × 2, η × 2, α/γ system × 2, audit × 2) per ADR-004 R75 Wave H amendment; the earlier 19-tool R74.5 plan was pruned during Waves H + I
Decision trail with hash-chained thought_record entries
Merkle tree sealing every session
Obsidian sync (pull-based via robocopy)
GitHub integration (branch + commit logging)

Concept maturity after Phase 0 seal:

8 of 15 Greek concepts ship code at colibri_code: partial (α β γ δ ε ζ η ν)
7 remain colibri_code: none (θ ι κ λ μ ξ π) — spec-only for later phases
ADR-006 defines partial as the correct graduation for a Phase 0 slice; complete is reserved for concepts whose full phased spec has shipped

World gains:

Traceable work: every task is recorded with a decision trail
Cryptographic anchor: sessions are sealed with Merkle roots
Reproducible audits: the full chain of reasoning is stored and verifiable
Single-node stability: Phase 0 is not P2P; one MCP server, one SQLite database

Database schema snapshot (illustrative):

mcp_tasks
  id PK, status, task_num, title, created_by_agent, assignee, 
  state (β FSM), timestamp, parent_round

mcp_rounds
  id PK, round_num (R75, R76, ...), phase (A, W, B), 
  manifest, writeback, merkle_root

mcp_sessions
  id PK, session_num, seal_document, root_hash, 
  created_at, completed_at

mcp_thought
  id PK, session_id FK, previous_hash, content, 
  timestamp, hash (SHA-256)

mcp_merkle_tree
  id PK, leaf_hash, left_hash, right_hash, root_hash, 
  level, position

mcp_vcs_events
  id PK, event (commit, branch, pr), 
  sha, branch_name, timestamp

mcp_obsidian_sync
  id PK, sync_time, files_synced, conflict_strategy, 
  result

Constraint: No AMS_* environment variables are read. Phase 0 uses COLIBRI_MODE and COLIBRI_* only.

Definition of done (achieved at R75 seal, 2026-04-18):

✅ All 28 subtasks done with writeback (28/28 non-deferred)
✅ npm test + npm run lint + npm run build pass (1084 tests / 26 suites on d5f6a1ff)
✅ MCP server boots cleanly, connects to client, executes tool chain
✅ Full task lifecycle (INIT → DONE) demonstrated and Merkle-sealed
✅ Session seal document created with Merkle root
✅ GitHub PR merges cleanly to main (Waves A–I, 2026-04-16 → 2026-04-18)

Note on round-to-phase mapping: Phase 0 completed in a single round (R75) with 9 waves (A–I). Subsequent phases may similarly compress depending on agent throughput; the R81–R90 range for Phase 1 is a planning estimate, not a hard schedule.

R76 bridge round (Phase 0 → 1 transition, 2026-04-19, SEALED)

Status: Sealed 2026-04-19 at merge commit ae0b78ec via PR #164. Bridged R75’s Phase 0 seal to the R81 Phase 1 kickoff. No code deltas — hygiene, planning, and ceremony only.

Scope:

Hygiene cleanup — .claude/skills/ mirror resync (9 canon skills diverged post-Wave H), colibri-verification rewrite (saturated with donor refs beyond Wave H strikes), HERITAGE tagging for stragglers, docs/inventory-r74-2.md dangling refs, Sigma skill stub, 22→23 skill count reconciliation (1 new skill added in Wave 2).
Phase 1 planning prep — κ Phase 1 task prompts (../guides/implementation/task-prompts/p1.1-kappa-rule-engine.md), δ Phase 1.5 router-graduation plan (../guides/implementation/task-prompts/p1.5-delta-router-graduation.md), this roadmap reconciliation.
Phase 0 ceremony — session seal (s8), Merkle anchor of the full Phase 0 seal evidence.

PRs in range: #152–#164 (Wave 3 + Wave 4 hygiene + planning + ceremony).

Exit: R76 closes when all three tracks are merged and the Obsidian vault mirror is synced.

R77 pages-finish round (post-Phase-0 hygiene, 2026-04-19, SEALED)

Status: Sealed 2026-04-19 at merge commit 77e579b8 via PR #171. Zero code deltas; tests remained 1085/1085 green.

Scope: R77 shipped the GitHub Pages long-tail cleanup from the R76 Pages audit. Hero ring Greek links, section index coverage, sidebar rendering, mirror drift, and CLAUDE.md §9.2 doc counts all converged to post-seal reality in a single round.

Pre-round hotfixes (2026-04-19 AM):

PR #165 — colibri-hero.js rewrite; Greek ring now points at real concept URLs (γ → 2-plugin/modes.md, ν → 4-additions/index.md).
PR #166 — 10 missing section index.md files created; previously-404 folder URLs now return 200.

Wave 1 (three parallel T3 executors):

PR #167 — .claude/skills/ mirror resync against the .agents/skills/ canon.
PR #168 — broken-ref cleanup + _config.yml pin of just-the-docs@v0.12.0.
PR #169 — sidebar frontmatter reconciliation across 80 files so Pages renders the docs tree as a tree (was flat).

Wave 2 (serial):

PR #170 — CLAUDE.md §9.2 doc-count reconcile on git-tracked semantics (post-Wave-1 counts at e2305277).

Phase B seal: PR #171.

Symbolic Merkle root: 38a39b7d6425d9d0bcc993799bbc72f9202e4afd6fad21769dbb864e4ab8cdc6

Key outcome: Pages sidebar renders as a tree (was flat); theme pinned to just-the-docs@v0.12.0; 3 mirror skills resynced; §9.2 counts reconciled on git-tracked semantics. No src/ deltas — R77 is a documentation + Pages round only.

Phase 1: Rule Engine (R81–R90, ~8 weeks, planned)

Status: In progress — Wave 1 opened 2026-04-19. Kickoff: R81 (active). Task prompts at ../guides/implementation/task-prompts/p1.1-kappa-rule-engine.md (landing in R76.P1 sibling PR).

Concepts active: κ (full) · ν (partial, webhooks)

What it does:

Rules become first-class. The system can express “when X happens, do Y” as a deterministic, auditable rule. Every node in a future P2P network will evaluate the same rule the same way. Rules are the foundation of every legitimacy layer that follows.

Code targets (estimated 20 tasks):

Module	What it adds	Lines
`src/rules/integer-math.js`	bps_mul, bps_div, decay, isqrt, ilog2	~200
`src/rules/dsl-parser.js`	PhoenixDSL class, 8 built-ins	~500
`src/rules/engine.js`	rule execution, guard/effect parsing	~800
`src/rules/admission.js`	AAL: token bucket, reputation, stake	~600
`src/rules/governance.js`	rule versioning, constitutional anchoring	~400

New tools:

rule_apply — execute a rule against an event
rule_create — author a new rule (governance only)
rule_list — enumerate active rules
rule_evaluate_test — test a rule against a corpus before activation

Sample rule:

rule AcceptCommitment {
  guard:
    event.type == "CommitmentAccepted"
    AND commitment.status == "open"
    AND actor.stake.available >= commitment.required_stake

  effects:
    state.transition(commitment, "active")
    stake.freeze(actor, commitment.required_stake)
    obligation.assign(actor, "deliver", commitment.deadline)
}

World gains:

Determinism: every node can evaluate the same input and reach the same conclusion
Auditability: rule execution is logged and Merkle-sealed
Admission control: rules gate which agents can submit which actions
Foundation for consensus: Phase 3 consensus validates rule evaluation

Definition of done:

Rule parser (DSL → AST) complete
Execution engine (AST → effects) complete
10 built-in rules specified and tested
Rule versioning (rule changes do not break old nodes)
Admission Layer operational

Phase 1.5: Multi-Model Router (R91–R100, ~6 weeks, planned)

Status: Planned. Kickoff: R91+ (pending Phase 1 κ completion and multi-model trigger conditions per ADR-005 §Implementation). Task prompts at ../guides/implementation/task-prompts/p1.5-delta-router-graduation.md (landing in R76.P2 sibling PR).

Concepts active: δ (full)

What it does:

Phase 0 assumes Claude only. Phase 1.5 opens the gates. The router evaluates each task and scores 8 model candidates: Claude 3.5 Sonnet, Kimi, Codex, GPT-4, GPT-4o, LLaMA, Mixtral, others. The highest-scoring model wins. The decision is logged to ζ.

Code targets (estimated 8 tasks):

src/domains/router/
  ├── scoring.ts     — 8 model candidates, composite score
  ├── models.ts      — model profiles (cost, latency, strengths)
  ├── feedback.ts    — outcome logging, weight updates
  ├── cache.ts       — recent routing decisions
  └── tools.ts       — router MCP tools

New tools:

router_score_task — evaluate a task, return ranked model list
router_call — execute a task with the selected model
router_feedback — log outcome, update weights

Scoring dimensions:

Task complexity (token count, instruction length, reasoning required)
Domain expertise (code, math, narrative, vision)
Token budget (cost per 1K tokens)
Latency tolerance (p50 ms response time)
Availability (some models may be down)

World gains:

Cost optimization: simple tasks route to cheaper models
Capability matching: complex reasoning tasks route to Sonnet
Latency control: time-sensitive tasks route to fast models
Feedback loop: outcomes improve future routing

Definition of done:

Router scores tasks correctly against 8 models
Decision and outcome logged to ζ
Weights updated based on outcomes
Cost-benefit analysis shows 20–30% token savings vs. always-Claude

Phase 2: Reputation (R101–R120, ~12 weeks, planned)

Status: Specified. docs/concepts/λ-reputation.md complete. Not yet scheduled.

Concepts active: λ (full)

What it does:

Agents become persistent. Every agent (executors, Sigma, PM, future humans) gets an identity key and a reputation score. Reputation is computed per domain and decays without activity. Fraud leaves an irreversible scar.

Code targets (estimated 20 tasks):

src/domains/reputation/
  ├── scoring.ts      — 5 domains, decay scheduler
  ├── tokens.ts       — L0–L2b token lifecycle
  ├── limits.ts       — derived limits (parallel tasks, rate bonuses)
  ├── scars.ts        — fraud registry, irreversible marks
  ├── agents.ts       — agent identity + key management
  └── tools.ts        — reputation MCP tools

Five reputation domains:

Domain	Measures	Decay	Scar triggers
Execution	Task completion on time	5% / epoch	Missed deadlines, low quality
Commissioning	Brief quality	3% / epoch	Vague tasks, scope creep
Arbitration	Dispute resolution	10% / epoch	Biased decisions
Governance	Rule participation	4% / epoch	Voting against consensus
Social	Community behavior	2% / epoch	Hostile communication

New tools:

reputation_score — query agent reputation
reputation_update — apply event (task done, scar assigned)
reputation_decay — periodic decay scheduler
reputation_limit_check — can this agent do this action? (gates by stake, rate, etc.)

Experience tokens:

L0 (local): issued for completing work, non-transferable
L1: promoted from L0 after external verification
L2a / L2b: domain-specific advanced tokens, transferable to other nodes (Phase 3+)

Scars (permanent):

Cap reduction: max achievable reputation decreases
Domain ban: permanently excluded from domain
Follows identity across forks (Phase 5+)

World gains:

Trustworthy agents: reputation enables P2P consensus (Phase 3)
Accountability: agents cannot hide fraud; scars are public
Graduated roles: only high-rep agents can commission tasks or vote
Incentive alignment: agents are rewarded for good behavior

Definition of done:

Reputation computed per domain
Decay scheduler runs per epoch
Scars are irreversible
L0/L1 tokens issued and tracked
Rate limits enforced based on reputation

Phase 3: Consensus (R121–R150, ~15 weeks, planned)

Status: Specified. docs/concepts/θ-consensus.md complete. Not yet scheduled.

Concepts active: θ (full) · T1/T2 operationalized

What it does:

Phase 0–2 is single-node. Phase 3 turns Colibri into a P2P network. Nodes gossip about events. Arbiters sign votes. Quorum must agree before events finalize. Byzantine Fault Tolerance tolerates up to (n-1)/3 faulty nodes.

Code targets (estimated 30 tasks):

src/consensus/
  ├── voting.ts        — QuorumCalculator, equivocation detection
  ├── finality.ts      — 5 finality levels, FinalityVote
  ├── gossip.ts        — Bloom filter, adaptive fanout, Triple-Anchor
  ├── time-anchors.ts  — signed timestamps, median clock
  ├── vrf.ts           — VRF proof for arbiter rotation
  └── tools.ts         — consensus MCP tools

Five finality levels:

Level	Meaning	Reversible?
PENDING	Just proposed	Yes
SOFT	Some votes received	Yes
QUORUM	Threshold reached (>2/3)	Yes (dispute window)
HARD	Dispute window closed (100+ epochs)	Only via new events
ABSOLUTE	Full irreversibility	No

Quorum formula:

quorum = floor(2n / 3) + 1

Example: 7 nodes → quorum 5 (tolerates 2 faulty)

Byzantine protections:

Equivocation detection: two signatures on contradicting votes = proof of fault
Gossip validation: triple-anchor check (rule version + state root continuity + fork ID)
Time anchors: high-rep arbiters publish signed timestamps; nodes detect clock drift
VRF rotation: arbiter selection is pseudorandom and verifiable

New tools:

consensus_propose — propose an event
consensus_vote — sign a vote
consensus_finality — query finality level
consensus_gossip — exchange state with peer nodes

World gains:

Byzantine tolerance: network survives up to 33% faulty nodes
Verifiable consensus: every vote is signed and auditable
Decentralization: Phase 0–2 single-node becomes multi-node P2P
True P2P: T1 (Sigma) and T2 (PM) move from external to internal

Definition of done:

Quorum voting implemented and tested
Equivocation detection works
Gossip protocol runs
Time anchors synchronized
BFT simulation passes (test corpus with faulty nodes)

Phase 4: Integrity Monitor (Later, ~8 weeks)

Status: Specified. docs/concepts/μ-integrity-monitor.md complete. Not yet scheduled.

Concepts active: μ (full)

What it does:

Self-checks for logical traps, coercion patterns, and axiom drift. Three advisory roles: Translator (language → commands), Sentinel (injection/coercion detection), Guide (state explanation). These are read-only advisors; they cannot veto but can warn.

Code targets (estimated 15 tasks):

src/domains/integrity/
  ├── circular-logic.ts  — dependency DAG, cycle detection
  ├── coercion-trap.ts   — enumerate actions, flag negative outcomes
  ├── axiom-drift.ts     — rule change tracking, warn before limits
  ├── translator.ts      — NLP → structured commands
  ├── sentinel.ts        — injection pattern scanner
  ├── guide.ts           — state explanation generator
  └── tools.ts           — advisory MCP tools

Three detection types:

Circular logic: task A depends on B, B depends on A → reject
Coercion trap: all outcomes are negative for a participant → warn
Axiom drift: constitutional parameters changing too fast → warn

World gains:

Self-awareness: system can detect its own logical errors
Participant protection: coercion is detected and flagged
Constitutional protection: axiom drift is tracked

Definition of done:

Circular dependency detection working
Coercion detection returns low false positive rate
Axiom drift warnings trigger correctly

Phase 5: State Fork (Later, ~10 weeks)

Status: Specified. docs/concepts/ι-state-fork.md complete. Not yet scheduled.

Concepts active: ι (full)

What it does:

Nodes gain the right to exit. If a node disagrees with the network, it can fork its state and continue independently. Forks are cryptographically identified. Reputation and identity keys follow you across forks.

Code targets (estimated 20 tasks):

src/domains/fork/
  ├── fork-id.ts         — compute fork ID from divergence event
  ├── fork-state.ts      — snapshot state at divergence
  ├── isolation.ts       — three isolation modes (ISOLATED, READ_ONLY_PARENT, BRIDGED)
  ├── checkpoint.ts      — 7 of 10 arbiters sign checkpoints
  ├── merge.ts           — two forks rejoin protocol
  ├── history.ts         — fork genealogy
  └── tools.ts           — fork MCP tools

Fork ID formula:

fork_id = SHA-256(parent_fork_id + divergence_event_id + rule_version_hash + reason)

What stays shared across forks:

Identity keys (Ed25519 keypairs)
Constitutional axioms (S01)

What forks independently:

Event log
Reputation scores
Token balances
Rule set
BFT consensus state

Isolation modes:

Mode	See parent?	Write to parent?
ISOLATED	No	No
READ_ONLY_PARENT	Yes	No
BRIDGED	Selective	Selective

Merge protocol: timestamp ordering (default), reputation-weighted voting, or manual intervention.

World gains:

Exit right: no network can hold you hostage
Sovereignty: you control your fork, rules, and data
Continuity: your identity and reputation follow you
Reversibility: forks can merge if the reasons change

Definition of done:

Fork ID computation verified
State snapshots work
Merge protocol tested (two forks rejoin)
Identity keys persist across fork boundary

Phase 6: Governance (Later, ~12 weeks)

Status: Specified. docs/concepts/π-governance.md complete. Not yet scheduled.

Concepts active: π (full)

What it does:

Rules can change, but only through supermajority voting and with constitutional protection. Seven immutable axioms cannot be voted away. Rate limits prevent rapid rule changes. Rule versions enable gradual rollout.

Code targets (estimated 25 tasks):

src/domains/governance/
  ├── voting.ts          — two voting tracks, supermajority thresholds
  ├── axioms.ts          — seven constitutional axioms (S01)
  ├── proposals.ts       — rule proposal + voting period
  ├── versioning.ts      — rule versions, gradual activation
  ├── change-limits.ts   — rate limits on parameter changes
  ├── test-corpus.ts     — before/after rule validation
  └── tools.ts           — governance MCP tools

Seven constitutional axioms (S01) — immutable:

Append-only events
Derived reputation
No absolute authority
Consequence windows
Subjective finality
Right to exit (max 10% penalty)
Technical sovereignty

Two voting tracks:

Constitutional-adjacent: >80% supermajority, 3-stage voting (30-day intervals)
Non-constitutional: >66% quorum, public discussion period

Rate limits on change:

Maximum ±10% change to any single reputation parameter per 6 months
Minimum 2-epoch stability period after change to same parameter
Old and new rule versions must produce identical results on test corpus before activation

Permanent prohibitions (cannot be voted away):

Administrative access to bypass rules
Anonymous reputation resets
Retroactive rule application
Machine-only capital sanctions (human must be in loop)

World gains:

Democratic change: agents vote on rules that affect them
Constitutional protection: core axioms cannot be abandoned
Gradual rollout: rule versions enable safe upgrades
Transparency: voting is public and auditable

Definition of done:

Supermajority voting works correctly
Constitutional axioms enforced at all times
Rule change rate limits enforced
Test corpus validation before activation

Phase 7: Integrations & Intelligence (Later, ~15 weeks)

Status: Partially specified. See extensions.md. Not yet scheduled.

Concepts active: ν (full) · δ (AI intelligence suite)

What it does:

Full plugin system with worker thread isolation. Real-time CRDT/OT vault sync via Yjs + WebSocket. 24-module AI intelligence stack: semantic cache, query optimizer, pattern recognizer, intent classifier, scheduler, predictor.

Code targets (estimated 40 tasks):

src/domains/integrations/
  ├── plugins/
  │   ├── plugin-loader.ts       — worker thread isolation
  │   ├── plugin-db-sandbox.ts   — restricted DB access
  │   ├── plugin-registry.ts     — plugin inventory
  │   └── tools.ts               — plugin_invoke, plugin_list
  │
  ├── vault-sync/
  │   ├── crdt-sync.ts           — Yjs + WebSocket real-time
  │   ├── conflict-resolution.ts — 3-way merge strategy
  │   └── webhooks.ts            — push notifications
  │
  └── ai-intelligence/
      ├── semantic-cache.ts       — embedding cache
      ├── query-optimizer.ts      — plan optimization
      ├── pattern-recognizer.ts   — recurring patterns
      ├── intent-classifier.ts    — what does agent want?
      ├── scheduler.ts            — optimal execution order
      └── predictor.ts            — outcome forecast

World gains:

Extensibility: users can write plugins
Real-time collaboration: vault updates push live
AI augmentation: 24-module intelligence suite
Cost optimization: semantic cache, query optimization, scheduling

Definition of done:

Plugin system runs in worker threads, cannot crash main process
CRDT sync works, conflicts resolved correctly
Semantic cache reduces token costs
All 24 AI modules operational

Phase 8: Identity — Soul Vector (Later, ~15 weeks)

Status: Specified. docs/concepts/ξ-identity.md complete. Not yet scheduled.

Concepts active: ξ (full)

What it does:

The final piece. Every agent carries an Ed25519 keypair — their soul vector. The key persists across forks, sessions, and even if the node goes offline for months. Your identity is cryptographically bound to your history. You can prove you did something; you can sign contracts; you can be held accountable.

Code targets (estimated 20 tasks):

src/domains/identity/
  ├── keypair.ts          — Ed25519 generation, storage
  ├── signing.ts          — sign/verify operations
  ├── recovery.ts         — Shamir secret sharing (backup)
  ├── migration.ts        — identity across forks
  ├── soul-vector.ts      — complete identity bundle
  ├── attestation.ts      — third-party identity verification
  └── tools.ts            — identity MCP tools

What soul vector contains:

Ed25519 keypair (public + private)
8 soul domains (execution, commissioning, arbitration, governance, social, + 3 custom)
Reputation in each domain (inherited across forks)
Experience tokens
Scars (permanent, irreversible)
Fork history (genealogy)

Shamir recovery: keypair split into 5 shards, need 3 to recover. Enables backup without single point of failure.

Migration: when you fork, your identity keypair moves with you. Your new node signs a genesis event with your key, proving continuity.

Attestation: other high-rep agents can attest to your identity, strengthening your reputation.

World gains:

Persistent identity: you are not ephemeral
Accountability: you can be held responsible for past actions
Cross-fork continuity: your history follows you
Cryptographic binding: your actions are signed and verifiable
Social trust: high-rep agents can vouch for you

Definition of done:

Keypair generation and signing work
Recovery via Shamir shards works (3 of 5)
Identity persists across fork boundary
Soul vector contains all 8 domains
Attestation protocol works

Phase Dependency Graph

Phase 0   (execution core)
    ↓
Phase 1   (rule engine)
    ↓
Phase 1.5 (multi-model router)
    ↓
Phase 2   (reputation)
    ↓
Phase 3   (consensus)
    ↓
Phase 4   (integrity monitor)
Phase 5   (state fork)
Phase 6   (governance)
    ↓
Phase 7   (integrations + AI intelligence)
    ↓
Phase 8   (identity soul vector)

Phase 0 is the critical path. Phases 1–3 are sequential and unlock Phase 3’s P2P consensus. Phases 4–6 can largely overlap with each other and with Phase 2–3. Phase 7 can run in parallel. Phase 8 depends on all others being stable.

Compression note: Phase 0 shipped in 1 round (R75) against a 6-round plan. Subsequent phases may also compress if the single-agent / high-throughput pattern continues; the calendar in the Timeline Estimate below should be read as a planning ceiling rather than a floor.

Timeline Estimate

Phase	Rounds	Weeks	Calendar
0	R75 (sealed 2026-04-18)	1 round vs 6 planned	Apr 2026
1	R81–R90	8	May–Jul 2026
1.5	R91–R100	6	Jul–Aug 2026
2	R101–R120	12	Aug–Nov 2026
3	R121–R150	15	Nov 2026–Feb 2027
4–6	R151–R200	25	Feb–Aug 2027
7	R201–R215	8	Aug–Oct 2027
8	R216–R230	8	Oct–Dec 2027
Total	230 rounds	~88 weeks	Apr 2026–Dec 2027

This is a rough estimate. Actual timelines depend on parallel work, team velocity, and unforeseen complexity.

Phase Roadmap: When the World Comes Alive

Phase 0: Execution Core (R75, sealed 2026-04-18)

R76 bridge round (Phase 0 → 1 transition, 2026-04-19, SEALED)

R77 pages-finish round (post-Phase-0 hygiene, 2026-04-19, SEALED)

Phase 1: Rule Engine (R81–R90, ~8 weeks, planned)

Phase 1.5: Multi-Model Router (R91–R100, ~6 weeks, planned)

Phase 2: Reputation (R101–R120, ~12 weeks, planned)

Phase 3: Consensus (R121–R150, ~15 weeks, planned)

Phase 4: Integrity Monitor (Later, ~8 weeks)

Phase 5: State Fork (Later, ~10 weeks)

Phase 6: Governance (Later, ~12 weeks)

Phase 7: Integrations & Intelligence (Later, ~15 weeks)

Phase 8: Identity — Soul Vector (Later, ~15 weeks)

Phase Dependency Graph

Timeline Estimate

See Also