Approvals and safety

Automation is only useful if you can trust it. Snoze applies the same safety model to everything that acts on your behalf — buttons, scheduled actions, and the assistant.

What pauses for approval

Operations are classified by stakes. Routine work — creating a record, updating a field, drafting a page — runs immediately. The same scale applies in connected apps: reading a pull request or posting a comment is routine, while consequential external changes wait for you. High-stakes work pauses and asks first:

• deleting items or records in bulk
• changes that touch many records at once
• consequential changes outside the workspace — committing files, merging pull requests, sending or publishing on your behalf

When something pauses, you see exactly what’s about to happen and approve or decline it. Approving clears that batch of related work; the next high-stakes operation asks again.

Everything is attributed and logged

Every automated change is recorded: which action or assistant conversation made it, when, and with what inputs and outputs. Action runs have a full history you can audit, and assistant edits appear in the workspace like a teammate’s — visible in real time and undoable.

Permissions still apply

Nothing automated escapes the permission model. An action runs with the authority of the person who triggered it; the assistant works with the permissions of the person asking. If you can’t delete a database, neither can anything acting for you — Permissions explained covers the model.