Every level of the organization carries something the others don’t have.

Executive leadership carries vision, strategic context, and pattern recognition from years at altitude. Working teams carry operational truth — what is actually hard, what is actually possible, what the customer is actually saying.

Neither has complete information. Both must contribute.

The Cascade is the infrastructure that makes this contribution possible — governed, documented, and resistant to the political collapse that happens when either altitude dominates without accountability.

One Cascade: intent travels down, ground truth travels up, iterating until the answer is one neither side could have written alone.

The problem with one-directional authority

Most organizations run prioritization as a one-directional process. Executives set priorities. Teams execute them. The mechanism for surfacing operational truth upward — the constraint the team knows about, the dependency nobody addressed, the thing that will make this decision fail in practice — is informal, unreliable, and undocumented.

The result: decisions made without the information that would have changed them, and execution teams absorbing the cost of uninformed commitments in silence.

The other failure mode is the opposite: team-driven prioritization where every team optimizes locally, there is no mechanism for executive context to reach the comparison, and the resulting lists are technically defensible but strategically disconnected.

The Cascade prevents both failures. It is not consensus. It is governed contribution — each level contributing what it carries, in a structure that makes every contribution visible and every override accountable.

Catchball

The Cascade is implemented through Catchball — the bidirectional alignment mechanism that runs within every Cycle.

Catchball is named after the management practice of tossing a planning “ball” between levels of an organization: executives throw down with context and constraints; teams throw back with operational reality and counterproposals; alignment is reached through structured iteration, not unilateral decision.

In Priorities.ai, Catchball is a first-class system concept with its own state machine, its own API surface, and its own governance record.

How a Catchball Loop works

State machine: working → proposed → returned → accepted_provisional → accepted → rejected → closed

A loop opens within a Cycle for a specific track or scope.
A proposal is formed — typically by a team or department — containing a candidate ranked list, supporting rationale, and declared constraints.
The proposal moves up to the decision authority holding the “ball.”
The authority reviews and responds with one of: accept (provisional or final), return with guidance, or reject with rationale.
If returned, the team updates the proposal with the new information and throws it back.
When accepted, the Catchball Loop records the accepted state as a governance event — the moment alignment was reached.

Every exchange in every loop is recorded. Every acceptance and rejection carries a rationale. The record of who held the “ball” and what they decided with it is on the record, not in someone’s memory.

Authority lanes

Catchball operates in authority lanes — the organizational channels through which a proposal is legitimate to travel. An item cannot bypass the authority chain. A team-level proposal cannot go directly to the board without passing through the intermediate authority that holds responsibility for that scope.

This is the structural mechanism that prevents the “someone senior who wasn’t in the room” problem. If that senior person was not in the authority lane for this decision, their veto is visible and it is either processed through the correct channel or it is flagged as a governance anomaly.

What the Cascade produces

The Cascade does not produce alignment — it produces a documented state of alignment.

When a Catchball Loop closes with accepted:

The proposal is on the record
The rationale is on the record
Every exchange that led to the outcome is on the record
The accepted list becomes eligible for inclusion in the Published Priority List

When the Published Priority List is released:

It carries the full provenance of the Cascade that produced it
Every future change to that list must be evaluated against that provenance
The organization has, for the first time, an instrument panel for evaluating whether a proposed change is legitimate or not

The role of the Executive Inbox

Executives are not secondary users in the Cascade. They are the decision authority that gives the process its legitimacy.

The Executive Inbox is the surface through which authorized decision-makers review Catchball proposals, see the supporting rationale, evaluate the alignment between proposals and strategic objectives, and exercise their authority — with their decision recorded.

An override is not a failure of the process. An override with rationale, recorded, is exactly what the process is designed to handle. An override without rationale, invisible to the execution team, is the failure the process is designed to prevent.

Developer access

The Cascade is exposed through the Catchball API:

GET /v1/catchball/loops?cycle_id=:id — list all loops in a cycle
POST /v1/catchball/proposals — submit a proposal (calls catchball_submit_proposal RPC)
GET /v1/catchball/proposals/:id — inspect a proposal and its history
POST /v1/catchball/proposals/:id/accept — accept a proposal (calls catchball_accept_packet RPC)
POST /v1/catchball/proposals/:id/reject — reject with rationale
GET /v1/catchball/threads?proposal_id=:id — get the discussion thread for a proposal

Note: POST /proposals and POST /proposals/:id/accept are routed through RPCs to maintain the authority model. Direct table writes are rejected by the database.