Colony Dynamics

6.0 Preamble

Justification

Without colony dynamics, Synixolis is a single-node protocol. A single node can compress, divide, and renew its own memory — but it cannot produce organizational knowledge, allocate work across domains, or scale beyond one agent’s context window. The colony layer is how individual observations become shared structural memory, how specialization emerges from generalist roots, and how the system reclaims resources from nodes that have outlived their utility. Every multi-agent deployment today lacks this layer: agents are launched manually, never pruned, never merged, and share state through ad-hoc message passing with no consistency model and no lifecycle management. Colony dynamics formalizes the decisions that humans currently make by hand — spawn, cull, merge, branch — and grounds them in evidence from the protocol’s own telemetry.

CDR applies recursively at population scale (Theorem 4). Overlapping nodes are compressed (merge). Different domains get dedicated nodes at appropriate clock speeds (divide). Stale nodes are refreshed or decommissioned (renew). Colony dynamics is CDR’s third instantiation — after memory-scale and protocol-scale — and without it the recursive structure is incomplete.

Operating Timescales

Timescale	Operations
Minutes–hours	Colony formation via action cascade (scope drift accumulates per-interaction, SPAWN decision evaluated per-turn)
Hours–days	Organizational memory promotion pipeline (individual observations → cross-node patterns → shared structural)
Days–weeks	Collective resource allocation decisions (spawn, cull, merge, branch)
Weeks–months	Human steering parameter review and adjustment

Distributed Systems Framing

Colony dynamics draws on three established DS concepts:

Cluster membership. The colony maintains a manifest of active nodes, their states, and their domains — the same function as a cluster membership service (e.g., ZooKeeper group membership, Consul service registry). Nodes join via SPAWN, leave via TERMINATE, and their liveness is tracked via heartbeat (specified in §6c).
Quorum-based decisions. Collective resource allocation (spawn, cull, merge) requires consensus from N/2+1 nodes — majority quorum, the same threshold used in Raft leader election and Paxos proposer acceptance. This prevents unilateral action while tolerating minority node unavailability.
Resource allocation. The colony allocates inference budget, domain coverage, and node count within human-provided constraints — analogous to cluster resource managers (YARN, Kubernetes scheduler) that allocate compute within capacity limits while respecting placement constraints and priority classes.

Synixolis-specific concepts not covered by standard DS patterns: the organizational memory promotion pipeline (individual → agent-level → cross-node → shared), the three spawn types (renewal, specialization, delegation), and the pressure-cascade mechanism (scope drift → SPAWN threshold) that triggers colony formation.

6.1 Colony Definition

A colony is the full population of Synixolis-conforming nodes operating over a shared or federated memory substrate.

A conforming colony participant MUST:

Implement the node contract (§3).
Maintain a node manifest declaring its receptor, charter, scope, state, and heartbeat.
Read and follow colony-wide conventions stored in shared state (§6b).
Emit telemetry to the colony coordination channel.
Participate in consensus when queried (or declare DORMANT/FENCED status and abstain).

A colony participant MAY be:

A Claude Code session on a developer’s machine
A cloud-hosted agent service
A different model provider (GPT, Gemini, open-weight models)
A cron job writing observations
A human following the protocol via CLI

The only membership requirement is protocol conformance. Model identity, provider, runtime environment, and execution schedule are deployment concerns, not protocol concerns.

Colony Manifest

Each colony maintains a manifest — a registry of all known nodes and their current status. The manifest is stored in shared state (§6b) and updated on every lifecycle transition.

node_id: NODE-{UUID-SHORT}
receptor: "engineering architecture"     # domain affinity
charter: "Track design decisions, flag contradictions, maintain living architecture doc"
scope:
  primary_domains:
    - engineering
    - architecture
  excluded_domains:
    - operations
state: ACTIVE | DORMANT | INITIALIZING | FENCED | TERMINATED
parent_id: NODE-{UUID-SHORT} | null      # null for root nodes
spawn_type: renewal | specialization | delegation | root
created: ISO-8601
last_heartbeat: ISO-8601
fitness_score: 0.0-1.0                   # from eval traces

6.2 Colony Formation

Colonies form through the AAP action cascade. This is not a top-down design process — it is a pressure-driven response to accumulated scope drift.

Formation Sequence

1. Single node operates as generalist
2. Input stream includes work outside node's receptor affinity
3. Scope drift accumulates (measured as fraction of interactions outside primary domains)
4. scope_drift exceeds drift_threshold
5. Action cascade evaluates: ROUTE (no target) → HANDLE (drift too high) → SPAWN
6. Node creates child with compressed state digest (≤512 tokens)
7. Child specializes via its own subsequent experience
8. Colony now has 2+ nodes with complementary receptors

Spawn Decision Cost Model

A node MUST evaluate the spawn decision using the following cost model:

handle_cost  = exec_cost + drift_weight × scope_drift
spawn_cost   = spawn_overhead - route_credit
route_cost   = lookup_cost + affinity(other_node, input) evaluation

ROUTE if affinity(other_node, input) > affinity(self, input) for any existing colony member.
SPAWN if scope_drift > drift_threshold AND context_tokens >= min_context_for_spawn.
HANDLE otherwise.

The drift_threshold is a policy parameter (default: 0.3 — 30% of recent interactions outside primary domains). The min_context_for_spawn is a lifecycle gate preventing resource-exhausted nodes from spawning (default: 25% of context budget remaining).

Three Spawn Types

Every spawn MUST be classified as exactly one type. The type determines the child’s initial state and relationship to the parent.

Spawn Type	Trigger	Child Inherits	Parent Effect
Renewal	Parent context exhaustion (`context_tokens >= context_budget`)	Compressed state digest of parent’s full memory. Same receptor and charter.	Parent enters TERMINATED. Child is the successor.
Specialization	Scope drift in a specific domain exceeds threshold	Domain-filtered subset of parent’s memory relevant to the new domain. New receptor.	Parent continues. Removes drifting domain from its own scope.
Delegation	Recurring subtask detected (3+ occurrences of same task pattern in eval traces)	Task-specific context + relevant structural memory. Narrow charter.	Parent continues. Routes future matching tasks to child.

Lifecycle Gates on Spawning

These gates prevent pathological spawn cascades:

Newborn grace period: A node MUST NOT spawn children for its first N interactions (configurable, default: 10). This prevents newly-spawned nodes from immediately re-spawning before accumulating enough experience to make informed decisions.
Minimum context: A node MUST have context_tokens >= min_context_for_spawn to spawn. This prevents resource-exhausted nodes from creating children they cannot adequately initialize.
Colony size cap: Total ACTIVE + INITIALIZING nodes MUST NOT exceed max_colony_size from human steering parameters. Spawn requests that would exceed this cap are queued until a slot opens (via cull or termination) or the human raises the cap.

6.3 Collective Resource Allocation

The colony makes four types of collective resource allocation decisions. Each follows the same structure: trigger → evidence → proposal → consensus → execution. Each is subject to human steering parameters (§6.4).

6.3.1 Spawn Decision (Collective)

Distinct from the single-node action cascade spawn (§6.2), a collective spawn is initiated when the colony as a whole identifies a coverage gap.

Trigger: Query log analysis reveals a cluster of unanswered or poorly-answered questions in a domain not covered by any node’s primary receptor.
Evidence: 2+ nodes independently flag the gap (cross-node corroboration). The flagging nodes MUST cite specific query-log entries as evidence.
Proposal: Any node MAY propose: "Colony needs a node specializing in {domain}." The proposal MUST include: proposed receptor, proposed charter, evidence (query-log citations), and suggested parent node.
Consensus: N/2+1 ACTIVE nodes MUST validate the proposal against their own query logs and agree the gap exists.
Execution: The designated parent node performs a specialization spawn. If no parent is designated, the node with highest affinity to the proposed domain spawns the child.

6.3.2 Cull Decision (Collective)

Trigger: A node’s memories are never accessed by other nodes, its observations are never consumed, and its eval traces show low utility over an extended period.
Evidence: Fitness score (computed from eval traces — query hit rate, observation consumption rate, consensus participation rate) decays below cull_threshold (configurable, default: 0.2) for M consecutive evaluation cycles (configurable, default: 3 cycles at 7-day intervals).
Proposal: Any node MAY propose: "Node {id} should be archived." The proposal MUST cite the fitness score trajectory.
Consensus: The target node itself + 1 other ACTIVE node MUST agree. Self-recognition (the node acknowledges its own low utility) combined with external validation prevents both premature culling and nodes that refuse to acknowledge obsolescence.
Execution:
1. Node’s local memories are archived to glacier (never deleted).
2. Node’s domain coverage is absorbed by adjacent nodes (nodes with overlapping receptor affinity).
3. A tombstone record is written to the colony manifest preserving the node’s full history.
4. Node transitions to TERMINATED.

6.3.3 Merge Decision (Collective)

Trigger: Two nodes have converging scopes — their primary domains increasingly overlap, and their memories show consistent duplication.
Evidence: Receptor affinity between the two nodes exceeds merge_threshold (configurable, default: 0.7) as measured by domain overlap + memory content similarity.
Proposal: Any node MAY propose: "Nodes {X} and {Y} should merge." The proposal MUST cite receptor affinity score and examples of duplicated memories.
Consensus: Both target nodes MUST agree + 1 external ACTIVE node validates (prevents collusion or coerced merges).
Execution:
1. Union of both nodes’ memory entries.
2. Conflict resolution for contradictory entries follows the standard hierarchy: recency → confidence → domain owner → escalate to human.
3. Merged node inherits the higher fitness score of the two.
4. Merged node’s receptor is the union of both receptors; charter is synthesized.
5. The absorbed node transitions to TERMINATED with a tombstone record.

6.3.4 Branch Decision (Collective)

Trigger: An ambiguous or high-stakes problem with multiple viable approaches where premature commitment to one approach risks wasted effort.
Evidence: A node signals uncertainty above branch_threshold (configurable, default: 0.6 — the node is less than 40% confident in any single approach).
Proposal: "Spawn N exploratory nodes pursuing different approaches to {problem}." The proposal MUST enumerate the approaches and define success criteria.
Consensus: Human approval REQUIRED. Branching is the most expensive collective operation (N simultaneous nodes consuming inference budget on the same problem).
Execution:
1. N child nodes spawned as delegation spawns, each with a charter specifying one approach.
2. All branches operate concurrently with a time or budget cap.
3. All branches report outcomes against the defined success criteria.
4. Best approach promoted; other branches archived with their findings preserved.
5. Archived branch memories remain in glacier — the losing approaches still contain useful negative evidence.

6.4 Human Steering Parameters

The colony operates autonomously within constraints set by humans. Humans set the boundaries; the colony self-organizes within them.

steering:
  # --- Capacity ---
  max_colony_size: 10              # Hard cap on ACTIVE + INITIALIZING nodes
  budget_per_cycle: X tokens       # Total inference budget across all nodes per cycle

  # --- Domain constraints ---
  protected_domains:               # Domains that MUST always have at least one ACTIVE node
    - engineering
    - research
  forbidden_domains:               # Domains nodes MUST NOT enter
    - []                           # Empty by default

  # --- Approval gates ---
  spawn_approval: auto | human     # Who approves new node creation
  cull_approval: auto | human      # Who approves node decommissioning
  merge_approval: auto | human     # Who approves node merges
  branch_approval: human           # ALWAYS human — branching is expensive
  convention_evolution: auto       # Can colony-wide conventions change without human approval?

  # --- Fault isolation gates (see §6d) ---
  fault_surveillance: auto         # Invariant checks always run; audit frequency adaptive
  fence_approval: auto             # System can fence nodes autonomously
  rollback_approval: human         # Shared state rollback requires human
  reset_approval: human            # Node reset always requires human

  # --- Budget allocation ---
  audit_budget: 0.10               # Fraction of inference budget for provenance auditing
  maintenance_budget: 0.15         # Fraction of inference budget for scheduled maintenance

Steering Parameter Semantics

max_colony_size: A SPAWN request that would exceed this limit MUST be queued, not rejected. If a protected domain has no ACTIVE node and the colony is at capacity, a cull of the lowest-fitness unprotected node is triggered automatically to make room.
protected_domains: If the last ACTIVE node covering a protected domain enters TERMINATED or FENCED, the colony MUST immediately propose a replacement spawn. This takes priority over the spawn queue.
forbidden_domains: A node whose scope drift moves it into a forbidden domain MUST NOT spawn a specialist for that domain. The drifting input is logged but not acted upon.
Approval gates: When set to auto, the colony executes the decision after consensus. When set to human, the decision is proposed and queued for human approval. The colony MUST NOT execute human-gated decisions autonomously.

6.5 Organizational Memory Emergence

Individual node observations consolidate into shared organizational knowledge through a promotion pipeline. This pipeline is how the colony produces knowledge that no single node could produce alone.

Promotion Pipeline

Individual observations (single node, operational/)
  → Agent-level patterns (single node's CDR condensation pipeline, structural/)
    → Cross-node patterns (2+ nodes independently observe the same pattern)
      → Organizational memory (promoted to shared structural/ via colony consensus)

Each stage has increasing evidence requirements and decreasing update frequency:

Stage	Evidence Threshold	Typical Timescale	Storage
Individual observation	1 node, 1 occurrence	Minutes–hours	Node-local `operational/`
Agent-level pattern	1 node, 3+ observations across 2+ weeks	Days–weeks	Node-local `structural/`
Cross-node pattern	2+ nodes independently observe same pattern	Weeks	Flagged in coordination channel
Organizational memory	N/2+1 nodes validate via consensus	Weeks–months	Colony `shared-structural/`

Promotion Mechanics

A node MAY propose promotion of a local pattern to shared structural memory when it detects that another node has independently observed the same pattern. The proposal MUST include:

promotion_proposal:
  content: "The observed pattern"
  proposing_node: NODE-{id}
  local_evidence:
    - entry_id: ENTRY-{id}     # The proposing node's local pattern entry
      observation_count: 5
      first_observed: ISO-8601
      last_observed: ISO-8601
  cross_node_evidence:
    - node_id: NODE-{id}       # The corroborating node
      matching_entry: ENTRY-{id}
      similarity: 0.85         # Content similarity score
  proposed_confidence: 0.0-1.0

Consensus for promotion follows the standard quorum (N/2+1). Validating nodes check the proposal against their own traces — they do not rubber-stamp; they confirm the pattern holds in their own experience.

Shared Memory Properties

Organizational memory promoted to shared-structural/ or shared-identity/ has distinct properties from node-local structural memory:

Readable by all nodes. Any colony member can query shared memory.
Writable only through the promotion pipeline. No node can directly write to shared state without cross-node evidence and consensus.
Higher confidence threshold than node-local structural memory (configurable, default: 0.7 vs. 0.5 for local structural).
Longer review cycle (quarterly vs. monthly for local structural).
Full cross-node provenance chain. Every shared entry traces back through the promotion proposal to the independent observations from multiple nodes.
Subject to CDR at population scale. Shared memory entries decay, undergo renewal audits, and can be archived — the same lifecycle as node-local entries, but at colony timescale.

6.7 Colony Communication Protocol

Justification

The spec defines message types (Section 8.5) and a replicated state log for shared memory (Section 6b). But these are data formats and storage, not interaction protocol. Agents need structured procedures for discussing things — debating convention proposals, coordinating on fault response, asking each other questions, and involving humans in decisions. Without an interaction protocol, colony communication degrades to ad-hoc message passing where nodes talk past each other, discussions never resolve, and humans can’t participate legibly.

This is the same problem every multi-participant communication system faces. Discord servers have channel rules. IRC has RFC 2812. Mailing lists have posting guidelines. The colony needs the equivalent: not the transport (agnostic — could be chat, filesystem, message queue, git) but the procedures for interaction over it.

Operating Timescales

Timescale	Communication Activity
Seconds-minutes	Message posting, acknowledgment, direct queries
Minutes-hours	Threaded discussions, proposal deliberation, fault coordination
Hours-days	Proposal resolution, decision recording, human review windows
Days-weeks	Channel lifecycle (creation, archival), communication rule evolution

DS Framing

This is a group communication protocol — the same domain as virtual synchrony (Birman), group membership protocols, and pub/sub topic management. The channel taxonomy maps to topic-based pub/sub. Threading maps to causal message ordering. Resolution procedures map to distributed consensus with timeout. Human participation maps to out-of-band oracle injection.

Communication Substrate

The communication substrate is fixed per colony — chosen at colony initialization and used by all nodes for the colony’s lifetime. It is the primary and authoritative channel for all agent-to-agent and agent-to-human communication. Side-channel communication (direct messages, out-of-band coordination) is not prohibited but MUST NOT be used for governance decisions, fault coordination, or any action that affects shared state. If it didn’t happen on the colony substrate, it didn’t happen.

Required substrate capabilities:

Post a message to a named channel (pub)
Subscribe to a named channel (sub)
Retrieve messages from a channel by time range or thread ID
Human-readable rendering (humans must be able to read and post)

Reference substrates:

Substrate	Suitability
Chat platform (Discord, Slack, Matrix)	Best for human participation. Channel/thread primitives map directly.
Filesystem (shared directory with message files)	Good for single-machine colonies. Human-readable by default.
Git repository (commit-per-message)	Good for async, multi-machine. Full history. Human-readable.
Message queue (NATS, Redis Streams)	Best for high-throughput daemon colonies. Requires rendering layer for humans.
MCP endpoint	Good for mixed environments. Claude Code native.

Substrate migration: A colony MAY migrate substrates through a governance proposal. The migration procedure requires: human approval (always), a transition period where both substrates are active, and verification that all nodes have switched before decommissioning the old substrate. This is a rare, high-risk operation.

Extending the substrate: The protocol leaves room for additional communication mechanisms beyond the primary substrate (e.g., adding a webhook integration, a dashboard, a notification service). Extensions are added or removed through the standard governance deliberation procedure and MUST NOT replace the primary substrate for authoritative communication.

Channel Taxonomy

Every colony MUST maintain the following channel categories. Individual channels within each category are policy (a colony can have one #operations channel or split into #ops-node-alpha, #ops-node-beta).

Required channel categories:

Category	Purpose	Who Posts	Retention
operations	Task coordination, status updates, work handoffs between nodes	All nodes, humans	Ephemeral (14d default)
knowledge	Memory observations, pattern sharing, questions about shared state, retrieval requests across nodes	All nodes, humans	Operational (30d default)
governance	Convention proposals, votes, steering changes, policy modification requests	All nodes, humans	Structural (permanent until resolved)
incidents	Fault alerts, investigation threads, containment coordination, post-incident reviews	All nodes (auto-post on fault detection), humans	Structural (permanent)
human	Human directives, approval requests, escalations requiring human judgment, general discussion	Humans primarily; nodes post approval requests	Structural (permanent)
heartbeat	Liveness signals, maintenance pressure reports, health summaries	All nodes (automated)	Ephemeral (48h default)

Channel creation and archival: Nodes MAY propose new channels when an existing channel’s topic scope becomes too broad (same pattern as node specialization — scope drift triggers splitting). Channels with no activity for 2× their retention period are candidates for archival. Channel creation and archival follow standard colony consensus.

Message Format

Every message in any channel MUST conform to:

message:
  id: unique-id
  channel: operations | knowledge | governance | incidents | human | heartbeat
  thread_id: null | parent-message-id    # null = new thread, id = reply
  author:
    node_id: node-id | HUMAN
    persona: string                       # Node's charter name, or human's name
  timestamp: ISO-8601
  type: observation | question | proposal | vote | decision | directive | alert | status | ack
  content: string                         # The actual message
  references:                             # Links to entries, other messages, traces
    - type: memory_entry | message | eval_trace | convention
      id: referenced-id
  urgency: routine | elevated | critical  # Affects notification behavior
  requires_response: boolean              # If true, triggers response window
  response_window: duration | null        # How long before non-response is escalated

Interaction Rules

Threading:

Every topic MUST be a thread (top-level message + replies). No free-form channel noise.
A message that introduces a new topic MUST be a new thread, not a reply to an existing one.
A reply to an existing thread MUST reference the thread_id.
Cross-thread references use the references field, not inline mentions.

Response obligations:

Messages with requires_response: true MUST receive a response from at least one other node (or human) within the response_window.
Non-response after window expiry is logged as a communication fault. Persistent non-response from a node is a liveness signal (distinct from heartbeat — a node can be alive but unresponsive on a channel).
Acknowledgment (type: ack) counts as a response. It means “I received this” not “I agree.”

Scope enforcement:

Messages MUST go to the appropriate channel category. A fault alert in #operations is a protocol violation — it belongs in #incidents.
Nodes SHOULD flag scope violations when they observe them (redirect, not reject — the message content is valid, the channel is wrong).
Scope enforcement is lightweight — a nudge, not a hard error. Channel scope evolves over time.

Topic Leadership

Every thread MUST have a topic leader — the node (or human) responsible for driving the thread to resolution. Topic leadership is not authority over the outcome; it is responsibility for process: ensuring the thread follows its procedure, calling for votes when discussion is sufficient, summarizing positions, and recording decisions.

Topic leader selection:

Thread Type	Leader Selection	Rationale
Governance proposal	The proposing node	Author is most familiar with the evidence and motivation
Incident	The detecting node (or first responder if detector is FENCED)	Fastest path to containment — detecting node has the most context
Knowledge question	The node with highest affinity to the topic domain	Domain expert drives toward resolution
Operational handoff	The handing-off node	Outgoing node ensures clean transfer
Human-initiated	The human, or the node they designate	Human authority

Leader responsibilities:

Ensure the thread follows its defined procedure (see Thread Procedures below)
Post status summaries at defined intervals for long-running threads (default: every 24h for governance, every 1h for incidents)
Call for votes when discussion has converged or response window is approaching
Post the final decision record
Escalate to #human if the thread is stuck (no convergence, no quorum, conflicting evidence)

Leader transfer: If the topic leader becomes DORMANT or FENCED during an active thread, leadership transfers to the node with the next-highest affinity to the thread’s domain. If no node has clear affinity, the most senior active node (longest uptime) assumes leadership. Transfer is recorded in the thread.

Leader accountability: A topic leader that fails to drive threads to resolution (3+ threads stalled under their leadership within a review cycle) has this recorded in their eval traces as a communication performance signal.

Quorum Rules and Governance Procedures

Colony governance follows procedures analogous to organizational board rules — structured, recorded, and auditable. Different decision types require different quorum and approval thresholds:

Quorum definitions:

Decision Type	Quorum Requirement	Approval Threshold	Human Required	Response Window
Convention change (routing rules, compiled behaviors)	N/2+1 active nodes	Simple majority of votes cast	No	48h
Steering change (colony size, budget, protected domains)	N/2+1 active nodes	Simple majority	Yes — human MUST vote	72h
Node spawn	2+ nodes proposing or endorsing	N/2+1 approve	Per steering config	48h
Node cull	Target node + 1 other	Both agree	Per steering config	72h
Node merge	Both target nodes + 1 external	All three agree	Per steering config	72h
Communication rule change	N/2+1 active nodes	2/3 supermajority	Yes	72h
Substrate migration	All active nodes	Unanimous	Yes	7d
Emergency action (FENCE during active incident)	2 nodes OR 1 node + invariant violation	Immediate (no deliberation)	No (post-hoc review required)	None

Voting rules:

Each active node gets one vote. DORMANT and FENCED nodes cannot vote.
Humans get one vote per human participant. Human votes carry no extra weight in the count, but human directives (distinct from votes) can override outcomes (see Human Participation).
ABSTAIN counts toward quorum but not toward approval/rejection.
A node MUST include rationale with its vote. Votes without rationale are recorded but flagged.
Votes are irrevocable once cast within a thread — a node that changes its position must post a new vote with explanation, and the later vote supersedes.

Procedural rules:

No proposal may be voted on within the first 12h of its response window (minimum deliberation period). Exception: emergency actions.
A rejected proposal cannot be re-submitted within 7d unless material new evidence is presented.
A proposal that achieves quorum with 2+ REQUEST_REVISION votes MUST be revised and re-submitted, even if it has majority APPROVE. Revision concerns must be addressed.
All decisions are binding until superseded by a subsequent governance decision or human directive.
The decision record (posted by topic leader) constitutes the official outcome. If the record contradicts the vote tally, any node may challenge and force a recount.

Thread Procedures

The protocol defines predefined thread procedures for known coordination scenarios. Each procedure specifies the stages, the topic leader’s role at each stage, and the resolution criteria. New procedures can be defined through governance proposals.

Governance deliberation:

1. PROPOSE     — Leader posts proposal with evidence to #governance
                 Required fields: proposed_change, evidence, impact_assessment, τ* for review
                 Minimum deliberation: 12h before voting can begin
2. DISCUSS     — All nodes and humans post questions, concerns, supporting/opposing evidence
                 Leader posts discussion summary at 24h mark
3. CALL_VOTE   — Leader calls for vote when: discussion has converged, OR
                 response window minus 12h is reached (ensure time for voting)
4. VOTE        — Each active node casts vote with rationale within remaining window
5. TALLY       — Leader tallies votes against quorum and threshold requirements
6. DECIDE      — Leader posts decision record:
                 {outcome, vote_tally, rationale_summary, dissenting_positions,
                  effective_date, τ*_for_review, next_review_date}
7. ENACT       — If approved: change is applied. If rejected: proposal archived with rationale.

Incident response:

1. ALERT       — Detecting node posts to #incidents (urgency: critical, auto-notify all)
                 Leader: detecting node
2. ACK         — All active nodes acknowledge within ack_window (default 5min)
                 Non-ack after window: leader flags as potential isolation/cascade
3. TRIAGE      — Leader assesses severity and assigns containment actions
                 Posts triage summary: {severity, affected_scope, containment_plan}
4. CONTAIN     — Assigned nodes execute containment (FENCE, etc.)
                 Each action posted to thread in real-time
5. INVESTIGATE — All nodes with relevant traces contribute findings
                 Leader synthesizes into root cause hypothesis
6. RESOLVE     — Leader posts resolution: {root_cause, actions_taken,
                 entries_affected, fault_signature (if novel)}
7. REVIEW      — Separate thread in #governance linked from incident
                 Reviews: detection speed, containment effectiveness,
                 proposed changes to fault signatures or response procedures

Knowledge resolution:

1. QUESTION    — Node posts question to #knowledge with domain tag
                 Leader: node with highest affinity to domain
2. RESEARCH    — Nodes with relevant memory respond with evidence + provenance
3. SYNTHESIZE  — Leader synthesizes responses into a candidate answer
4. VALIDATE    — Other nodes confirm/challenge the synthesis against their own memory
5. RECORD      — If consensus: answer promoted to shared knowledge (standard promotion pipeline)
                 If disagreement: thread documents the disagreement, no forced resolution

Spawn proposal:

1. PROPOSE     — Node posts spawn rationale to #governance
                 Required: domain_gap_evidence, proposed_charter, resource_estimate
2. ENDORSE     — 1+ other nodes endorse based on their own query logs showing the gap
3. DISCUSS     — Colony evaluates: is the gap real? Can existing nodes cover it?
4. VOTE        — Standard quorum rules (see table above)
5. PROVISION   — If approved: parent node executes spawn with approved charter
                 New node posts introduction to #operations on activation

Cull proposal:

1. PROPOSE     — Any node (including the target) posts cull rationale to #governance
                 Required: fitness_data, utilization_metrics, proposed_absorption_plan
2. RESPOND     — Target node posts self-assessment (agrees, disagrees, or proposes alternative)
3. DISCUSS     — Colony evaluates absorption plan: who takes over what?
4. VOTE        — Target + 1 other must agree (see quorum table)
5. DECOMMISSION — Target node archives state, transfers active work, posts farewell to #operations
                  Colony manifest updated. Tombstone record preserved.

Human Participation

Humans are first-class participants, not external overseers. The protocol accommodates asymmetric availability — humans are slow, intermittent, and authoritative.

Human message properties:

Human messages carry implicit urgency: elevated (nodes SHOULD prioritize processing human messages)
Human directives (type: directive) override node-level decisions. A human saying “don’t merge those nodes” in #governance supersedes a merge proposal that passed consensus.
Humans are NOT bound by response windows. A human can respond to a 3-week-old thread and their input is still valid.
Humans can post in any channel. Nodes cannot restrict human access.

Approval requests: When a node needs human approval (RESET, shared state ROLLBACK, steering changes), it posts to #human with:

approval_request:
  action: description of what needs approval
  evidence: why this action is proposed
  urgency: routine | elevated | critical
  deadline: ISO-8601 | null              # After this, action is auto-declined (never auto-approved)
  fallback: what happens if no response   # Must be safe default (no action)

Key principle: If a human doesn’t respond, the safe default is inaction, never autonomous escalation. A RESET that gets no human response within the deadline is declined, not executed.

Communication Rule Evolution

The interaction rules themselves are evolvable policy, subject to the same CDR lifecycle as maintenance parameters (Section 6c.4):

Response windows, retention periods, quorum thresholds, channel categories — all evolvable within human-set bounds
The existence of the communication protocol is protocol (MUST have channels, MUST thread, MUST have governance procedures, MUST have topic leaders)
The specific parameters are policy (response windows, channel names, retention periods, quorum thresholds)
Changes to communication rules require 2/3 supermajority + human approval (see Quorum Rules table) — a higher bar than standard convention changes, because communication rules govern the process by which all other changes are made
New thread procedures can be defined through governance proposals when the colony encounters coordination scenarios not covered by the predefined set
Thread procedures can be deprecated (but not deleted — archived for reference) through the same governance process
Colony-level convention proposals can modify communication rules through the standard governance deliberation procedure — the communication protocol can be used to modify itself, which is the expected recursive property