DVT Guide: Local Transcription & Audio Lifecycle
A design-validation plan for local ASR, interruption recovery, corrupted audio, duplicate prevention, deletion timing, and evidence-based privacy claims.

DVT for a local-transcription recorder must validate the complete state machine, not just speech-recognition output. A passing system captures audio, survives interruption, commits a usable note, records provenance, and deletes a source slice only after the computer has consumed it for transcription.
What is the system under test?
The approved C1 architecture divides work across two devices. C1 performs capture and on-device voice activity detection, stores encrypted audio slices temporarily, and transfers over Bluetooth or USB-C. The paired macOS or Windows computer performs local ASR and speaker labeling, writes local OKF Markdown, and instructs C1 to delete each slice after transcription consumption.
That boundary creates at least six observable states:
- Captured: a complete or recoverable slice exists on C1.
- Staged: the computer has copied the slice but has not committed a note.
- Transcribed: ASR produced candidate text.
- Committed: the Markdown note and its metadata are durably written.
- Acknowledged: the sync state records that the slice was consumed.
- Released: C1 deleted the source slice.
The destructive transition is last. If a process crashes between staging and commit, the source must remain recoverable. If commit succeeds but deletion acknowledgement is lost, the next run must identify the already-consumed slice and avoid a duplicate note.
How should the interruption matrix be tested?
Inject failure at every boundary, then verify both sides. “The app recovered” is not enough; compare file hashes, note counts, device inventory, and state pointers before and after restart.
| Injected failure | Expected device state | Expected computer state |
|---|---|---|
| Power loss during capture | Earlier slices intact; active slice complete or explicitly marked invalid | No fabricated note |
| Disconnect during transfer | Source slice retained | Partial staging file ignored or resumed |
| Process killed during ASR | Source slice retained | No committed duplicate; retry allowed |
| Power loss during note write | Source slice retained | Atomic write leaves old state or complete new note |
| Disconnect after commit, before delete | Source may remain | Processed hash prevents retranscription; delete can retry |
| Corrupted slice | Not deleted until a local quarantine copy is verified | Error and source provenance preserved |
How do you validate transcription without inventing one accuracy number?
Word error rate is useful for a fixed labeled corpus, but it can hide the errors that matter to work. Build a versioned evaluation set containing quiet speech, low-volume speech, keyboard noise, accents and supported languages, overlapping speakers, domain terms, names, dates, numbers, and negation. Keep the hardware placement and source level recorded with each sample.
Report at least three layers:
- WER or CER on the labeled corpus, with model and decoder versions.
- Critical-term recall for identifiers, numbers, names, and negative instructions.
- Task usability: whether a reviewer can derive the intended decision without replaying the entire recording.
Do not compare two ASR systems on different audio, language settings, or post-processing rules. The OpenAI Whisper paper is one example of reporting robustness across diverse datasets rather than presenting a single universal accuracy claim.
What does VAD validation need to measure?
Voice activity detection changes what reaches ASR. An aggressive threshold can clip quiet syllables or the start of a sentence; a permissive threshold can retain long noise regions. Test false rejection, false acceptance, boundary truncation, and fragmentation against labeled time intervals. Then inspect the downstream transcript, because a small timing error may delete a critical negation even when aggregate VAD metrics look acceptable.
The documented C1 audio design uses Opus at 16 kHz mono and 16 kbps. RFC 6716 defines Opus across a much wider range; the project-specific rate is a design choice, not an inherent fixed Opus requirement. Verify decoder compatibility, duration, channel count, and end-to-end hash or frame accounting on the actual encoded files.
How should privacy claims be verified?
“Local” is an architecture claim that can be tested. Capture DNS and network traffic while recording, transferring, transcribing, searching, and exporting. The OneMira product claim is narrower than “nothing ever uses the internet”: OneMira speech recognition and transcription run on the paired computer, while any third-party AI service selected by the user follows that provider’s data path.
A privacy test should therefore record:
- which process opens each network connection;
- whether audio bytes or only update/telemetry metadata leave the machine;
- where temporary audio, model caches, logs, and transcripts are stored;
- when device and local temporary files are deleted;
- whether a third-party agent receives a selected excerpt or the full note.
Local processing can reduce one class of cloud exposure, but it does not automatically satisfy GDPR, HIPAA, employment policy, or recording-consent law. Compliance depends on purpose, consent, access control, retention, jurisdiction, and the downstream tools used.
What evidence closes DVT?
For every requirement, retain the test version, device and software build, input fixture, expected result, measured result, logs, hashes, screenshots where useful, and disposition. Re-run the matrix on both supported operating-system families. A passing happy path on one powerful computer does not validate recovery, low-resource behavior, or another platform.
The troubleshooting documentation should map user-visible errors to these states. Production repeatability then moves to the PVT guide.
Sources and further reading
- OpenAI: Robust Speech Recognition via Large-Scale Weak Supervision — primary research paper describing Whisper evaluation across datasets and languages.
- IETF RFC 6716: Opus — standards-track codec definition and supported operating range.
- Microsoft audio-device design guidance — capture bandwidth, received noise, microphone matching, and speech-recognition considerations.
- OneMira C1 specifications — current public local-processing and audio-lifecycle statement.