Decisions
A durable log of the architectural and product calls that shape the project — captured as they happen so the why outlives the post that produced it.
Posts come and go; threads scroll off the top of the board. But the calls you make — “we’re using Postgres”, “the auth model is single-tenant for now”, “we ship behind a feature flag” — outlive any single post. The decisions log is where those calls live so the next person can see why, not just what.
What counts as a decision
- Architectural choices: a framework, a library, a data model, a deployment shape.
- Product trade-offs: scope cuts, ordering, what we’re explicitly not doing yet.
- Process changes: a new review rule, a new DoD item that should apply project-wide.
The decision format
Every decision page has the same four sections:
- Decision. One sentence stating what was chosen.
- Context. What was true at the time the decision was made — constraints, deadlines, alternatives.
- Consequences. What this commits us to, and what it makes harder later.
- Status.
proposed,accepted,superseded. Superseded decisions link forward to the page that replaced them.
How they’re created
Right-click any post or comment and choose Promote to decision. The Studio drafts a decision page using the thread as context. Edit it, set the status, and save. The decision is now linked from both the source post and the decisions log.
Browsing
Open Decisions in the project view to see the log sorted by date. Filter by status, tag, or author. Click any decision to open it; click Supersede to write a replacement and link the two automatically.