Decision register
A decision register is a structured table of decisions with rationale, stakeholders, owner, status, follow-up tasks, review date, and what each supersedes.
A decision register (sometimes called a decision registry) is a structured table of an organization's decisions, one row per decision, with fields for rationale, stakeholders, owner, status, follow-up tasks, review date, and what the decision supersedes. It is the database view of a decision log: the same decisions, made filterable and auditable.
The fields
| Field | What it holds |
|---|---|
| Decision | The verdict as one sentence |
| Rationale | Why, plus the alternatives rejected |
| Owner | The one person accountable for the call |
| Stakeholders | Who was consulted or must accept it |
| Status | Proposed, approved, superseded, or retired |
| Follow-up tasks | Work the decision creates, linked to tickets |
| Review date | When a temporary call should be re-checked |
| Supersedes | The earlier decision this one replaces |
| Source | Link to the thread, doc, or meeting where it was made |
Rationale and rejected alternatives are the fields teams skip first and miss most: without them, a decision can be obeyed but never re-evaluated.
Register vs log
A log is append-only and chronological: easy to write, good for "what did we decide last month?" A register is a table: good for "which approved decisions touch checkout?" and "which calls are due for review?" Project management and governance teams tend to say register; product and engineering teams tend to say log. Most teams need one record, not two.
An example row
| Decision | Rationale | Owner | Stakeholders | Status | Follow-ups | Review | Supersedes |
|---|---|---|---|---|---|---|---|
| Refunds over $500 need manual review | Chargeback spike in Q3; auto-approve kept for small refunds | Dana (Payments PM) | Support lead, Finance | Approved | PAY-412 add review queue | 2027-01-31 | D-031 (all refunds auto-approved) |
Keeping it current
Registers decay the same way logs do: filing is manual, statuses stop being updated, and superseded rows stay marked approved. Assign one owner per row, set review dates on temporary calls, and record reversals as new rows. Lockstep removes the filing step by drafting entries from Slack, Notion, and Jira for the owner to approve in one click. See what a decision register should store and the decision log tools comparison.
- What fields should a decision register have?
- At minimum: the decision in one sentence, rationale, alternatives rejected, owner, stakeholders consulted, status, date, follow-up tasks, review date, and a supersedes link. Add a source link to where the decision was made.
- What is the difference between a decision register and a decision log?
- A decision log is a chronological stream of entries; a decision register is a structured table you can filter by status, owner, or area. Many teams keep one record and use both names. The register's extra fields make it easier to audit and review.
- Where should a decision register live?
- Anywhere with structured fields and filtering: a Notion or Confluence database, Airtable or Coda, a Jira project, or a dedicated tool like Lockstep. What matters more is that entries get written at the moment of decision and that people can find them later.
Related