How the recap reaches everyone

Three actions on the draft

Action 1: approve (the most common)

If the draft is clean — no needs-confirm flags, owners and dates all resolved — the organizer reads it, agrees, and taps Approve. The button submits to a Function URL Lambda (a small public web address attached straight to a Lambda, no API Gateway in front of it). The Lambda formats the clean recap as an HTML email, drops the needs-confirm section since there’s nothing left in it, and sends it to the whole attendee list via SES outbound. Then it marks the run as sent in the mn-runs table with the timestamp and the organizer’s name.

The attendees get a tidy email: a short summary, the decisions, and a table of action items each with an owner and a due date. Every action item links back to the transcript moment behind it, so anyone who wants to check a line can, in one click.

Action 2: edit (resolve the flags first)

More often, the draft has a flag or two — the vendor follow-up with no owner, the “before the launch” date that never got pinned down. The organizer taps Edit. A simple form opens showing each needs-confirm item next to the transcript line behind it, so they have the context without re-listening. They pick an owner from the roster, set a real date, and can also trim wording on any item or shorten the summary. On save, the Function URL Lambda applies the edits, clears the flags, and sends the clean recap to everyone — the same send path as approve.

This is the step that makes the whole system honest. The model surfaced what it wasn’t sure about instead of guessing, and the one person who actually knows — the organizer, who was in the room — resolves it in a few seconds. The attendees never see the uncertainty; they see a clean recap that happens to have had a human pass over the tricky parts.

Action 3: discard (the stop)

Sometimes the recap shouldn’t go out at all. The recording was a one-on-one that doesn’t need a group email. The wrong file got uploaded. The meeting was sensitive and the notes shouldn’t be circulated. The organizer taps Discard and the run stops: nothing is sent, no attendee is emailed. The recording and transcript stay in S3 (so a discard isn’t a delete — it’s a “don’t send”), and the run is closed in mn-runs with action discarded and the organizer’s name, so there’s a record of the choice.

Discard exists because the default has to be safe. A system that sends unless told not to will eventually send something it shouldn’t. This one sends only when a human says go.

Auto-send, for the meetings that earn it

The default is always a human in the loop. But some meetings are routine — the daily standup, the weekly check-in — and the same person approves a clean draft every single time. For those, the style doc can turn on auto-send for a named meeting type, with one hard condition: the draft has zero needs-confirm flags. If everything resolved cleanly, the recap goes out on its own and the organizer just gets a copy. The moment a draft has a single flag — an unclear owner, a fuzzy date — auto-send is skipped and it falls back to the normal approve-or-edit flow. So auto-send only ever ships drafts that would have been one-tap approvals anyway.

Every run is logged, every recap is recoverable

The mn-runs table records every meeting: the recording, the transcript location, the draft, the action taken (sent, edited-then-sent, discarded), the organizer, the timestamp, and a snapshot of exactly what email went out. Three months later, when somebody asks “wait, who was supposed to handle the vendor thing?”, the answer is one lookup away, with the transcript line that started it. The recap email everyone half-remembers is the working memory of the meeting; the run record is the permanent one.

Next post: the cost breakdown. The whole pipeline runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go — mostly transcription — and how it scales.

All posts