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 setup milestones 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. Team invites are skipped for solo/flat setups, but 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

During setup you choose the Sync Brief scope — one company-wide brief, or one per cluster — 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 (a V2 composite setup records completion itself, so that path needs neither). 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, by the V2 composite setup approval itself (which records completion in its own transaction, which is why that path needs neither), or by onboarding.activate when an owner approves a V1 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, Signal→goal informs bindings declared on a V2 plan, Frictions, tasks, and Sync scope in one transaction. A failure rolls back the entire application and leaves the confirmation pending.

A schema_version: 2 setup plan carries one more thing: what the AI Chief of Staff may do, and where it runs. That same single approval configures the canonical AICOS on its lane — the Runner lane when the plan names a Runner setup that is finished and reachable, otherwise a visible Cloud fallback only when the plan's `cloud_fallback_authorized` is true, stating which of the three reasons applied (no Runner setup was referenced, the referenced one never finished, or the lane itself was not reachable) and preserving the Runner preference so it can be resumed later. When the preferred Runner lane is unreachable and cloud_fallback_authorized is false, both lanes are unavailable: the company still completes, AICOS stays paused with recovery reason aicos_no_lane_available, no Trusted grant is minted, and the one setup decision is the recovery item — never a silent Cloud write. It reads the AICOS's own rehearsal evidence and activates the chief of staff only when a real dry-run passed on the lane it actually ended up on; anything else leaves AICOS truthfully paused while the company still completes, with the setup decision itself carried forward as the one thing the owner acts on to recover. It also establishes the bounded Trusted grant AICOS acts under when a lane was configured. All of it is one human decision and one transaction: exactly one decision row, at most one grant, one grant event when a grant exists, and a receipt that names them — and a later failure rolls the grant, the lane, and the company back together. Re-submitting the identical plan after a lost response returns the same ids and creates nothing twice. A V2 Signal may also declare optional goal_keys naming logical goals in the same plan; those apply as informative (informs) Signal→goal bindings in the same transaction, so the Scorecard is wired without a post-setup goal.bind_measurable loop. An unknown goal key is refused at plan validation rather than silently dropped. Driving a goal's status (drives_status) stays a deliberate post-setup steward act. One posture is refused rather than applied: a Signal submitted as live_verified is rejected before the approval card exists, naming each Signal and saying why — the connection that would prove a Signal is live has to feed a Signal that already exists, and this setup is the thing creating it. Submit those Signals as manual, imported history, or not connected, then connect their integration from the Signal page once the company is there. On a Beta company the same approval also records a versioned launch default — a setting, not authority: it names the setup decision it came from and says that agents this company launches later start with the Trusted posture. It grants nothing to anybody and creates no grant for the agents the plan leaves in draft; every agent still gets its own grant only at its own reviewed launch. Companies on any other plan are left untouched. A Beta company that finished onboarding BEFORE that default existed opts in the same way, after the fact: aicos.trusted_beta.status shows the current review — what the chief of staff may do unattended, what always asks, its budget, and the scope digest that review is bound to — and aicos.trusted_beta.enable, owner only, stages one ordinary approval for it. Approving it creates exactly one bounded grant for the canonical chief of staff, one decision naming the human who approved it, and turns the launch default on. It is refused if the company is not on the Beta plan, if its autonomy ceiling is set below high, if the chief of staff already holds an active grant, or if the Charter or permissions moved after the review was read — in which case read the status again and opt in against the current one. aicos.trusted_beta.disable turns the posture back off so later launches create no grant; it revokes nothing that already exists, which is agent.trust.revoke, per agent.

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, a safe description of the offending content, and a one-line remedy. The lint never reproduces what it matched — a path or an email address can itself be a credential — so it names the shape and the character offset instead (a relative file path at character offset 5), masks a phone or payment number to its digit count and last four, and names secret-shaped material only by class. The exact field path in each violation is what locates it. Free-text narrative may contain ISO dates (YYYY-MM-DD), everyday currency amounts, and short numeric references; adjacent dates are read as separate dates, so a date in prose never forces a bisection. Two things are treated as a direct contact or payment identifier: a run of nine or more digits, and a grouped number that carries a payment card's grouping, its 13-to-19-digit length, and its check digit. Digit script does not change that answer — non-ASCII digits are folded first, and zero-width, bidi, and combining characters are removed before grouping, so a number that survived a copy-paste out of a PDF or a right-to-left document is still read as one number. Separator choice mostly does not either: spaces, tabs, newlines, commas, dashes, and the other grouping punctuation all join digits into one candidate. The exception is thousands grouping, which is recognised only when the separator is the one a locale actually emits — a comma, a period, a space, or a non-breaking space. A number grouped in thousands by a semicolon, a colon, a pipe, an underscore, a tab, a newline, an en-dash, or a comma followed by a space is not read as a card. That narrowing is deliberate: without it, several ordinary amounts sitting next to each other in a sentence merged into one candidate and were rejected about nine times in ten. Three limits are worth stating rather than discovering. A run of more than 32 consecutive separator characters inside one number splits it, and the part after the split is no longer examined as a card — for spaces, periods, hyphens, parentheses, and slashes the nine-or-more-digit rule still catches it, but for tabs, newlines, and the comma family nothing does. A single amount written with comma thousands separators that reaches 13 digits and happens to satisfy the card check digit is rejected, and that is deliberate — it is the same shape a card written with thousands separators takes, so the check fails closed. Its message says it is a grouped number matching a payment-card checksum rather than naming it a card, because nothing about its leading digits identifies an issuer. The frequency rises with magnitude: measured over 2,000 random amounts per size, none below 13 digits is rejected, about 9% of 13-digit amounts are, about 29% of 16-digit, and about 48% of 19-digit. Everyday amounts are therefore untouched, and several *comma-grouped* amounts standing next to each other in a sentence are read as separate numbers rather than merged into one. Adjacent amounts written without separators are not — 112500000 118750000 is one 18-digit run to the nine-or-more-digit rule, and is rejected on that ground rather than as a card. Group large figures, or reference them by their Signal, to keep them out of the rule. 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, and then — only when the plan deliberately left agents in draft — rost onboard rehearse and rost onboard activate. Under a V2 setup those last two are optional: the setup approval already completed onboarding. Runner setup is part of that same credentialed surface: rost runner setup start --runtime claude|codex --agent --json, rost runner setup status --setup-id <id> --json, and rost runner setup resume --setup-id <id> --json run on the implementation credential, so an external implementation agent drives the resumable lifecycle without borrowing an owner session — while device pairing and provider consent stay human-only actions inside it, and rost runner setup cancel stays an owner action the bounded credential is refused. The plan then submits only the resulting runner_setup_id with the preferred lane and brain; the server proves the tenant, the owner and the run relation itself, and a reference that names another tenant's setup — or one that has expired or been cancelled — is refused rather than quietly applied. 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, and warnings — and the onboarding-completion effect only when this activation will actually perform one. Approval rechecks the full projection, records one composite human decision, makes every agent live and arms eligible schedules; under V1 it also completes onboarding atomically, while under a V2 setup onboarding is already complete and the card says so rather than claiming an effect approval will not perform. Any stale or failed member rolls the transaction back; same-key retry returns the committed receipt without duplicating effects. When the company carries the Beta launch default, that same card shows each agent's own authority review — what it may do unattended, what always asks, its connections, budget, and where to revoke — and approval mints exactly one grant for that agent inside the same transaction that makes it live, under the same composite human decision. There is no second approval and no separate Approvals card: the launch action is the one thing the owner does. Under a schema_version: 2 setup that activation is OPTIONAL: the company is complete and operating the moment the setup applies — the setup itself records onboarding as finished — and onboarding.activate only takes live the additional agents the plan left in draft. Skipping it leaves a complete operating company, and the next actions are named rather than implied: launch each drafted agent from its own Seat when it is ready, read aicos.trusted_beta.status and then aicos.trusted_beta.enable to put the company on the Trusted posture, and connect each Signal's source from that Signal's page. An implementation run that stops there is complete, not incomplete.

After activation, /home keeps a Setup receipt card in view: the applied and activated dates, what the one approval actually created (Seats, Agents, Goals, Signals, Frictions, Tasks), and how many agents went live with how many schedules armed, linking back to the /onboarding lifecycle view. A company that never ran the composite setup sees no card. An applied-but-not-activated V1 setup says "Activation pending" rather than claiming completion; an applied V2 setup says "setup complete", because that approval finished onboarding itself and any remaining launch is optional.

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:runner-setup-method -->

• Runner setup method (runner-setup-method) — runner setup is the preferred execution checkpoint before agent activation for Seats that run on the tenant's own runner; map the client host to its provider runtime, keep pairing and provider consent human-only, and treat setup completion as server-read state. Commands: runner_setup.start, runner_setup.status, runner_setup.resume, runner_setup.cancel.

<!-- 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.