Privacy
Autolace holds something unusually sensitive: a client's unreleased product idea, in their own words, before they have built it. This page says plainly what is held, who touches it, how long it stays and how to take it back.
Last reviewed 15 August 2026
What we hold
Account details. Your name, your email address and which seat you hold. All three are supplied by a Pisteyo operator when they invite you. Nobody registers themselves, so nothing here was collected from a form you filled in for us.
Session content. Everything said in a discovery session: the questions, your answers, the sentences you were quoted saying, the list of what the session took as read, the words it wrote definitions for, the diagrams, any document pasted or uploaded into the session, and every version of the brief written from them.
Operational records. Timestamps, how many rounds a session took, how long each one took, sign-in events, errors, and the calls a build machine makes to collect a finished brief. The figures kept for measuring the instrument itself carry no client content at all.
Every company that processes it on our behalf
This list is exhaustive, and it is meant to stay that way: adding a company without adding it here is a defect, not an oversight.
| Company | What it processes | Why |
|---|---|---|
| Clerk | What it processesYour name, your email address and your sign-in events. | WhyAccounts, invitations and signing in. |
| Supabase | What it processesEvery record described above, at rest, in a managed Postgres database. | WhyThe database and file storage. |
| Vercel | What it processesRequests in transit, and platform logs about them. | WhyHosting the application. |
| Resend | What it processesA recipient address and the body of a transactional email. No session content travels in one. | WhySending invitations and notifications. |
| Anthropic | What it processesSession answers and the accumulating brief, when it is the configured provider. | WhyGenerating each round and writing the brief. |
| OpenAI | What it processesSession answers and the accumulating brief, when it is the configured provider. | WhyGenerating each round and writing the brief. |
| OpenRouter | What it processesSession answers and the accumulating brief, when it is the configured provider. | WhyGenerating each round and writing the brief. |
| OpenAI embeddings | What it processesShort passages of brief and session text, turned into numeric vectors. | WhySearch across your own engagements. A separate call from the provider running the conversation. |
Exactly one model provider is active at a time, chosen by an operator. The vectors that make search work are computed by a separate call to OpenAI regardless of which provider is running your session, which is easy to miss and is why it has its own row above.
No model is trained on what you say
Session content is sent to the configured provider for one purpose: generating the next question and writing the brief. It is never sold, never used for advertising, and no provider is authorised to train on it. The application calls the providers through interfaces whose terms exclude training by default, and the admin screen offers no provider or endpoint where that is not true.
How long it is kept
Nothing expires on a timer. Your brief is a deliverable, and deleting it quietly a year later would be worse than keeping it, so session content stays for the life of the engagement and for at least twenty-four months after it ends. Coming back to a build the following year still finds it.
It goes when a Pisteyo operator deletes the engagement, which removes its sessions, its briefs and every version of them, the list of what was assumed, the words that were defined, the outside systems that were named and the vectors derived from all of it, together and at once. Within thirty days of that the same is true of our backups. Operational logs are kept for twelve months. Aggregate figures about the instrument itself are kept indefinitely, because they contain nothing about anybody.
Who can reach it
You reach the engagements you have been attached to, and nothing else. That boundary is enforced by the database on every query rather than by the screens, so a page that forgot to ask still returns nothing. Pisteyo operators reach every engagement, because running them is the job.
One machine door exists. A build machine holding a token issued by Pisteyo can collect a finished engagement by its build code. The build code itself is an identifier, not a secret, and grants nothing on its own. That door carries no keys, no account data and no other engagement.
Taking it with you, and closing your account
Settings, then Account exports everything attached to you as a file you can keep: your profile, and for each engagement you belong to, the transcript, the list of what was assumed, every brief version and the outside systems named. It is written by the same renderer that serves the build machine, so what you get is what a builder gets.
The same page closes your account. It is a real deletion and not a flag: you confirm by typing your own email address, and your sign-in identity, your account record and every engagement membership are removed.
What closing your account does not delete, stated plainly. The engagement content stays. A transcript, a list of assumptions and a brief belong to the engagement, which belongs to the client organisation, not to whoever happened to be at the keyboard; after your account is gone, those records are attributed to the session alone. If a client organisation wants its engagement content destroyed, it asks Pisteyo, who deletes the engagement, and that takes everything with it.
What does not apply here
Autolace holds no health information, no payment details, no card numbers, no biometrics and no data about children. It charges nobody, so there is no billing record to protect. The commercial sensitivity of what you describe in a session is real, but it is a matter for the agreement between you and Pisteyo rather than for this page; do not mistake a privacy policy for that agreement.