S03 — State Model

There is no global state. Each node computes state locally from the events it has seen.

State categories

Category	Scope	Examples
Replicated	Gossiped across nodes	Event DAG, identity registry, reputation checkpoints, active commitments, active disputes, rule engine version, governance state
Local	Node-private	Computed reputation cache, intent queue, rate limit counters, gossip state, UI state
Derived	Computed on demand	Reputation scores, eligibility checks, graph analytics

Intersection model

Two nodes A and B may have different views of the world. Their shared truth is the intersection T(A) ∩ T(B) — only events that both have seen and validated.

Synchronization exchanges only mutually relevant events, not full state dumps.

Bootstrap

A new node joins by:

1. Downloading the latest reputation checkpoint (threshold-signed by quorum)
2. Verifying the checkpoint signatures
3. Requesting all events after the checkpoint
4. Computing local state from checkpoint + events

Reputation checkpoints

Created periodically by quorum agreement. Contain: state root hash, epoch number, reputation snapshot for all known identities. Signed by threshold (7/10 top arbiters). Serve as recovery anchors — nodes can rebuild from any valid checkpoint.

Object state machine

Each tracked object type has a defined set of valid states and allowed transitions. The rule engine (S11) is the only component permitted to execute state transitions — no other code may mutate an object’s state directly.

State table: object types × states

Object type	States	Terminal states
Commitment	open → active → pending_verification → completed / disputed / cancelled	completed, cancelled
Dispute	open → arbiter_assigned → in_deliberation → resolved / escalated	resolved
Appeal	filed → panel_assigned → in_deliberation → resolved	resolved
Sanction	intent_issued → admission_window → applied / reduced / lifted	applied, lifted
Identity	registered → active → deactivated / suspended	deactivated
Governance proposal	draft → open_vote → ratified / rejected / withdrawn	ratified, rejected, withdrawn
Fork	pending → active → merged / abandoned	merged, abandoned

Transition triggers table

Object	From → To	Triggered by	Event type
Commitment	open → active	Executor accepts; stake frozen	EVT-A02
Commitment	active → pending_verification	Executor delivers	EVT-A03
Commitment	pending_verification → completed	Creator confirms delivery	EVT-A04
Commitment	pending_verification → disputed	Creator opens dispute within window	EVT-B01
Commitment	active → cancelled	Mutual agreement or deadline exceeded	EVT-A05
Dispute	open → arbiter_assigned	VRF selects arbiters	EVT-B02
Dispute	arbiter_assigned → in_deliberation	All arbiters submit commit hashes	EVT-B03
Dispute	in_deliberation → resolved	Quorum of reveals counted	EVT-B04
Dispute	resolved → escalated	Loser files appeal within window	EVT-C01
Sanction	intent_issued → admission_window	Protocol issues sanction intent	EVT-D01
Sanction	admission_window → applied	Admission window expires with no response	Rule engine (automatic)
Sanction	admission_window → reduced	Subject yields within window	Rule engine
Identity	registered → active	Registration validated	EVT-E01
Identity	active → deactivated	Voluntary exit (AX-06)	EVT-E05
Fork	pending → active	Fork creation event validated	EVT-FORK-CREATE
Fork	active → merged	Merge protocol completes with quorum in both forks	EVT-FORK-MERGE

Key rules:

• State transitions are append-only: the old state is never deleted, only the new state is recorded.
• Transitions are deterministic: given the same event and prior state, every node computes the same new state.
• Invalid transitions are silently ignored (no error emitted); this preserves determinism when replaying event logs that contain rejected proposals.

---

Implementation Status

⚠ Donor genealogy table — not a Phase 0 claim. The table below was assembled in R40 against the pre-R53 donor AMS runtime (projects/unified-mcp/src/, deleted R53). Every src/controllers/*.js reference and “spec-only” verdict is heritage. Phase 0 Colibri has zero distributed/P2P state code — S03 is a forward-looking P2P design spec for the legitimacy axis (Phase 4+) and will be redesigned against src/domains/state/ (target path) when that phase ships.

Verified against donor AMS source: 2026-04-06 (pre-R53)

Claim	Status	Notes
No global state; each node computes locally	Spec-only	The current Colibri server is a centralized MCP server with a single SQLite database (data/ams.db, rename to colibri.db is pending for the Colibri rewrite). No multi-node architecture exists.
Three state categories (Replicated, Local, Derived)	Spec-only	No replicated or gossip-propagated state layer in codebase. All state is local to the single server process.
Intersection model (T(A) ∩ T(B))	Spec-only	No peer-to-peer synchronization or intersection logic found in src/.
Bootstrap via checkpoint download + event replay	Spec-only	src/gsd/checkpoint.js implements local workflow checkpoints (file-based snapshots with rollback), not network-distributed reputation checkpoints. No quorum verification, no threshold signatures.
Reputation checkpoints signed by 7/10 top arbiters	Spec-only	No threshold signing, no arbiter concept, no quorum logic anywhere in the source tree.
Synchronization exchanges only relevant events	Spec-only	No gossip protocol or event exchange mechanism implemented.
Event DAG as replicated state	Spec-only	No DAG data structure found in src/. The autonomous pipeline (src/controllers/autonomous.js) uses a linear state machine: INIT -> GATHER -> ANALYZE -> PLAN -> [DRY_RUN/APPLY] -> VERIFY -> DONE, stored in SQLite.

Summary: S03 describes the target P2P state model for the Colibri protocol. The current Colibri codebase is a single-server MCP implementation with no distributed state, gossip, or multi-node architecture. All claims in this spec are forward-looking design specifications.