Core concepts
View as Markdown

Decisions

A decision is a Droplet that carries a RAPID roster and a sign-off. Approvers weigh in, the decider makes the call, and everyone can see where it stands — all in a docked tray on the Droplet.

A decision is a Droplet wearing the decision Type. It is not a new kind of object — it's a normal Droplet (with all the sharing, comments, search, and access that implies) that additionally carries a RAPID roster and a sign-off. The Droplet body holds whatever context you want — a brief, a doc, a dashboard; the decision machinery rides alongside it in a tray docked to the bottom of the page.

Because a decision is just a Droplet + a Type, there's no separate "decision" resource to learn. The content is the Droplet; the roles and the sign-off state are read and driven through the Sign-off resource.

The RAPID roster

Every decision names who plays which role, using the RAPID framework:

  • Recommend — drives the recommendation.
  • Agree — must sign off; these are the approvers who cast a response.
  • Perform — will carry it out.
  • Input — consulted for their perspective (they don't cast a sign-off).
  • Decide — makes the call.

A role can be held by people or by a team (a User Group) — useful when, say, a whole leadership group is consulted. Only the Agree and Decide roles cast sign-offs; the others are there so everyone can see who's involved and where they stand.

The lifecycle

A decision moves through four phases, driven by its status:

  1. Draft — being assembled. The sign-off isn't open yet; an editor turns it on with Open for sign-off.
  2. In flight — open for sign-off. Approvers weigh in (agree / agree with a condition / disagree); a colored bar shows the mix at a glance.
  3. Decided or Blocked — the decider has made the call. In practice the decider simply casts their own sign-off: agree records it as decided, disagree records it as blocked, with a short summary of the call.

An editor can reopen a decided decision (clearing the call) or close an open one back to draft; responses are kept either way.

Removing a decision is a different act from closing it. Closing pauses the sign-off; removing takes the decision-ness off the Droplet entirely — the roster, the sign-offs and the recorded call go with it, and what's left is an ordinary Droplet with its content intact. In the browser that's Remove decision, at the foot of the Edit decision dialog, which names what it's about to discard before it does. From the CLI it's drop droplets clear-type, which reports the same afterwards. There's no undo.

The sign-off tray

On any decision, a bar is docked to the bottom of the page. Collapsed, it shows the status, how far along the sign-off is, and — for you — your role and whether you're needed. Expanded, it shows two columns: the roster on the left (who holds each role, with each approver's response and a team's vote breakdown) and, on the right, what you're signing off on plus the one action that's yours to take. Editors can edit the proposition inline and open or close sign-off from here.

Finding your decisions

The Decisions page (in the sidebar) lists every decision you can see, grouped by where it is: awaiting you, in flight, draft, and decided. An agent can ask the same question through signoff mine — "what's waiting on me?"

Driving it programmatically

Everything above is available through the Sign-off resource — over HTTP, the drop signoff CLI, and the drop_signoff_* MCP tools. The read is affordance-bearing: it tells you (or an agent) exactly which actions are available, so a decision can be moved along without guessing at the rules.