Epic: Meeting knowledge — minutes become institutional memory, not a Discord attachment

[qiuethan]

Blocked by

No response

Summary

The platform's stated thesis is "institutional knowledge that survives graduation." /record produces the single richest artifact this org generates — what was decided, by whom, and what someone committed to do — and none of it is kept. services/meeting has no database by design; the bot posts meeting-minutes.pdf into the channel and that is the end of it. Scroll far enough back, or lose the channel, and the org's decision record is gone.

Nothing about a meeting is catalogued, owned, searchable, or attributable to a team. The board has an epic for indexing documents (#125) and one for a docs-grounded helper bot (#81); when both land, they will faithfully search stale Google Docs while every actual decision the org made stays invisible to them. This epic closes that gap, and in doing so materially improves the corpus #125 is being built to search.

Model

Three pieces, in order: persist (a meeting record survives the session), catalogue (it becomes a first-class owned entity the rest of the platform can reference), surface (members can find it).

Three constraints govern the shape, and the first two are the interesting ones:

• Audio must never persist. Today audio streams to AWS as transcription input and is never written to disk. That property is not negotiable and this epic does not weaken it — transcript and minutes are the artifacts, audio is not.
• The catalog is keyed on normalized URLs. documentation-system ingests a URL, dedups on it, and hangs a content snapshot off it. A meeting has no URL. Either meeting records get a canonical identity the catalog can accept, or the catalog's model widens to hold non-URL entities.
• meeting is deliberately stateless. Giving it a database is a real architectural change, not a detail. The alternative — meeting stays stateless and hands minutes to a service that already owns persistence, ownership validation, and grants — keeps the existing shape.

The decomposition below is conditional, and only the first item is filed. Every later item changes shape depending on how the design issue answers those questions — including which zone it lands in, which is not knowable in advance for the persistence work. They stay unchecked lines here and get promoted to real issues once the design closes, per the template's "promote each to its own sub-issue as it's picked up." Filing them now would mean filing issues nobody can estimate or pick up.

Decomposition (build order)

• Design: where a meeting record lives, what identifies it, and how long it is kept — the three decisions above plus retention, settled and written into docs/MEETING-RECORDING.md, which already documents this feature's cross-cutting design. Does meeting gain a database, or does documentation-system take ownership of minutes? What is a meeting's canonical identity? How long is a transcript kept, who can delete one, and what can a member ask to have removed? Retention is decided here rather than late because soft-delete, deletion timestamps, and per-participant removal are all schema — deciding them after the schema ships means a migration.
• Persist the meeting record — transcript, generated minutes, participants (resolved to directory people where they are linked), channel, start and end time. Audio still never touches disk. Zone follows the design decision.
• Structured decisions and action items — minutes already generate these as prose; extract them as structured fields alongside the narrative so they can be queried rather than read.
• Catalog ingest with ownership and visibility — meeting records become first-class catalogued entities, owned by a team derived from the channel or supplied at /record start, and subject to the same actor-scoped grants as documents. Ownership is set at ingest rather than bolted on afterwards. A private team's meeting must not be readable org-wide by default.
• /meetings browse — list and show subcommands so members can find a past meeting from Discord, mirroring /doc's shape.
• Retention enforcement — implement whatever the design issue decided: expiry, deletion, and the member-facing removal path.

Area

service, docs-system, bot

What we can build on

• /record already works end to end — live Amazon Transcribe streaming, rolling transcript, LLM-generated minutes, branded PDF. This epic keeps what happens after "stop"; it does not rebuild the pipeline.
• meeting already calls llm for minutes generation, so structured extraction is a prompt-and-schema change on an existing call rather than new plumbing.
• documentation-system already owns owner validation against the directory, per-doc grants (Document visibility: per-doc grants (person/team) + actor-scoped enforcement #74), and content snapshots — the exact machinery meeting records need.
• team-tracking already resolves Discord ids to people, which is how participants become directory references rather than raw handles.
• docs/MEETING-RECORDING.md documents the existing split between the bot's voice surface and the service, including why it breaks two conventions. It is where the design decision belongs.

Not in this epic

• RAG indexing of meeting content — Epic: RAG retrieval layer — /embed + pgvector store + actor-scoped similarity search #125 owns embedding and retrieval. This epic makes meetings available to be indexed; it does not index them. Epic: RAG retrieval layer — /embed + pgvector store + actor-scoped similarity search #125 carries the matching requirement that its pipeline key on catalog entities rather than URL-fetched documents, so meeting records are not silently excluded.
• Action-item follow-up and nudging — chasing an action item to completion is worth its own epic once records exist. This epic extracts and stores them; it does not chase them.
• Changing how transcription works — the STT pipeline, speaker handling, and the no-audio-on-disk guarantee are unchanged.

Open questions

These are the design issue's agenda, not loose ends — it exists to close them.

• Does meeting gain a database, or stay stateless and hand off? Leaning toward hand-off: it preserves the current architecture, and the catalog already has grants, ownership, and snapshots built.
• Where does the PDF itself live — regenerated on demand from stored minutes, or stored as a blob? Regeneration is cheaper to build and avoids a blob store the platform does not currently have.
• Default visibility for a meeting record — team-only, or org-wide? Team-only is the safer default and can be widened; the reverse is not true.
• Do participants need to consent to persistence explicitly, given a transcript becomes durable rather than ephemeral?