Two voice-capture paths exist today, behaving differently:
/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.
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.
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.
storage_path.source_mode: "voice" and source_file_id on the resulting assertion — the same metadata shape the file-upload path already sets.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.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.
Unifying the two voice-capture mechanisms (Path B, rejected for this CR). Any change to the file-upload voice path, which already works correctly.