Most of what LumaVista does happens inside your account. Research, notes, documents, the knowledge graph — all of it stays within a boundary you control. Automations change that. A workflow that posts to Slack, sends an email, or writes to your calendar reaches outside, and the people on the other end can’t tell whether you wrote it or a schedule did.

So there is one rule governing every one of those actions:

An automation may contact the outside world only if a person saw what it was going to do.

This page explains how that rule is enforced, the three choices you get when an automation asks permission, and — plainly — what each one costs you. If you are setting up scheduled automations, read the section on standing releases before you turn one on.

What counts as reaching outside

Every action an automation can take is classified as one of three kinds:

Kind	Meaning	Needs approval
Read	Fetches something. Nobody learns anything new.	No
Write	Changes something inside your own account.	No
Send	Someone outside your account now sees something they didn’t before.	Yes

The test for send is not “does this change data” — it’s “does a third party now see something they did not see before?” Posting a Slack message is a send. Sending mail is a send. Creating a calendar event is a send, because a calendar is a surface other people can look at.

Two details matter more than they look:

Anything unclassified is treated as a send. If an action doesn’t declare what it does, or declares something we don’t recognise, it is gated. Getting the classification wrong in the cautious direction means an automation pauses and asks. Getting it wrong in the other direction means something leaves without you. We chose the direction that fails safely.

Read failures and send failures are handled oppositely, on purpose. If we can’t read your settings, we show you stale information — annoying, recoverable. If we can’t confirm you approved a send, we don’t send. You can always resend a message. You cannot unsend one.

Two switches, both off

Before any send can happen unattended, two independent permissions must both be on:

A per-step release — “this particular step of this particular automation may send.”
An account-wide release — “my account permits unattended sending at all.”

Both default to off, and they are combined with AND, not OR. One without the other still pauses for approval. The account-wide switch exists so that you have a single control that governs everything, no matter how many automations you’ve built or how long ago you built them.

The per-step release cannot be set by writing it into an automation’s definition. Automations can be authored by you, generated from a template, or assembled by an AI agent — and an agent that could grant itself sending permission would make the whole system decorative. The permission is stripped from every authoring path. It can only be set through a deliberate action in the interface, by you.

The three choices

When an automation reaches a gated send, it pauses and shows you exactly what it intends to do. You have three options.

Approve once

The default, and the safest. You approve the specific thing in front of you, it happens, and the automation goes back to asking next time.

What you approve is pinned. The content is resolved before you see it and stored as-is, so what ships is byte-for-byte what you read. This matters more than it sounds: templates and AI-assembled content are re-resolved every run, so an approval that merely said “yes, proceed” would authorise a re-run that produces something different. It doesn’t work that way here — approving pins the exact payload.

A declined approval is a decline, not a “not yet.” The step fails and the run reports the failure. It does not quietly re-ask forever.

Allow the next run

For scheduled automations, approving every night is impractical, so you can authorise the next run in advance.

This is deliberately not “approve whatever happens next.” You cannot approve content that doesn’t exist yet — that would be exactly the thing the pinning rule prevents. Instead you approve a bounded envelope: a description of what next run is allowed to be.

For a calendar automation, the envelope is roughly: at most this many events, only in the calendar LumaVista created, only for dates in the next 48 hours. When the run happens, the actual content is checked against that envelope. If it fits, it proceeds. If it exceeds the envelope in any way — more events than allowed, a different calendar, a date outside the window — the automation pauses and asks you, exactly as if you’d never granted anything.

Three properties bound it:

Single use. It authorises one send. The following run asks again.
It expires. 24 hours by default, and you choose.
The expiry is checked when the send actually happens, not when the run was scheduled. This matters because scheduled automations don’t always run when you’d expect — if your account is encrypted and you’re offline, a run waits until you next connect. A grant that expired while you were away is expired, and a late-firing run will pause and ask rather than act on lapsed permission.

You can see every active grant, and revoke any of them, in Settings → Chief of Staff.

Always allow

The step sends without asking, every time, until you revoke it or the step changes.

Be clear-eyed about this one: it is the broadest of the three, and it is not envelope-checked. “Approve once” pins one payload. “Allow the next run” bounds one run. “Always allow” releases whatever that step produces, indefinitely. If the step’s content is generated — by a template, by an AI agent — you are releasing future content you haven’t read.

Two things limit it:

It’s bound to the step as configured when you approved it. Change what the step does and the release drops automatically. You’ll be asked again the next time it runs. This is intentional: permission you granted for one thing shouldn’t survive that thing being rewritten.
It’s per-step, not per-automation. Releasing one step doesn’t release the others.

The offer appears at the approval prompt rather than buried in settings, and that’s deliberate — the moment you’re reading a concrete example of what a step produces is the best-informed moment you’ll ever have to decide whether that shape is always acceptable. Better than deciding it blind in a configuration screen.

Because the account-wide switch is separate, turning on “always allow” for a step while unattended sending is off for your account does nothing on its own. You’ll be asked to enable the account-wide permission too, as its own decision, because its scope is much wider than the step you were looking at.

How this interacts with encryption

If your account is encrypted, LumaVista cannot read your data without a key that only your devices hold. That is a deliberate constraint and it has a consequence for automations: an automation that runs while you’re offline can’t read your data either — unless you’ve separately enabled background execution.

Background execution and send approvals are two different consents, and it’s worth keeping them apart in your head:

Background execution determines whether a scheduled automation can open your data at all while you’re away. It works by sealing your key so that it can be used for your scheduled runs, without LumaVista ever holding a copy it could use on its own. There is no key escrow — no recovery path, by design.
Send approvals determine whether that automation may then contact the outside world.

An approval grant contains no key material. Granting “allow the next run” does not weaken your encryption, expand what LumaVista can decrypt, or create a copy of anything. It is an authorisation record and nothing else.

What it does change is operational, and here is the honest version: for the duration of that grant, there exists a path by which your data reaches a third party without a person in the loop. Bounded by the envelope, limited to a single use, and expiring — but not zero. That is the trade you are making, and it’s a reasonable one to make deliberately. It is not a reasonable one to make by accident, which is why the default is off and the grant is narrow.

Rotating your encryption key, or deleting your account, revokes every grant along with everything else.

What we can and cannot promise

We can promise that no classified send leaves without one of the three approvals above; that an approve-once payload is the exact content you read; that a grant is checked against its envelope and its expiry at the moment of sending; that a step’s release drops when the step changes; and that every gated decision is recorded.

We cannot promise that an “always allow” step will only ever produce content you’d have approved — that is precisely what you set aside when you chose it. We cannot promise that a third party you’ve authorised us to contact will handle what they receive the way you’d like; once something is sent, it is subject to their retention and access, not ours. And we cannot recover a send. There is no unsend.

Where to look

Settings → Chief of Staff — the account-wide unattended-sending switch, active one-run grants with their expiry times, and every step currently set to “always allow.”
The automation’s run history — every gated decision, what was approved, and by which of the three routes.

Related reading: How Your Data Is Protected for the encryption model, and Guiding Your Research: Human-in-the-Loop for approvals during research runs, which are a separate system with a different purpose.