How it works
Every meeting page on Peanut Gallery is produced by an automated pipeline. Here's what that means in practice.
Two levels of coverage
Not every meeting is processed the same way. There are two distinct levels, and it matters which one you're looking at.
We pull the city's published agenda and minutes documents and extract structured data from them: motions, votes, attendance, and a plain-language summary of what was decided.
This is fast to produce and covers most meetings. It tells you what was decided. It does not tell you what was said, who argued what, or how the discussion unfolded.
We download the audio recording, transcribe it with Whisper, attribute every turn to a specific speaker, and generate a summary of the actual discussion β including debate, public input, and staff presentations.
This takes longer. It tells you what was said. Every timestamp in the transcript is a deep-link into the city's recording.
Many meetings have both. Where they do, you can compare the official account with what the transcript shows β they sometimes differ.
Sources
Vancouver City Hall publishes video recordings of most council, committee, and public hearing meetings through a platform called Sliq/Harmony. The city also publishes official agendas and supporting documents on council.vancouver.ca.
Peanut Gallery pulls from both sources.
The pipeline
- Detect β Find new meetings published to Sliq
- Fetch documents β Pull the official agenda and linked PDFs from the city's website
- Transcribe β Download the audio and convert speech to text
- Attribute speakers β Identify who is speaking throughout the recording
- Extract structure β Pull out motions, votes, and attendance
- Summarize β Write plain-language summaries of the meeting and each motion
Steps 1β2 and 5β6 run on every meeting. Steps 3β4 require the audio recording and produce the full transcript.
Transcription
Audio is downloaded from the city's recording platform and run through a speech-to-text model (Whisper). Typical council meetings run two to five hours; transcription takes somewhat less time than that.
Raw transcription is accurate on clear audio but struggles with heavy accents, crosstalk, and unfamiliar proper nouns β particularly bylaw numbers, place names, and the names of councillors and staff.
Speaker attribution
The raw transcript doesn't know who is speaking. A second pass uses Claude to attribute each turn to a specific councillor, the mayor, city staff, or a member of the public β based on contextual cues in the recording: explicit introductions, chair language, mover language, and forms of address.
Attributions carry a confidence level:
- High β the speaker was explicitly named
- Inferred β the attribution follows from context
- Unknown β couldn't be determined
Informal crosstalk and public speakers who aren't introduced by name are hardest to attribute.
Structured data
Claude reads the attributed transcript and official documents and extracts:
- Meeting metadata β committee, chair, meeting type
- Attendance β present, absent, leave of absence
- Motions β title, movers, outcome, full vote record, timestamp in the recording
This structured data drives the motions table and attendance list on each meeting page.
Summaries
A final pass produces plain-language summaries:
- A meeting summary covering the full session β main items, decisions, notable moments
- A motion summary for each substantive motion β what was proposed, key context, and what staff recommended
For meetings with a full transcript, summaries draw on what was said in the recording. For meetings processed from official documents only, summaries are based on the written record.
Per-motion documents
For motions involving a referral report or staff report β typically rezoning applications and policy referrals β the pipeline reads the actual report and summarizes it separately. This runs as its own AI pass so the context window stays focused: each motion gets a summary grounded in its specific document rather than generic meeting context.
Staff reports for major rezoning applications can exceed 100 pages. The pipeline reads the first 8,000 characters, which captures the executive summary, key recommendations, and planning rationale β the content most useful for a plain-language summary.
Summaries are generated by AI and are not reviewed by humans before publication.
Editorial judgments
The pipeline makes editorial decisions that are worth being explicit about.
- Motion categorization. Each motion is classified as substantive, procedural, or minutes adoption. Substantive motions appear in the main motions section. Procedural motions (in-camera authorization, adjournment, consent agenda adoption) are separated or collapsed. This categorization is done by Claude; borderline cases may be miscategorized.
- Summary framing. Meeting summaries are written for a general audience. They reflect what the pipeline judged to be the main items and notable moments. A summary is not a verbatim record β it is an interpretation of the record. The source recording and official minutes are always linked for comparison.
- What "sourced" means. Every summary links back to the source it was drawn from β a transcript timestamp or an official document. "Sourced" means linked, not independently verified. The pipeline does not fact-check claims made by councillors, staff, or members of the public. It summarizes what was said.
Accuracy and limitations
Transcription errors are most common with proper nouns: street names, neighbourhood names, councillor names, and bylaw references. A curated list of known Whisper mistranscriptions is applied before speaker attribution β for example, common misreadings of councillor names. This list grows as errors are discovered and reported.
Speaker attribution works well in formal proceedings where introductions are explicit. Open-mic periods and public commenters are harder.
Motions may occasionally be missed, merged, or misattributed when the audio signal is weak or parliamentary language is unclear. Informal consensus decisions may not appear.
Summaries reflect what was said or recorded. They may not capture context visible only in the written agenda, and they may contain errors. If you spot one, use the link at the bottom of the page.
Corrections
When an error is reported and confirmed, the affected meeting is reprocessed and the corrected version replaces the original. Corrections are not announced individually β if you submitted a report and don't hear back, check the meeting page; if the content changed, it was acted on.
To report an error, use the feedback form. Include the meeting date and a description of what's wrong. Transcription corrections (wrong speaker name, mangled place name) and summary corrections (wrong outcome, missing context) are both in scope.
Who maintains this
Peanut Gallery Vancouver is a project of Peanut Gallery. The pipeline prompts, categorization rules, and editorial decisions described on this page are maintained by the project. There is no newsroom and no editorial board β the pipeline is the editorial process, and this page is its documentation.
The source data β city recordings and official documents β is published by the City of Vancouver. Peanut Gallery is not affiliated with the City.