Round

A round is the middle time-unit of Colibri’s three-level temporal hierarchy: session → round → task. A round is a bounded batch of planned work that opens with a plan, runs in ordered waves, and closes with a seal. Rounds are named Rn (R53, R54, …); the current cycle is R75.

Authoritative state model: ../spec/s03-state-model.md. Sigma orchestrator contract: ../agents/sigma-orchestrator.md.

The three phases of a round

Every round has exactly three phases, in order: Phase A (plan), Phase W (waves), Phase B (seal). Phases do not overlap. A round begins when Phase A opens and ends when Phase B’s seal is countersigned.

Phase A — plan

T1 sigma drafts the round’s plan: the list of tasks to promote, their wave allocation, their dependencies. The plan is a document (docs/roadmap/RNN-plan.md in the donor layout; roadmap.md in the World Schema v3 layout) committed to the main branch. Plan commits are themselves audited; a round with no committed plan cannot enter Phase W.

Phase W — waves

Phase W runs exactly five waves, in order. Each wave gates the next: no wave N+1 task may begin until every wave N task has reached DONE or CANCELLED.

Wave	Name	What ships
1	Governance	Axiom updates, ADRs, rule upgrades
2	Runtime	α middleware, γ server lifecycle, DB schema changes
3	Domain	β, ε, ζ, η, θ, ι, κ, λ, μ, ξ, π, δ — concept-specific work
4	Integrations	ν — external surfaces (Git, Obsidian, Claude API, etc.)
5	Test + CI + Docs	Verification, CI green, doc regen

The five-wave order is load-bearing. Governance before runtime because rule changes must land first. Runtime before domain because concepts depend on runtime primitives. Domain before integrations because integrations wrap concept APIs. Test + CI + Docs last because they observe everything prior.

Phase B — seal

T1 sigma closes the round. Seal activities:

Writeback audit. Every executed task must have a task_update(status=done|cancelled) and a final thought_record. Orphans are flagged; the round does not seal with unresolved orphans.
Merkle finalization. For each proof-grade session in the round, merkle_finalize has been called; merkle_root returns a non-null value; the root is embedded in the round’s seal document.
Seal document. docs/session-seal-<round>.md records the round’s outcomes, Merkle roots, open questions, and the session-level chain hash that links this round to the next.
Roadmap advance. The next round’s entry in roadmap.md is promoted from planned to active.

A round that cannot seal (e.g. because verification failed or an orphan cannot be resolved) is extended into the next round by explicit sigma decision; it does not silently cross round boundaries.

Wave gates

A wave gate is the boundary between waves. The gate closes when:

Every wave N task is terminal (DONE or CANCELLED).
Every task’s writeback is present.
Every proof-grade task’s Merkle root is recorded.
The wave’s aggregate CI check is green (for waves 2 and later).

The gate opens for wave N+1 only after all four. No wave may be “partially complete” across the gate.

Round ids

A round id is Rn where n is a strictly increasing integer. Sub-rounds use Rn.m (R74.3, R74.3.1, R74.3.2 — a chain of hotfixes that all landed the same day). Sub-round suffixes are chosen at sigma’s discretion; they do not carry semantic meaning beyond “this is a derivative of Rn.”

Round-level chaining

Each round’s seal embeds the session chain hashes of the rounds it closed. The next round’s Phase A plan cites those seal hashes, forming a round-level hash chain on top of the session-level chain. This is fractal SHA-256: task chain → session chain → round chain → epoch chain.

The 5-step chain, inside a round

Inside Phase W, every executor task follows the 5-step chain: audit → contract → packet → implement → verify. The five steps map onto the β FSM:

Step	β state
audit	GATHER
contract	ANALYZE
packet	PLAN
implement	APPLY
verify	VERIFY

The 5-step chain is not a round-level structure; it is a task-level structure that exists inside every Wave 3 / Wave 4 / Wave 5 task. See task.md.

Signal matrix

At the round boundary, sigma gathers signals from the three axes:

Execution axis — task completion counts, CI state, regression status.
Intelligence axis — decision-trail density, reflection quality, novel-skill count.
Legitimacy axis — Merkle root count, chain-verification pass rate, axiom-drift advisories.

A green round is green on all three axes. A round green on execution but silent on legitimacy is a false-green and is flagged in the seal.

What a round is not

Not a release. Releases are external artifacts (a tagged commit, a Pages deploy); rounds are internal. A round may ship zero external artifacts.
Not a sprint. Sprints are time-boxed; rounds are scope-boxed. A round runs until its plan is satisfied, regardless of elapsed time.
Not a retry unit. If a task fails, the retry is the task’s concern (β’s state machine). A failing task does not roll back the round.

Example: R75 round seal document

A sealed round emits a docs/session-seal-<round>.md whose frontmatter records the machine-checkable facts about the round. The schema below is the canonical shape; the values shown are illustrative of an R75 seal.

round: R75
phase_a_plan: "PLAN-RED execution — World Schema v3 migration"
phase_b_seal: 2026-04-16T14:30:00Z
sigma: T1-claude-opus-4.6
merkle_root: 0xabcd1234...ef56
tasks_completed: [R75.1, R75.2, ..., R75.28]
tasks_orphaned: []
writeback_status: PASS
artifacts:
  audit: docs/audits/r75-plan-red-audit.md
  contract: docs/contracts/r75-plan-red-contract.md
  packet: docs/packets/r75-plan-red-packet.md
  verification: docs/verification/r75-plan-red-verification.md
commit_range: [54fc79a9, 55efb49f]
pr_number: 114
blockers_for_next_round: []

tasks_orphaned: [] is the critical green signal: every executed task has a matching thought_record. writeback_status: PASS means the orphan scan ran cleanly. merkle_root pins the round to η’s proof tree.

Example: failed gate + escalation

Scenario: Wave 2 gate at R87. All five tasks reported DONE, but audit_verify_chain returns a hash break at task R87.3 thought_record #7.

PM stops Wave 3 dispatch. The gate does not open: rule 2 (writeback present) is satisfied but rule 3 (chain verifies) is not.
Sigma opens the session seal with verdict: PARTIAL and attaches the chain-break proof JSON ({task_id: "R87.3", bad_index: 7, expected_hash: "0x...", observed_hash: "0x..."}).
Escalation to T0. The seal lists the break under blockers_for_next_round. T0 reviews and selects the recovery path.

Recovery path:

T0 reviews the break and identifies the tampered (or corrupted) record.
Executor appends a new thought_record(thought_type: "correction", parent_hash: <last good hash before the break>, content: "<details of divergence and fix>").
Re-run audit_verify_chain from the correction forward.
A new session seal supersedes the PARTIAL seal; the superseding seal cites the failed-seal hash in its supersedes: field.
Wave 3 dispatch resumes only after the new seal returns writeback_status: PASS.

A failed gate is not a crisis — it is the mechanism doing its job. The chain-break is caught before downstream waves build on corrupted state, and the correction leaves its own audit trail in ζ.