TL;DR
A meeting summary tells you what people discussed. A decision log tells you what was actually decided, who had authority, why the choice was made, where it applies, and what evidence should reopen it.
Use one row or page per decision. Keep these fields explicit:
question → state → authority → options → evidence → decision → scope → review trigger
AI can draft candidate fields from an authorized meeting record. It should not decide that agreement occurred, identify an approver from seniority, invent rejected options, or turn a tentative action into a commitment.
This guide provides a copyable template, state model, worked example, bounded prompt, and review checklist. For the larger cross-meeting system, start with AI meeting notes for product managers.
Meeting notes are not a decision log
Consider this recap:
The team discussed using a gradual rollout. Priya raised a support concern. Alex suggested starting with new workspaces. The team agreed to move forward and monitor results.
It sounds useful, but it leaves the next reader with unanswered questions:
- What exact question was decided?
- Who had authority to approve it?
- Was “move forward” an approved rollout or a proposal for more analysis?
- Which users and environments are in scope?
- What support concern remains?
- What observation would pause, reverse, or expand the rollout?
Use five decision states
| State | Meaning | What can happen next |
|---|---|---|
| Proposed | A decision question and one or more options exist | Gather evidence, name authority, set a decision point |
| Decided | The authorized owner chose a direction and scope | Execute approved actions and monitor the review trigger |
| Deferred | The decision is intentionally postponed | Record the missing evidence, dependency, and next checkpoint |
| Revisited | New evidence or a trigger has reopened the decision | Reassess options without erasing the previous rationale |
| Superseded | A later authorized decision replaced it | Link the replacement and preserve the historical record |
Do not use “closed” as a synonym for “decided” if the decision still has an active review trigger. Do not overwrite an old decision when conditions change. Link the new record so a future reader can see the change.
Copy the decision-log template
``md
`DEC-042: Rollout boundary for workspace onboarding
Decision question
What exact choice must be made?
Source boundary
Which meetings, documents, metrics, experiments, and constraints were reviewed?
Options considered
1. Option A
2. Option B
3. Option C
Evidence and constraints
Decision and rationale
What was chosen, by whom, and why?
Dissent and unresolved questions
What material disagreement or uncertainty remains?
Actions
Review history
Keep the decision identifier stable. The title can change; the identifier makes links and audit history durable.
Draft the log in four passes
1. Recover candidate decision language
Find explicit statements such as “I approve,” “we are choosing,” “defer until,” “this applies only to,” or “we will revisit when.” Also recover the question those statements answer.
Do not treat “sounds good,” “I like that,” silence, or repeated discussion as a decision. A model should return UNCLEAR when the source does not establish authority or scope.
2. Separate evidence from rationale
Evidence is a source-backed input: a research finding, metric, incident, technical constraint, policy, or experiment. Rationale is the decision owner's explanation of how those inputs led to the choice.
Do not backfill a polished rationale the owner never gave. Write rationale not recorded and ask for review.
3. Confirm authority and scope
The loudest, most senior, or most frequent speaker is not automatically the approver. Confirm the role outside the transcript if necessary.
Scope should answer which product area, users, platform, environment, geography, or time period the choice covers. “Proceed with onboarding” is not enough. “Enable the new completion state for newly created internal test workspaces” is reviewable.
4. Add a review trigger
A review trigger is stronger than “revisit later.” It names the evidence or condition that reopens the decision: a date, measured threshold, incident, dependency resolution, research round, policy change, or launch phase.
Do not invent a numeric threshold because the template has a field. If the owner did not set one, record not set` and assign a review question.
Worked example: a staged onboarding rollout
Synthetic meeting evidence:
- Research found that two participants could not tell when setup finished.
- Engineering said the completion event is reliable only for newly created workspaces.
- Support asked for a rollback path and a known-issues note.
- The product director approved an internal rollout for new test workspaces, with wider rollout deferred until the event works for migrated workspaces.
| Field | Entry |
|---|---|
| Question | Where can the new completion state be enabled now? |
| State | Decided |
| Authority | Product director, confirmed outside the speaker label |
| Options | All workspaces; new test workspaces only; defer all rollout |
| Evidence | Research observation, event limitation, support readiness constraint |
| Decision | Enable only for new internal test workspaces |
| Scope | Internal test environment; newly created workspaces; no customer rollout |
| Actions | Instrument result, document known limitation, prepare rollback check |
| Review trigger | Revisit after migrated-workspace completion events are verified and support checks the rollback path |
The participant count is preserved as coverage, not transformed into market prevalence. The broader rollout stays deferred rather than disappearing from the record.
Copyable prompt for a draft decision record
Use this only with approved source material:
Draft a decision record from the supplied meeting transcript, notes, and authorized references. Return: decision question, state, candidate decision owner, driver, contributors, informed parties, options actually considered, source-backed evidence, constraints, exact decision wording, rationale as stated, effective scope, dissent, unresolved questions, actions, and review trigger. Provide a recoverable source reference for every material claim. Use only these states: proposed, decided, deferred, revisited, superseded. Do not infer authority from seniority, speaking time, title, or enthusiasm. Do not invent options, rationale, scope, owner, date, threshold, action, or approval. If the source does not establish a field, write NEEDS REVIEW. Label the output DRAFT DECISION RECORD.
Have the named decision owner verify the question, state, decision, rationale, scope, and trigger. Have each action owner confirm the commitment before sending anything to a tracker.
Where Shadow fits
Shadow can provide a reviewable meeting source on a Mac. Its documented local core includes meeting capture, transcription, speaker diarization, meeting Markdown, and available media in the local vault. The meeting review supports playback and timestamp navigation, which can help a reviewer recover the source moment.
A detected Speaker is not a verified person. Confirm identity and authority before naming an approver. A Meeting Skill can draft a structured Markdown result or send supported output to a configured webhook, but generated claims, decisions, owners, and dates require review. A webhook transmission does not establish that the receiving record is approved or correct.
Core capture is local. Optional AI, Ask, sharing, and webhooks can send relevant context externally; review privacy and data leaving your Mac before using them. Obtain the required recording consent before capture.
Shadow's current Help documentation does not describe an organization-wide decision register, authority verification, product-change approval, or automatic review-trigger monitoring. The template is an editorial workflow a team can apply to an authorized record.
What is real, what is interpretation, and what is unproven
Real now
- Atlassian publishes decision templates that separate decision roles, context, options, actions, outcome, and status.
- Decision logs can index individual records without erasing their history.
- Shadow currently supports local meeting records and optional reviewable Skill output under documented boundaries.
Interpretation
- The five-state model and review-trigger field are this article's proposed controls.
- A stable identifier and linked superseding record can make product history easier to reconstruct.
- Source references can make an AI draft easier to challenge and correct.
Unproven
- This article does not claim a template improves decision quality, speed, accountability, or delivery outcomes.
- It does not claim AI can determine authority, consensus, or organizational intent reliably.
- It does not claim Shadow automatically creates, verifies, updates, or governs a decision log.
Audit the first five decisions
| Check | Pass condition |
|---|---|
| Decision existence | The source contains an explicit choice or the record remains proposed |
| Authority | The approver is verified independently of voice grouping |
| Evidence trace | Each material input has a recoverable source |
| Option integrity | Only real considered options appear |
| Scope precision | The decision says where it applies and where it does not |
| Trigger clarity | A reviewer knows what evidence or date reopens the choice |
| History | Revisited or superseded records link rather than overwrite |
If reviewers repeatedly correct authority or state, stop automating those fields. A shorter proposed record is safer than a polished false decision.
If this workflow fits your team, download Shadow and test one draft decision record on an authorized meeting. Keep it proposed until the decision owner checks it.
Sources and verification date
This article was researched and verified on October 5, 2026.