# internal-meeting-brief — section structure

Derived from the first real run (2026-09-21, APTA 2026 Booth 09-16 recap) and made
explicit here so every future brief has the same skeleton instead of reinventing its
structure per meeting. This is the contract — read it before generating a brief.

## Always present (fixed, in this order)

1. **Header** — title (meeting subject, not the raw Plaud filename), meeting date +
   duration, prepared date, source (transcript / manual notes), mode (Agenda/Recap).
   Also attach relevant deal-identifying context in the header/subhead when the topic
   is a commercial engagement — e.g. the SO/PO numbers and total, as validated in the
   Oshkosh brief — so the document is self-identifying without opening the manifest.
2. **Attendees** — one card per attendee. Internal MPM people resolved by name where
   possible. If Plaud's speaker diarization didn't resolve a name, render the literal
   transcript label ("Speaker 1," "Speaker 3") — never guess a name. Follow with a
   `note.info` flagging any unresolved speakers explicitly, so it's visible, not buried.
   When external counterparts are named in discussion but weren't present, give them
   their own card group ("Named in discussion, not present") with resolved contact
   info (see SKILL.md step 4) rather than omitting them or burying them in prose.
   **If the topic has a real end-client organization** (an agency, most commonly),
   give it a distinct "End Agency" card of its own — separate from individual
   people — showing the legal-name/brand-name pair (e.g. "City of Oshkosh, dba: GO
   Transit"), a re-hosted logo, website, and general contact info. See SKILL.md
   step 5.
3. **Topics Covered** — a `cards` grid, one card per distinct subject actually
   discussed. Card count and grid density (c2/c3/c4) follow the number of real topics —
   don't pad to hit a round number, don't force unrelated topics into one card to save
   space.
4. **Key Decisions** (recap) or **Discussion Plan** (agenda) — decisions actually made
   (recap) or points to be raised (agenda). Use `quad` when there are 3-5 distinct,
   roughly parallel decisions; use plain prose or a `note` when there's only one or two,
   since forcing a single decision into a quad grid wastes space and implies false
   parallelism.
5. **Open Items** — an `actions` table with status pills. Every action item needs an
   owner field even if the honest value is "Unassigned" — never leave the column blank,
   since a blank reads as "forgotten to track" rather than "no owner yet." **When the
   brief includes action items Claude is suggesting rather than items the meeting
   itself raised** (validated pattern from the Oshkosh brief), split them into two
   visually distinct tables with a labeled subhead and a badge (e.g. `MEETING` vs.
   `PROPOSED`), and say explicitly that proposed items are suggestions needing an
   owner to accept them — never blend a suggestion into the same table as a committed
   action item where they'd read as equally real.
6. **Notes & Flags** — one `note` per genuinely separate concern: data-source
   limitations encountered (a failed pull, a missing transcript), naming/identity
   uncertainty, anything that needed a judgment call worth surfacing rather than
   silently resolving. This section exists specifically so the never-fabricate rule has
   somewhere to put its flags, visibly, not as a footnote.

## Present only when content genuinely calls for it (dynamic)

A dynamic section is content that has a **specific internal structure** the fixed
sections above would flatten into an unreadable wall of text or an over-long table row.
Add one only when the meeting's actual content has this shape — never as decoration,
never because a template "should" have variety.

| If sequential, ordered process (3+ steps, each depending on the last) | `flow` | Anti-vandalism 3-tier escalation (09-16 meeting); Oshkosh deployment sequence, client kickoff → survey → mount → install → go-live → acceptance (09-22 meeting) — **validated in real production use** |
| A named component/system with distinct sub-parts worth breaking out | `layerbox` + `filepill` | (not yet exercised on a real internal-meeting-brief; seen in development-brief-flavored source material) |
| A genuine two-sided contrast (us/them, before/after, keep/avoid) | `compare` | (not yet exercised on internal-meeting-brief; used in vendor-partner-style source material) |
| A spec/BOM-style matrix with yes/no or multi-column comparison | `unitgrid` | (not yet exercised) |
| A handful of headline numbers worth calling out at a glance | `specbar` | Oshkosh billing milestones — three estimate amounts + total, each with its own trigger condition — **validated in real production use** |

**Rule of thumb:** if you're reaching for a dynamic section and can't point to the
specific part of the meeting that has this shape, don't add it. The fixed six sections
above should carry ordinary meeting content on their own. Dynamic sections are earned
by unusual content structure, not added for visual variety.

## What's still unproven

This contract is based on exactly one real run. It hasn't been tested against:
- Agenda mode (only recap mode has run for real)
- A meeting with genuinely no clear "topics" (a single-subject deep-dive)
- A meeting needing more than one dynamic section
- A recurring topic's second brief (pre-fill/delta-confirm behavior for attendees,
  per CW-027 Concept.md, hasn't been exercised — the 09-16 brief was a topic's first
  run, full interview by necessity)

Revise this file after the second real run rather than treating it as settled.