Command Palette
Search for a command to run...
Decision Governance
WorkflowHow decisions flow from proposal to conclusion.
The Decision Lifecycle
Decisions flow through stages, from creation to conclusion. Each stage has specific behaviors and restrictions.
Lifecycle Stages
Draft (Optional)
Imported decisions start as drafts. Drafts are hidden from the graph and decision list until approved.
- • Not visible in graph
- • Can be edited freely
- • Must be approved to become active
Active
The default state for new decisions. Open for discussion but no engagement yet.
- • Visible in graph
- • Open for arguments, comments, votes
- • Auto-promotes to "Under Discussion" on first engagement
Under Discussion
Active debate is happening. Arguments and rebuttals are being added.
- • Automatically triggered when arguments/votes are added
- • Shows activity indicators
- • Can be concluded at any time by decision owner
Concluded (Approved / Rejected / Deferred)
The decision has reached a final state. No more changes allowed.
- • Approved — A winning position was selected
- • Rejected — The proposal was declined
- • Deferred — Decision postponed
- • Arguments and votes are locked
- • Final rationale is recorded
Voting
Voting is optional. Decisions can be concluded without votes, or votes can inform (but not dictate) the outcome.
Open Voting
All team members with "participate" permission can vote. Votes are visible to everyone.
Anonymous Voting
Vote counts are shown, but who voted for what is hidden. Reduces social pressure.
Vote Deadlines
Set an end date for voting. After the deadline, no new votes can be cast.
Vote Override
Decision owners can choose a different outcome than the vote result. The override is recorded.
Relationships > Voting
Remember: Arbtr optimizes for understanding why decisions were made, not just what people voted for. The rationale matters more than the count.Concluding a Decision
When you conclude a decision:
- Select the outcome
Approved, Rejected, or Deferred
- Choose the winning position (if Approved)
Which option was selected
- Write the rationale
Explain why this outcome was chosen. This is the most important part.
- Add follow-ups (optional)
Tasks or actions that result from the decision
- Set importance
Anchor, Committed, Standard, or Tentative
Decision Delegate
Sometimes a decision owner can't be present to conclude a decision—they may be on leave, in a different timezone, or simply want to delegate authority. The Decision Delegate feature allows owners to assign another team member to conclude decisions on their behalf.
Assigning a Delegate
Only the decision owner can assign a delegate. Open the decision menu and select "Assign Delegate" to choose from team members.
Delegate Permissions
The delegate can conclude the decision just like the owner—selecting outcome, winning position, and writing the rationale.
Ratification Workflow
For teams that need an extra layer of governance, Arbtr supports a Ratification Workflow—think of it like "branch protection rules" for your strategic decisions.
When enabled, concluded decisions don't become final immediately. Instead, they enter a "Pending Ratification" state until approved by a designated approver (typically a CTO or Principal Engineer).
Pending Ratification
After conclusion, decisions wait for the designated approver to review. A banner appears on the decision page showing the ratification status.
- • Visible indicator on decision pages
- • Clock icon shown in graph view
- • Approver sees "Ratify" and "Veto" buttons
Ratified
The approver confirms the decision. It becomes truly final and is recorded in the audit log.
Vetoed
The approver rejects the conclusion with a reason. The decision reverts to "Active" status for further discussion. The veto reason and original rationale are preserved in the audit log.
Enabling Ratification
- Go to Team Settings (gear icon in sidebar)
- Scroll to "Ratification Settings"
- Enable "Require ratification for concluded decisions"
- Select the ratification approver from your team members
Who Should Be the Approver?
Typically the CTO, Principal Engineer, or whoever has final authority over architectural decisions. The approver can ratify their own decisions.Audit Trail
Every significant action is logged in the decision's audit history:
Decision Events
- Decision created
- Status changed
- Title/context edited
- Decision concluded
Engagement Events
- Arguments added/deleted
- Votes cast/changed
- Relationships added/removed
- Resources linked
Governance Events
- Delegate assigned/removed
- Ratification pending
- Decision ratified
- Decision vetoed (with reason)
The audit log shows who did what and when—essential for governance and compliance.
Previous
Bulk ImportNext
Briefings