Pipe Ritual Transcripts into Decisions and Actions

Workflow area: Stakeholder Communication · Tier: Foundation · Hands-on time: ~25 minutes

The gap between "we decided in planning" and "nothing happened" is usually not commitment — it's capture. Somebody agreed to something at minute 43, nobody wrote it down, and three weeks later the decision gets re-litigated from scratch. Meeting AI solves the capture; what it cannot solve is that transcripts record who spoke, not who committed — and an AI that assigns action items on its own will assign work to whoever happened to describe it. The audit pass exists because assignments are social acts, and you own them.

When to use — and when not to

• Use it for recurring decision-bearing ritualssprint planning, roadmap reviews, OKR check-ins, stakeholder syncs: meetings whose output is supposed to be commitments.
• Use it to end re-litigationa searchable trail of "decided X on date Y, here's the discussion" is the antidote to the quarterly amnesia loop; it feeds pb-24's decision log directly.
• Use it when you run the meetingthe extraction is your closing ritual: last five minutes, decisions and actions on screen, confirmed live.
• Skip it for sensitive syncsperformance conversations, personnel decisions, legal matters: no bot, no transcript, no extraction.
• Skip auto-posting to trackersan unreviewed pipeline from transcript to Jira assignment will eventually assign the wrong person a commitment they never made, publicly. Always keep the human gate.

The recipe

1. 1.

   Record the ritual with consent. Granola, Fireflies, or your platform's native notetaker, with recording disclosed and consented per pb-01's norms. For recurring rituals, put the notetaker in the calendar series so capture is default, not per-meeting effort.

2. 2.

   Run the extraction within an hour of the meeting. Freshness matters — you're the audit layer and your memory is part of the audit. Paste the transcript:

   Copy

   Extract decisions and actions from this meeting transcript.
   
   Meeting: [RITUAL NAME, DATE — e.g. "Sprint planning, Aug 5"]
   Attendees: [NAMES + ROLES]
   
   Output:
   1. DECISIONS — one line per decision, with:
      - what was decided (as stated, not improved)
      - who made or ratified the call
      - the alternative that was rejected, if discussed
      - timestamp of the moment of decision
   2. ACTIONS — one line per action:
      - the action, the owner AS EXPLICITLY STATED, the deadline if
        one was said
      - if ownership was implied but never stated, put owner as
        [UNASSIGNED — discussed by NAME] — do NOT assign it
   3. OPEN THREADS — raised but not resolved.
   4. AMBIGUITIES — anything you could not confidently classify as
      decided vs discussed. When in doubt, put it here, not in
      DECISIONS.
   
   Rules: no inferred commitments, no invented deadlines. Every item
   carries its timestamp.
   

3. 3.

   Audit before anything leaves your screen. Good output looks like:

   Copy

   DECISIONS
   - Hold the pricing change until bulk-approval adoption data lands
     (ratified by Ravi, 22:14; rejected: ship with Sept release)
   ACTIONS
   - Draft SSO fix rollout note — Meera, by Aug 12 (31:40)
   - Follow up with Acme on beta feedback — [UNASSIGNED — discussed
     by Sunil] (18:22)
   AMBIGUITIES
   - "We should probably deprecate the v1 export" (Ravi, 40:03) —
     musing or decision? Not classified.
   

   Check the three classic failures: discussed promoted to decided (spot-check decision timestamps against the transcript — was it actually a call, or a strong opinion?), speaker promoted to owner, and invented deadlines ("by next week" that nobody said). Resolve every [UNASSIGNED] and every AMBIGUITY yourself — usually a 30-second Slack confirm: "Taking this one, Meera?"

4. 4.

   Post the confirmed summary where the attendees live. Decisions and actions — now human-verified — to the meeting channel within the hour, with a one-line "reply if I got any of this wrong" window. Silence after an explicit review window is legitimate confirmation; silence after an unreviewed auto-post is just unnoticed error.

5. 5.

   Push actions to the tracker, decisions to the log. Actions become Linear/Jira issues with owner, deadline, and a transcript link. Decisions append to the running decision log (pb-24 builds the retrieval layer on top). The transcript link on every item is what makes "wait, when did we agree to that?" a ten-second lookup instead of a meeting.

Make it yours

• Granola for the low-ceremony path: its meeting templates can run a decisions/actions structure per ritual type, and it merges your typed notes with the transcript — your in-meeting annotations become part of the extraction's evidence.
• Claude Project per ritual: keep the last several extractions as project knowledge and each new one gains memory — "flag any action from previous meetings that was due before today and never marked done" turns the ritual into a self-auditing loop.
• Team scale: wire Fireflies or Zapier to drop each raw extraction into a private channel for the meeting owner, who audits and forwards — the automation handles motion, a named human holds the gate for every ritual on the calendar.

Quality check

• Decisions were actually decidedspot-check two timestamps against the transcript; a strongly stated opinion is not a ratified call, and this is the highest-cost misclassification.
• Every owner really committedno assignment ships that the model inferred from who spoke; [UNASSIGNED] items got explicit human confirmation.
• No invented deadlines or commitmentsevery date in the output was said out loud; check any that look suspiciously tidy.
• Ambiguities went to humans, not to the trackerthe AMBIGUITIES section is empty only after you emptied it, never because the model classified everything confidently.
• The trail links backevery posted decision and tracker item carries its transcript timestamp, so any future dispute resolves by lookup, not memory.