Privacy Policy

What Operating Studio collects, what it does with it, who else sees it, and how long it is kept. Written for the product as it actually works, not as we would like it to sound.

Last updated 18 August 2026

What this covers

This policy covers operating.studio, the Operating Studio application served at your Company’s subdomain, the private agreement pages we send to a Company’s signer, and the connections a Company can make to Google Workspace, Slack, and a transcription provider.

Operating Studio is a tool an organization runs. For the operational data inside a Company, that Company decides what goes in and who may see it; we process it on the Company’s behalf. For the account data that identifies you and for what you send us through the public request form, we decide the purposes described here.

What we collect

Identity, from Google sign-in

Google is the only way to sign in. Operating Studio requests only the standard OpenID scopes — openid, email, and profile — which give us your name, email address, profile picture, and Google account identifier. We use them to identify you, to match you to the Company memberships an administrator has authorized for your email, and to attribute the work you do. We never receive or store a password.

Your Company’s operational data

Workflow definitions, Projects, Tasks and their field values, Runs and the evidence behind them, human approvals, Artifacts and their versions, and an append-only activity history of who did what and when. Whatever your Company chooses to put into a Project or Task is stored as part of that operational record.

Data from connections your Company makes

Where a Company connects Google Workspace, Slack, or a transcription provider, we receive the data described in those sections below — documents Operating Studio created or that a user explicitly attached, Slack workspace and channel identifiers, and meeting transcripts and their metadata.

Agreement and billing information

For a Company we are engaging or serving: the names and email addresses of the person authorized to accept the agreement and the person who receives invoices, the commercial terms of the engagement, the record of the agreement being sent, viewed, and accepted, and the identifiers and payment state of each invoice. This is described in full under agreements, acceptance, and billing below.

Access requests from this website

The request form on the home page collects the email address you would sign in with, optionally a company name and a note. Submissions are written to our hosting provider’s server logs and may be relayed to a channel in our own Slack workspace so a person sees them. They are used only to reply to you about access.

Technical logs

Our hosting and database providers record ordinary request data — IP address, user agent, requested path, timestamps, and errors — which we use to keep the service running, to debug it, and to investigate abuse.

Analytics

We use Google Analytics on this site and in the application to understand visits, sessions, the pages people use, approximate location, and browser and device information. We use those reports to understand how Operating Studio is used and improve the service, not to advertise to you.

Cookies

Operating Studio sets cookies needed to keep you signed in and to keep requests secure. Google Analytics also sets first-party cookies, including _ga and a property-specific _ga_* cookie, to distinguish visitors and sessions. We do not sell or share personal information for cross-context behavioural advertising.

Google user data and Limited Use

Operating Studio’s use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of information received from Google Workspace APIs will adhere to the Google User Data Policy, including the Limited Use requirements.

The scopes we request

openid, email, profile — to sign you in and identify you. Nothing more.
https://www.googleapis.com/auth/drive.file — requested only when a Company administrator connects Google Workspace, and the only Drive-family scope we ask for. It is per-file access: it lets Operating Studio create files in the Shared Drive folder your Company designates, and read or update only the files Operating Studio itself created, or that a user explicitly picked and attached.

We deliberately do not request the broad drive or documents scopes. Operating Studio cannot list, browse, search, or read the rest of your Drive, including files merely shared with the connected account. That is a real trade-off we accepted rather than ask for more access than the product needs.

What we do with it

Google user data is used for one thing: providing the features you can see in Operating Studio’s own interface. Concretely, publishing an approved Artifact as a Google Doc into your Company’s destination folder, keeping that document updated when a corrected version is approved, and reading a document a user explicitly attached to a Task so a Workflow can work from it. Each of those actions is visible in the activity record for the Project that caused it.

What we will not do with it

We do not sell Google user data, and we do not transfer it to advertising platforms, data brokers, or information resellers.
We do not use Google user data to serve advertising of any kind, including retargeting, personalized, or interest-based advertising, and we do not use it to assess credit-worthiness or for lending.
We do not use Google user data to create, train, or improve generalized or non-personalized artificial intelligence or machine learning models. Where Operating Studio sends content to a model to produce an output you asked for, it is to power that user-facing feature only — see AI models below.
We transfer Google user data to others only where the Limited Use requirements permit it: to provide the user-facing features described above, for security purposes such as investigating a bug or abuse, to comply with applicable law, or as part of a merger, acquisition, or sale of assets after obtaining your explicit prior consent.

Human access

People on our team do not read your Google user data, with the narrow exceptions the Limited Use requirements allow: where you have given affirmative agreement to view specific files, where it is necessary for security purposes such as investigating a bug or abuse, where it is necessary to comply with applicable law, or where the data has been aggregated and is used for internal operations in line with applicable privacy law.

Credentials and control

The OAuth refresh token for a Google connection is held in encrypted secret storage, with the encryption keys held outside the database. It is never exposed to browser code, never written to logs, and never placed in a model’s context. A Company admin can disconnect Google Workspace from Settings → Connections at any time, and you can independently revoke access at myaccount.google.com/permissions. Documents already created in your Shared Drive stay in your Drive and remain yours; revoking access simply ends our ability to touch them.

Status. The Google Workspace connection is live: a Company administrator can authorize it from Settings → Connections, and it requests the drive.file scope above and nothing else. Our Google Cloud app is not yet published to production status, so an authorization currently expires after seven days and has to be renewed — the product says so on that screen rather than letting the connection fail quietly. Every commitment in this section applies from the moment a connection is made.

Slack

Operating Studio runs its own Slack app. A Company admin installs it into the Company’s Slack workspace through OAuth, which gives us a bot token scoped to that workspace and stored in the same encrypted secret storage as every other credential.

The scopes are chat:write plus the minimal channel-read scope the destination picker needs to list channels.
The bot is used to post notifications — Human Steps waiting, failures, overdue work — to public channels it has been invited to. We do not read your message history, we do not join private channels, and we do not use Slack data for anything except delivering those notifications.
What we store from Slack is the workspace and channel identifiers and names you chose, the bot token, and the delivery status of messages we sent.

A Company admin can disconnect Slack at any time, and a workspace owner can remove the app from Slack’s own settings. Separately from any Company connection, an access request submitted on this website may be relayed to a channel in our Slack workspace so a person sees it.

Status. As of the date on this page, no Company has installed the Slack app; the in-product connection ships in a later delivery.

Meeting transcripts

The reference Scribe Workflow turns approved internal meeting transcripts into reviewed decisions, commitments, and a published document. Where a Company connects a transcription provider (Fireflies first), the connection is an API key held in encrypted secret storage.

The provider’s webhook carries identifiers rather than content; Operating Studio then fetches the transcript through the provider’s API when the Project is started.
We receive and store the transcript text, the meeting title, date, and participants, and the recording and processing consent state recorded for that meeting.
Consent is checked before a transcript is sent to a model. A Project whose consent state is missing or negative stops visibly and waits for a person instead of proceeding.
Transcripts are used to produce the outputs of that Workflow and the evidence behind them. They are not used for any other purpose.

The pilot is scoped to internal meetings. Client sessions, coaching conversations, and restricted employee material are outside it, and Operating Studio should not be pointed at them. This is a limit of the current product, not a preference.

Status. As of the date on this page, no transcription connection is live; this section describes how transcripts will be handled when it is.

AI models

If Agent delegation is made available and a Company attaches an Agent to a role-assigned Template Task, Operating Studio may use large language models to help execute that Task. Model calls are routed through OpenRouter using credentials we hold, so Companies do not supply their own model keys. Only the Project information, transcript, and attached documents needed for that Task are sent to the selected model to produce its requested output.

Content is sent to produce the output you asked for, and for no other purpose.
We select providers and settings that do not train on the content we send, and we enable zero data retention wherever the provider offers it. Not every provider offers the same guarantees; that is a reason we constrain which providers we route calls to rather than a reason to be vague about it.
We do not use Company data to train or improve our own or a third party’s generalized models unless the Company first chooses that use in writing.
Every Run records which prompt, provider, and model actually ran, so what was sent and where is auditable after the fact.
Credentials and secrets are never placed in a model’s context.

Agreements, acceptance, and billing

Operating Studio is a paid service, so before a Company is active we prepare a written service agreement and afterwards we invoice it. That produces a small, deliberately durable set of records, separate from the Company’s operational work.

The private agreement link

We send the agreement to the named signer as a link carrying a cryptographically random token. Only a hash of that token is stored, never the token itself. The link needs no Operating Studio account and reveals only that document and its versions — never the Company’s operational data. Opening it records the first and most recent view times. A revoked link shows a generic unavailable page rather than naming the Company.

Acceptance evidence

When the signer types their name and accepts, we record the version accepted, the signer’s configured email address, the name they typed, the time, a hash of the exact document, the policy versions in force, and — where the request provides them — the network address and browser user agent the acceptance came from. That evidence exists so both sides can later show what was agreed and by whom. We do not claim it is notarization, identity proofing, or a qualified digital signature.

Documents we keep

Each agreement version is an immutable snapshot, and both the sent and the completed PDF are held in private object storage with their hashes. They are reachable only through the document’s own private link or an authorized action by our platform administrators. Each snapshot also stores the archived text of the terms of service and this policy as they stood when it was sent, so a later edit to either page cannot quietly change what a Company agreed to.

Invoices and payment

Invoices are created and sent through Stripe. We store the Stripe customer and invoice identifiers, the amounts and line items, the due date, and the payment state Stripe reports — draft, open, paid, void, or uncollectible — plus the record of any billing hold and who cleared it. Payment-card and bank details are entered on Stripe’s own hosted pages and are never sent to or stored by Operating Studio. Stripe’s handling of that data is governed by Stripe’s privacy policy.

Email we send about an engagement

The agreement link, the completed agreement PDF, and the welcome email are delivered through Resend. Resend receives the recipient address, the subject and body, and any attachment, and returns delivery metadata — a message identifier, timestamps, and whether the provider accepted, delivered, bounced, or rejected the message. We store that metadata so a failed delivery is visible and can be retried instead of failing silently.

Status. As of the date on this page, no Stripe or Resend integration is live and no Company agreement has been issued through the product; this section describes how that data will be handled when it is. Every commitment here applies from the moment the first agreement is sent.

How we use information

To run the service for your Company: executing Workflows, generating the screens you use, notifying people, and producing Artifacts. To keep it working and safe: debugging, monitoring health, investigating abuse, and enforcing the terms of service. To agree terms with your Company, to invoice it, and to keep the record of both. To communicate with you about access and about the product. And to comply with the law.

We do not sell personal information, and we do not use it to advertise to you. We do not use Company data to build generalized AI models.

Isolation between Companies

We maintain commercially reasonable administrative, technical, and organizational safeguards appropriate to the information and risk. These include encryption in transit and at rest where supported, access controls, least-privilege practices, and an auditable record of sensitive administrative actions.

If we confirm a security incident affecting a Company’s data, we notify that Company promptly, share the facts reasonably available to us, take reasonable steps to contain and correct the incident, and cooperate with legally required notices.

Companies are isolated from one another, and that isolation is enforced in the database rather than only in application code. Every tenant-owned row carries its Company; references between rows use composite keys that include it, so a row cannot point at another Company’s records even under a policy bug. Row Level Security is enabled on every exposed table and its policies require an active Company membership rather than merely an authenticated session. Browser clients are read-only: every change goes through a server API that re-checks Company ownership.

A hostname identifies which Company is being requested but never authorizes access by itself. Platform administrators have no implicit membership in any Company and no read path into Company data — they must be added as a member like anyone else. Structural changes, approvals, Runs, and interventions are audited.

Inside a Company, V1 is deliberately coarse. There are three roles — Super Admin, Admin, and Member — and they decide what a person may change, not what a person may see: every active member can see that Company’s operational work. Please read what Operating Studio is not for before deciding what to put in it.

We hold no security certification such as SOC 2 or ISO 27001, and we do not claim one. A single production environment serves every Company.

Retention and deletion

Your Company’s operational data is retained while your Company uses Operating Studio. The material most worth being careful about — transcripts, incoming webhook payloads, rendered prompts, and Run evidence — carries a retention class, and deleting it propagates across the database, file storage, backups, and provider logs rather than stopping at the row you can see.

Specific retention periods are not yet published, because the retention classes are still being set. We would rather say that than name a number the system does not enforce. When those periods are fixed they will be stated here. For the same reason we do not publish a backup, restore, or point-in-time-recovery promise: keep your own copy of anything you cannot afford to lose, and see the terms for what that posture is today.

Agreement and payment records outlive a deletion request. When an engagement ends we delete the Company’s operational data on request, but the accepted agreement and its acceptance evidence, the invoice and payment record, and the audit entries showing who did what are kept: they are the record of a commercial relationship and of our own legal and accounting obligations. They hold the signer and billing contact’s name and email, the amounts, and the dates — not the Company’s operational content.
When an engagement ends, a Company may ask us to return or delete its operational data. Documented legal, accounting, security, backup, and audit records that we must retain remain subject to the limits described here rather than being silently discarded.
When a membership is removed, access ends immediately, but the membership row is kept so past approvals and completed work keep their original actor. Deleting the person’s identity outright is done on request.
A Company admin can ask for an export or deletion of the Company’s data, and we will carry it out. There is no self-serve export or delete button in the product yet; today it is a request handled by a person.
Access requests submitted on this website persist in our hosting provider’s logs for that provider’s log retention period and in the Slack channel they were relayed to, until deleted.
Documents published to your Company’s Google Drive live in your Drive under your Company’s control; deleting data in Operating Studio does not delete them there.

Your choices

Most of what you can ask for goes through your Company admin, who can change your role, correct the email your membership is keyed to before your first sign-in, and remove your access. For anything else — seeing what we hold about you, correcting it, or deleting it — contact us through the route below and we will act on it.

If the law where you live gives you rights over your personal data, such as in the United Kingdom, the European Economic Area, or California, we will honour requests those laws entitle you to make. Where the data belongs to a Company’s operational record, we will work with that Company’s admin to answer you.

You can revoke Operating Studio’s access to your Google account at any time at myaccount.google.com/permissions.

Children

Operating Studio is a workplace tool and is not directed at children. We do not knowingly collect data from anyone under 18. If you believe we have, tell us and we will delete it.

Changes to this policy

We will update this page as the product changes — in particular as each connection described above goes live. The date at the top always reflects the current version, and we will tell Company admins about material changes.

Contact

Privacy questions, data requests, and security reports can be raised through the person who invited you, through your Company admin, or through the request form on the home page, which reaches us directly.