Charter design playbook

A Charter is a seat's operating contract. It must be specific enough for a human to understand the job and strict enough for an agent to operate safely.

Required Charter sections

• Purpose: why this seat exists.
• Responsibilities: the recurring outcomes the seat owns.
• Autonomous scope: what the seat may do without asking.
• Approval scope: what requires human confirmation.
• Must-escalate conditions: what the seat must not decide alone.
• Measurables: how the seat knows it is on track.
• Tools and data: which systems the seat may use.
• Reporting rhythm: what the seat reports into Signal, Friction, Cascade, and Sync.

Responsibility quality bar

Responsibilities should be outcomes, not vague activities. "Keep vendor payments clean and on time" is stronger than "help with accounting." The test is whether a measurable, escalation, or handoff can be attached to the responsibility.

Agent and hybrid Charters

Agent Charters need tighter boundaries than human Charters. They must separate autonomous work from approval-required work, and they must name conditions that always escalate.

Hybrid Charters should split the work: what the human remains accountable for, what the agent performs, and where the handoff happens.

Operate Charters from CLI or MCP

List and read first, then draft, then leave activation to a human.

• List: rost command charter.list --json '{}' or rost_list_charters (scope: tenant). Read one with charter.get / rost_get_charter.
• Draft one: rost command charter.draft --json '{"seat_id":"<seat-id>"}' (scope: seat or tenant-admin); draft every eligible seat with charter.draft_all / rost_draft_all_charters. Draft commands are not gated — they produce a draft charter_version_id. charter.draft_all only drafts active seats and returns the real result: { drafted, skipped, draft_ids, skipped_seats: [{ seat_id, reason }] } where reason is seat_not_active (the seat is still draft/vacant — confirm it first) or charter_exists (it already has a draft/active Charter). Read skipped_seats to see why a freshly-built graph drafted fewer Charters than it has seats.
• Edit a draft: charter.update_draft / rost_update_charter_draft with the charter_version_id and the new doc.

When to stop for confirmation

charter.approve, charter.skip, charter.apply_seat_type_recommendation, and charter.sign_manifest are human_required. Over MCP rost_approve_charter returns a pending confirmation, not an activation. Approving a Charter, signing a permission manifest, or expanding authority is a human act recorded against decided_by. An agent prepares the draft and surfaces the approve link; it does not approve. See the confirmations guide.

Approval rule

Drafting can be assisted by agents. Activation is a human decision. When authority, tool permissions, credentials, or go-live status changes, route through confirmation.