CR-2026-146 — Retain Audio for Live-Dictation Voice Captures — v0_1

Version. 0.1 Date. 2026-07-05 Status. Drafted, not staged for build. Number 146 confirmed free at staging (highest prior: CR-2026-145). Base: engine main @ 5e9c857, OL main @ 2a320fd. No build yet. Repos. loomworks-engine, loomworks.

What this fixes

Two voice-capture paths exist today, behaving differently:

• File-upload path (uploaded audio file, transcribed): audio retained permanently in storage, viewable via the existing "View source" mechanism (same route CR-2026-130 built for images/PDFs). Nothing lost.
• Live-dictation path (browser mic → live transcription → sent as text via /converse): no audio file ever reaches the engine. Only the transcript is kept. The assertion carries no source_mode, no source_file_id — nothing to play back or verify against.

When a transcription is imperfect — accents, names, specialized terminology, or content where accuracy matters (e.g. capturing an account from an Indigenous Tribe Elder) — the live-dictation path has no way to verify what was actually said. The original spoken content is lost the moment it becomes text.

Fix — Path A: extend the working pattern, do not rebuild

Wire the live-dictation path so the audio is uploaded and stored the same way the file-upload path already does, then reuse the existing View source mechanism to add a Replay option. This is the smaller, lower-risk path: the file-upload path is already mature and tested; the live-dictation path gains the same behavior rather than both paths being redesigned into one.

Why Path A over unifying the two paths (Path B, considered and set aside)

Path B — merging the two voice mechanisms into one — was considered. Rejected for this CR: nothing about the current two-path split is broken, only incomplete on the live-dictation side. Path B is a bigger, riskier change for the same end result. Fix the incomplete side; do not rebuild the whole thing.

Fix in detail

• When live dictation captures a note, upload the recorded audio through the same object-storage path the file-upload mechanism already uses, producing a real storage_path.
• Set source_mode: "voice" and source_file_id on the resulting assertion — the same metadata shape the file-upload path already sets.
• Add a "Replay" action on assertions with source_mode: "voice", reusing the existing source-file route (GET /engagements/{id}/uploads/{upload_event_id}/source-file) — the same route already serving audio correctly for the file-upload path.

Seed check

No explicit seed commitment on audio retention. Specification-level. Consistent in spirit with "corrections preserved, not smoothed" — a transcription is an interpretation of the original; without the original, an error in that interpretation can never be verified or corrected against source.

Out of scope

Unifying the two voice-capture mechanisms (Path B, rejected for this CR). Any change to the file-upload voice path, which already works correctly.