Canonical cooperation Gov · CWV 1.1.0

Agent, Team, and Network Coordination

One model for live multi-participant coordination, durable semantic continuity, private evidence, and canonical results.

Gov Manual

Purpose

Coordinate human and AI participants without conflating current operations, durable memory, raw evidence, or canonical authority.

Use when

Participants share an outcome, a task joins or resumes a team, RAgents is used, or relationships cross teams and disciplines.

Required action

Resolve participants, scope, ownership, coordination state, related XRT, and repository CWV before substantial execution.

Core meanings

Agent

An AI-capable Participant in a distinct task, chat, process, or automation context.

Team

An operational group coordinating shared outcomes under explicit scope, roles, ownership, and work state.

Network

A relationship layer connecting distinct Participants or Teams without merging their authority or work queues.

RAgents

A project-owned operational realization. It is not Global Governance, an XRT archive, a transcript store, or canonical implementation state.

Four distinct layers

LayerQuestionHome
Operational coordinationWho is doing what now?Team surface such as RAgents
Semantic continuityWhat was learned and why?XRT chain and CWV
Raw evidenceWhat was actually present?Private/local verified transcript
Canonical resultWhat applies now?Repository or project main

Continuity Freshness Gate

  1. Refresh stale or uncertain bootstrap state.
  2. Resolve repository, project, task, and team/network scope.
  3. Discover related XRT before creating a new chain.
  4. Read applicable XRT fast-path records.
  5. Inspect authoritative operational coordination state.
  6. Compare both with current repository/CWV evidence.
  7. Continue without silent duplication or ownership conflict.

The gate runs automatically on substantial entry, resumption, or material scope change. Reopening a chat UI is not refresh evidence. 2HE BOOTSTRAP remains the explicit force-refresh control.

Safe cadence

Update coordination state on meaningful events such as assignment, blocker, handoff, completion, or ownership release. Use scheduled reconciliation to repair missed events, not as the primary processing model. Create or extend XRT only when durable continuity value exists; do not create one XRT per chat.

Cooperative execution safety

Use isolated worktrees for parallel code changes and one transactional ownership authority for each shared runtime or deployment target. Adapters reject expired fencing tokens. Persistent in-flight reservations prevent takeover during uncertain external actions.

Idempotent requests, conditional revisions, immutable XRT packages and explicit delivery states prevent silent overwrites. Concurrent XRT heads remain visible until reviewed and consolidated.

Protection levels: isolated, coordinated_manual, enforced, unavailable. Fixture tests do not enroll production chats or Blender sessions. Pages is a projection and never grants a write lease.

ROCK runtime and recovery manual