Congregates · Chio Docs

Proposed coordination pattern

This page proposes congregate coordination. Bilateral two-party co-signing is documented separately; quorum co-signing remains planned.

Swarm Within One Organization

A swarm is a single organization's internal agent collective: a SwarmTaskGraph of cooperating agents (single root, acyclic, bounded max_depth and max_fanout) operating with a shared budget pool and revocation epoch. Delegated child tasks are admitted through chio-swarm-authority, a fail-closed verifier that checks the task graph, the continuation tokens, the capability-attenuation chain, and the live budget allocations before the task runs. A swarm is within one trust boundary and is governed by one operator.

Cross-Organization Coordination

A congregate is the discipline that lets independent swarms cooperate across an organizational boundary without merging into one swarm. Congregates do not share a kernel, operator, or budget pool. They use bilateral co-signing, where two kernels independently commit to the same canonical action (see Bilateral Receipts), revocation gossip, evidence-referential governance, market-based allocation, and jointly authored workflow receipts. They are a coordination pattern between independent kernels.

Dimension	Swarm	Congregate
Scope	One organization	Two or more organizations
Trust boundary	Single boundary, single operator	Separate organizational boundaries
Admission	`chio-swarm-authority` over a `SwarmTaskGraph`	Bilateral co-sign, escalated up the governance ladder
Budget	One shared budget pool	Each org's own pool; purchases can draw from both pools
Shared record	Internal receipts, one signer	Workflow receipts, jointly authored across kernels

Congregate Boundaries

A congregate has these boundaries:

No hosting provider. It runs on no third-party infrastructure or shared cluster.
No DAO governance. It has no token, electorate, or routine-action voting quorum.
No fixed roster.Participation follows completed bilateral handshakes rather than a membership list or registration form.
No kernel fork. Joining does not modify, replace, or subclass a participant's kernel.
No runtime replacement.Each organization keeps its internal swarm dispatcher.

Each organization retains its kernel, authority, and receipts.

How They Compose

Within one organization, swarm agents exchange pheromone signals and draw from the same budget pool. Those actions need no cross-signature.

A cross-boundary action, or an action for which a decaying signal is insufficient evidence, uses the governance ladder . Both kernels independently evaluate and sign the same canonical action, producing the dual-signed record described in Bilateral Receipts. A single action class can sit anywhere on that ladder:

yaml

action_classes:
  pheromone_deposit:
    mode: observation
    consistency_model: crdt-commutative
    co_sign: none
  cross_org_capability_grant:
    mode: receipt_backed
    consistency_model: totally-ordered
    co_sign: bilateral_if_cross_org
  shared_state_revocation:
    mode: receipt_backed
    consistency_model: quorum-required
    co_sign: n_of_m

The three-organization example of this escalation path is the 3-Vendor Walkthrough.

Congregates and the Cognition Market

Pool-level purchasing, one buyer transacting against a swarm's shared budget pool, is a congregate mechanism. It lets a swarm buy a finding once instead of having individual agents buy or derive it again. See The Cognition Market for the purchase path and Status & Retraction for what happens when a sold finding is later revoked.

Quorum co-signing in devnet

The examples on this page use the shipped two-party co-signing path. Devnet also provides opt-in, fail-closed n-of-m co-signing through FROST. Its detached authorization record uses schema chio.frost.authorization.v1, and chio_federation::frost::verify_for_execution checks it against an active trusted roster and a completed authorization slot. A quorum request made while the feature is disabled returns UnsupportedQuorum. Devnet maps this authorization to clearing.round_finalize for clearinghouse round finalization and channel.close for payment-channel close. The reserved adjudication.panel_decision mapping for the proposed parametric adjudication panel is planned. Production dispatch does not yet use this devnet feature. The quorum-required consistency model and co_sign_quorum scope now invoke the FROST checks in devnet.

Next steps

Federation & Swarms · why cross-org agents need this distinction at all
Bilateral Federation · the per-pair trust handshake a congregate is built on
Bilateral Receipts · the dual-signed record two kernels jointly produce
3-Vendor Walkthrough · the three-organization example
The Cognition Market · pool-level purchasing between congregate members

PreviousPortable Reputation Next3-Vendor Walkthrough