Privacy Policy

Version 3.3 — Last updated October 4, 2026 — Effective October 4, 2026

This Privacy Policy explains how Primordio LLC, a Delaware limited liability company (“Primordio,” “we,” “us”), collects, uses, discloses, and retains information in connection with the Primordio Documentation Generator and our websites, APIs, and documentation (the “Service”).

It is part of, and incorporated into, our Terms of Use. Capitalized terms not defined here have the meanings given there.

Controller designation and contact. Primordio LLC is the controller of personal data collected through the Service. All privacy questions, requests, and appeals go to contact@primordio.com.

What this policy does not cover.

• Personal data we process on your behalf. Where you are a customer and we process personal data about your own customers, employees, or other individuals as part of delivering the Service, you are the controller and we are the processor / service provider, and our handling of that data is governed by our Data Processing Addendum and by any signed agreement between us — not by this policy. Section 2 explains the split.
• The Primordio company website. primordio.com publishes its own privacy policy, which covers that website. This policy covers this product.
• Your own site. A run opens a browser against a system you operate. What that system collects from its own visitors is governed by your privacy policy, not ours.

---

1. The short version

• We collect the account information you register with, the URLs and instructions you submit, the artifacts we generate from them, and basic operational and usage data.
• A run records your site. Whatever is displayed on screen during a run — including any real personal information on your own system — is captured in the resulting video and screenshots and stored with your workspace.
• The desktop app records on your Mac, and keeps the results there. Tutorials, recordings, images, and logs the Primordio desktop application produces stay on your Mac; we do not receive them. What the desktop app sends us is your sign-in, a periodic licence check, a receipt when you accept these policies and a receipt for each recording’s attestation (identifiers, hashes, versions, and times — never the recording or anything in it), each recording’s start and finished length for your workspace’s usage meters, the words of a narrated tutorial’s steps so that the narration can be written and spoken (Section 6), and — when a step’s control cannot be found by its words and you have left the setting on — one picture of the window being recorded, so that an AI model can point at the control. Section 3.2 and Section 6.
• Run inputs come in two kinds. Values you supply for a single run are erased when that run finishes. Values you choose to save on a tutorial are stored as entered until you remove them or delete the tutorial. Section 4 explains both.
• The doc-gen SDK runs in your own CI and never sends us your source code. If you use it (a private beta), each check sends us file paths, the changed text your product shows its users, short content hashes, commit identifiers and your repository’s name — and, only if you choose our model passthrough, a demo’s steps and those changed strings for our AI provider. Section 3.2 and Section 6.
• We do not sell personal information. We do not share it for cross-context behavioral advertising. We do not engage in targeted advertising. We do not use your content to train our own AI models, and we have not opted in to any program that would let our AI providers train on it. We use only AI providers and configurations whose terms state that our inputs and outputs — text and images alike — are not used to train their models. Section 6.
• We use third-party providers for authentication, hosting, storage, compute, AI planning and narration, payments, email delivery, and our own company mailbox. They are listed in Section 5.
• We keep your content until you delete it, with one exception: we may delete content from workspaces that have been inactive for 60 days after a subscription ends — and we will send you two warnings before we do. Section 7.1.
• You can request access, deletion, correction, or a copy of your information at contact@primordio.com.

2. Our role

For information about your account, workspace, billing, and use of the Service, we act as the controller and this policy governs.

For content you create through the Service — including anything recorded from a system you operate — we act as a processor / service provider on your instructions. Where that content contains personal information about your own customers, employees, or other individuals, you are the controller of that information and you remain responsible for having a lawful basis to collect it and to have us process it. We process it only to provide the Service to you and not for our own purposes. Content the desktop application keeps on your Mac and never sends us — recordings, images, tutorials, logs — is not processed by us at all; for it we are neither controller nor processor, and it is governed by whatever you do with it.

Every customer is covered by our Data Processing Addendum. It applies automatically, without a signature, and contains the service provider and processor commitments that US state privacy law requires between a business and its vendor — including the prohibition on our selling, sharing, or retaining your data for our own purposes, our subprocessor obligations, and your audit rights. If your organization needs a countersigned copy for its vendor records, email contact@primordio.com and we will return one; your protections do not depend on that.

3. Information we collect

3.1 Information you provide

Category	Examples	Source
Account and identity	Name, email address, password or federated login, profile image, organization name and membership, role	You, via our authentication provider
Workspace configuration	Workspace names, brand logo image, accent color, narration and caption defaults	You
Site verification data	Domain names you claim, nicknames you assign, the verification token we generate, the result and time of our DNS lookups, and — where the Service asks you to identify it — the basis on which you are authorized to automate that domain. The verification record lives until you remove the domain; the audit record of every add, verify, and remove event — who, and when — is kept for the life of the workspace as evidence of what was verified (Section 3.3 and Section 7)	You and public DNS
Run inputs	Site URLs, titles, descriptions, and the plain-English step instructions you write	You
Run input values (“secrets”)	Values you supply for {{TOKEN}} placeholders — which may include usernames and passwords for a test account on your own system	You. See Section 4.
Saved run inputs	Run input values you choose to keep on a tutorial so they are filled in automatically on every run. Stored as entered, until you remove them.	You. See Section 4.
Clarification answers	Free-text answers you give when a run pauses to ask a question	You
Support and correspondence	Your name, email address, organization, and the contents of the contact, support, and access-request forms and the emails you send us, together with our replies	You
Billing	Plan selection, subscription status, billing contact, and your consent to automatic renewal. Payment card numbers are collected and stored by our payment processor, not by us.	You, via our billing provider
Acceptance records	When you accepted these policies, and which version was in force at that time — kept with your account at our authentication provider and as a receipt; for an acceptance made in the desktop application, also the app version and the network address it came from	Generated when you accept
Desktop sign-in and licence	When you sign in to the desktop application, a one-time code and verifier exchanged through your browser; then a desktop session, stored on our side as a hash and on your Mac sealed by the macOS Keychain, together with the name of the Mac you signed in from and the time of each licence check (every six hours while the app runs, and on demand). The session is replaced when you sign in on another Mac	You, via the desktop application
Desktop narration requests	When a desktop tutorial is narrated, before its recording: the tutorial’s workspace, the chosen voice and delivery style, and for each step its action, its words (with input placeholders such as {{EMAIL}} — never input values or the text a step types), its target, its note, and any spoken line you wrote; then each line to be spoken. The written lines and the audio come back to your Mac. We keep neither; our log holds counts, the model, the minutes charged, and timings	Supplied by you, when you record a narrated tutorial
Desktop model requests	When a step’s control cannot be found by its name, its tooltip, or your description, and you have left “Ask a model at Primordio before asking me” on: one picture of the window being recorded (at most 1,568 pixels wide; the window only, never the whole screen or other applications), with the likely controls numbered on it; the step’s words; your words for the control; and the numbered controls’ names, roles, and container names with their positions on that picture. Such a picture can contain anything the window showed — titles, names, file names, notifications inside the window, and whatever data the application displayed. At most twenty per recording. See Section 6 for what we do with it	Generated by the desktop application
Desktop attestations and acceptance	Before every recording, the confirmation you give in the desktop application that you are authorized to operate and record the target, that only data you may record is on screen, that only test credentials are involved, that you are using a demonstration environment where possible, that the recording completes no consequential action, and that you are not evading a safeguard — recorded on your Mac with the statements’ text hashes, the policy versions in force, your user identifier, the time, and the app version, as run-record.json beside the recording — and sent to us as a receipt: the recording’s identifier, the statements’ hashes, the versions in force and accepted, the time, the app version, the kind of target and its bundle identifier, the run’s settings, and the network address it came from; never the tutorial, the target’s name or address, a step, a picture, or the recording. Your acceptance in the desktop application of the policy versions in force is recorded the same way (the “Acceptance records” row). The full records stay on your Mac; the receipts are our copy, and we may still ask you for the full records when investigating a complaint	Generated when you record
Run attestations and run records	Each time you approve or restart a run, the confirmation you give that you are authorized to automate the system, that only data you may record is on screen, and that credentials are in run inputs only — recorded with the statements’ text hashes, the policy versions in force, your user identifier, the time, your IP address and browser — together with the results of the pre-run checks (the secret-pattern scan, with any findings masked; the live TXT re-check). Stored with the run and written beside its artifacts as run-record.json	Generated when you approve a run

3.2 Information the Service generates about your system

Cloud runs. When you approve a run in the web application, our infrastructure opens a real browser and performs the approved steps against the system you verified. In doing so we create and store:

• Screenshots of each step, captured from the target system as it appeared at that moment;
• Screen recordings compiled into an MP4 video;
• A screenshot attached to any clarification question the run pauses to ask;
• Narration text, synthesized audio, transcripts, and caption files;
• A written guide in HTML and Markdown with the screenshots embedded; and
• A structured plan and storyboard describing the steps, target elements, and narration.

These artifacts contain whatever your system displayed during the run. If your system was showing real customer records, real names, real messages, health information, financial information, or government identifiers, that information is now stored in your workspace as part of the artifact — and it may bring both of us within privacy laws that would not otherwise apply. We strongly recommend running only against systems populated with synthetic demonstration data. Section 6.5 of the Terms makes this your responsibility.

The doc-gen SDK (private beta). The SDK is a command-line tool and GitHub Action that you run in your own repository and CI, to keep a tutorial current as your code changes. It reads your code on the machine that runs it; it never sends us source code, diffs, or file contents. When it reports a check, it sends us, for each demo whose watched files changed: the repository’s host, owner and name (nothing else from its address — never credentials in it); the two commit identifiers compared; each changed file’s path and change type; each changed user-facing string — button and link text, labels, placeholders, alternative text, test identifiers, routes, and exported names — before and after, with its file and line, at most 200 characters each; a short hash of each changed image, stylesheet or font, never its content; and the check’s result, its reasons and its rename hints. If you push an outline, it sends the tutorial fields you edit in the application. We store each check with its tutorial, where everyone who can see that tutorial in your workspace can see it. Those strings are whatever your product displays: if your code contains real personal information in its interface text, the check carries it. Each download of the SDK is recorded in your workspace’s audit log (Section 3.3). The comment the SDK can post on a pull request is sent from your CI to GitHub with your own GitHub credentials; it does not pass through us. What the SDK sends to an AI model is described in Section 6.

Desktop runs. When you record with the desktop application, the recording is made on your Mac, by the application, in the window of the Mac application, local web application, or iOS Simulator you chose. On your Mac it creates and keeps: the raw and finished video; a still image of each step; the picture, with numbered options, that it shows you when it pauses to ask which control a step means; the picture it sends with a model request (Section 6), kept beside the recording; a text listing of the accessibility names and positions of the window’s controls at the moment a search failed (an ax- file), to help fix the tutorial; the run’s record and event files; and, for each application you record, the names it learns from that application’s tooltips, kept per application so later recordings find controls faster. None of this is sent to us — only the receipt of the run record’s attestation, the recording’s usage (its length, for the workspace’s meters, Section 3.3), and for a narrated tutorial the step words, described in Section 3.1. The narration’s audio is kept with the recording (narration.m4a, and a cache of spoken lines in narration-cache/), and the lines the site writes are kept on the tutorial so you can edit them. It all lives in ~/Library/Application Support/Primordio - Doc Generator/ on your Mac — projects/ for tutorials, runs/ for recordings, apps/ for learned names, logs/ for the app’s logs — until you delete it, and uninstalling the application does not delete it. A recorded window can show more than the demonstration: notifications, window and document titles, account names, file names and paths, tabs, messages, dialogs, and the application’s own data. Close what you do not want recorded before you start.

3.3 Information we collect automatically

Category	Examples
Authentication and session	Session cookies set by our authentication provider (see the Cookie Policy)
Payment fraud-prevention signals	Only on the Billing page, while the payment form is shown: our payment processor’s script sets two fraud-prevention cookies on our domain and collects browser and device signals so the processor can detect payment fraud (see Section 3.2 of the Cookie Policy). We do not receive these signals or read those cookies
Run and job telemetry	Job status, step-by-step event log, timings, error messages, failure captures, sandbox identifiers
Usage and metering	Tutorials created, video minutes rendered, documentation generations, storage consumed, API calls, rate-limit counters; and for the desktop application, each recording’s start and completion — its identifier, the tutorial’s random identifier, the workspace, the finished length, whether it was narrated, and the minutes and credit charged (never the tutorial’s name, steps, or content)
Audit records	Domain add, verify, and remove events, and each download of the doc-gen SDK (the version, and whether it was downloaded with an organization API key or by a signed-in member), with the acting user’s or organization’s identifier and a timestamp. Our audit log currently records these events only — it is not a comprehensive record of all account activity
Web analytics	Aggregate page views and visits, collected by our hosting provider’s analytics without cookies or advertising identifiers
Performance telemetry	Real-user page-load and responsiveness measurements (Core Web Vitals), reported by our hosting provider’s speed-insights tool against the page route rather than any identifier
Bot-detection signals	When you submit the contact, support, or access-request form, our bot-detection provider collects browser and interaction signals to tell a person from an automated script. We receive only a verdict — human or bot — not the underlying signals
Desktop app logs	The desktop application writes an operational log on your Mac (logs/ in the folder named in Section 3.2): app and helper version, macOS version, timestamps, which screen and feature was used, recording identifiers, the application recorded (its bundle identifier), permission state, action types, error messages, and security records — an address the app refused because it was not on your Mac, a click it refused because another application was in front, a target it refused because it is a category we do not record, a licence check that failed. Bearer tokens, sidecar secrets, and API keys are redacted from it by pattern; run input values are never written to it. It stays on your Mac unless you attach it to a support message, and we may ask you for it when investigating a complaint
Desktop session and model-request metadata	On our side: the hashed desktop session and the time of each licence check (Section 3.1); and, for each model request, the model used, the number of tokens, the time taken, how many controls were numbered, and whether the model chose one — never the picture, the step’s words, or your words
Technical logs	IP address, browser and device type, and request metadata, generated by our hosting and infrastructure providers for security and reliability. Our hosting provider’s firewall also derives an approximate location from your IP address to enforce the geographic restrictions described in Section 3.4 of the Terms during the beta; we do not store that location against your account

We do not use advertising cookies, ad networks, cross-site trackers, session-replay tools, fingerprinting, or data brokers. The browser and device signals our payment processor collects on the payment form (above) are used only to prevent payment fraud, never to track you.

3.4 Information we do not want, and will not knowingly accept

Do not submit to the Service, and do not run it against a system — or record a window on your Mac — displaying, any government-issued identifier, payment card or financial account number, protected health information, information about a child under 13, biometric identifier, precise geolocation, or credentials for a production or privileged account. Section 6.4 of the Terms prohibits this. If you submit such information anyway you do so at your own risk, and we may delete it without notice.

Credentials belong in run inputs and nowhere else. A run input is the only field of the Service designed to receive a password or other secret, and the only one to which the handling in Section 4 applies. Step instructions, notes, clarification answers, titles, descriptions, and URLs are not: they are sent to our AI provider, stored in the plan and narration, and may be spoken aloud in the generated video. Support and contact messages are stored in our mailbox. When you approve a run, we scan the storyline’s prose for credential-shaped text and refuse to start until you have reviewed what we found — but that scan matches patterns, not intent, and we do not warrant that it will notice every secret. If you put a credential in any of those fields, revoke or rotate it at once.

4. Run inputs and credentials — exactly how they are handled

This is the most sensitive information the Service accepts — an account login combined with a password is “sensitive personal information” under California law, and we treat every run input as if it were — so here is precisely what happens to it, including what our safeguards do not cover. We use run inputs for one purpose only: typing them into the target system during the run you approved. There are two kinds of run input, and the difference matters.

4.1 Per-run inputs (the default)

• Run input values are submitted at the approval gate, immediately before a run begins. Values whose names suggest a secret are masked in our interface.
• They are stored in a database column on the job record, protected by row-level security so that only your workspace can read them. They are not written into the workflow payload, the job event log, or any durable run state.
• During the run, values are injected directly into the browser at the moment they are typed. A redaction pass removes known secret values from error messages and captured page markup before those are stored.
• Redaction does not apply to images. Screenshots and video frames are captured as pixels and are not scrubbed. If a value you supplied is visible on screen during a run — for example typed into a field the target system does not mask, echoed back in an error banner, or included in a URL — it will appear in the resulting screenshot or video and be stored with your workspace, and it will remain there after the run’s stored values have been erased. This is why the Terms require you to use only dedicated test-account credentials.
• Values are erased from the job record when the run reaches a final state — completed, failed, expired, or abandoned.
• They are not erased while a run is paused in a recoverable state — a failed test walk or a failed build that you may still resume. In that situation they remain on the job record until you resume the run to a final state or delete the tutorial. If you want them removed sooner, delete the tutorial.
• Values are limited to 20 per run, 500 characters each.

We do not log per-run input values, display them back to you after submission, include them in any artifact by design, or send them to any AI provider.

4.2 Saved inputs (only if you turn them on)

You may choose to save a run input on a tutorial so that it is filled in automatically on every later run. If you do:

• The value is stored as entered — in the clear, not hashed or encrypted at the application layer — on the tutorial, in the same row-level-secured database as the rest of your workspace, and our database provider encrypts it at rest. It is copied onto each run’s job record when a run starts and handled from there exactly as Section 4.1 describes.
• It stays until you remove it. Saved inputs are not erased when a run finishes. They are deleted when you remove the saved input, delete the tutorial, or delete the workspace.
• Values whose names read as a secret (for example anything containing “password,” “token,” or “key”) are never sent back to your browser; the interface shows only that a value is saved, and you can replace it. Values with other names are shown so you can edit them.
• The same image caveat applies: a saved value that appears on screen during a run is in the recording.

Saving is a convenience for demonstration accounts. It is not a credential vault, and the interface says so at the point where you save a value. Section 6.4 of the Terms — test-account credentials only — applies with more force here, because the value outlives the run.

4.3 Run inputs in the desktop application

The desktop application asks for run input values when a recording starts and uses them on your Mac; they are not sent to us and are not sent to any AI provider.

• A value whose input name reads as a secret (for example PASSWORD, TOKEN, PIN, API_KEY, OTP, SECRET) is used for that recording only: it is never written to the recording’s record, its images, or the app’s log, and is not shown in captions. Other values appear in the captions of the video, by design, so that the demonstration reads correctly.
• Typing into a Mac application is done by placing the text on the clipboard, pasting it, and putting the clipboard’s previous contents back. The clipboard is not secure storage, and any application on your Mac that watches the clipboard could see the value at that moment.
• The same image caveat applies with more force here: the recorded window is a live application on your Mac, and a value the application displays is in the recording.
• The desktop application does not save run inputs between recordings and has no saved-input feature.

5. How we use information, and who we share it with

5.1 Purposes

To operate and deliver the Service; authenticate you and secure your account; plan, execute, render, and store your runs; meter usage and enforce quotas and rate limits; process payments; provide support; detect, investigate, and prevent fraud, abuse, and security incidents; maintain reliability and performance; and comply with legal obligations and enforce our Terms.

5.2 We do not sell or share

We do not sell personal information, and we do not share it for cross-context behavioral advertising, as those terms are defined under California and other U.S. state privacy laws. We have not done so in the preceding twelve months, including with respect to anyone we know to be under 16. We do not use personal information for targeted advertising, and we do not engage in profiling that produces legal or similarly significant effects. There are no third parties to whom we have sold or may sell personal information.

5.3 Service providers

We disclose information to the following providers, each for the limited purpose shown:

Provider	Purpose	What it receives
Clerk	Authentication, user and organization identity, session management, API key issuance and verification, billing interface	Name, email, credentials and session data, organization membership, workspace and subscription identifiers; the record of which policy versions you accepted, and when, kept as private metadata on your user
Stripe (through Clerk Billing)	Payment processing and payment fraud prevention	Payment method and billing details; and, while the payment form is shown on our Billing page, browser and device signals and two fraud-prevention cookies, which Stripe uses to detect payment fraud under its own privacy policy. We never receive or store full card numbers, and we do not receive those signals.
Neon	Managed PostgreSQL database	All workspace, tutorial, job, usage, audit, and configuration records described in Section 3
Vercel	Application hosting, web-application firewall, private object storage for artifacts, isolated sandbox compute that runs the browser automation, scheduled jobs, cookieless web analytics, and cookieless performance measurement (Speed Insights)	Application traffic and technical logs, including the IP-derived approximate location the firewall uses; all generated videos, screenshots, audio, captions, and documents; the execution of the run itself; the aggregate analytics and performance data points described in Section 3.3; the desktop application’s sign-in, licence, and model requests as application traffic — the picture in a model request passes through and is not stored
OpenAI	Large language model planning, narration writing, and text-to-speech synthesis	The written step instructions and planning context you submit, and the narration text generated from them, as text; and, from the desktop application only, the picture of the recorded window and the words that accompany a model request, and a narrated tutorial’s step words and lines (Section 3.1); and, from the doc-gen SDK only when you choose our model passthrough, a demo’s step text and the changed user-facing strings described in Section 6. We do not send video, recordings, run input values, saved inputs, or your account details to any AI provider. Section 6 states exactly what is sent and the retention and training position
Resend	Delivery of the email generated when you submit the contact, support, or access-request form, and of any account notice we send you (for example the deletion warnings in Section 7.1)	Your name, your email address, and everything you typed into that form — including any account email, charge date, or charge amount you supplied — so that the message reaches our inbox and we can reply to you; for account notices, your email address and the notice text. We do not enable Resend’s open or click tracking, so no tracking pixel or rewritten link is added to what we send
Google Workspace (Gmail)	Our company mailbox. Every message you send to contact@primordio.com, every form submission Resend delivers to it, and every reply we send you is stored there	Your name, email address, and the full content of your correspondence with us, including privacy requests, appeals, arbitration opt-outs, DPA requests, and support threads, for the retention period in Section 7
Vercel BotID	Bot detection on the contact, support, and access-request form endpoints, to stop automated abuse	Browser and interaction signals collected in your browser at the moment you submit a form. We receive only the resulting verdict

About the form notification. When you write to us through a form, the message is sent to our own inbox by Resend; your address is set as the reply-to so that replying reaches you. Do not put passwords, full payment card numbers, or other secrets into a support form — the form itself says so, and Section 3.4 explains why.

About email we send you. Email we send necessarily passes through, and is stored by, the email provider of the address on your account. If that address is hosted by Google, Microsoft, or another provider, that provider processes the message under its own terms as the operator of your mailbox — it is your provider, not ours, and it is not on the list above for that reason.

We also use GitHub, HashiCorp Terraform Cloud, and Slack for source control, infrastructure management, and internal operational alerting. These receive our code and configuration, not your content.

This list is our current subprocessor list, and it is restated with processing detail in Annex C of the Data Processing Addendum. If we add or replace a provider that processes your content, we will update this policy and give notice at least 30 days before the change takes effect, so that you can object or terminate — the mechanics are in Section 7.2 of the Addendum.

5.4 Other disclosures

We may also disclose information to comply with law, legal process, or a lawful government request; to enforce our Terms or investigate a suspected violation; to protect the rights, property, or safety of Primordio, our users, or the public — including responding to a complaint from the operator of a system you automated; with your direction or consent; and in connection with a merger, acquisition, financing, or sale of assets, in which case we will require the recipient to honor this policy or give you notice and a choice.

5.5 Within your organization

If you use an organization workspace, your organization’s administrators and owners can see and control the workspaces and content you create there, including deleting it. Your use is also subject to your organization’s own policies.

6. AI and automated processing

The Service uses large language models to convert your written steps into an execution plan and to write narration, and a text-to-speech model to synthesize that narration into audio. The instructions you write, the plans derived from them, and the narration text are transmitted to our AI provider for processing. If you use the doc-gen SDK with our model passthrough, a language model is also used to judge which steps of a demo a code change affects.

What we send, and what we never send. For cloud runs we send text: the site URL, the title and description you give a tutorial, your written step instructions and section headings, the names (never the values) of any input placeholders you reference, the step log a run produces — each step’s action, the description of the element it acted on, and its intent — the notes and clarification answers you write, and the narration to be spoken.

The doc-gen SDK, only when you choose our passthrough. The SDK matches most code changes to a demo’s steps without any model. For the changed user-facing strings it cannot place, it asks a model, and you choose how it reaches one. With your own model key (ai.mode: byo), the request goes from your CI directly to the provider you chose, under your account with that provider and its terms; it does not pass through us, and this Section’s statements about our AI provider do not apply to it. With our passthrough (ai.mode: passthrough), the SDK sends us the demo’s identifier, title and site, the text of its steps, and the unplaced strings with their file paths and kinds — never source code — and we add our instructions, relay the request to our AI provider, and pass the answer back. We do not store the request or the answer; our log of it holds only the workspace, the model used, the token count, and the time taken.

The desktop application also sends images, in one situation. When a step’s control cannot be found by its name, by a tooltip, or by your description, and you have left “Ask a model at Primordio before asking me” on in Settings › Privacy (it is on by default), the desktop application takes one picture of the window being recorded — the window only, at most 1,568 pixels wide — numbers the likely controls on it, and sends that picture to us together with the step’s words, your words for the control, and the numbered controls’ names, roles, and container names. We relay it to our AI provider with the question “which numbered control is this?”, pass the answer back, and keep nothing: we do not store the picture or the words, and our log of the request holds only the model used, the token count, the time taken, and the shape of the answer. The picture can contain anything the window showed at that moment. Turning the setting off means the desktop application asks you instead, every time.

What we never send, cloud or desktop: run input values, saved inputs, video, recordings, your name, your email address, or any other account information. A narrated desktop tutorial uses the first two, for the same purpose as a cloud run: the step words described in Section 3.1 are sent to write the narration (text completion), and each line to be spoken (text-to-speech); nothing from the screen is sent for narration. The Service currently makes three kinds of request to an AI provider — text completion (which includes the doc-gen SDK’s passthrough requests), text-to-speech, and the desktop control question above — and no other. We expect to use images more in future — for example to find a control in a cloud run, or to check a recording — and if we do, we will update this Section, and the same rule will apply: no training, and no copy kept by us beyond the request.

Our standing rule for choosing AI providers. We use only AI providers, and only configurations of those providers, whose published terms state that data we submit and the output we receive are not used to train or improve the provider’s models unless we opt in — and we do not opt in. If a provider changes that position, we will stop using it, or move to a configuration that preserves it, before continuing to process your content through it. We do not use your content to train our own models.

What we can tell you precisely about OpenAI, as of the date above. We currently use OpenAI’s API for text and for the desktop control question. Under OpenAI’s published terms, data submitted through its API — text and images alike — is not used to train or improve OpenAI’s models unless the customer explicitly opts in, and we have not opted in. OpenAI retains API inputs and outputs, including images, for up to 30 days for abuse monitoring and may access that data within that window to investigate suspected abuse; OpenAI states that it may retain such data longer where required by law or where reasonably necessary to protect its services or a third party from harm. We do not enable stored completions or any other feature that would keep application state, files, or conversation history on OpenAI’s systems, so beyond that abuse-monitoring window OpenAI holds nothing of yours on our behalf. We do not currently have a zero-data-retention arrangement with OpenAI. If our providers or their terms change, we will update this policy.

Output may be inaccurate. The Service does not make automated decisions that produce legal or similarly significant effects about any individual.

The narration in generated videos is synthetic. It is produced by an AI text-to-speech system and is not a recording of a human voice. We include a disclosure to that effect in the videos we produce, and the Terms require you not to remove it.

7. How long we keep information

Data	Retention
Tutorials, videos, screenshots, documents, transcripts, captions	Until you or a workspace administrator deletes them, until an older version is pruned by your plan’s version cap, or under the inactivity rule below
Per-run input values (“secrets”)	Erased when the run reaches a final state; retained while a run is paused in a resumable failed state (Section 4.1). Values visible in screenshots persist with the screenshot
Saved run inputs	Until you remove the saved input or delete the tutorial or workspace (Section 4.2). Not erased when a run finishes
Job records and event logs	Deleted with the tutorial they belong to
Run attestations and run records	Deleted with the tutorial they belong to; the copy beside the artifacts is deleted with the artifacts
Desktop narration requests	Nothing retained by us beyond our metadata log for the request (Section 3.3), which follows the technical-log period below; the recording’s minutes are metered as usage (“Usage and metering records”). Our AI provider’s own retention is stated in Section 6
Desktop model requests	Nothing retained by us; our metadata log for the request (Section 3.3) follows the technical-log period below. Our AI provider’s own retention is stated in Section 6
Code-change checks (from the doc-gen SDK)	Deleted with the tutorial they belong to
doc-gen SDK passthrough requests	Nothing retained by us; our metadata log for the request follows the technical-log period below. Our AI provider’s own retention is stated in Section 6
Desktop session	Until you sign out, sign in on another Mac, or the session expires through disuse; the last-seen time is updated at each licence check
Content on your Mac (tutorials, recordings, images, learned names, attestations, logs)	Until you delete it. We cannot see or delete it; deleting your workspace or account does not delete it; uninstalling the desktop application does not delete it. The folder is named in Section 3.2
Clarification records	Expire automatically after a short window; deleted with the tutorial
Usage and metering records	Retained after content deletion for billing accuracy, quota enforcement, and financial records — generally seven years
Subscription and auto-renewal consent records	At least three years, as consumer-protection law requires
Privacy request and appeal records	At least 24 months
Support and contact correspondence (held in our Google Workspace mailbox)	24 months from the last message in the thread, then deleted — except where it relates to a billing dispute, a security incident, or a legal hold, in which case it is kept until that matter closes
Billing dispute and chargeback records	Seven years, as financial-records and card-network rules require
Acceptance records (which policy version you accepted, when) and desktop attestation receipts (Section 3.1)	For the life of the account and for as long afterward as a claim could be brought — they survive deletion of the account, because they are what shows what was agreed
Audit records	For the life of the workspace
Domain verification records	Until you remove the domain
Account and billing records	For the life of the account, and afterward as required for tax, accounting, and legal purposes
Technical and security logs	For the retention period of the infrastructure provider that generates them — from one day for our hosting provider’s application request logs to ninety days for provider account and security-event logs, depending on the provider and the log type. We do not extend these periods ourselves

Records our payment processor keeps. Deleting your account or content does not delete the transaction records our payment processor holds. It retains them independently, for its own legal, tax, accounting, fraud-prevention, and card-network obligations, under its own privacy policy.

7.1 Inactivity deletion

We never delete your content while you have an active paid subscription in good standing, however long it has been since anyone signed in.

After a subscription ends, your content stays available to view and download for at least 30 days. After that window, we may permanently delete the content in a workspace once the workspace has gone 60 consecutive days with no sign-in, no authenticated API request, and no active paid subscription.

We will warn you first. We will send at least two notices — approximately 30 days and 7 days before the deletion date — to the email address on your account and to the billing contact on file. Each will state the deletion date and include a working export link. We keep a record of every notice we send. We commit to attempting this notice, but we cannot warrant delivery to an address that is out of date or blocked, so keep a current email address on your account and keep your own copies of anything you want to preserve.

We will not delete content that we know to be subject to a litigation hold or preservation demand, a disputed charge or pending refund, or an open support ticket about the account. Deletion under this rule is permanent. Section 11 of the Terms governs.

7.2 Backups

Deleted content is removed from active systems promptly. Residual copies may persist in routine infrastructure backups for a limited period before being overwritten in the ordinary course.

8. Your rights and choices

8.1 Rights we honor

Depending on where you live, U.S. state privacy law may give you the right to:

• Know and access what personal information we have collected about you, the categories of sources, the purposes, and the categories of recipients;
• Obtain a copy of your personal information in a portable format;
• Correct inaccurate personal information;
• Delete your personal information;
• Opt out of sale, sharing for cross-context behavioral advertising, targeted advertising, and certain profiling — none of which we do;
• Limit the use of sensitive personal information — we do not use it for any purpose beyond providing the Service; and
• Not be discriminated against for exercising any of these rights. We do not deny service, charge different prices, or provide a different level of service to anyone who exercises a privacy right.

Whether any particular state’s law applies to us depends on thresholds most of them set by the number of consumers a company processes data about, and we are a small company well below those thresholds. We do not rely on that. As a matter of policy we extend every right listed above to all U.S. users, regardless of residence and regardless of whether the law in question reaches us. These rights are drawn from laws including the California Consumer Privacy Act (as amended by the CPRA), the Colorado Privacy Act, the Virginia Consumer Data Protection Act, the Connecticut Data Privacy Act, and comparable laws in Utah, Texas, Oregon, Montana, Florida, Delaware, Iowa, Nebraska, New Hampshire, New Jersey, Tennessee, Minnesota, Maryland, Indiana, Kentucky, and Rhode Island.

On GDPR. Because we do not offer the Service in the European Economic Area, the United Kingdom, or Switzerland (Section 3.2 of the Terms), we do not process personal data under the EU or UK GDPR and this policy therefore states no Article 6 legal bases. If we ever begin offering the Service in those territories, we will publish the legal bases we rely on, and our transfer safeguards, before we do.

8.2 How to exercise them

Email contact@primordio.com with the subject line “Privacy Request,” the email address on your account, and what you are asking for. We will:

• acknowledge your request within 10 business days;
• verify your identity, usually by confirming control of the account email — for sensitive requests we may ask for more; and
• respond substantively within 45 days, extendable once by a further 45 days where reasonably necessary, with notice to you.

We may decline where the law permits — for example where we cannot verify your identity, where a request is manifestly unfounded or repetitive, or where retention is required by law. If we decline we will tell you why.

8.3 Appeals

If we deny your request you may appeal, at no cost, by replying to our decision with the subject line “Privacy Appeal,” within 90 days. We will review it and respond in writing within 45 days, explaining our reasoning. If we deny the appeal, we will give you a method to submit a complaint to your state Attorney General, and we retain appeal records for at least 24 months.

8.4 Authorized agents

You may use an authorized agent. We will ask for written proof of authorization and may ask you to confirm the agent’s authority directly.

8.5 Self-service

You can delete individual tutorials, versions, and their artifacts, and remove any saved run input, from within the Service at any time, subject to your workspace role. Deleting a whole workspace or account is currently handled by contacting us at contact@primordio.com. Deleting content does not refund usage already metered. Content the desktop application keeps on your Mac is deleted the way any file on your Mac is — from the desktop application’s Recordings and Tutorials pages, or in the Finder from the folder named in Section 3.2 — and a privacy request to us cannot reach it.

8.6 Opt-out preference signals

We do not sell or share personal information and we do not engage in targeted advertising, so there is nothing to opt out of. Because of that, we do not currently detect or process the Global Privacy Control or any other opt-out preference signal — under California’s regulations, honoring such a signal is not required of a business that does not sell or share personal information. If that ever changes, we will implement signal handling and say so here before we begin selling or sharing anything. We do not respond to legacy “Do Not Track” headers, for which no common standard exists.

9. Security

We take measures designed to protect information. Described precisely, and limited to what we actually do:

• Authentication, session management, and API key issuance are handled by a specialist provider. API key secrets are hashed by that provider and displayed to you only once, at creation.
• Tenant data is isolated at the database layer using PostgreSQL row-level security. Queries against tenant tables are scoped to a workspace by a transaction-local session setting. A lookup for a record outside your workspace returns “not found.”
• Generated artifacts are stored in a private object store and served only through a route that checks workspace ownership on each request. We do not issue public artifact URLs, share links, or embed codes.
• Runs execute in isolated, ephemeral sandbox virtual machines that are torn down after each job, with a wall-clock ceiling enforced by a scheduled process that stops overdue jobs.
• A navigation guard blocks the automation browser, at the network layer, from navigating to any host outside the verified allow-list for that run.
• Run input values are injected at runtime and redacted from stored error text and captured page markup. As Section 4 states plainly, this redaction does not extend to screenshots or video.
• Traffic between you and the Service is encrypted in transit using TLS. Our database and object-storage providers encrypt data at rest. We do not represent that every internal connection between our own components is separately encrypted.
• The desktop application, stated as precisely: its sign-in session is sealed with the macOS Keychain and never shown to the interface; its automation helper listens only on the Mac’s loopback interface with a secret that changes at every launch, and writes only inside the application’s own data folder; it records web applications only at a loopback address on the same Mac and blocks the recording browser from navigating anywhere else; it refuses a click when another application is under the pointer; it remembers controls by their names and never by position or picture; it never writes a secret-named run input to disk or to its log, and redacts tokens and keys from that log; it refuses some categories of application as targets and records every refusal; it will not record until you have confirmed the attestation in Section 3.1, and it sends us a receipt of that attestation (no content) which we keep; and the picture in a model request is sent over TLS and not stored by us. Not yet in place, stated as plainly: the desktop application is not yet code-signed or notarized and has no automatic update, so you must obtain it only from us and check that you have; and it does not scan a tutorial’s text for credential-shaped values before recording. We will update this Section as those change.

What we do not claim. No system is perfectly secure, and we do not represent that ours is. We do not hold SOC 2, ISO 27001, HIPAA, PCI DSS, or any other security certification or attestation, and nothing in the Service or our marketing should be read as implying that we do. We do not currently maintain a formal third-party audit program or a bug bounty. Our application-level logging is limited, and our audit log covers domain verification events only.

If you become aware of a vulnerability, report it to contact@primordio.com and we will respond.

Incidents. We will notify affected users and customers of a security incident involving their personal information as and to the extent required by applicable law. We do not commit here to a specific notification deadline, because the applicable deadline depends on the law of the affected person’s state and on what the investigation establishes; we commit to meeting whichever deadline applies and to telling you what we know as soon as we reliably know it.

10. Children

The Service is not directed to anyone under 18, and we do not knowingly collect personal information from anyone under 18. If you believe a minor has provided us personal information, contact us and we will delete it.

11. Changes to this policy

We may update this policy. We will post the revised version with a new version number and “Last updated” date. For material changes we will give at least 30 days’ notice by email and in-product notice before the change takes effect, and we may require you to accept it. Changes apply only to information processed after the effective date.

12. Contact

Primordio LLC Privacy requests, appeals, and questions: contact@primordio.com

Use the subject line “Privacy Request” for requests under Section 8, and “Privacy Appeal” for appeals under Section 8.3.