ROST implementation method

ROST setup is a staged operating-system implementation. The goal is not to mirror a historical org chart. The goal is to make the company legible enough that humans and agents can operate inside the same accountability model.

Setup opens with one decision: continue through the guided step rail yourself, or hand the CLI- and MCP-driven implementation off to your own coding agent. Either path drives the same staged implementation below, and provider connections stay human-approved either way — the choice can change later.

Stage 1: Bring the company into view

Start with the company context that already exists: org charts, team notes, planning docs, process notes, metrics, or a founder transcript. The first output is a rough Compass and a draft Responsibility Graph.

Good setup work answers four questions:

• What outcomes is the company pursuing?
• What functions must exist for those outcomes to happen?
• Which seats own those functions?
• Which work can be handled by a human, an agent, or a hybrid seat?

Agents should call onboarding.status before recommending next steps. If context is missing, recommend adding context before creating many seats.

Stage 2: Design functions before staffing people

Build the Responsibility Graph from functions and seats first. Do not start by arranging names. A seat is a function with accountability, authority, and measurable outcomes. A human can occupy more than one seat, and a seat can be vacant while the structure is clarified.

The first graph should be small enough to understand. Start with the top operating seat, then major functions, then the first operational seats that carry measurable work. Add detail only when it clarifies ownership.

Solo founders and small flat teams

If it is just you, or a small flat team of four or fewer people, declare that at the start of org intake. Setup skips the org-chart upload and the "who reports to you" question, and instead asks which functions the company needs covered today. It proposes a standard small-company function tree — company leadership, revenue, sales, marketing, delivery and operations, finance and admin — that you occupy, then pivots straight to which functions to staff with agents. Because there is no one to invite, the team-invite step is skipped. You can still invite people later from settings.

Stage 3: Convert seats into Charters

A Charter is the executable job description for a seat. It should define purpose, responsibilities, autonomous scope, approval scope, must-escalate conditions, measurables, and tool permissions.

For human seats, the Charter creates clarity. For agent and hybrid seats, the Charter becomes operating context and permission boundaries.

Stage 4: Staff carefully

Staffing happens after the seat is clear. A human occupancy should be accountable to the seat's Charter. An agent occupancy must have a human Steward chain and should begin with dry runs before go-live. A hybrid seat must say which responsibilities stay human and which are delegated to an agent.

Durable changes that expand authority require human confirmation.

Stage 5: Run the rhythm

Guided setup asks you to set the Sync Brief scope — one company-wide brief, or one per cluster — as its own step, scoped against the graph you have built so far. It is not a one-time choice: change it any time in settings. See the Sync rhythm playbook for what the brief compiles.

Once the graph is live, run the operating rhythm: Signal tracks measurable health, Friction captures issues, Cascade ties work to goals, and Sync turns the weekly meeting into a decision forum.

The system should surface exceptions before the meeting. Humans should spend Sync time deciding, resolving, and clarifying authority.

When onboarding finishes, the app opens on the Responsibility Graph with a short next-step note: you have a graph, agent seats, and dry runs in place; the next moves are to approve your Compass, add cycle goals, and define the signals you want to track. The same sequence applies whether you continue in the app, the CLI, or an MCP client.

Operate Compass and onboarding from CLI or MCP

The Compass is drafted, then activated by a human through supersession.

• Inspect onboarding: onboarding.status / rost_onboard_status. Attach company reference documents with onboarding.attach_reference / rost_attach_reference_document (text/markdown, with a title, kind, and source; onboarding.upload_context is the back-compat alias). This is reference-only — it lets Compass and Charters cite the docs; you author the Compass directly (see the Compass authoring guide). Advance with onboarding.advance_step; complete with onboarding.finish. onboarding.status reports a tenant onboarded once four derived requirements pass — a seat below the root, an active Compass, a Charter with at least one measurable, and an agent in dry-run or live — and the completion marker has been written — by onboarding.finish, or by onboarding.activate when an owner approves an agent-led composite setup. A reference document is not one of them: attaching one grounds Compass and Charter citations, it never gates completion. Invite teammates with onboarding.create_invite.
• Read the Compass: compass.get_current / rost_get_current_compass or read the resource rost://compass/current (tenant-admin). List context gaps with compass.list_gaps / rost_list_compass_gaps and answer them with compass.answer_gap / rost_answer_compass_gap.
• Draft and activate: compass.draft / rost_draft_compass then compass.update_draft; activate with compass.approve_version / rost_approve_compass_version or discard with compass.reject_draft. compass.set is a compatibility helper for setting the approved Compass over MCP.

When to stop for confirmation

onboarding.setup, onboarding.finish, compass.approve_version, compass.reject_draft, and compass.set are human_required. onboarding.source_ingest is a bootstrap-safe none prerequisite that retains bounded source bytes encrypted under the exact tenant/run, computes its digest and canonical parser manifest server-side, and remains permanently outside Trusted and Full Operator. onboarding.setup is the one-approval composite apply: it freezes the complete plan and live proof at staging, then rechecks them and applies Compass, cycle, Responsibility Graph, Charters, staffing, goals, Signals/readings, Frictions, tasks, and Sync scope in one transaction. A failure rolls back the entire application and leaves the confirmation pending.

Both commands fail closed on a missing server capability (for example unconfigured document-source storage) with a named, owner-facing remediation string that says what to do next — never a bare error code or a raw configuration value. onboarding.source_ingest checks this before decoding the uploaded source; onboarding.setup checks it before any plan-shape or Responsibility Graph foundation validation runs, so the block happens as early as the command can report it. The web onboarding entry screen surfaces the same deployment-wide readiness state before an owner invests in the flow.

Content-linting on a setup plan reports every violation in one response rather than the first: each names its rule, the exact field path, the offending substring (quoted, with secrets redacted and payment/phone numbers masked), and a one-line remedy. Free-text narrative may contain ISO dates (YYYY-MM-DD) and short numeric references — only a run of nine or more digits is treated as a direct phone or payment identifier — so a date in prose no longer forces a bisection. The approval card also carries non-blocking reachability warnings: for each agent- or integration-sourced Charter measurable whose Seat permission manifest grants no read-capable tool, it names the input the agent cannot read, so the owner sees the gap before approving rather than after an agent escalates at runtime.

The whole composite flow has first-class CLI verbs: rost onboard source-ingest --file <path> ... for each allowed local source, rost onboard setup --input-file <plan.json> to stage the one owner approval (it prints the confirmation id and exact approval URL), rost onboard setup-status --input-file <plan.json> to discover the applied receipt by idempotent re-submission of the identical plan, then rost onboard rehearse and rost onboard activate. Each uses an existing implementation-bootstrap credential first; only an absent credential leaves the user-session path available, while expiry, read errors, authentication failures, and policy refusals stop without a principal change. The generic rost command <id> --json path and the generated MCP tools expose the same schemas.

After setup succeeds, call onboarding.rehearse with the exact setup application, expected setup digest/revision, and a caller idempotency key. This is the implementation principal's one bounded execute exception: it is ungated because it can run only the setup receipt's exact agents in the sandbox, with no schedule arming, go-live transition, credential access, source mutation, or external communication. It rechecks the current Charter manifest, pinned published Skill versions and content hashes, schedule, execution lane, and canonical configuration digest under the same tenant/run boundary. A complete batch returns an immutable terminal batch receipt plus one immutable per-agent receipt with nonzero checked counts, runtime run ids, bounded tool previews/manifest holds/errors, and passed or failed status. Same-key/same-configuration retry returns that terminal evidence; a changed configuration conflicts instead of silently reusing it. The rehearsal never returns an approval URL and never stages activation. The later, separate onboarding.activate command consumes that exact terminal batch and the unique run/configuration evidence for the setup receipt's complete agent set. It stages one owner approval whose durable card shows every agent, Seat, Charter/configuration digest, rehearsal run, effective lane/model, permissions, schedule, warnings, and the onboarding-completion effect. Approval rechecks the full projection, records one composite human decision, makes every agent live, arms eligible schedules, and completes onboarding atomically. Any stale or failed member rolls the transaction back; same-key retry returns the committed receipt without duplicating effects.

onboarding.advance_step, onboarding.attach_reference, compass.answer_gap, and drafting a Compass are none — none of them returns a pending confirmation. onboarding.create_invite is the exception: it is an owner/admin human-gated ordinary invite path, and accepts only the strict ordinary invite flags (cohort beta-tester/design-partner flags are server-only). none is not the same as "agent-callable", and it is not the same as "available to the implementation-bootstrap principal" either. onboarding.create_invite and compass.answer_gap record the human who ran them, so they run as a person, not from an agent session. onboarding.advance_step and onboarding.attach_reference are none yet the bootstrap policy classifies both deny, so an implementation agent has no route to them at all: while an implementation run is active, a headless invocation of either is refused outright — naming the command and the missing implementation route — rather than quietly running under a co-resident owner session (DER-3255). An explicit interactive terminal remains the owner's own deliberate path for them. What the bootstrap agent does have here is exact-run source ingestion (onboarding.source_ingest, lifecycle class) for company documents, and compass.set (stage class) for authoring a Compass version whose activation stays human-gated. Attaching a reference document is an owner act, or a tenant-seat agent's over MCP. Approving a version (a supersession) is a human act. The agent drafts and surfaces the approve link. See the confirmations guide.

Method reference index

The implementation method is split into stable sections so a CLI, MCP, or in-app agent can navigate to just the one it needs instead of reading the whole corpus closely. A section id is directly retrievable: run rost reference get rost-implementation-method --section <id> on the CLI, or call rost_reference_get with {"slug":"rost-implementation-method","section":"<id>"} over MCP. Both return just that section, its driving commands, and the versioned public reference that expands it. The MCP tool can additionally slice other guides by their Markdown section headings. Each entry below lists the versioned public reference that expands it and its driving commands. Command shapes come from live command discovery — the ids here name the command, they are not a substitute for the registry contract.

<!-- section:evidence-hierarchy -->

• Evidence hierarchy (evidence-hierarchy) — ground every company fact in live tenant reads, then cited owner documents, then marked provisional assumptions; never invent. Commands: onboarding.status, onboarding.attach_reference, compass.list_gaps.

<!-- section:provisional-assumptions -->

• Provisional assumptions and source citation (provisional-assumptions) — cite the source for every non-obvious fact; label unconfirmed inferences provisional and offer them for correction. Commands: onboarding.attach_reference, compass.answer_gap.

<!-- section:company-assessment -->

• Company assessment (company-assessment) — bring the company into view and answer the four legibility questions; use the small-company function tree for solo founders and small flat teams. Commands: onboarding.status, onboarding.upload_context.

<!-- section:compass-method -->

• Compass method (compass-method) — draft the Compass, then a human activates a version through supersession. Commands: compass.draft, compass.update_draft, compass.approve_version.

<!-- section:responsibility-graph-method -->

• Responsibility Graph method (responsibility-graph-method) — build from functions and Seats before names; Seats own things, people reach them through occupancies. Commands: seat.create, seat.set_type.

<!-- section:charter-method -->

• Charter method (charter-method) — the Charter is a Seat's executable job description; a human reviews before approval and agent Seats need a Steward chain, dry runs, and vault-referenced secrets. Commands: charter.draft, charter.approve, charter.sign_manifest.

<!-- section:cascade-method -->

• Cascade method (cascade-method) — cycle objectives cascade from the Compass's horizon goals; there is no cascade-create command, only cascade.import. Commands: compass.update_draft, cascade.import.

<!-- section:signal-method -->

• Signal method (signal-method) — Signal tracks measurable health; agents draft readings and humans confirm them. Commands: signal.bind, signal.report, signal.confirm_reading.

<!-- section:friction-method -->

• Friction method (friction-method) — Friction captures issues; recurring Friction is a Sync input. An agent files and proposes; resolving is human_required and records a human decision. Commands: friction.file_issue, friction.resolve.

<!-- section:sync-method -->

• Sync method (sync-method) — Sync is the weekly decision forum and the Sync Brief compiles its prep. Commands: sync.brief.compile, sync.brief.get, sync.run.start, sync.run.complete, sync.item.assign.

<!-- section:verification -->

• Verification (verification) — re-read live state before claiming a step done; a drafted Compass or Charter is not an approved one. Commands: onboarding.status, compass.get_current.

<!-- section:handoff -->

• Handoff and completion (handoff) — finish only after required approvals; skipping guidance selects a path, it does not claim completion. Commands: onboarding.finish.