Privacy claims are easy to make. Architecture is harder to fake. This post describes exactly how audio moves through Verity — from microphone to text on your screen — with enough specificity that you can evaluate the design yourself. No vague assurances, no marketing language. Just the pipeline.
If you want the short version: your audio is never written to disk and never used for training — it's transcribed on infrastructure we operate ourselves, never handed to a third-party AI API provider, and discarded immediately after transcription. If you want to understand why, read on.
The audio pipeline, end to end
Here's the full flow before we go layer by layer:
Microphone → local capture → on-device voice-activity detection → compressed audio encoding → encrypted transport → Verity STT → raw transcript → AI polish → AES-256-GCM encryption → encrypted storage
Audio exists as raw uncompressed samples only in the first three stages, all of which run locally on your machine. By the time anything leaves your device it is already a compressed binary stream on an encrypted connection. From there it is transcribed on Verity-operated infrastructure — never a third-party AI provider — and discarded immediately afterwards.
Stage 1: Local capture and voice activity detection
Audio capture negotiates whatever sample format your hardware provides and resamples to a fixed 16kHz before any further processing, so the pipeline behaves identically across wildly different microphones.
Before any audio leaves your machine it passes through voice activity detection. The detector scores each short chunk — tens of milliseconds at a time — for whether it contains speech, and anything below the threshold is dropped outright. Silence and background noise are never sent anywhere.
The voice-activity detector ships inside Verity and runs as a local binary. There is no cloud call, no remote model inference, and no data transmission at this stage — it runs entirely on your CPU.
Speech-containing chunks are then compressed with a codec chosen for low bitrate and good speech quality — small enough to keep transport fast, faithful enough that recognition accuracy is unaffected.
Stage 2: Transmission to the orchestrator
The compressed binary stream is sent to Verity's orchestrator over a TLS-encrypted connection. The audio travels as raw binary rather than base64 or any other expansion format, so nothing is inflated in transit.
Before sending audio, the client sends a short configuration message specifying the transcription mode, active languages, and any vocabulary hints, so the server can route the request appropriately.
The orchestrator receives the binary stream and reassembles it server-side. This is the point where the audio exists outside your machine for the first time. It is held only for the duration of processing — never written to permanent storage, never logged, never retained after transcription completes.
Stage 3: STT processing
Verity runs speech-to-text on its own infrastructure — models we host, on compute we provision. The STT layer uses multiple model profiles with automatic failover for reliability. Audio is not permanently stored, not logged, and not used for model training.
Verity supports 20 languages. The models underneath recognise a good deal more, but 20 is the set we test and commit to, so 20 is what we advertise — if your language is on the list it has been evaluated, not merely accepted by a model that will attempt anything you give it.
Requests are routed by detected language, and the routing layer fails over on its own: if one path starts erroring or timing out, traffic moves to a healthy one without your session noticing. That failover state lives in memory only — no audio is ever buffered or parked while a component recovers, because holding audio to retry it would break the zero-retention guarantee this whole design exists to keep.
After transcription completes, audio is discarded. It is not held for retry, not kept for debugging, and not archived.
Stage 4: LLM polish
The raw transcript text (not audio) goes through an LLM polish step. This corrects punctuation, handles register for the active persona (tightening prose for formal, stripping only filler words for minimal, etc.), and cleans up STT artifacts.
The LLM step is a text-in, text-out operation — it receives only the raw transcript text, not your audio, session metadata, or account information. The polish model runs on Verity-operated infrastructure alongside STT.
Stage 5: Encryption and storage
The polished transcript is encrypted before it touches our database. Encryption uses AES-256-GCM with a per-user key derived via HKDF-SHA256 from a master key material. Each user's transcripts are encrypted under a key unique to that user — we cannot read your transcripts without your key, and a compromise of one user's key does not affect any other user.
The ciphertext and an identifier linking the transcript back to its session are written to our database. The plaintext is never logged, never written to temporary files, and is not accessible to Verity engineers without a key that is not stored alongside the data.
What is never collected
To be explicit about the negative space:
- No audio recordings. We do not save your audio. We do not have an audio archive. There is no object storage bucket with your voice.
- No voice prints or speaker models. We do not build a model of how you speak. Each transcription is processed independently with no memory of previous sessions.
- No training data extraction. Your audio and transcripts are not used to train or fine-tune any model.
- No behavioral profiles from dictation. We do not analyze vocabulary patterns, topic distribution, or speaking style across sessions to build a profile of your interests or identity.
- Zero audio retention. Audio is processed on Verity-operated servers and discarded immediately after transcription — never stored, never sent to a third-party AI provider, never used for model training.
Transparent processing and accountability
When a privacy policy says "we may share data with third-party service providers," it is nearly impossible to evaluate the actual risk. The vagueness is the problem.
Verity addresses this concern by publishing specifics: speech-to-text and AI polish run on infrastructure we provision and control, with audio discarded immediately after transcription and no third-party AI API in the path. The underlying compute is rented from AWS — they supply the servers, not the software, and do not access data independently of us. We publish exactly how audio flows through the pipeline, and what our retention posture is at every stage. No external service receives any audio or transcript data.
GDPR compliance architecture
Verity's pipeline is designed with GDPR's data minimization principle as a constraint, not an afterthought. Concretely:
- Data minimization. Audio is processed and discarded. The only personal data retained is the encrypted transcript text, which is the minimum necessary for the product to function.
- Zero-retention processing. Audio is processed on Verity-operated infrastructure and discarded immediately after transcription. Keeping inference in-house removes the AI-subprocessor category from the risk surface entirely.
- Right to erasure. Account deletion triggers deletion of all encrypted transcript records and key material. After deletion, there is no path to recover transcript content — the ciphertext is orphaned.
- Data residency. Verity's servers are in the United States. Transfers from the EU/EEA and UK rely on the EU Commission Standard Contractual Clauses, and the full sub-processor list is in our privacy policy. We would rather say plainly where your data is today than imply otherwise.
Where the models actually run
Speech-to-text and AI polish both run on infrastructure Verity provisions and operates. The models are open-weight releases that we host ourselves — we download the weights and serve them from our own inference servers. That distinction matters: running a model that some lab published is not the same as calling that lab's API.
The compute underneath is rented from AWS, which is the honest way to put it — we do not own datacenters. AWS supplies servers, storage, and networking; it does not run the models, and it does not access your data independently of us. That is a meaningfully different trust boundary from handing audio to an AI vendor whose business model depends on data.
On desktop, Verity also supports a local processing mode — speech recognition runs entirely on your machine, with no audio leaving your device at all. This is opt-in and best suited for users who need fully offline operation or have strict data residency requirements.
Evaluating this yourself
We encourage scrutiny. The privacy features page details our data practices. The privacy policy is written in plain language, not legalese designed to obscure. And our trust page covers the technical architecture in additional detail.
If you're a security engineer evaluating Verity for a regulated environment, we're happy to answer questions about our security program or discuss specific compliance requirements. The point of publishing this level of detail is to enable that conversation, not to avoid it. For a platform-specific view, see how this compares to built-in dictation on iPhone and Windows.