Public-Sector Transcript Summarization
Summarise public meeting transcripts with no third-party APIs, a full audit trail, and human review before publication - including the migration and adoption plan candidates skip.
Last updated:
A government client wants AI summarisation of public meeting transcripts, with no third-party APIs, a full audit trail, and human review before publication. Compliance dominates every choice here. No third-party APIs removes the frontier models; full audit trail means every version of every draft is retained and attributable, including drafts never published; human review before publication means the system's output is a draft and the workflow around that draft is most of the engineering. The piece candidates skip is the end: migration of the backlog and adoption by the clerks who have to use it.
“Compliance is the design, not a constraint on it. The system produces drafts, never publications. The review UI and how fast it is to verify a claim are the real deliverable, and the rollout plan is what decides whether any of it gets used.”
Clarifying Questions (Ask These First ~5 min)
| Question | Why it matters |
|---|---|
| Is no third-party APIs absolute, or does an accredited sovereign cloud count? | Decides between self-hosted weights and an accredited regional service |
| Who signs off before publication, and what do they do today? | The review workflow is the product, and it has to beat the current process |
| Does the system produce the transcript, or is one supplied? | ASR errors propagate into every summary and into the published record |
| What must the audit trail prove - authorship, changes, or both? | Sets the versioning model and the retention schedule |
| Any accessibility or plain-language obligations? | Usually mandated in public-sector publishing and shapes the output format |
| What is the records-retention schedule? | Unpublished drafts are often public records too |
| What happens when a published summary is wrong? | There must be a correction and re-publication path, designed rather than improvised |
Architecture (Draw This)
Say this as you draw it
Key Components (30-second pitch each)
- 1Self-hosted models chosen for the task, not the leaderboard - Summarising a supplied transcript is well within open-weights capability. Pick a model that fits the available hardware, pin the version, and accept the lower ceiling - the requirement already made that trade, so the job is to scope the task to match.
- 2Chunk by agenda item, not by token count - A council meeting is a sequence of decisions. Summarising per item yields the structure people actually use - motion, mover, vote, outcome, actions - and makes every claim traceable to a bounded span of the transcript.
- 3Timestamp-level grounding - Each sentence in the draft carries the transcript span it came from, so a reviewer verifies in seconds rather than re-reading a three-hour meeting. This is the single feature that makes human review survive contact with real volume.
- 4The audit trail includes drafts you never published - Under most public-records regimes a generated draft is itself a record. Append-only storage, reviewer identity, full edit history, and a retention schedule agreed with the records office before launch rather than after the first request arrives.
- 5Review speed is the adoption metric - A reviewer who spends longer checking than they would have spent writing will stop using the system. Measure time to approve and edit distance from week one and treat them as the primary success metrics, above any model score.
- 6Migration and adoption - the part candidates skip - A backlog of historical meetings to process, a parallel-run period, training for the clerks who review, a published disclosure that AI assisted the summary, and a defined rollback to the manual process. In public-sector work this is usually what decides success, not the model.
What Separates a Strong Answer
- 1Self-host models - Select models that fit the task and hardware, accepting lower ceilings for compliance. This ensures control over data and aligns with the client's constraints.
- 2Chunk by agenda item - Focus on agenda items rather than token counts for summarisation. This mirrors how meetings are structured and supports traceability and clarity.
- 3Timestamp-level grounding - Ensure each summary sentence maps to a transcript span. This allows reviewers to verify claims quickly, essential for handling large volumes efficiently.
- 4Plan migration and adoption - Address the backlog, train clerks, and define rollback processes. Successful adoption hinges on these operational aspects, not just the model's performance.
Constraint to Design Consequence
| Constraint | Consequence |
|---|---|
| No third-party APIs | Open weights self-hosted or an accredited sovereign cloud; no frontier model, and you own the operations |
| Full audit trail | Append-only store, versioned drafts, named reviewers, agreed retention - drafts are records |
| Human review before publication | The system emits drafts only; the review UI and its speed are the actual deliverable |
| Public accountability | A published disclosure that AI assisted, plus a correction and re-publication path |
| Accessibility obligations | Structured semantic output with a plain-language layer, not a wall of prose |
Rollout Plan
| Phase | What happens | Exit criteria |
|---|---|---|
| Pilot | One committee, transcripts supplied, reviewers shadow the current process | Edit distance and time to approve better than manual |
| Parallel run | Both processes on every meeting; published output still manual | Agreement on decisions and votes above the agreed bar |
| Limited production | The AI draft is the starting point, with a documented manual fallback | No correction events attributable to the model over N meetings |
| Backlog migration | Historical meetings processed in batch and reviewed in bulk | Records office sign-off |
| Steady state | All committees, sampled quality assurance, quarterly model review | Sustained review time and no open accuracy findings |
3 Biggest Risks
- 1ASR errors becoming the authoritative record - A misheard name or vote becomes a published fact. Mitigated by publishing the transcript alongside the summary, flagging low-confidence spans in the review UI, and refusing to summarise any span below the confidence threshold.
- 2Reviewer rubber-stamping - Drafts that are usually right train reviewers to approve without reading. Mitigated by tracking edit distance per reviewer, independent sampled quality assurance, and deliberately surfacing the flagged spans rather than burying them.
- 3Scope drift from summary to interpretation - The system starts characterising motives or tone rather than reporting what happened. Mitigated by a fixed prompt boundary, structured output fields, and a forbidden-phrase check that blocks evaluative language before review.
Google Stack: Assured Workloads or Google Distributed Cloud → self-hosted Whisper for ASR (or Chirp in an approved region) → Gemma or another open model on GKE with vLLM → Cloud SQL for versioned drafts → Cloud Logging as the append-only audit sink → Cloud Identity for reviewers
Azure Stack: Azure Government or a sovereign region → Azure AI Speech in-region → open weights on AKS, or Azure OpenAI where the accreditation covers it → Azure SQL with temporal tables for draft versioning → Purview retention policies → Entra ID reviewer identity
AWS Stack: AWS GovCloud → Amazon Transcribe in-region → vLLM on EC2 GPU instances, or Bedrock where accredited → Aurora with versioned draft records → S3 Object Lock for the immutable audit store → CloudTrail for access history
Other Options: Fully self-hosted - Whisper with WhisperX diarisation, Llama or Qwen on vLLM, Postgres with row versioning, MinIO with object lock, and Keycloak for reviewer identity. This is the common answer wherever no third-party means literally no cloud.
Frequently asked questions
What if a published summary turns out to be wrong?
A correction workflow, not a quiet edit. Re-publish with a visible change note, retain both versions, and record the cause in the audit trail. In a public-records context an unlogged edit is worse than the original error, because it damages trust in everything else you published.
How do you evaluate summarisation quality here?
The structured fields make it tractable: did it capture every motion, every vote outcome and every action item? Those are checkable against the official minutes. Free-text quality sits on top as a rubric score, and the harness itself is the one described on the evaluation and drift problem.
The transcripts are public anyway - can you use a hosted model?
Worth asking, because the answer is sometimes yes. But the restriction is often procurement rather than privacy, and procurement rules do not care that the data is public. Confirm which kind of constraint it is before designing around the wrong one.
How much hardware does this need?
Batch summarisation of a few dozen meetings a week is not latency-sensitive, so a single GPU node running overnight is usually enough - one of the rare cases where self-hosting is genuinely cheap. Size for the backlog migration, which is the real peak, not for steady state.
What about bilingual or minority-language obligations?
Translate from the approved summary rather than from the transcript, so only one version is reviewed for accuracy and the translation is checked against it. Machine-translated output passes through the same review gate as the original.
Why not just publish the transcript?
They usually already do, and the summary exists because nobody reads three hours of transcript. Saying this shows you understand the user need - the value is the decision record, which is exactly why the output is structured rather than narrative prose.