Building AI Software That Thinks in Pipelines

Most AI tools are black boxes. You put something in, you get something out, and you have no idea what happened in between. When it works, fine. When it breaks, you are stuck.

floure takes a different approach. It is built as a pipeline - a sequence of independent stages, each doing one thing and passing the result to the next.

How the pipeline is structured

Audio goes in. Text comes out. Between those two points, five stages run in sequence:

1. Capture - Record audio from your microphone at 16kHz
2. Detect - Voice Activity Detector identifies speech boundaries
3. Transcribe - Whisper.cpp converts speech to text on your GPU or CPU
4. Refine - Optional LLM pass removes filler words and cleans formatting
5. Output - Insert text into your active window

Each stage is independent. You can modify, replace, or debug any stage without touching the rest.

What this enables

Debugging. If transcription quality drops, you inspect each stage. Check the audio capture. Check the VAD boundaries. Check the confidence scores. The problem reveals itself.

Flexibility. Want to swap Whisper.cpp for Faster-Whisper? Replace stage 3. Want to add punctuation restoration? Insert a new stage. The pipeline does not care what each stage does internally, as long as the input and output formats match.

Testing. Each stage is tested in isolation. The VAD is tested with recordings from 15 microphones. The transcription engine is validated against 200 hours of labeled speech. Failures in one stage do not mask failures in another.

Transparency. floure exposes intermediate output from every stage in debug mode. Raw audio waveforms. VAD decision boundaries. Confidence scores per token. The unrefined transcription before cleanup.

Why Rust

The pipeline runs in Rust. The main reason is concurrency. Audio capture, VAD detection, and transcription all run on separate threads. They share data through lock-free channels. Rust's type system guarantees no data races at compile time.

Audio buffers are shared through ownership. One thread writes, others read, and the compiler ensures nobody steps on anyone else's toes. No mutexes. No deadlocks. No runtime surprises.

Memory usage sits around 50MB at idle and peaks at 800MB during transcription with the large-v3 model.

The result

floure is a 30MB application that runs a full speech-to-text pipeline on your machine. No cloud servers. No API keys. No data leaving your computer. Each stage is visible, testable, and replaceable. If something goes wrong, you can open the hood and see exactly why.