Case Study - Resolving the Riskiest Unknown Before Writing a Line of Product Code

Overview

The default assumption going in was a well-known iOS limitation: recording from a Bluetooth headset mic forces a "telephone quality" audio profile. For surgical dictation, that's disqualifying — the acoustic detail that distinguishes drug names and implant identifiers lives in exactly the frequency range that mode strips out. Building the entire capture architecture around an assumption that turned out wrong would have meant weeks of wasted engineering, discovered only after the fact.

The problem

The test that mattered wasn't "is the audio audible" — it was whether specific clinically catastrophic failure modes survived transcription: a mistaken laterality, a garbled implant identifier, a misheard drug name. Those aren't the failures a generic audio-quality test surfaces.

Why it took a physician-engineer

Designing a test protocol scored against exactly those hard cases — rather than generic intelligibility — required knowing, clinically, which mistranscriptions are catastrophic and which are merely annoying, and building the entire spike around that distinction from the outset.

Approach

Before any capture-path code was written, the risks were ranked explicitly — seven identified risks, likelihood and impact, the highest being that the "high-quality" mode's media-tuning would preserve exactly the ambient noise it needed to suppress. A single-screen, throwaway test app captured audio and routed telemetry against a fixed test matrix — device model, iOS version, capture mode, app state, distance, and a sustained run for thermal and session stability — against a realistic OR noise bed, not a quiet room.

Four sequential decision gates were defined up front — stream acquisition, isolation in noise, transcription fitness, endurance — with an explicit rule that a partial pass was acceptable everywhere except transcription fitness on the hard tokens, which was non-negotiable because it was the whole point of the exercise.

Under the hood

The spike exercised the high-quality Bluetooth recording mode, which requires a current-generation earbuds model on a current iOS release, with automatic fallback to standard quality when the high-quality link isn't available. It tested voice isolation against media/wide-spectrum tuning directly, since the two modes behave very differently in noise. The outcome fed directly into the shipped product: a live route-telemetry readout — negotiated port, sample rate, quality mode, channel count — built into the real capture screen, so a silent fallback to narrowband audio is visible immediately as a UI signal rather than discovered later as unexplained poor transcription. On a go decision, the validated capture path was implemented as a native Swift module — on-device wake/stop-word detection, a several-second pre-roll ring buffer so an utterance already underway isn't clipped, and a hold-to-dictate manual fallback for when the sterile field makes voice control impractical.

Outcome

The spike reached a go decision in roughly four to five focused days, with the exact device/OS constraint and a documented fallback plan already in hand before the production capture module's first line was written — the riskiest, least controllable variable in the product resolved on a known timeline instead of discovered mid-build.