Hemory TeamOn this page
A decision record explains one choice: what was decided, why it made sense, who or what process authorized it, and which conditions apply. Its purpose is to help someone understand and use the decision without reconstructing every discussion that led to it.
A meeting summary answers a broader question: what happened in this meeting? It may already contain a good decision record. Create a separate entry when the choice needs to stay visible across meetings, documents, or later changes—not simply because every meeting must produce another document.
TL;DR
- A decision record follows a choice; a meeting summary follows a meeting. Either can preserve detailed reasoning.
- Include the decision, scope, reason, acceptance, and important conditions. Add alternatives or follow-up work where they help.
- The decision-maker and the person carrying out the work may be different. Neither should be invented to complete a field.
- Hemory can preserve the discussions behind a decision and supply accessible context for a draft, reducing detailed note-taking and later reconstruction.
- Keep the current instruction clear while preserving the earlier reasoning when a decision changes.
Decision record, meeting summary, and decision log
These records organize information around different units:
| Record | Organizing unit | Main use |
|---|---|---|
| Meeting summary | One discussion | Catch up on topics, outcomes, and follow-up work |
| Decision record | One choice with its context | Understand the basis and scope of that choice |
| Decision log | A collection of decisions | Find relevant choices and see which ones still apply |
A decision can span several meetings. A single meeting can settle several decisions. That is why a project may need a decision record even when its meeting summaries are good.
If you need a register of several choices rather than the explanation of one, use the decision log template.
The difference is not that summaries omit reasons by definition. A summary can contain the rationale, alternatives, and approval in full. If that section is easy to find and maintain, use it. A separate record becomes useful when people repeatedly need the choice independently of the meeting recap.
An action list serves another purpose: tracking work. “Use the existing intake form for the pilot” is a decision. “Rina will update the pilot instructions” is a commitment. Recording one does not automatically record the other, and finishing the instructions does not make the decision obsolete.
What belongs in a useful record?
Include enough information for someone to understand the choice and its limits. The following fields are a writing aid, not a requirement to fill every blank for every routine decision.
| Field | What to write | Judgment that matters |
|---|---|---|
| Decision and scope | The choice, including the project, audience, or version it covers | Avoid expanding a pilot choice into a permanent policy |
| Status and relevant dates | Proposed, accepted, replaced, or another clear description; when acceptance and effect occur | A draft date is not necessarily the decision date |
| Context and rationale | The problem, constraints, and reason for choosing this approach | Separate the stated reason from a plausible explanation added later |
| Acceptance | Who or which authorized process made the choice | The speaker, decision-maker, and implementation owner may differ |
| Conditions and alternatives | Limits, dependencies, and meaningful options considered | An unselected option is not automatically a rejected one |
| Related work | Actual commitments, owners, and timing where known | Leave unstated details open rather than assigning them yourself |
| Source reference | A recognizable meeting, document, or exchange | A reference helps retrieval but does not grant access |
The decision-making authority may be an individual, a committee, or another established process. Do not replace a valid group decision with an invented individual owner. If implementation needs a responsible person and none has been assigned, identify that separate gap.
A compact format for one decision
Use the relevant fields in your existing project document. For a simple choice, a paragraph may be enough; use the fuller format when the reasoning or conditions will matter later.
Decision, scope, and status:
Accepted by / decision process and date:
Reason and important conditions:
Alternatives and their outcomes, where relevant:
Separate commitments and timing, if any:
Source and later revision reference:For a proposal, make that status clear and leave acceptance unconfirmed. For an accepted conditional choice, keep both the acceptance and the condition. “Approved for the pilot after training” should not become either “approved without limits” or “no decision made.”
The shared record should contain the conditions needed to act. A private transcript reference can support your work, but a colleague should not have to open it to discover the restriction on the decision.
Example: one pilot decision, with its reason intact
This fictional example records the position at an October 28 review; it is not an actual project record or Hemory output. Alex is authorized to decide the pilot scope:
Alex: “Use the existing intake form for the two-week pilot. Building the replacement would delay our test of the service itself. We’ll consider a redesign after we review the pilot findings.”
Rina: “I’ll update the pilot instructions by October 30.”
The record can be concise:
Decision: Use the existing intake form for the two-week service pilot.
Status: Accepted for this pilot.
Accepted by: Alex, pilot scope decision-maker, on October 28.
Reason: Building a replacement would delay testing the service itself.
Alternative: A replacement form was not selected for this pilot;
consider redesign after reviewing pilot findings.
Related commitment: Rina will update the instructions by October 30.
Source: October 28 pilot review, intake-form discussion.This does not establish a permanent rejection of redesign, a date for the pilot to start, or completion of Rina’s work. It gives the next person a usable choice and the reason behind it without adding facts to make the template look complete.
Draft from the sources you already have
Start with an existing approval, project note, or meeting summary if it contains the answer. When it records the outcome but omits a condition or rationale, follow the reference to the discussion where that point was settled.
If the relevant conversation was captured in Hemory, its transcript and organized Memory can provide the surrounding explanation. For a known discussion, ask about the choice, reason, and scope. When the decision spans several accessible discussions, a compatible AI agent connected to Hemory can help assemble a draft:
Draft a decision record for the pilot intake form using the relevant
Hemory discussions you can access.
Include the accepted choice, scope, stated reason, alternatives,
conditions, and any separate commitments.
Identify the basis for acceptance. Keep missing details explicit,
and distinguish a later suggestion from an accepted replacement.Supply any current approval document the agent cannot access. You do not need to manually compile a complete transcript extract before asking for the draft. Hemory’s role is to preserve and make the spoken context usable; the record then makes the chosen outcome easy to act on.
Review the parts that would change someone’s work: acceptance, scope, conditions, and responsibility. You usually do not need to reread unrelated meeting topics to confirm a clear decision.
Keep changes understandable
If a later authorized decision replaces the pilot approach, record what changed and when it takes effect. Preserve the earlier rationale so someone reviewing the pilot can understand the choice made at that time.
A proposal to redesign the form does not by itself replace the pilot decision. Nor does completing Rina’s instructions change the decision’s status; that updates the related task.
For accepted replacements with a later start date or narrower scope, see when a new decision replaces an old one.
Use the document’s existing history or a linked replacement entry when helpful. The important result is that a reader can distinguish the instruction for current work from the reason behind the earlier one.
FAQ
Does every meeting need a decision record?
No. Some meetings exchange information without making a choice. Others make routine decisions that are sufficiently recorded in the summary. Create a separate entry when it makes an important choice easier to find and reuse.
Is a decision record the same as an architecture decision record?
An architecture decision record focuses on a technical architecture choice. The broader idea also applies to product scope, operating processes, and other work decisions. Use the terminology and format appropriate to your team’s subject.
Can a group be recorded as the decision-maker?
Yes, when that reflects the actual authority and process. Keep implementation responsibilities separate; naming a committee does not identify who promised to do a particular task.
What if I cannot recover the reason?
Keep the established choice and state that its reason was not found in the sources reviewed. Ask for clarification when the rationale affects current work, and identify a later explanation as such.
For your next consequential discussion, use Hemory to preserve the spoken context while you participate. Then use the available material to create the shortest decision record that still explains the choice and its limits.
