Skip to content

Speech intelligence, applied research

Biona HQ

A speech intelligence practice building edge native systems for teams that cannot send audio to a hosted API.

Role
Founder
Organisation
Biona HQ
Period
2023 to present
Status
Active
Domain
Speech intelligence, applied research

01

Overview

Biona HQ is the studio the rest of this work runs through. It takes on speech and language problems for organisations in regulated settings, where the data cannot leave the building and the usual hosted approach is not available.

The remit is deliberately narrow. Speech recognition, speaker and turn structure, and turning spoken interaction into something a system can act on, delivered as working software rather than a report.

02

Problem

Speech is the interface most organisations already have and the one they capture least well. Meetings, consultations, support calls, and field work all generate speech, and most of it becomes either nothing or a recording nobody opens.

The teams with the most to gain are usually the ones least able to adopt the standard tooling. Healthcare, finance, and public sector work carry constraints that rule out streaming audio to a third party, so they are left choosing between a compliance problem and no automation at all.

03

Solution

The studio builds on a shared foundation: a local speech pipeline that can be deployed inside a client environment, an evaluation harness that measures quality on that client own data rather than a public benchmark, and a delivery model that leaves the client owning the system.

Every engagement starts by defining what failure looks like before anything is built. If a project cannot state how it would know the system is wrong, the evaluation is designed first and the model second.

04

Technical architecture

  1. 01

    Deployment target

    Pipelines are packaged to run on device or inside a client network boundary, with no outbound dependency at inference time.

  2. 02

    Speech layer

    Quantised recognition models with timestamped output, segmentation, and domain vocabulary handling tuned per engagement.

  3. 03

    Understanding layer

    Extraction into typed schemas defined with the client, so the output is data their existing systems can consume rather than free text.

  4. 04

    Evaluation layer

    Per engagement test sets drawn from real recordings, with grounding and error analysis reported alongside accuracy.

  5. 05

    Handover

    Documentation, evaluation tooling, and deployment scripts transfer with the system so the client can maintain and retrain it.

05

Technologies

Speech

  • Whisper
  • ONNX Runtime
  • CTranslate2
  • PyTorch

Serving

  • Python
  • FastAPI
  • Docker

Infrastructure

  • AWS
  • Terraform
  • GitHub Actions

Evaluation

  • Word error rate analysis
  • Grounding metrics
  • Human review loops

06

Challenges

  • Benchmarks do not survive contact with real audio

    A model that performs well on clean read speech degrades sharply on a real recording with crosstalk, accents, and a room. Every engagement needed its own test set built from the client actual recordings before any accuracy claim meant anything.

  • Selling restraint

    The commercially easy answer is to promise a system that does everything. The useful answer is a narrow system that does one thing reliably and says so when it cannot. Scoping conversations are a large part of the work.

  • Maintaining research depth alongside delivery

    Client work rewards shipping, research rewards patience. Keeping a separate stream of open experimentation was the only way to stop delivery pressure from quietly ending the research.

07

Outcomes

  • A reusable local speech foundation now underpinning multiple products, including Nora Health
  • Engagements delivered inside client environments with no audio leaving the network boundary
  • Evaluation treated as a deliverable, so clients can verify quality after handover

08

Key learnings

  • A studio scales on shared infrastructure, not on hours. The parts worth building twice are the evaluation harness and the deployment path.
  • Clients rarely need state of the art. They need a system whose failure modes are known and documented.
  • Constraints that look like obstacles are often the differentiator. Edge deployment was the reason for winning the work, not a compromise on it.

Contact

If you are working on something where being wrong matters, I would like to hear about it.

I am open to consulting engagements, research collaborations, and conversations that do not have a clear outcome yet.