You review the facts and access. Nothing is published without your approval.
The method behind the recordFrom discussion to decisions and owned actions
What makes a meeting decision record different from meeting notes?
Meeting notes describe the conversation. A decision record tells readers what was actually decided, why, who owns the next action, and what remains unresolved. An agent can draft that structure from supplied notes, but participants should verify commitments and ambiguity before the reviewed HTML record is shared.
What to give your agent
Meeting notes or a transcript you are permitted to use, plus the date and purpose of the discussion.
The proposal, brief, or options considered, so the record can preserve relevant tradeoffs rather than invent rationale.
Explicitly agreed actions, owners, and dates; missing commitments should remain marked as unconfirmed.
Any authoritative decision or task system the team already uses, to avoid creating contradictory records.
Sort statements by their status
Ask the agent to separate decisions, proposals, questions, and background. A suggestion, silence after a suggestion, or a positive comment is not sufficient evidence of agreement. If the notes are ambiguous, mark the item for confirmation. This classification matters more than making the meeting sound productive.
Preserve the reason for the choice
For each confirmed decision, include the scope, rationale, and a material tradeoff from the supplied discussion. Explain which options were deferred or rejected only when that is recorded. Avoid assigning motives to participants. A useful rationale helps a future reader understand the conditions under which the choice made sense.
Make the next actions specific
Write each action as an observable deliverable with its confirmed owner and due date, if agreed. Keep a missing date visible instead of choosing one. Separate actions from desired outcomes: prepare a sample is an action; improve adoption is a goal. Link to the existing task record when one is supplied.
Confirm before distributing
Have the appropriate participants verify decisions and commitments. Remove private discussion, unnecessary personal information, and restricted links. Lead the HTML page with what changed, then actions and unresolved issues. Apply your saved style if available without letting color imply approval. Share after review, and clearly label later corrections or superseding decisions.
Turn the supplied meeting notes into a concise decision record as static HTML. Lead with confirmed decisions and what changed. For each decision include its scope, recorded rationale, and important tradeoffs. Then list agreed actions with the exact owner and due date when supplied, followed by unresolved questions. Keep proposals separate from decisions. Do not infer agreement from silence, invent commitments, assign missing owners, or create deadlines. Mark ambiguous items for participant confirmation. Link to supplied authoritative task or decision records where appropriate. Remove confidential discussion and unnecessary personal details. Apply my saved artifact style if available, with readable headings and restrained emphasis. No scripts or forms. Return a review draft; wait for approval before publishing or changing access.
Check before you shareAccuracy, clarity, and permission
Does each decision have clear evidence of agreement in the notes or participant confirmation?
Are proposals and unresolved questions visibly separate from confirmed decisions?
Have owners and dates been verified instead of inferred by the agent?
Does the record respect confidential discussion and point to the team’s authoritative records?
When HTML fits
A compact handoff for people who attended and colleagues who need the outcome without reading a transcript.
When another format fits better
A replacement for required formal minutes, legal records, approvals, or task tracking. A published action list does not assign or synchronize tasks in another system.
What we started withThe same facts, as a wiki page
Fictional team wiki
Harbor pilot readiness — meeting record, September 7, 2026
Meeting details
Attendees: June (product), Mateo (support), Sana (engineering). Recorded by June. This is a summary, not a transcript; no recording or verbatim quotations are available.
Agreed decision
Agreed by everyone: start an invite-only pilot with 20 existing customers and keep public signup closed. A start date was not agreed. The purpose is to limit support load while observing onboarding problems, not to establish statistical significance or claim customer success.
Actions and owners
Sana checks event logging by September 9.
Mateo writes the support playbook by September 10.
June drafts the invite list by September 10.
Proposal, not approved
June proposed expanding to 100 customers after the pilot. That proposal is not approved, and neither an expansion date nor a success threshold was agreed.
Open questions and next checkpoint
Open questions: who owns the go/no-go decision, and what support volume should trigger a pause? No owners or deadlines were assigned to these questions. The September 11 checkpoint reviews logging, the playbook and the invite list. It is a readiness review, not an agreed launch date.
Inspect the HTMLOne self-contained file
The example is sanitized and isolated from this site. No scripts, forms, or live data.
<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Harbor pilot · Decision record</title><style>
*{box-sizing:border-box}html{color-scheme:light}body{margin:0;background:#faf8f2;color:#172520;font:17px/1.65 system-ui,sans-serif}main{max-width:960px;margin:auto;padding:clamp(20px,5vw,64px)}h1,h2,h3,p{margin:0 0 18px}h1{font:500 clamp(32px,5vw,58px)/1.12 Georgia,serif;letter-spacing:-.025em;overflow-wrap:anywhere}h2{font:500 29px/1.25 Georgia,serif}h3{font-size:18px;line-height:1.4}.label{font:700 12px/1.5 system-ui,sans-serif;letter-spacing:.12em;text-transform:uppercase}.intro{font-size:20px}.lead{background:#153e32;color:#fff;padding:28px;margin:28px 0}.lead p:last-child{margin:0}.grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,220px),1fr));gap:20px;margin:28px 0}.card{background:#fff;border:1px solid #cad3c9;padding:24px}.metric{font:500 42px/1.1 Georgia,serif;display:block;margin-bottom:12px}section{margin:36px 0}ul,ol{padding-left:22px}li{margin-bottom:12px}.note{color:#40584d;font-size:14px}footer{border-top:1px solid #bac8bf;padding-top:24px;margin-top:40px;font-size:14px}.decision{background:#f7f4ed;color:#282238}.decision .lead{background:#332753}.decision .card{border-color:#d6ccdf}.decision .note{color:#5d4e6d}.meeting{background:#f5f8fc;color:#142c48}.meeting .lead{background:#163e69}.meeting .card{border-color:#bccde0}.meeting .note{color:#3d5673}@media print{body{background:white}.card,.lead{break-inside:avoid}}
</style></head><body class="meeting"><main><header><p class="label">Harbor / Decision record / September 7, 2026</p><h1>A small pilot. Not a public launch.</h1><p class="intro">The team agreed on the pilot audience. A start date and launch authority remain unresolved.</p><p class="note">June (product), Mateo (support), Sana (engineering) · Recorded by June</p></header>
<aside class="lead"><p class="label">Agreed by all attendees</p><h2>Invite 20 existing customers. Keep public signup closed.</h2><p>Limit support load while observing onboarding problems. This is not evidence of customer success or statistical significance.</p></aside>
<section><h2>Actions with owners</h2><div class="grid"><article class="card"><p class="label">September 9, 2026</p><h3>Sana · Check event logging</h3><p>Bring the logging check to the readiness review.</p></article><article class="card"><p class="label">September 10, 2026</p><h3>Mateo · Write the support playbook</h3><p>Prepare the playbook for the next checkpoint.</p></article><article class="card"><p class="label">September 10, 2026</p><h3>June · Draft the invite list</h3><p>Prepare a list for the agreed 20-customer pilot.</p></article></div></section>
<section class="card"><p class="label">Proposed · not approved</p><h2>Expansion to 100 customers</h2><p>June proposed expanding after the pilot. The team did not agree to an expansion date or a success threshold.</p></section>
<section><h2>Still needs a decision</h2><ul><li>Who owns the go/no-go decision? <strong>Unassigned.</strong></li><li>What support volume should trigger a pause? <strong>No threshold agreed.</strong></li></ul><p>No owners or deadlines were assigned to these questions. Do not treat them as resolved.</p></section>
<section><p class="label">Next checkpoint · September 11, 2026</p><h2>Review readiness—not launch.</h2><p>Review the logging check, support playbook, and invite list. This checkpoint is not an agreed pilot start date.</p><p class="note">Source: the fictional meeting notes accompanying this example. This is a summary, not a verbatim transcript.</p></section><footer>Fictional worked example by share/artifacts. Names, dates, and figures are invented for demonstration. Static snapshot; no live data or automatic updates.</footer></main></body></html>
Another example: a reporting-workflow pilotA separate fictional case, from notes to next action
From a discussion recap to an actionable record
A fictional product-planning meeting. The decisions, owners, and timing illustrate the format rather than describe a real team.
The original notes
We talked about the pilot, discussed documentation, and agreed there is more work to do. Marketing also had some questions.
Decision
Limit the first pilot to the reporting workflow. Broader onboarding is not included in this pilot.
Rationale
The team wants to review one complete workflow before expanding scope. This postpones feedback on the other workflows.
Action
Design owner: prepare a sample report for the next review. Due date was not recorded and requires confirmation.
Still open
Who will recruit pilot participants? No owner was confirmed in the notes.
Not a decision
A public launch was suggested but not approved. Do not treat it as a scheduled commitment.
The record preserves a useful boundary: a topic can be discussed without becoming a decision or a promise.
Questions, adaptations & sourcesGo deeper when you need to
Should I include the full transcript?
Usually the decision record should stand on its own. Link to an approved transcript only when readers need it and are permitted to access it. Do not publish a transcript simply because an agent used it as source material; it may contain unrelated or confidential discussion.
What if no decision was made?
Say so. A useful record can state the question, the options discussed, what information is missing, and the agreed next step if there is one. Do not manufacture a conclusion to fill the template. An honest open question is more actionable than false certainty.
How should a later decision be recorded?
Keep the original context understandable and mark the earlier decision as superseded, with a date and a link to the new record when available. For a correction, explain what changed. Do not silently rewrite history when readers may have acted on the earlier version.