Meeting knowledge: design — where a meeting record lives, what identifies it, and retention

[qiuethan]

Blocked by

No response

What

Settle four decisions that the rest of the meeting-knowledge epic is built on, and write them into docs/MEETING-RECORDING.md:

1. Does services/meeting gain a database, or does it stay stateless and hand minutes to a service that already persists things?
2. What is a meeting record's canonical identity, given the catalog dedups on normalized URLs and a meeting has no URL?
3. What is the retention policy — how long a transcript is kept, who can delete one, and what a member can ask to have removed?
4. Is the PDF stored, or regenerated on demand from the stored minutes?

Why

Every other item in the epic changes shape depending on these answers — including which zone the persistence work lands in, which is why none of them can be filed as real issues yet. Someone picking up "persist the meeting record" today cannot tell whether they are writing an Alembic migration in services/meeting or an ingest path in services/documentation-system.

Retention is in here rather than at the end of the epic on purpose. Soft-delete, deletion timestamps, per-participant removal, and expiry are all schema decisions. Deciding them after the schema ships means a migration, and it means a window where the platform is storing recordings of people talking under a policy nobody wrote down.

Area

service, docs-system

Done looks like

• docs/MEETING-RECORDING.md states where a meeting record lives and why, in the same voice as the existing cross-cutting design it already documents.
• A meeting's canonical identity is defined, and it is clear whether the catalog's URL-keyed model widened or meeting records got a synthetic identity it accepts.
• The retention policy is written down: duration, who may delete, and the member-facing removal path.
• The remaining epic items can each be given a single zone and promoted to real issues.
• No code ships from this issue.

Design notes

The hand-off option is the one to beat. documentation-system already owns persistence, owner validation against the directory, per-doc grants (#74), and content snapshots. Keeping meeting stateless preserves an architecture the platform documents and relies on, and avoids a fourth database. The case for giving meeting a database has to be stronger than "the minutes are generated there."

Audio stays off disk regardless. Whatever is decided, the guarantee that audio streams to AWS as transcription input and is never written to disk does not change. Transcript and minutes are the artifacts.

The catalog's URL keying is the real constraint. ingest_doc() normalizes a URL and dedups on it. Widening that model touches ingest, dedup, and every consumer that assumes a doc has a source URL — a bigger change than it sounds. A synthetic canonical identity is cheaper but risks being a URL-shaped lie that later confuses fetch logic.

Coordinate with #125: its indexing pipeline is required to key on catalog entities rather than URL-fetched documents, precisely so meeting records are not silently excluded from retrieval. Whichever identity is chosen here has to satisfy that.

Out of scope

• Implementing any of it. This issue produces a written decision, and the epic's remaining items are promoted from it.
• Changing transcription, speaker handling, or minutes generation.
• Deciding whether action items get chased — that is a separate epic, once records exist.