Collective State Model

6b.0 Preamble

Justification

Without a specified consistency model, “shared memory” is a logical concept with no physical semantics. Section 6 defines when information becomes shared (the promotion pipeline) and who decides (consensus). But it does not specify where shared state lives, how it is replicated across nodes, what a node sees when it reads shared state, or how concurrent writes from multiple nodes are reconciled. Without these answers, a node cannot reason about what it will observe when reading shared state — and if nodes cannot reason about shared state visibility, the promotion pipeline, consensus protocol, and fault isolation system all operate on undefined foundations.

Concretely, without this section:

• Two nodes promoting contradictory entries simultaneously have no resolution protocol.
• A new node joining the colony has no defined bootstrap procedure.
• A fault isolation rollback has no defined target state to restore.
• Nodes operating offline have no defined reconciliation procedure on reconnection.

Operating Timescales

Timescale	Operations
Milliseconds	Reads from materialized local views
Seconds–minutes	Consistency propagation (log replication between nodes)
Minutes–hours	Writes to shared state (promotion pipeline commits)
Hours–days	Checkpoint creation (periodic + on-rollback)
On-demand	New node bootstrap from checkpoint + log tail

Distributed Systems Framing

This section draws directly on five established DS concepts:

• State machine replication. The shared state log is a replicated sequence of state transitions. Each node applies the same transitions in causal order to arrive at a consistent materialized view. This is the foundational abstraction of replicated state machines (Schneider 1990).
• Event sourcing. The log is the source of truth, not the materialized views. Views are derived projections that can be rebuilt from the log at any time. This is the event sourcing pattern (as formalized by Fowler/Young): store the sequence of state changes, not the current state.
• Causal consistency. The consistency model is causal consistency — the weakest model that preserves the “happened-before” relation necessary for provenance chain integrity. This is strictly weaker than sequential consistency or linearizability, and strictly stronger than eventual consistency. Formally: if operation A causally precedes operation B (A happened-before B), then every node that observes B also observes A. (Lamport 1978, Ahamad et al. 1995.)
• Materialized views. Each node maintains local read-optimized projections of the log — the shared-structural/, shared-identity/, and conventions/ directories. These are materialized views in the database sense: derived from the source of truth, rebuilt on demand, optimized for read access patterns.
• Checkpointing. Periodic snapshots of materialized state serve as bootstrap points for new nodes and rollback targets for fault recovery. This is the standard checkpoint/restart pattern used in long-running distributed computations (Chandy-Lamport 1985 for the snapshot algorithm; simpler here because we have an ordered log).

Synixolis-specific: the log schema is designed for the promotion pipeline and convention evolution, which are Synixolis concepts. The transport abstraction (log is protocol, transport is policy) is Synixolis’s contribution — standard event sourcing assumes a specific transport (event bus, database); Synixolis decouples the logical log from its physical replication mechanism.

---

6b.1 Storage Topology

Shared colony state is a replicated append-only log with materialized views. The canonical representation is an ordered sequence of state transitions. Each node materializes its own local view of shared state by replaying the log.

Directory Structure

colony-state/
├── log.md                       ← Append-only transition log (source of truth)
├── shared-structural/           ← Materialized view: current shared structural entries
├── shared-identity/             ← Materialized view: current shared identity entries
├── conventions/                 ← Materialized view: current colony-wide compiled rules
└── checkpoints/                 ← Periodic snapshots for bootstrap + rollback
    └── checkpoint-{seq_id}.md

The Log

log.md is the single source of truth for all shared state. Every mutation to shared state — promotion, edit, rollback, excision, convention change — is an append to this log. The log is never modified in place; entries are never deleted or rewritten.

Each log entry MUST contain:

- seq_id: integer                # Monotonically increasing within the log
  operation: PROMOTE | EDIT | ROLLBACK | EXCISE | CONVENTION_ADD | CONVENTION_REMOVE | CHECKPOINT
  entry_id: ENTRY-{UUID-SHORT}   # The shared memory entry affected (null for CHECKPOINT)
  content: "..."                 # The entry content (for PROMOTE/EDIT) or diff (for CONVENTION_*)
  proposing_node: NODE-{id}      # The node that initiated this operation
  consensus_evidence:            # Which nodes validated, with their vote timestamps
    - node_id: NODE-{id}
      vote: APPROVE | REJECT
      timestamp: ISO-8601
  causal_deps: [seq_id, ...]     # Log entries this entry causally depends on
  timestamp: ISO-8601

The causal_deps field is the mechanism for causal ordering. If entry E has causal_deps: [12, 15], then any node applying entry E MUST have already applied entries 12 and 15. This is the vector clock / dependency tracking mechanism that enforces causal consistency without requiring a global total order.

Materialized Views

The shared-structural/, shared-identity/, and conventions/ directories are derived projections of the log. They exist for read performance — a node querying shared memory reads from these directories, not by scanning the log.

Materialization rules:

• A PROMOTE entry creates or updates a file in the appropriate shared directory.
• An EDIT entry modifies the corresponding file in place.
• A ROLLBACK entry reverts the corresponding file to its state at the referenced checkpoint.
• An EXCISE entry removes the corresponding file (archiving it with an EXCISED flag, not deleting).
• CONVENTION_ADD and CONVENTION_REMOVE modify files in conventions/.

A node MAY rebuild its materialized views from the log at any time. If a view and the log disagree, the log is authoritative.

---

6b.2 Consistency Model

The colony uses causal consistency — the weakest consistency model that preserves provenance chain integrity.

Why Causal Consistency

Synixolis nodes are session-based, not daemon-based. A Claude Code session may last minutes or hours, then go dormant for days. Requiring strong consistency (linearizability, sequential consistency) would mean:

• Dormant nodes block all shared state writes (they cannot participate in a total ordering protocol).
• Partitioned nodes (offline sessions) cannot operate on shared state at all.
• Every write requires synchronous coordination with all ACTIVE nodes.

These constraints are incompatible with the session-based execution model. Eventual consistency is too weak — it permits nodes to observe effects without their causes, which breaks provenance chain integrity (a node could see a promoted entry without seeing the entry it references).

Causal consistency is the precise fit:

• Guarantee: If operation A causally precedes operation B (A is in B’s causal_deps, or A was observed by the node before it issued B), then every node that observes B also observes A.
• Non-guarantee: Concurrent operations (neither causally precedes the other) MAY be observed in different orders by different nodes. This is acceptable because concurrent promotions to shared memory are independent by definition — if they were dependent, one would causally depend on the other.

Causal Dependency Tracking

Each node maintains a dependency context — the set of log entry seq_id values it has observed. When a node appends to the log, it includes its current dependency context in causal_deps. This ensures:

1. A promotion that references another shared entry lists that entry’s log seq_id in causal_deps.
2. A convention change that was proposed in response to observing a specific shared entry lists that entry’s seq_id.
3. A rollback that targets a specific contamination window lists the affected entries.

Nodes replaying the log MUST apply entries in an order consistent with causal_deps. Entries with no causal relationship MAY be applied in any order.

Partitioned Operation

A node that is temporarily partitioned (offline Claude Code session, network outage) continues operating on its local view of shared state — the materialized views as of its last sync. The node MAY:

• Read from its local materialized views (stale but causally consistent as of last sync).
• Write to its own local memory (not shared state).
• Queue promotion proposals for submission on reconnection.

The node MUST NOT:

• Assume its local view is current.
• Present shared state reads to users without noting the last-sync timestamp.

On reconnection, the node:

1. Fetches all log entries since its last observed seq_id.
2. Applies them in causal order to update materialized views.
3. Submits any queued promotion proposals (which may now conflict with entries written during the partition — conflicts resolved per §6b.3).

---

6b.3 Conflict Resolution

Conflicts arise when two nodes perform concurrent operations on shared state that produce contradictory results. Because causal consistency permits concurrent operations to be observed in different orders, explicit conflict resolution is required.

Conflict Detection

A conflict exists when:

• Two PROMOTE entries for the same domain produce contradictory claims (detected by the contradiction check in the write path, §3).
• Two CONVENTION_ADD entries propose incompatible routing rules.
• A PROMOTE entry and an EXCISE entry target the same entry_id concurrently.

Resolution Hierarchy

Conflicts MUST be resolved in the following priority order:

1. Recency. The entry with the later timestamp takes precedence. Rationale: more recent information is more likely to reflect current state.
2. Confidence. If timestamps are within a tolerance window (configurable, default: 1 hour), the entry with higher confidence score takes precedence.
3. Domain owner. If confidence scores are within tolerance (configurable, default: 0.05), the entry from the node whose receptor most closely matches the domain takes precedence.
4. Escalate. If none of the above resolves the conflict, it is escalated to human decision. The conflicting entries are flagged in the log with an UNRESOLVED_CONFLICT marker. Both entries remain visible (neither is suppressed) until the human resolves.

Resolution Recording

Every conflict resolution MUST be recorded in the log:

- seq_id: integer
  operation: CONFLICT_RESOLUTION
  conflicting_entries: [seq_id_a, seq_id_b]
  resolution: recency | confidence | domain_owner | human
  winner: seq_id
  rationale: "Entry {seq_id_a} at 2026-03-25T14:30Z supersedes {seq_id_b} at 2026-03-25T10:15Z by recency"

This creates an auditable trail of conflict resolutions that can be reviewed for patterns — systematic conflicts between two nodes in the same domain may indicate a merge or scope clarification is needed.

---

6b.4 Transport Abstraction

The log is the protocol. Transport is policy.

The protocol specifies the logical structure of the log (§6b.1) and the consistency guarantees it provides (§6b.2). How the log is replicated between nodes is a deployment decision. The protocol requires three transport capabilities:

1. Ordered append. A node can append an entry to the log with a seq_id greater than all existing entries it has observed.
2. Range read. A node can read all log entries in a seq_id range (for catch-up after partition).
3. View materialization. A node can rebuild materialized views from the log (for consistency verification and bootstrap).

Reference Transport Implementations

Transport	Topology	Append Mechanism	Range Read	Suitable For
Shared filesystem	Single machine, all nodes access same directory	File append to log.md with filesystem lock	Read file from offset	Local development, single-user
Git repository	Multi-machine, asynchronous	Each log entry is a commit; git push	git log --since	Team deployment, naturally versioned
MCP endpoint	Multi-machine, synchronous	MCP tool call to append service	MCP tool call with range parameters	Service-oriented deployment
Message queue	Multi-machine, asynchronous	Publish to ordered topic	Consumer group with offset tracking	High-throughput deployment

A conforming node MUST NOT assume a specific transport. The node interacts with the log through the three capabilities above. Transport selection is a colony-level configuration decision.

Transport-Specific Considerations

• Filesystem transport: Concurrent appends require a lock file or atomic rename. The reference implementation uses log.md.lock with advisory locking.
• Git transport: Each log entry maps to a commit. causal_deps map to git parent references. Git’s DAG naturally enforces causal ordering. Merge commits represent conflict resolutions.
• MCP transport: The append service is responsible for seq_id assignment and causal ordering. The service is a coordination point — it does not need to be highly available because nodes can operate on stale views during outages.

---

6b.5 Checkpoint Policy

Checkpoints are snapshots of the materialized views at a specific seq_id. They serve two purposes: bootstrap source for new nodes, and rollback targets for fault recovery (§6d).

Checkpoint Creation

• Checkpoints MUST be created every N log entries (configurable, default: 100).
• Checkpoints MUST be created on any ROLLBACK event (the post-rollback state becomes the new checkpoint).
• Checkpoint creation is a colony-level operation: one node creates the checkpoint, and other ACTIVE nodes SHOULD validate that the materialized views in the checkpoint match their own local views at that seq_id.

Checkpoint Format

checkpoint_seq_id: integer
created_by: NODE-{id}
created_at: ISO-8601
validated_by:                      # Nodes that confirmed view consistency
  - node_id: NODE-{id}
    validated_at: ISO-8601
log_hash: SHA-256 of log entries 0..seq_id   # Integrity verification

The checkpoint file is followed by a full copy of all materialized views (shared-structural/, shared-identity/, conventions/) as of that seq_id.

Checkpoint Retention

• The most recent K checkpoints (configurable, default: 5) are retained in the hot path (colony-state/checkpoints/).
• Older checkpoints are archived (moved to glacier or equivalent cold storage). They are never deleted.
• On any ROLLBACK event, the system identifies the most recent clean checkpoint (before the contamination window) as the rollback target.

---

6b.6 New Node Bootstrap

When a new node joins the colony (via any spawn type), it MUST bootstrap its view of shared state. The bootstrap procedure is:

1. Locate latest checkpoint. Read the most recent entry in colony-state/checkpoints/.
2. Load checkpoint state. Materialize local views from the checkpoint’s snapshot of shared-structural/, shared-identity/, and conventions/.
3. Replay log tail. Read all log entries from checkpoint_seq_id + 1 to the current log head. Apply each entry in causal order to update materialized views.
4. Set dependency context. The node’s initial dependency context is the set of all seq_id values it has observed through checkpoint + log tail replay.
5. Transition to ACTIVE. The node is now operating on a causally consistent view of shared state and can participate in consensus and promotion.

This procedure ensures a new node does not need to replay the entire log history — it starts from the nearest checkpoint and catches up. For a colony with 10,000 log entries and checkpoints every 100 entries, the maximum replay is 100 entries (worst case: the node arrives just before a new checkpoint would be created).

Bootstrap Failure Handling

• If the latest checkpoint is corrupt (hash mismatch), the node falls back to the next most recent checkpoint.
• If all checkpoints are corrupt, the node replays the full log from entry 0. This is expensive but correct — the log is the source of truth.
• If the log itself is unavailable (transport failure), the node enters INITIALIZING state and retries on a backoff schedule. It MUST NOT transition to ACTIVE with an empty or partial view of shared state.