What belongs in a decision journal?
Keep enough context for your future self or a permitted colleague to understand the choice. A useful entry answers six questions:
- What are we deciding? Name one choice, an owner, and a decision date.
- Which alternatives are realistic? Include keeping the current approach.
- What do we know? Link the evidence and record its date, source, and limits.
- What are we assuming? Separate an inference from a verified observation.
- Why this response? State the constraint or tradeoff that made the difference.
- When should we revisit? Choose a date or a concrete change in conditions.
The entry need not be long. A short note with a clear source and a disconfirming condition is more useful than a confident conclusion whose inputs cannot be reconstructed.
Copy this decision journal template
Question: Owner and decision date: Alternatives (including the current approach): Constraints: budget, time, reliability, permissions Evidence: - Observation, original source, date, and qualification - Missing evidence or unresolved disagreement Assumptions: - What we believe but have not established - What would change our mind Response: Act / Monitor / Ignore / Clarify Reason for this response: Smallest authorized next step, if any: Revisit date or trigger: At the revisit: - What happened, and how do we know? - Which assumption held or failed? - Retain, revise, or close the decision? Why?
Copy it into a document or your existing decision record. Keep sensitive company information in a workspace with the appropriate access controls.
A worked example: should we evaluate a new support assistant?
Illustrative example: a small software team is considering a tool that drafts customer-support replies. This is not a customer result or a recommendation for a particular provider.
- Question
- Should we run a limited evaluation on routine support questions?
- Evidence
- The provider describes a draft-review workflow. Our own review found that several common questions require product-specific context. We have not yet checked the tool against those cases.
- Constraint
- A person must review every reply. Customer data may only be used within approved processing permissions.
- Response
- Clarify which test inputs are permitted, then consider a bounded evaluation. Do not connect the live support inbox yet.
- Revisit trigger
- Review after the agreed test set is scored, or earlier if a required privacy or reliability condition cannot be met.
The entry explains what is known and what is missing. It also prevents “evaluate” from quietly becoming permission to deploy or send customer replies.
How do you review a decision without rewriting history?
Read the original entry first. Record the later observation separately, with its source and date. Ask whether the original assumption was reasonable given the information then available, and whether the same reasoning still applies.
A positive outcome does not prove the process was sound; a negative outcome does not by itself prove the original choice was unreasonable. Record what you can establish and leave causal explanations provisional when evidence is incomplete.
When is “Monitor” enough?
Choose Monitor when the evidence does not justify a change but a specific trigger could. Write that trigger: a measured reliability threshold, an agreed renewal date, or the result of a defined experiment. “Keep an eye on it” is difficult to review because it never states what should change the decision.
Choose Ignore when a signal does not apply to the current question, and Clarify when a missing premise prevents a justified choice. None of these labels should silently authorize an external action.
Use the journal with a bounded evaluation
The AI tool evaluation guide shows how to build the evidence for an adoption decision. Feedsion’s decision brief workflow connects a question, inspectable evidence, your judgment, and a timed revisit. You can explore the sample before creating an account.