A free writing template
Decision record
Keep the options, reasoning and consequences of an agreed choice together.
Use it when a choice affects future work and the next reader needs to understand why it was made.
No account or email needed. Downloads work without JavaScript.
Make the structure useful
Current facts.
A clear next step.
Replace the prompts with your own context. Keep an unanswered question visible when the facts are missing. Agree the people and decisions rather than copying them from the example.
The blank and filled versions are portable Markdown. They do not install native Tellenze templates or create workspace work.
Define clear work- 01
Name the choice, its current status and who has authority to make it.
- 02
Record the facts, options and tradeoffs. Mark assumptions and unresolved evidence plainly.
- 03
State the chosen option and why it fits the constraints. Include the consequences and work it creates.
- 04
Agree a reason to revisit the choice, then link the record from the work it affects.
01 / Your starting point
Begin with the real work.
Copy or download this version. Replace the placeholders, then review the definition with the people who will use it.
Portable Markdown
Blank template
Use the preview below, then copy the text or download a .md file.
Decision: [the choice]
Status and authority
- Status: [proposed, agreed or superseded]
- Decision maker: [who can agree this choice]
- Contributors: [whose input was considered]
- Decision date: [complete when agreed]
- Affected work: [access-checked links]
Context
[The problem, known facts and constraints that make this choice necessary]
Options and tradeoffs
For each realistic option:
- Option: [approach]
- Benefit: [why it could help]
- Cost or limitation: [what it requires or gives up]
- Evidence: [source, or clearly marked assumption]
Decision and reason
- Chosen option: [complete only when agreed]
- Reason: [why it fits the facts and constraints]
- Uncertainty: [what remains unknown]
Consequences and follow-up
- What changes: [practical effect on people or systems]
- Required work: [actions, agreed owners and links]
- What we accept: [a limitation or risk, and who agreed]
Revisit when
[A concrete change, signal or review point that should reopen this choice]
Sources and later changes
[Current source versions; link a replacement decision rather than silently rewriting history]
View blank template Markdown source
02 / A fictional example
See how the sections connect.
The Northstar customer portal is fictional. Its receipt-download scenario shows a writing approach, with assumptions, unfinished checks and required decisions kept visible.
Use the structure with your own facts. Example text is not evidence of a shipped feature or approval for an action.
Portable Markdown
Filled example
Use the preview below, then copy the text or download a .md file.
Decision: the first receipt download uses PDF
Fictional example: Northstar customer portal. This records an illustrative product choice.
Status and authority
- Status: agreed for this fictional example.
- Decision maker: the portal product owner.
- Contributors: the developer, reviewer and Support representative.
- Decision date: recorded in the real decision when agreed; no actual approval is implied here.
- Affected work: the receipt-download brief and implementation item.
Context
Customers need a portable payment record. The portal already has a PDF approach, and the first change is limited to a completed order's receipt. The team needs a format the reviewer can inspect against agreed fields.
Options and tradeoffs
-
Option: generate a PDF with the existing approach.
-
Benefit: a portable document using a familiar implementation path.
-
Cost or limitation: the layout and output fields need explicit verification.
-
Evidence: the existing generator and receipt-format agreement would be linked in actual work.
-
Option: provide a printable HTML view first.
-
Benefit: reuses browser rendering.
-
Cost or limitation: printed output depends on the browser and print settings.
-
Evidence: a prototype would be needed to compare output; none is claimed in this example.
Decision and reason
- Chosen option: PDF using the existing approach.
- Reason: it fits the agreed portable-document outcome and avoids a new dependency in the first change.
- Uncertainty: the developer still needs to verify the generator's handling of the agreed fields.
Consequences and follow-up
- What changes: a completed order gains a receipt-download action.
- Required work: the developer implements the output; the reviewer checks fields, ownership and failure behavior.
- What we accept: refund receipts and bulk export need separate definitions; the product owner agrees that scope.
Revisit when
The current generator cannot represent the required fields, or observed customer needs require a different accessible output. Discuss a replacement decision before changing the implementation scope.
Sources and later changes
Link the current format agreement and receipt brief. Keep any later replacement decision connected to this record.
View filled example Markdown source
Check before you share
A useful file.
A result you can trust.
- Replace placeholders and fictional facts.
- Check that readers can open every source.
- State what is verified and what remains unfinished.
- Agree the next action and any required approval.
Another useful starting point
Keep the next conversation clear.
COME TAKE A LOOK
A little less busy.
A lot more together.
Curious? Join the waitlist and see how we welcome your team.
Tell us a little about your team. We’ll explain the next steps and invite you when we have capacity for your workspace.
Join waitlist Start with your email. No payment needed to join.