Record lectures on Mac without them leaking into work

A filter is a wall you can walk around

A filter is a wall you can walk around. Most apps that let you record lectures on Mac keep class and work in the same pile and draw the line between them with a query: show me the rows where the mode is student. That line holds right up until the one time a query forgets to draw it.

Savory's Student mode makes a different choice. A lecture does not sit in the meetings table wearing a student label. It lives in its own tables, owned by you, with no shared mode column for a stray query to misread. The wall is not a rule the code agrees to honor. It is the shape of the data.

That single choice is the whole post. State it once and everything else falls out of it: what a lecture can and cannot become, where it can and cannot travel, and why a student can keep an internship and a seminar in the same app without the two ever touching. The rest of this is just following the choice to its consequences.

Isolation by table ownership

The usual way to keep two kinds of thing apart inside one app is a discriminator column. One meetings table, a mode field, and a WHERE clause on every read that filters to the half you want. It is cheap to build and it works most of the time. Most of the time is exactly the problem.

Every feature that reads meetings now has to remember the filter. Search has to remember it. Export has to remember it. The action-item extractor has to remember it. Forget it in one place, one time, in one release, and a lecture surfaces in a work search, or a work meeting turns up in a class list. The wall was only ever a habit that every query privately promised to keep, and a habit is not a guarantee.

Table ownership removes the promise. Lectures live in user-owned tables that the meetings code does not read from and has no way to write to. There is no mode column to misread, because there is no shared row to carry one. A query against your work meetings cannot return a lecture, not because it filters lectures out, but because it is not looking at the same data at all. Correctness stops depending on every future author remembering a convention.

You can feel the difference the first time you go looking for something. When you search your meetings, you are searching a table that has never held a lecture, so there is no chance of a class transcript bubbling up next to a client call. When you open your coursework, you are in a space the meetings code cannot see. The two never negotiate over a shared row, because there is no shared row to negotiate over.

This is the same instinct behind Savory's other structural decisions. Just as we argued that notes should orbit people instead of sitting in a chronological pile, we think the boundary between school and work belongs in where the data lives, not in a condition the code has to keep restating. A boundary you can see in the schema is one a bug cannot quietly erase.

What a lecture structurally cannot do

The clearest way to describe a wall is by what it stops. In Savory, a lecture cannot become an action item. Not because a rule forbids it, but because the coursework extraction path holds no action-item writer at all. The code that reads a lecture has no hand that could reach the action-items table, so there is no accident to guard against.

A lecture cannot become a shared meeting either. It is excluded from the Meetings list and from meeting search, so there is no surface where a seminar could be mistaken for a standup and pulled into your working life. The absence is deliberate. A capability that does not exist cannot be triggered by a bad tap, a bad query, or a bad merge.

And a lecture cannot cross into your work calendar. The two modes are separated at the data layer, so a class session is never a candidate to appear beside your one-on-ones. This is privacy by subtraction, the same principle that runs through the rest of the product: the leak you never have to defend against is the one the architecture made impossible in the first place.

There is always a temptation, when you build a wall like this, to cut a door in it: a share button that promotes a lecture into a meeting, an export that flattens everything into one tidy list. We did not, and the reason is the same reason the wall works. Every door is a place the wall can fail. The moment a single code path can move a lecture onto the meetings side, the guarantee weakens from cannot to should not, and should not is the language that bugs are written in.

What it is like to record lectures on Mac

With the wall in place, the day-to-day is quiet and unremarkable, which is the point. You set up your courses for the term, each with its code, its color, and its schedule. When a class starts you record the lecture, and it lands under the right course, transcribed on your Mac by the same engine that handles meetings. The on-device transcription does not care whether the room is a lecture hall or a conference room.

On a Mac, that capture can pull two streams at once: the room through the microphone and the system audio, so a lecture that includes a shared clip or a narrated slide is not lost to a laptop speaker. On iPhone and iPad the capture is mic-only. It records the room or the professor's microphone, which is enough for a lecture but is a narrower surface than the Mac's dual-stream capture. Both can record a lecture. They do not record it the same way, and it is worth knowing which device you are holding.

The transcript then sits beside the session it came from, and the coursework the class mentioned (a problem set, a reading, a due date read aloud) can be pulled out and tracked next to it. The unit you actually work in is the course, not a flat timeline. A term is a set of courses, a course is a set of sessions, and a session is where the transcript and its coursework live together, under a heading that means something to you.

None of this asks you to think about tables. You think about the class and the problem set due Thursday. The structure does its work underneath, filing the transcript where it belongs and keeping it there, so the mental model you carry is the honest one: this is my coursework, and it is not tangled up with my job. The database is allowed to be complicated so that the semester does not have to be.

The permission gate is a checkbox, and it says so

Recording a class touches other people, and the rules differ by school and by place. Savory does not pretend to know those rules. What it does is make the decision deliberate: each course carries a per-course instructor-permission self-attestation, a confirmation that you have permission, which you make once for that course before recording.

Be clear about what that gate is and is not. It is a checkbox that records your own attestation. It is not jurisdiction-aware, it does not encode per-state consent law, and it cannot tell you whether your professor is comfortable with it. It is a prompt that makes you stop and answer honestly, once per course, rather than drifting into ambient capture without a thought. You start every recording yourself, once you have answered.

That is a smaller promise than a compliance engine, and we would rather make the smaller promise truthfully than dress a checkbox up as something it is not. The responsibility to ask stays with you. The app's only job here is to make sure the question is in front of you before anything is captured, not to answer it on your behalf.

Local capture, cloud coursework

Capture and transcription happen on the device. The audio is never written to disk, and the transcript is produced locally, the same way it is for a meeting. We have made the architecture case for keeping transcription off the server at length elsewhere, so the short version will do here: your voice, and your professor's, never need to reach a data center to become text. Because Savory does not sync to a server, the lecture stays on your device and goes nowhere.

There is one honest seam, and it happens to matter most to a student. Turning a lecture transcript into structured coursework (reading the assignments and the deadlines out of what was said) runs through the same cloud summary path that meetings use. It is opt-in, and it runs with your own key, but it is not offline. The transcript is local. The AI reading of that transcript into a list of deadlines is not.

So the line sits here: the lecture, the audio, and the transcript stay on your machine, and the one step that leaves is the summary, and only when you ask for it. If you never run one, nothing about the lecture goes anywhere. If you do, it is the transcript text that gets processed, with a key you brought yourself. That is a narrower claim than end-to-end offline, and it is the true one.

This is the seam students should weigh most, because coursework is usually the reason to bother in the first place. If offline is a hard requirement for you, the transcript alone still gives you the full text of the lecture on your own machine, and you can read it, search it within the course, and keep it there indefinitely without ever running a summary. The cloud step buys you structure, a tidy list of what is due and when, in exchange for that one round trip. It is your call, lecture by lecture, whether the trade is worth making.

Where the wall stops

A boundary is only trustworthy if you know exactly where it ends, so here are the edges of this one in v1. You cannot overlay your personal or work calendar onto the class schedule. The class schedule stands on its own, built from your courses, and merging another calendar into it is deliberately not wired yet. If you were hoping to see your shift, your seminar, and your dentist in one grid, that is not what this is.

The schedule is also literal about time. This version does not model holidays or term rollover, so a reading week or the end of a semester is something you account for, not something the app infers for you. And at-rest encryption is not yet Savory's own layer: the lecture data leans on FileVault on the Mac and iOS data protection on the phone, rather than a separate encrypted store that ships with the app. That is a real distinction, and worth stating plainly rather than implying more.

One last piece of context, since honesty about a wall means honesty about the building. This is pre-launch. Student mode is real, and the containment described here is genuinely how it is built, but it is not yet something you install from a distributed App Store build. We would rather describe the wall accurately before the doors open than oversell it once they do.

Why containment is the feature

It is tempting to sell lecture capture on the transcript alone: catch every word, never miss a definition, search the whole term. That is table stakes, and plenty of tools clear it. The thing that is genuinely hard to add later, and easy to get wrong, is the guarantee that a lecture will never quietly become part of your working life.

You get that guarantee here by construction, not by discipline. Lectures live in their own tables, they hold no path to an action item, they stay out of meeting search, and they never reach your work calendar. Not because a filter is doing its job today, but because there is nothing left for a filter to fail at tomorrow. The wall is made of where the data lives, and that is the only kind of wall that does not erode.

That is the trade Savory keeps making across the app, and it is the same one behind on-device transcription and people-first organization: pay the harder engineering cost up front so that the user is never the one holding the guarantee. A student should not have to trust that a filter was applied correctly on every screen of every future update. A student should be able to trust the shape of the data, which does not change when the next feature ships.

If you keep school and work in the same head, you should be able to keep them in the same app without keeping them in the same pile. Student mode is where that starts.