The audio never becomes a file: meeting transcription without recording audio

The file is the liability

Most privacy work is spent protecting the recording: guarding it, encrypting it, deciding who is allowed to open it. The stronger move is to never make one in the first place.

Savory does meeting transcription without recording audio. The sound of a call is captured, turned into text, and released, and the sound itself never becomes a file on your disk. There is a transcript afterward, which is the thing you actually opened the app to get. There is no recording, which is the thing most apps quietly keep whether you wanted it or not.

This is a smaller claim than it sounds and a larger one at the same time. It is smaller because plenty of the app writes to disk, and we will get to exactly what. It is larger because the one thing everyone actually worries about, the raw audio of the room, is the one thing that never lands anywhere it could be found later.

A recording is a liability that outlives its usefulness. You needed the words. You kept the sound. Then the sound sits in a folder, on a server, in a backup, waiting to become the thing someone asks for. The cleanest way to not have that problem is to not have the file, so that is the design Savory starts from and works outward.

What happens to the sound

Here is the whole life of the audio. Savory captures it as raw samples in memory, converts those samples to the format the transcriber expects (16 kHz, mono), hands them to the model, and lets them go. The buffer is reused for the next slice of sound, so the oldest audio is continuously written over by newer audio and, at the end, by nothing at all. Nothing is appended to a file, because no file is ever opened.

On Apple's platforms, the ordinary way to save audio is an object called AVAudioFile. You create one, you write samples into it, you close it, and now there is an .m4a or a .caf sitting on disk. Savory never creates that object. There is no code path that opens a recording file, which means there is no half-written recording to find if the app crashes, no leftover in a temporary directory, and no scratch file that 'just this once' survives a session.

Working in memory is not a trick to save space. It is the point. A file persists by definition, and persistence is exactly the property we did not want the audio to have. Keeping the samples in memory means they age out on their own, overwritten by the next buffer, with no cleanup step that could be skipped and no delete that could quietly fail.

The transcript is produced from a stream that only ever existed as data passing through. By the time a sentence appears in your notes, the sound that produced it is already gone. What you can read afterward is a description of what was said, not the thing itself.

What meeting transcription without recording audio means

Most tools weld two jobs together and call the bundle 'recording.' The first job is turning speech into text, which is the useful part. The second is keeping the audio around after, which is the part nobody actually asked for. They feel like one feature because the same button starts both, but they are not one feature, and they do not carry the same risk.

Meeting transcription without recording audio simply refuses the second job. The transcription runs. The retention does not. You get the artifact you came for, the words, without the artifact you never actually wanted, a sound file of everything anyone in the room said.

There is a fair objection here. Sometimes you want to go back to the tape, to hear a tone or catch a word the transcript got wrong. That is a genuine trade, and it is the one Savory chose against on purpose. The transcript is what you keep, and the cost of never holding a sound file is that there is no sound to replay later.

This design is easy to miss, because the industry default is the exact opposite. A meeting bot joins the call, records the audio to a server, and transcribes from that stored file. The file is the source of truth, and the file persists indefinitely. Savory inverts the order: the transcript is the source of truth, and the audio was never written down at all. If you want the reasoning behind refusing the bot in the first place, that is its own argument.

A property of the build, not a setting

A promise like this is only worth as much as the thing that keeps it true. A setting can be flipped, by you or by a menu you clicked through too fast. A default can quietly change in an update, and nobody notices until the day it matters. So the no-write rule is not a preference you turn on. It is a condition the build itself has to satisfy before it can ship.

There are two guards. The first is a static check that runs in continuous integration, a script called audit-no-audio-write.sh, which scans the source for anything that looks like an audio write path and fails the build if it finds one. If a future change tried to add a recording feature, even by accident, the build would go red before that version could reach anyone.

The second guard is a runtime no-artifact audit inside the app itself, which confirms that no recording artifact was produced while it ran. Belt and suspenders: one guard reads the code before it ships, the other watches the running program after. Together they make 'the audio is never saved' a fact about how Savory is constructed, not a sentence on a marketing page.

That distinction carries more weight than it first appears. Features get toggled, forgotten, and re-enabled by the next person who touches them. Architecture is harder to walk back. When a guarantee lives in the build pipeline, breaking it is loud instead of silent, and loud is what you want from a rule this important.

The persistence axis

It helps to separate three questions that usually get mashed into one word, 'private'. Where does the audio travel? Where is it turned into text? And does it stick around afterward? Those are three different axes, and they have three different answers.

The travel question is about the network. Savory captures your call directly on your own machine instead of sending a bot into the meeting, so the audio is never transmitted anywhere during the call. The inference question is about compute. The words are produced by a model running on the device itself, not in a datacenter. Both of those matter, and both are covered in their own posts.

This post is about the third axis, persistence. Even audio that never crossed a network and was transcribed locally could still be written to your own disk and left sitting there for later. That is the file most people forget to worry about, precisely because it feels safe on your own machine, and it is the one Savory refuses to create.

The payoff is blunt. A recording that never exists cannot be leaked in a breach, cannot be subpoenaed, cannot be held for ransom, and cannot be recovered from a drive months later by someone who should not have it. You cannot lose what you never kept, and you cannot be asked to hand over what was never written down. Absence turns out to be the strongest form of protection, because there is simply nothing there to guard, encrypt, or defend.

What does get written down

Now the honest part, because a headline that flatly said 'nothing touches disk' would be a lie. Plenty touches disk. The transcript itself is saved, along with summaries, action items, the transcription model weights Savory downloads once and reuses, and ordinary diagnostic logs. All of that lives in a local database on your machine.

What is guaranteed never to become a file is the raw audio, and only the raw audio. The derived text, the words you can actually read, is stored so you can search it, revisit it, and build on it later. A notes app that forgot everything the moment you closed it would not be worth using. The point was never to keep nothing. It was to keep the text and let go of the sound.

That local database of derived text is protected at rest by the disk encryption your operating system already provides: FileVault on macOS and data protection on iOS. Savory does not yet add its own application-level encryption on top of that database. That is a deliberate, stated position rather than a hidden one, and it is worth knowing exactly where the line currently sits so you can decide for yourself.

One more distinction, because it is the easy one to blur. If you turn on AI summaries, the transcript text, not the audio, is sent to a cloud model to be summarized, and that path is opt-in and scrubbed before it goes. The raw audio is the thing under the strong guarantee described here. Text you choose to have summarized is a separate, clearly labeled decision, and you can see where each piece of data goes on the privacy page.

Both of your machines

The guarantee is not a macOS-only footnote. The in-memory pipeline works the same way on both platforms. Audio is captured, converted, transcribed, and released, whether you are recording at your desk on a Mac or in your hand on an iPhone. Neither device writes the sound to a file, and neither one keeps a copy for later.

That symmetry is deliberate. The whole idea falls apart if it holds on one device and quietly breaks on the other, because then you would have to remember which machine to trust with what. A rule that is only true sometimes is not really a rule. Here it is the same rule in the same place everywhere.

Other parts of Savory do differ by platform, and we say so plainly where it matters. The handling of the audio itself is not one of those places. On a Mac and on an iPhone alike, the raw sound is treated the same way and saved the same amount, which is to say not at all.

Savory is a pre-launch product, built for recent operating systems, and still early in its life. The persistence guarantee, though, is one of the parts we were least willing to leave soft, which is exactly why it is wired into the build instead of written on a slide and hoped for.

Designing for absence

There is a particular discipline in building a feature whose entire job is to leave nothing behind. It does not demo well. There is no file to point at, no playback button, no folder to open and say 'see, it worked.' The evidence is an absence, and an absence is a hard thing to show off in a screenshot.

You will not find a saved-audio tab in Savory, because there is no audio file to list. What you get instead is the transcript, searchable and yours, sitting where the audio would have been. The missing sound file is not a gap someone forgot to fill. It is the whole design, working quietly every time you record.

But absence is exactly what you want from the audio of a private conversation. The transcript stays because you need it. The sound goes because you do not. That is what recording looks like in Savory: it listens, it writes down the words, and it keeps no tape of the room, no clip in a folder, no copy on a server somewhere.

If that is the trade you would make for yourself, it is already the one Savory makes for you, with nothing extra to configure. When your next call is over, you will have the notes you needed and one less file you will ever have to worry about.