Meeting Assistant

01 / WORKFLOW

Workflow and implementation

A CLI tool became a web interface and Docker service for internal staff, connecting recording, transcription, speaker attribution, minutes, Notion storage, and email delivery.

I am the sole owner across planning, the speech pipeline and web UI, sign-in and access boundaries, deployment, operations, and maintenance. Requests from education and development staff led to an error-management UI, recording backups, and an Android web app.

02 / USAGE · 2026.08–09

Monthly usage records

The service is used by the education and development departments of a company of approximately 32 people. These monthly aggregates were supplied from the operating UI on Sep 15, 2026; individual names and activity are omitted.

• Total: 32 recorded meetings and 833 minutes. Minutes describe recorded meeting duration, not model latency or staff time saved.
• September is a partial month. Company headcount is not active users; these aggregates alone do not establish success, retention, or monthly growth rates.

03 / USER REQUESTS

Changes driven by user requests

As the operations owner, I brought logs, completed and failed jobs, and retry actions into the UI so I can investigate failures and respond. Requests to retain recordings and simplify mobile use led to backups and an Android web app.

• These are request summaries and implementation details supplied by the project owner, not verbatim user quotations or satisfaction measurements.

04 / SYSTEM

Architecture

An RTX 4090 runs faster-whisper and pyannote. Transcription and diarization are serialized, with waiting jobs marked queued. Transcript text is sent to the external Claude API to generate structured minutes.

The server returns a job ID instead of holding an HTTP response for the full audio pipeline. Short status polls separate long inference jobs from proxy request limits.

1. 01Audio

   faster-whisper

2. 02Diarize

   pyannote · RTX 4090

3. 03Minutes

   Claude · structured JSON

4. 04Deliver

   Notion · SMTP

05 / CHANGE · 2026.09

When the upload response is lost

A job can be created on the server while its start response arrives as an HTML error. A JSON parsing error then makes the upload appear to have failed. The client now looks for an existing in-progress job before asking the user to upload again.

1. 01Inspect response

   Detect HTML / 5xx

2. 02Find job

   Own in-progress jobs

3. 03Match context

   Time · department · sender · duration

4. 04Reconnect

   Poll the existing job ID

• Matching compensates for server/client clock differences and requires several conditions. This is heuristic reconnection, not an idempotency guarantee.
• The behavior is documented in the Sep 11, 2026 change and implementation. Reconnection success and duplicate reduction have not been aggregated.

06 / FAILURE HANDLING

Failures and retained results

Retry after a restart starts a new job from retained audio; it does not resume inference at a saved checkpoint.

07 / DATA FLOW

Sign-in and data flow

Google SSO identifies the user; the app lists and opens meetings created by that user. Notion uses separate department delivery routes. Local audio processing is distinct from sending transcript text to an external summary API.

The public demo runs on sample data. Internal recordings, transcripts, customer information, and operational credentials are excluded.

08 / EVIDENCE

Evidence and measurement scope

A Sep 15, 2026 review of implementation and change history confirms reconnection, interrupted-job records, and partial-result retention paths. The current internal RTX 4090 service is separate from the public UI demo.

The historical “56-minute file, about 28 seconds” observation covers chunked diarization only. It is not an end-to-end or repeated benchmark. Recorded usage appears in the monthly statistics. Human time savings, satisfaction, and stage-level success rates have not been measured.

ENGINEERING DECISIONS

Engineering decisions