Chio/Docs

Three-Layer Architecture

The congregate has three layers. Each cites the Chio primitive that already implements it (or, for the gating specs, names the missing piece).

Forward-looking concept

Layers below the “Coordination Discipline” row exist today; that top row is the chiodos research line, not shipped surface.

The three layers

rendering…
Top: chiodos coordination discipline (the congregate). Middle: one participant kernel per organisation. Bottom: Chio crates supplying the trust primitives. Each top-layer item names the Chio crate it builds on.

Two things to notice

  • The middle layer is not part of Chio. It is a separate runtime. Different domains can pick different shapes.
  • The top layer is not a deployment. It is a set of disciplines a participant kernel agrees to honour. Joining is implicit in honouring them, not in installing anything.

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 (gating spec; substrate trait + bilateral gossip via 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 a single artefact)
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-open-market (BidRequest → AskResponse → AcceptedBid)
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). Local Sensor signs a pheromone deposit, federation gossip pushes it under treaty scope, peer concentration calculation weights by peer reputation. No co-signing required.

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. Peers respond with AskResponses. The requester signs an AcceptedBid, which mints a scoped capability for the awarded peer.

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.