Decision Register
The Decision Register is a structured log of important architectural, product, and process decisions. Linking decisions to backlog items creates a traceable history of why the system is built the way it is.
Recording a Decision
- Navigate to a project and open the Decisions tab.
- Click New Decision.
- Fill in:
- Title — short statement of the decision (e.g. “Use ElectroDB for DynamoDB access layer”)
- Context — why the decision was needed
- Decision — what was decided
- Consequences — expected impact, trade-offs, and accepted risks
- Status — Proposed, Endorsed, or Reversed
Decision Statuses
| Status | Meaning |
|---|---|
| Proposed | Under consideration; not yet finalised |
| Endorsed | Agreed upon; should be followed |
| Superseded | Replaced by a newer decision |
| Reversed | Explicitly abandoned; included for historical context |
AI-Assisted Decision Writing
Click Draft with AI to open the AI modal. Describe the problem in plain language and the assistant will draft the Context, Decision, and Consequences fields for you to review and edit.
Linking Decisions to Tickets
From a decision’s detail page, click Link to ticket and search for backlog items. This creates a bidirectional link — the ticket list view shows a “decision” badge, and the decision page lists all affected tickets.
You can also add the link from the backlog item’s detail page: in the Links section, choose link type “decision”.
Mark as Noted
Team members can mark a decision as “noted” to acknowledge they have read it. This is useful for communicating important architectural choices to the wider team.
Reversing a Decision
If circumstances change, open the decision and click Reverse. PBL will prompt you to record the reason and optionally link the reversal to the ticket that triggered it. Reversed decisions are retained in the register for auditability.