---
title: Decisions
category: concept
slug: decisions
summary: "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."
---
# 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](/docs/types). 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](/docs/resources/signoff)** 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](/docs/resources/signoff)** 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.