5 — Time: How the World Ages

Time in Colibri flows at three zoom levels, each with its own structure, agents, and records. The smallest unit is the task (hours). Multiple tasks are grouped into a round (days). Multiple rounds form a session (months). Together, these three levels create a coherent timeline of work flowing from intent through execution and into permanence via cryptographic sealing.

Three Zoom Levels

Level 1: Task (Hours)

A task is a unit of work assigned to a single executor. It has:

  • Entry point: the executor receives a task ID, a prompt, and a worktree path
  • Pipeline: the task moves through 8 states in the β FSM
  • 5-step chain: audit → contract → packet → implement → verify
  • Output: source code changes, documentation, and a thought_record (mandatory)
  • Duration: 1–4 hours typical; up to 8 hours for complex features
  • Seal: the task is Merkle-sealed and closed

The β FSM states:

INIT → GATHER → ANALYZE → PLAN → APPLY → VERIFY → DONE
                                                   ↘ CANCELLED

Every state transition is a mutation (a tool call), which triggers:

  • Validation (schema check)
  • Audit (entry into α middleware)
  • Dispatch (the actual state change)
  • Recording (ζ record added)
  • Hashing (added to the Merkle tree)

Level 2: Round (Days)

A round is a batch of tasks executed in coordinated waves. It has:

  • Entry point: Sigma (T1) receives a human-authorized intent
  • Phase A — plan: Sigma reads state and writes a manifest (slices, owners, dependencies)
  • Phase W — waves: PM (T2) dispatches executors in 5 sequential waves
    • Wave 1: Governance (specs, ADRs, rules)
    • Wave 2: Runtime (α β γ core)
    • Wave 3: Domain (δ ε ζ η intelligence + proof)
    • Wave 4: Integrations (ν GitHub, Obsidian, API)
    • Wave 5: Test / CI / Docs (verification surface)
  • Wave gates: Wave N+1 cannot start until Wave N writeback is complete
  • Phase B — seal: Sigma audits the round, verifies all tasks closed, runs merkle_finalize
  • Output: a PR (merged by human), a round commit, and a session-level ζ reflection
  • Duration: 1–3 days typical
  • Seal: the round is sealed with a commit and documented in docs/ or docs/session-seal-sN.md

Each round owns one branch namespace: feature/rNN-<theme>.

Level 3: Session (Months)

A session is a coherent arc of 5–15 rounds sharing a single theme. It has:

  • Entry point: the human (T0) authorizes a session theme
  • Rounds: 5–15 rounds, each sealed by Sigma
  • Output: source code, specs, tutorials, skills, verified concepts
  • Final seal: a docs/session-seal-sN.md document
  • Merkle root: the final root hash covering all tasks and rounds
  • Duration: 1–3 months typical
  • Archive: the session is closed; subsequent work happens in a new session

Session history to date:

Session Rounds Theme Status
1 R01–R10 Baseline + donor absorption Complete
2 R11–R20 Deep dives, spec verification Complete
3 R21–R36 Neutralization, Greek vocabulary Complete
4 R37–R42 Soul Vector ξ, Governance π Complete
5 R43–R52 Target-design reframe, extractions Complete
6 R53–R72, R73 src/ deletion, master context, R73 unification Active
7 R75–R80 (planned) Phase 0 execution Planned

The Master Flow (15 Steps)

Every unit of work, from intent to seal, flows through a fixed sequence. This is the 15-step master flow:

  1. T0 intent: Human decides what needs to be done and why
  2. T1 manifest: Sigma reads state and writes Phase A manifest (slices, owners, dependencies)
  3. T2 startup: PM runs Chain 0 Bootstrap (unified_init, unified_vitals, unified_set_project, task_next_actions)
  4. T2 promote: PM promotes backlog tasks to todo (only tier with this authority)
  5. T2 dispatch: PM spawns T3 executor with task ID, worktree, branch name
  6. T3 audit: Executor reads task, verifies branch and context
  7. T3 contract: Executor writes a behavioral contract (audit document)
  8. T3 packet: Executor writes an execution plan (packet document)
  9. T3 implement: Executor makes code changes, writes, commits
  10. T3 verify: Executor tests the change, documents verification
  11. T3 writeback: Executor calls task_update(status=done) + thought_record, pushes branch
  12. T2 verify writeback: PM checks task update and thought record exist
  13. T1 phase-b: Sigma runs merkle_finalize and audit_verify_chain on the round
  14. T1 seal: Sigma creates round commit and documents round in session seal
  15. T0 merge: Human reviews PR and merges to main

At step 15, the work is permanent. The commit is on main. The Merkle root has advanced. The round is sealed.

Phase Progression (Phases 0–8)

Colibri does not ship all at once. It evolves through 8 phases. Each phase brings new concepts to life and new guarantees to the system.

Phase Activation Concepts What the world gains
0 R75–R80 α β γ ε δ ζ η ν(partial) Task pipeline, decision trail, Merkle proofs, skill registry, Obsidian + GitHub sync
1 R81–R90 (planned) κ Deterministic rule engine, DSL, admission layer (what agents can do)
1.5 R91–R100 (planned) δ full Multi-model routing — Claude, Kimi, Codex, GPT-class scoring
2 Later λ Persistent reputation, 5 domains, experience tokens, scars
3 Later θ P2P consensus, Byzantine voting, equivocation detection
4 Later μ Integrity monitoring, self-checks, coercion detection
5 Later ι State forking, exit right, merge protocol
6 Later π Governance voting, supermajority, constitutional protection
7 Later ν full Plugin system, CRDT sync, full AI intelligence stack
8 Later ξ Identity soul vectors, Ed25519 keypairs, persistent cryptographic identity

Critical path: Phase 0 (execution core) → Phase 1 (rules) → Phase 2 (reputation) → Phase 3 (consensus). Phases 4–8 extend the system horizontally and deepen trust guarantees.

Round Phases (A–B)

Every round follows a fixed three-phase sequence, all within the same day or two:

Phase A: Plan

Sigma receives the human’s intent (either implicit from a backlog or explicit in a mandate). Sigma:

  1. Reads the previous round’s writeback and reflections
  2. Queries the database for open tasks, open ADRs, unresolved comments
  3. Writes a Phase A manifest listing:
    • Slices (discrete work units, one task each)
    • Owner per slice (which wave, which agent pool)
    • Dependencies between slices
    • Definition of done

Output: docs/spawns/rNN-<theme>/manifest.md or logged directly to mcp_round_manifests

Phase W: Waves

PM receives the manifest and executes 5 sequential waves. PM:

  1. Starts Wave 1 (governance): promotes todo tasks, dispatches executors, waits for writeback
  2. Gate check: Wave 1 done? Yes, proceed.
  3. Starts Wave 2 (runtime): same pattern
  4. Gate check: Wave 2 done? Yes, proceed.
  5. Repeats for Waves 3, 4, 5

Wave gate rule: Wave N+1 cannot start until Wave N’s writeback is complete. If Wave N has zero tasks, it is skipped but the gate is logged as “empty — passed”.

Each wave produces multiple task completions, PRs (unmerged), and ζ reflections.

Phase B: Seal

Sigma runs at the end of the round:

  1. audit_verify_chain: verify the hash chain from the round’s first task to its last task
  2. merkle_finalize: add the round’s root to the session tree
  3. Round commit: create a commit on main (human merge) or on a round branch
  4. Documentation: record the round in docs/session-seal-sN.md (if session is closing) or docs/ (if round is live)

At this point, the round is sealed. All tasks are done, the chain is verified, and the proof is anchored.

Signal Rule: No Signal, No Close

A round does not close unless it leaves a signal on all three axes.

Execution signal: All assigned tasks are resolved (status=done or cancelled)

Intelligence signal: Round-level reflection exists (thought_record at Phase B seal) covering what was learned and what changed

Legitimacy signal: audit_verify_chain passes — no breaks in the hash chain

If any axis is silent, the round cannot close. Sigma refuses to seal. The round must be reworked.

Temporal Integrity

The three zoom levels must never conflict:

  • Task times must fit within round times (a task runs 1–4 hours; a round runs 1–3 days)
  • Round times must fit within session times (a round runs 1–3 days; a session runs 1–3 months)
  • Phase times must respect phase dependencies (Phase 1 cannot start until Phase 0 is complete)

This is enforced by:

  • Task FSM: if a task runs longer than TASK_MAX_DURATION (configurable, default 8 hours), it is forcibly transitioned to CANCELLED
  • Round gates: if Phase W exceeds ROUND_MAX_DURATION (default 3 days), Sigma escalates to T0 (human)
  • Session gates: if a session exceeds SESSION_MAX_DURATION (default 3 months), the session is auto-sealed and a new one starts

These are not hard errors — they are escalations. The human can override them if needed.

Recording Time

Every transition leaves a record:

  • Task → state: recorded in mcp_tasks with timestamp
  • Round → phase: recorded in mcp_rounds with phase name and timestamp
  • Session → open/closed: recorded in mcp_sessions with seal document path
  • ζ record: recorded with timestamp field (ISO 8601)
  • Merkle tree: leaves are sorted by timestamp; root is computed deterministically

Time is immutable in the Merkle tree. Once a leaf is hashed, its timestamp cannot change.

See Also

Table of contents

Back to top

Colibri — documentation-first MCP runtime. Apache 2.0 + Commons Clause.

This site uses Just the Docs, a documentation theme for Jekyll.