Chio/Docs

Docs

Three-Layer Architecture

The congregate has three layers. Each item identifies the Chio crate that implements it.

Implementation status

The diagram identifies shipped Chio crates, including the coordination items. Treaty rosters and multi-organization production deployments are proposed deployment work.

The three layers

rendering…
Top: congregate coordination rules. Middle: one participant kernel per organization. Bottom: Chio crates that provide capabilities, receipts, and federation checks. Each top-layer item identifies its Chio crate.

Two things to notice

  • Participant kernel. This is a separate runtime. Different domains can use different implementations.
  • Coordination discipline. This is a set of rules a participant kernel follows. It is not a separate deployable service.

Roles, cross-domain

Eight archetypes that recur across domains. A finance-domain participant might call its Sensor an “Oracle”; a cybersec participant uses domain-specific names. Capability scopes and governance authority are domain-independent. The last column points to the closest Chio implementation today, where one exists.

ArchetypeFunctionAuthorityExample crate / module
SensorIngests signals, deposits pheromonesRead + deposit, no executionchio-pheromone (shipped crate; PheromoneSubstrate trait and bilateral gossip using the chio-federation::revocation_gossip pattern)
InvestigatorFollows leads, reconstructs lineageRead + query, can flagchio-lineage (provenance DAG traversal)
CorrelatorJoins signals into incidentsRead + publish, advisorychio-workflow (multi-step plan as one workflow record)
ResponderExecutes approved actionsWrite under capability leasechio-federation::bilateral (joint commit at action time)
GovernanceIssues receipts, manages quorumGovernance, no direct executionchio-governance (dispute / freeze / sanction / appeal)
EvolverDrift-driven mutation + canaryProposal authoritychio-wasm-guards (hot_reload engine; canary corpus + post-swap rollback watchdog)
MemoryDurable knowledge graphAppend-only knowledgechio-revocation-oracle (sparse-Merkle epoch roots; passport bridge for revocation lineage)
AdversarialAdversary deployment + fitnessSandboxed onlychio-arena (coevolve, leaderboard; replayable fitness exported as reputation factor)

How decisions get made

Routine cross-org coordination (Observation mode). A local Sensor signs a pheromone deposit. Federation gossip sends it under treaty scope, and the peer concentration calculation weights it by peer reputation.

Joint destructive action (Receipt-backed mode). Both kernels independently evaluate the request and sign the same canonical body via bilateral co-signing. A workflow receipt captures the full joint multi-step plan.

Cross-org task allocation (Market mode). A participant publishes a BidRequest. Each responding peer mints a scoped capability token and returns it in its AskResponse. The requester signs an AcceptedBid against a signature-verified funds-reservation receipt, which binds the previously minted token.

Compromised peer expulsion (Sanction case + revocation gossip). A governance Sanction case is filed with named evidence. On enforcement, the passport revocation bridge flips the peer’s state and revocation gossip propagates pairwise.

rendering…
The four flows side by side. Observation is the routine path (no co-sign). Receipt-backed is the joint commit path. Market is the task-allocation path. Sanction is the expulsion path. Most cross-org volume is Observation; the destructive minority lands in Receipt-backed or Sanction.