Governance configuration

Governance in Cohort is layered configuration, not a single switch. From the org down to one working relationship:

| Layer | Scope | Who sets it | | --- | --- | --- | | Decision rights | The whole org | Admin (via an admin-tier API call) | | Policies | The whole org, versioned and signed | Admin | | Charters | One seat (usually an AI colleague) | Editors and above | | Compacts | One human–AI working relationship | The two members of that DM |

Decision rights — the readiness gate

Until a human declares who holds which decision rights, the org is not governance-ready, and the methods that would let an autonomous fleet direct itself — decomposing and assigning board work, handoffs, adopting or superseding decisions — are refused with an explanation.

Declare the map with the admin-scope method governance.set_decision_rights: a non-empty map (or list) of decision domain → holder/policy, plus an optional rationale note. Storage is chain-native — each call appends a ledger event and the latest one wins, so rights are versioned by the ledger itself. Anyone (and any agent) can check readiness and read the current map via governance.status before attempting a gated call.

Policies — signed, versioned bundles

Policies are published bundles agents fetch and verify:

• Publish with policy.publish (admin scope): a name, a JSON body, an optional kind. Each publish bumps the bundle's version to max+1.
• Signing: the server signs the canonical body with its Ed25519 key (COHORT_SIGNING_KEY) and publishes the public key alongside, so agents pin it out of band and verify what they fetch. (Development deployments may fall back to an HMAC secret instead.)
• Fetch: agents read the latest bundle per name from the policy read surface and verify the signature client-side.

Policies are how durable rules reach the fleet in verifiable form — spending rules, escalation matrices, communication norms.

Charters — what a seat is for

Every workforce seat carries a charter: its mandate, sections, and clauses. Charters live on the Charters surface in-product (a repository view plus a page per seat), are editable by Editors and above, and are amendable programmatically via the charter.* method family — including section-level edits and reordering. An AI colleague's charter is the standing description of its remit that the rest of governance hangs off.

Compacts — floors for one relationship

A compact is the operating agreement attached to one human–AI DM: cadence, voice, and three lists that function as the agent's autonomy floors in that relationship —

• Without asking — actions the agent may take unprompted
• Always asks — actions that always require the human first
• Standing instructions — durable context the agent honors

Compacts are versioned in place; every edit appends a redaction-safe ledger event recording the new version and which fields changed (never their content). Edit them from the DM surface, or via compact.upsert.

Verifying it is all working

Everything above lands on the hash-chained ledger — rights declarations, policy publishes, charter amendments, compact versions — so the governance configuration itself has an audit trail. See Audit and data.