Build a reusable prompt pipeline turning any meeting transcript into decisions with rationale, owner-dated actions, and RAID updates — then prove it on two meetings where the second quietly reverses a decision and one action floats by unowned. The log must record the reversal as final and flag the orphan, not paper over either.
Ben Osei is a business analyst at Bluegrass Payments, a fictional payments processor, supporting a project to overhaul chargeback operations. The project has the usual disease: decisions get made in meetings, remembered differently by everyone, and re-litigated three weeks later. Ben's fix is not more meetings — it is a pipeline: a prompt template that converts any transcript into a decision log, action list, and RAID updates in one pass, consistently enough that the team trusts the log more than their memories.
CHARGEBACK OPS OVERHAUL — Working session, Mon 02 Mar, 40 min
Present: Sara (Head of Ops), Ben (BA), Marco (Eng Lead),
Tania (Finance), Ravi (Compliance)
Sara: Volumes are up 30% and the team is drowning. Options on the
table: build a rules engine in-house, or buy the DisputeFlow module.
Marco: Build is 4-5 months, two engineers. But we control the rules.
Tania: DisputeFlow quoted 90k a year. Build costs us maybe 140k
in eng time, then it's ours.
Sara: Cash beats subscription this year. Decision: we BUILD the
rules engine in-house. Marco, feasibility spike by 20 March.
Marco: Taking it. I'll bring a design sketch too.
Ravi: Flag from me — if we auto-decline disputes, we may hit card
network rules on response documentation. Risk, not a blocker.
Sara: Log it. Also, someone should check whether our PCI scope
changes if dispute data flows through the new engine.
Tania: Not it. Buried this quarter.
Sara: We'll sort an owner later. Next: reason-code mapping. Ben to
draft the new taxonomy by 13 March — agreed.
CHARGEBACK OPS OVERHAUL — Working session, Mon 16 Mar, 35 min
Present: Sara, Ben, Marco, Tania (Ravi absent)
Marco: Spike results. Honest numbers: build is closer to 7 months
and 200k+ once we include the case-management UI we forgot.
Tania: That changes my maths. At 200k+, DisputeFlow at 90k a year
wins for at least two years.
Sara: Agreed, and I hate it. Reversing our call from the 2nd:
we BUY DisputeFlow. Marco's spike is the reason — costs, not
capability. Marco, contract review with procurement by 30 March.
Marco: On it. My design sketch becomes the integration spec.
Tania: I'll rebase the budget line by Friday the 20th.
Sara: Ben's taxonomy draft — landed on the 13th, nice. It feeds
DisputeFlow config now instead of our engine.
Sara: Ravi's card-network risk stands regardless of build or buy.
Keep it open until Ravi confirms DisputeFlow's response templates
satisfy the documentation rules.
Design the output schema before the prompt. Three artifacts, fixed columns. Decision log: ID | Decision | Date | Rationale | Alternatives considered | Status (ACTIVE / SUPERSEDED by ID) | Source line. Actions: ID | Action | Owner | Due date | Status | Source line. RAID: Type (Risk/Assumption/Issue/Dependency) | Entry | Raised by | Status | Source line. The schema is the pipeline's contract — the prompt serves it, not the other way round.
Write the pipeline prompt as a reusable template. Draft it with slots, roughly: "You are a project librarian. From the transcript below, extract into exactly these three tables: [schema]. Rules: a decision requires an explicit commitment by someone with authority — proposals and options are not decisions. Every action needs an owner stated in the transcript; if no owner was assigned, set owner = UNASSIGNED — never guess. Record rationale and alternatives only from what was said. Cite the transcript line for every row. If this transcript changes a prior decision (prior log provided below), mark the old decision SUPERSEDED and link it. Prior log: [slot]. Transcript: [slot]." Save it — this template, not any single output, is the deliverable you will reuse.
Run Meeting 1 through the pipeline. Paste the template with an empty prior log. Audit the output against the transcript line by line: the build decision with Tania's cost comparison as rationale and buy-DisputeFlow as the alternative considered; two owned actions (Marco's spike, Ben's taxonomy); Ravi's card-network risk in RAID; and the PCI-scope check. Watch that last one — what did your pipeline do with an action nobody took?
Fix the orphan-action behaviour if it guessed. Models dislike blank owner fields and will quietly assign the PCI check to Sara (she raised it) or Tania (she declined it — being mentioned near an action is not ownership). If your output invented an owner, tighten the template rule — "assign UNASSIGNED unless the transcript shows the person accepting the action" — and re-run until the orphan is flagged, not adopted.
Run Meeting 2 with Meeting 1's log as the prior. This is the pipeline's real test: continuity. Check three behaviours. The build decision must flip to SUPERSEDED with a link to the new buy decision — the buy decision is the log's final position, with Marco's spike as rationale. Ben's taxonomy action must close, not duplicate. Ravi's risk must stay open with the new DisputeFlow-templates condition, even though Ravi was absent.
Audit the reversal handling hard. Failure modes to hunt: both decisions listed as ACTIVE (the log now contradicts itself); the build decision silently deleted (history erased — the rationale trail is the log's whole value); the reversal recorded without Marco's spike as the cause. Exactly one representation is correct: old row kept, marked SUPERSEDED, linked forward; new row ACTIVE with rationale.
Re-run the whole pipeline once from scratch. Same template, both transcripts, fresh chat. Compare outputs. Differences reveal where your template still leaves judgment to the model — tighten the rules until two runs agree on decisions, owners, and statuses. A pipeline that only worked once is a demo.
Package the template for reuse. Save the final prompt with a three-line header: what it produces, what it needs (transcript + prior log), and its two known rules people forget (UNASSIGNED is a valid owner; SUPERSEDED rows are never deleted). Hand it to a colleague — or your future self in Lab 14, where meeting-driven requirements churn returns at scale.
A decision log that silently overwrites reversals will be trusted right up until someone quotes the old decision in a steering committee — history you cannot show is agreement you cannot prove.
A complete lab has all of the following:
The pipeline's value is not speed — it is consistency under awkward inputs: reversals kept as history with the new position final, and unowned actions flagged as unowned instead of assigned by invention. A log the team can trust is one that refuses to guess.