Cascade guide

Cascade connects company direction to seat-level commitments. It is a goal tree, not a ticket tracker. Work belongs in Cascade when it explains how a seat contributes to a larger outcome.

The four goal kinds

Cascade has four goal kinds that form one chain from vision to sub-step:

• Horizon goals (10-year, 3-year, 1-year) live in the Compass document, not in the goal tree. They change by supersession, roughly yearly.
• Company objective — the quarter's company-level rocks. Each is a cascade root that ties back to the active Compass's 1-year horizon, is materialized from the Compass, and renders as a read-only header tier on /cascade (edited through the Compass or by leadership, not inline). It can also be authored directly with goal.create --kind company_objective: no seat_id and no parent_goal_id — the root has neither — and the command anchors it to the tenant's active Compass version server-side (there is no compass id argument to pass). That active Compass must already carry a one_year horizon goal, or the command fails with a precondition error instead of creating an unanchored root. Re-versioning the Compass keeps the in-flight quarter's objectives intact — it never orphans them.
• Seat goal — a seat's quarterly rocks. A seat goal connects under a company objective, and seat goals may still nest (a function seat goal above an agent execution seat goal) for the accountable-human layer.
• Milestone — optional sub-steps of a seat goal. Completing milestones automatically rolls into the parent seat goal's progress, so a rock's percentage reflects real sub-step completion.

Good Cascade structure

• Company objectives connect back to the Compass 1-year horizon.
• Team or function seat goals connect to company objectives. This is the accountable human layer for most agent work.
• Agent execution seat goals connect below the human or function goal they advance, unless the agent seat is intentionally accountable for that outcome.
• Milestones connect below the seat goal they break down.
• Each commitment has one owning seat.
• Status is evidence-based where possible.

Setup-health recommendations

Cascade warnings are advisory, not blockers. They point to setup that should be reviewed before the next Sync:

• Uncovered Compass objective: the objective has no active child seat goal.
• Objective skips accountable function: current child goals are agent-owned without a human or function goal between Compass and execution.
• Seat missing cycle goals: an active seat has no current-cycle goal.
• Seat missing active Charter: an active seat has no approved Charter.
• Agent goal missing human accountability parent: an agent-owned goal has no human or hybrid goal in its ancestry.
• Orphaned goal branch: the owner seat or parent chain no longer reaches an active Compass objective.

/cascade leads with one computed line — how many goals are off pace this cycle, or an all-clear when none are. Off-pace and off-track goals stay fully visible with their owner seat and pace context; goals confirmed on pace collapse into a per-branch count you can expand. Creating or editing a goal opens the same drawer from a single New goal action or a goal's own edit control — there is no separate persistent form.

Goal progress and at-risk goals

A goal can carry a quantified progress (0-100) distinct from its on/off/done status. Report it with goal.set_progress; when an agent reports progress it lands as a proposal a human approves before the goal moves. A seat goal that has milestones takes its progress from milestone completion instead — the percentage is the share of its non-dropped milestones marked done, recomputed automatically as milestones complete, drop, or re-open. goal.list_at_risk projects which goals are off pace by comparing progress against the elapsed fraction of the cycle window (deterministic date math, no forecast model). Off-pace goals surface on /cascade, in the owner-only band on /home, in the weekly Sync Brief, and as a weekly owner alert. Status-only goals (no progress recorded) are excluded from the projection and render as pending measurement, not as proven on track.

On human and function seat pages, goal visibility includes both direct goals and descendant seat goals from the Responsibility Graph subtree, so a manager can review team progress without double-owning the agent's work.

Drive a goal's status from a Signal

A Signal can be linked to a goal for visibility, or set to compute its status. Bind a Signal with goal.bind_measurable. By default the binding is informative (role informs): it appears as a direct indicator on the goal, is allowed at any level (company objective, parent, or leaf), can be one of many on the same goal, and never changes the goal's status. To let a Signal drive a leaf goal's status instead, bind it with --role drives_status (the goal must be a childless seat goal or milestone — a company objective or a goal with children rolls up from its children, so a driver there is rejected). A goal can have at most one driving Signal, and choosing a driver is a deliberate, human-gated act. Promoting a Signal to the status driver requires a second anchor: a prior closed period plus the value that period's books show (second_anchor: { period_start, expected_value }). The instantaneous reading is not enough — the anchor proves the Signal matched reality at least once before it may automatically flip a goal, and it is recorded durably with the confirmation. Confirming a driver over an existing informative binding of the same Signal promotes that binding in place. A new drives_status binding defaults auto_status_enabled to true — this signal will set the goal's status from confirmed readings, and a steward can turn it off later with goal.set_auto_status (or opt out at bind time with --no-auto-status-enabled (which also merges into an --input payload, so it works with the second_anchor JSON a driver bind requires), or with "auto_status_enabled":false via --input/MCP); existing bindings keep whatever setting they already had.

A new drives_status binding is opted in by default: confirmed readings compute the goal's status from the bind. An opted-out binding stays an indicator until a steward opts in with goal.set_auto_status --enabled. Once opted in, the goal's status is computed from the measurable's latest confirmed reading against its target and direction — on target reads on-track, below target reads off-track. Only confirmed readings drive status; an agent's draft reading never auto-flips a goal. A human who sets the status by hand pins it, and that pin wins over the computed value until they change it or re-run goal.set_auto_status. Remove a binding with goal.unbind_measurable; the goal keeps its last status. While a binding is opted out, an off-track Signal never raises an at-risk alert on its own.

What does not belong

Do not put every task into Cascade. Small errands, private notes, and work with no strategic connection should stay out. Cascade should answer whether the company is moving toward its stated outcomes.

Operate Cascade from CLI or MCP

• Read: rost goal list --json / goal.list / rost_list_cascade_goals (scope: seat or tenant-admin). Returns goals, optionally filtered by cycle_id or seat.
• Create: rost goal create ... / goal.create / rost_create_cascade_goal with cycle, seat, parent, title, and definition of done. Omitting kind (the default) creates a seat goal and still requires seat and parent. Pass --kind company_objective to create the Cascade root itself instead — seat and parent are rejected, not just optional, since a company objective is the root, not a child — and the command resolves the tenant's active Compass version for you; there is no compass id to pass. That active Compass must already carry a one_year horizon goal, or the call fails with a precondition error rather than creating an unanchored objective. Authoring a company objective takes an owner membership: a seat-scoped agent can still create seat goals beneath one, but it cannot mint the root.
• Track: goal.update (title or definition of done — not gated) and rost goal status / goal.set_status (on/off/done). Seats may set only their own goals.
• Restructure: rost goal reparent / goal.reparent, rost goal reassign-owner / goal.reassign_owner (reassign a seat goal's owner seat — cycle and parent ancestry stay unchanged), and rost goal drop / goal.drop.

When to stop for confirmation

goal.reparent, goal.reassign_owner, and goal.drop are human_required; goal.create, goal.set_status, and goal.update are none, so a seat can add goals and update their status directly. Moving, reassigning, or dropping a goal changes how the company reads its own progress or who is accountable for it, so each returns a pending confirmation over MCP. goal.bind_measurable and goal.set_auto_status are also human_required — letting a Signal drive a goal's status is a deliberate steward act — while goal.unbind_measurable is none. An agent proposes the branch and surfaces the approve link; a human decides.

Agent guidance

Agents can suggest commitments and report progress. They should not create a new goal branch when the parent outcome is unclear. Ask a human to clarify the goal instead.