How Savory enforces meeting recording consent before it records

The gate that runs before the microphone

Consent is only as real as the code that enforces it. Meeting recording consent, in Savory, is not a checkbox you tick and trust the app to remember. It is a gate, a small piece of logic that runs before the microphone does, on every recording that starts from a calendar event, and it returns a decision the rest of the app has to obey.

The distinction matters. A setting is a stated intention. A gate is a control point that the code cannot route around. When you schedule work from your calendar, the recording does not begin and then check whether it was allowed. It asks first, resolves an answer, and only then does capture start or not start.

The order (decide, then capture) is the whole point, and it is easy to get wrong. A recorder that starts the microphone and then evaluates a rule has already captured the moment it was supposed to protect. Savory resolves the decision first, so a no is a no before a single sample is taken, not an apology issued after the fact.

Everything below is what falls out of that one choice: to make consent a step in the execution path rather than a note in a preferences pane. Once the decision is a real fork in the code, it needs an order of operations, a fallback for uncertainty, and a record of what it decided. Each of those is a section of this post.

How meeting recording consent gets decided

When the gate runs, it does not weigh feelings. It walks a fixed precedence chain and takes the first answer it finds. The order is deterministic, which means the same meeting with the same rules always resolves the same way, and you can reason about why.

There are four rungs, checked top to bottom. A per-meeting override comes first. Then a per-person rule. Then your global default, the answer you have chosen for everything. Then, if nothing above it spoke, the system default that ships with the app.

The per-meeting override sits at the top as a reserved capability. In this version there is no button that sets it and no menu that exposes it. It exists so the machine has a place to put a one-off decision, and it is used internally rather than surfaced as a control. For you, in practice, the meaningful rungs are the per-person rule and your global default.

Precedence is what makes the system legible. A more specific rule beats a more general one, every time, without a tie-breaker you have to guess at. If a person is marked, that beats your default. If nothing more specific applies, your default beats the shipped fallback. First match wins, and the chain stops there.

Determinism is not a technical nicety here, it is what lets consent be trustworthy. A gate that resolved the same inputs differently on different days would be impossible to audit and impossible to rely on. Because the chain is fixed, a decision you disagree with can be traced to exactly one rung and changed at that rung, rather than argued with in the abstract.

One person can decide the whole room

The per-person rule is the part most people will actually use. You can mark a person as never-record, and that mark dominates the entire meeting they are in. One flagged attendee is enough to pull the answer to no, regardless of how many other people are on the invite.

This is deliberate. Consent is not a majority vote. If someone should not be recorded, the fact that six other attendees are fine changes nothing about that one person. The rule that protects them has to outrank the convenience of everyone else, so it does.

There is an honest limit here, and it is worth stating plainly. A per-person rule can only fire when an attendee on the calendar event resolves to a known person. If the meeting has no attendees, or the invite carries only email addresses that do not match anyone Savory knows, the per-person layer has nothing to match against. It falls through, and the decision continues down the chain to your global default.

So the protection is strong where the calendar is populated and specific, and it is quietly absent where the calendar is empty or anonymous. That is not a gap to paper over. It is the boundary of what identity resolution can promise, and naming it is part of being honest about what the gate does.

When in doubt, the gate asks

Any gate that makes a decision can hit a state it did not expect. The question is which way it fails. Savory's gate fails safe, which here means it fails toward asking you rather than toward recording quietly.

If anything in the resolution goes wrong, an error reading a rule, an ambiguous state, a case the logic did not anticipate, the answer resolves to ask. The app surfaces the decision to a human instead of guessing in favor of capture. A recording that should not have started is a worse failure than a prompt you did not need, so the gate is built to prefer the prompt.

There is a sharper version of the same idea for the meeting whose presenter cannot be resolved at all. When the gate cannot establish who is even convening the meeting, it does not shrug and continue. It declines. No identity, no recording. The default under that kind of uncertainty is off, not on.

None of this asks you to trust a claim about intentions. Fail-safe is a property of the code path, not a promise about behavior. The only way the gate can resolve to record is if a rule or a default actually said so, and every other outcome, including every error it can hit, lands on ask or on decline.

This is also why a fresh install behaves the way it does. Out of the box, the system default is ask, so the first calendar event you try to record prompts you before anything is captured. You are not opted into recording by silence. You opt in by answering, and the app remembers the answer only in the ways you can inspect and undo.

A ledger you can read but not quietly rewrite

A decision that leaves no trace is indistinguishable from no decision at all. So every answer the gate resolves is written to a consent audit log. Not a marketing figure, an actual append-only record of what was decided and when.

The log is append-only, which means entries are added and never edited in place. It is tamper-evident, so a quiet after-the-fact rewrite does not go unnoticed. And it is free of personal content by design: it records that a decision happened and how it resolved, without dragging private detail into a file whose whole job is to be auditable. You can open it and read it. You cannot silently revise it.

The same seriousness applies to removing a rule. Deleting a consent rule is gated behind device biometrics, so the act of undoing a protection is not something that can happen with a stray click, or by someone who picked up an unlocked machine. Changing the rules is allowed. Changing them casually is not.

Why keep a log at all, when the app is not sending it anywhere? Because a control you cannot inspect is a control you have to take on faith. If a recording ever started that you did not expect, the log is where you find out which rung decided it and when, without any personal content coming along for the ride. It turns a vague worry into a specific line you can look at.

One boundary to be clear about: the rules and the audit log live on the device. They are local, and they are not synced across your devices. A never-record rule you set on your Mac is a fact about that Mac. If you record from another device, that device carries its own rules and its own log. On-device is the whole posture, and the trade-off that comes with it is that there is no cloud copy quietly doing the remembering for you.

The one door the gate does not guard

Here is the part a less careful description would hide. The consent gate governs meetings you record from a calendar event. It does not govern Quick Record, the ad-hoc capture you start by hand when there is no meeting on the calendar to hang it on.

Quick Record bypasses the gate entirely. There is no attendee list to resolve, no per-person rule to check, no precedence chain to walk, because there is no calendar event underneath it. It is the manual, on-purpose case: you, deciding in the moment to start capturing, with nothing scheduled to reason about.

We could pretend the enforcement is total. It is not, and claiming otherwise would be exactly the kind of overstatement this app is built against. The gate is a real mechanism with a real scope, and the scope is calendar-driven recording. When you reach for Quick Record, the machine steps back and the judgment returns to you, where it already was.

Which is a fair place to leave it. The gate exists to handle the scheduled, semi-automatic case, where a recording might otherwise start on a rhythm you set weeks ago and forgot. The ad-hoc case is already a deliberate act. You can read more about why we keep the human part human in the case against putting a bot in the room.

A default for the meetings that are just two people

Most people do not want a prompt on every single calendar event, and they should not have to choose between constant interruptions and a blanket yes. So the global default is a real dial, not a switch with two positions.

One option narrows the auto-record default to one-on-one meetings only. Turn on record-one-on-one-only, and Savory will auto-record the two-person conversations while leaving the larger meetings to prompt. The reasoning is that a one-on-one is a low-surprise case, where both sides usually already understand what the tool is doing, and the bigger the room, the more a recording deserves an explicit yes.

It is worth seeing how this sits inside the chain from earlier. The one-on-one option shapes your global default, which is the third rung. A per-person never-record rule still outranks it. If you have marked someone, marking them wins even in a one-on-one, because the more specific rule is always checked first. The convenience default only decides the cases the specific rules left open.

That layering is the quiet payoff of building consent as a precedence chain instead of a pile of toggles. You can be permissive by default and still be certain that a single protection you care about is never overridden by a convenience you set months ago. General ease and specific caution coexist because the order between them is fixed.

The part software should not automate

There is one thing the gate deliberately does not do, and the omission is a design position, not a missing feature. Savory does not notify the other people on the call that you are recording. Notify-attendees is off in this version, and the app makes no announcement on your behalf.

That means the gate is one-sided by design. It governs your decision to record, on your device, with your rules. It does not reach across the call and speak for you. Telling the people you are with that you are taking notes is a sentence you say, not a notification the software fires. Removing the bot from the room does not remove your side of that conversation, it just stops a machine from pretending to have had it for you.

It is also worth separating two things that are easy to blur. This entire post is about recording consent, the decision to capture audio at all. That is a different mechanism from the separate opt-in that governs whether a transcript is sent to a cloud model to be summarized. One is about whether the microphone runs. The other is about where the words go afterward. Keeping them distinct is the point, and each is its own explicit choice.

If you want the full picture of what stays on the device and what never leaves it, the privacy page lays it out, and the FAQ answers the questions that come up most. The short version is the one this post has been making the whole way down. Consent is a step in the code, not a line in the copy, and you can read every decision it ever made.