simse Privacy Policy

Effective date: 27 September 2026

Revised 30 September 2026 — Section 9.3 now says which of the files a command leaves inside a running cloud sandbox a conversation's deletion reaches: those in the conversation's working folder and in its own temporary folder, which are also moved aside while another of your conversations uses that sandbox. Files a command writes anywhere else in the sandbox stay until it shuts down or you delete your account.

Revised 29 September 2026 — the backup store inside our own cluster, which Section 13 named as not encrypted at rest, now sits on its own encrypted volume, its key sealed to the machine's security chip like the rest; Section 13 says so and records the date.

Revised 28 September 2026 — deleting your account now cancels a paid subscription at the payment processor before our record of it is erased; Sections 2, 9.2 and 9.3 say so. Deleting your account, or a conversation, now also deletes the files in the cloud sandbox workspaces it covers and the history of their versions, which neither had reached before; Sections 8 and 9.3 say so.

Revised 27 September 2026 — Cloudflare Web Analytics and Cloudflare Zaraz had been running on every page of our websites, for every visitor, without this policy naming them. Zaraz is now switched off, and Web Analytics runs only on simse.dev and only if you allow analytics in the cookie banner. Sections 2, 3.3, 3.4, 4, 6, 8, 9.1, 10.1, 10.2 and 11 describe the position. The same revision corrects statements that had drifted from how our systems work: no model training runs and the selection of training data does not yet honour the training setting (Section 5.6), and our backups include a copy inside our own cluster whose history from before 13 August 2026 has no expiry date (Sections 8.1 and 13). Sections 2, 3.3, 4, 5.4, 6, 8, 9.2, 9.3, 13 and 16 now also state what a sign-in records, what Cloudflare handles in transit and holds in backups, how long plugin, usage and mailing-list records are kept, that deleting your account pseudonymises the account record, does not reach sandbox workspace files and does not cancel a subscription, which backups are restore-tested, and where the command-line tool keeps its state. Section 10.4 now names the pages where each in-product request is made, and Section 16 says that the CLI sends a resumed session's earlier turns and your instruction files with your prompts.

Revised 26 September 2026 — your stored files are now backed up off-site each night, so Section 8.1 lists them with the 30 days after which those copies expire; and a tamper-evident copy of our audit record, including your account's security events without their IP addresses, is now also kept off-site, which Section 8.1 describes.

Revised 15 September 2026 — an inference credential is now provisioned, so the statements that none existed and that the path was not serving have been corrected throughout. The credential is a consumer-subscription one, which carries no data processing addendum and no transfer instrument; the commitment to process customer content only under a commercial API credential is unchanged, and the platform holds no customer accounts.

This policy explains what we do with your personal data when you use simse — the simse.dev app, the developer portal at platform.simse.dev, the API at api.simse.dev, and the scribe command-line tool.

Read Section 2 if you have one minute. Read Section 5 if you want to know what happens to the things you type into the assistant.

Schedule A — Entity particulars

These are the only blanks in this document. Everything else is decided. Fill each one in at publication, and fill in the effective date above.

Wherever this policy says "we", "us" or "simse", it means the entity named at A-1. We have not appointed a Data Protection Officer. We are not required to: our core activity is neither large-scale processing of special-category data nor large-scale systematic monitoring. Our designated privacy contact is privacy@telor.dev.

1. Who we are and how to reach us

We are the controller for the personal data described in this policy — we decide why and how it is processed.

If you use an application built by one of our developer customers, and that application runs on simse, then that customer is the controller of your data, not us — see Section 12.

2. The short version

3. What we collect, and where it comes from

3.1 Data you give us

3.2 Data we get from other people

3.3 Data we generate about your use

3.4 What we do not collect

We do not store a password, a password hash, a two-factor secret, or a recovery code — sign-in is passwordless, so none of those exist. We do not collect precise geolocation. We do not store your card number: card details go directly to Stripe, and we hold only Stripe's identifiers and the payment status. We run no advertising network and no ad pixels. The only third-party analytics is Cloudflare Web Analytics on simse.dev, and it runs only if you allow it (Section 11).

You can type anything into a prompt. Do not paste passwords, API keys, other people's personal data, or special-category data (health, race, religion, politics, sexual orientation, biometrics, trade-union membership). We do not ask for it, we do not want it, and we do not process it as a category — but if you paste it, it is processed like the rest of your prompt, including the transfer described in Section 5.

4. Why we process it, and our lawful basis

For the two legitimate-interest purposes (9 and 10), we balanced our interest against your rights before relying on it: the data is minimised, it is not combined with anything bought from a data broker, it is never used to advertise to you, and you can object at any time (Section 9). Ask privacy@telor.dev if you want the balancing assessment.

Where consent is the basis (purposes 8, 10a and 12), you can withdraw it at any time: for 8 and 12 in Account → Privacy, and for 10a through Cookie settings in the footer of every public page or in Account → Privacy → Cookies. Withdrawal is one step, it takes effect straight away, and it does not make our earlier processing unlawful. Your analytics answer (10a) is kept only in the cookie_consent cookie on your device, not in the preference ledger below. That is by design: Cloudflare delivers the script only on a request that carries your current "allow" answer, so the record of your permission travels with every request the processing depends on.

The record we keep of these choices. Every time you change one of these preferences we append a dated entry to a preference ledger, with the IP address the change came from, and that history is part of your data export (Section 9.2). For marketing email and for model training the entry is the evidence of your consent, or of your withdrawal of it. For tips and product updates it is not a consent record — the basis there is legitimate interest — it is the record of your objection, or of your withdrawal of an objection. We treat it as binding either way. We are telling you this because the ledger stores all three under one mechanism, and we would rather you knew what the entry against your name means than assume the three are the same thing.

Email in one line. Transactional email — sign-in links, security notices, receipts — is part of the service and cannot be switched off while you have an account. Marketing email is off unless you switch it on. Tips and product updates are on to begin with and off the moment you say so: one toggle at Account → Privacy, or one line to privacy@telor.dev. Those two are the routes, and we act on either immediately. Neither of those two sends is running today — the only email the product sends is transactional. The preferences are live all the same, and a choice you record now is the one we will honour when those sends begin.

5. What happens to your prompts — the AI section

This is the section a careful reader should read twice.

5.1 Your content goes to Anthropic

Every request you make to the assistant is sent to Anthropic to generate the response. simse does not run the model that answers you. All four of our service tiers are proxies to Anthropic's public Messages API, and each maps to a Claude model:

Which Claude model sits behind each tier is ours to change, and the API response does not tell you which one ran: its model field is the name your own request sent, returned unchanged. We neither check it against this table nor replace it with what served — see the AI Transparency Notice, Section 6. One tier is also configured to finish a turn on a second model when the first declines it, and nothing in the response distinguishes that either.

5.2 What exactly is sent

The whole request, as we assemble it, with nothing removed:

• every earlier turn in the conversation, yours and the assistant's;
• the system prompt, including the adaptive-memory entries we recall for you;
• the definitions of the tools the assistant can call;
• every content block — text, uploaded documents and images, tool inputs, and tool results (which is where file contents and command output travel).

We do not redact, mask, filter or summarise any of it first. It arrives at Anthropic byte-for-byte as we built it.

We do not attach any identifier for you. No account ID, no email, no name. Anthropic receives the content of the request and nothing that says whose it is.

Four things inside simse also call Anthropic with your content, and you should know about all of them. When a long conversation is compacted to fit, the text being compacted is summarised by a Claude model. When the platform scores the quality of an answer, the content being scored goes the same way. When it checks an answer against a claim you made, and when it re-asks your own question several times to gauge how consistent the answer is, the same. All four reach the same recipient, on the same terms as Section 5.3 — and like the serving path itself, all four now run: a credential was provisioned on 2026-09-15. It is a consumer-subscription credential, not the commercial API key Section 5.3 commits to, which is why the platform carries no customer accounts while it is the credential in place.

5.3 The terms it is processed under

The account class decides everything in this section, and it is not settled yet. There are two ways into Anthropic's API and they are not the same relationship:

• A commercial API account. Governed by Anthropic's Commercial Terms, which incorporate the Anthropic Data Processing Addendum by reference and take effect on first use of the API — there is no separate signature step. Under that agreement Anthropic acts as our processor: it may process your content only to return our response, and only on our instructions; it does not use your content to train its models; the addendum deems the EU Standard Contractual Clauses (Modules Two and Three) executed and carries the UK Addendum; and inputs and outputs are deleted within 30 days.
• A consumer Claude subscription credential. None of that exists. No data processing agreement, no standard contractual clauses, no processor relationship, and no contractual retention or training term at all — Anthropic's commercial terms say in so many words that they do not cover consumer Claude use.

The credential we hold today is the second class, not the first. One was provisioned on 2026-09-15, so the tiers serve and requests do reach the provider — under a consumer subscription, not a commercial API account. We also hold a commercial API key, and it cannot answer a request: it has no credit balance. So the class is now fixed in fact, and it is the class that carries none of the protections in the first bullet. Section 16.3 of the Terms of Service and clause 15.3 of the Data Processing Agreement say the same thing. So we do not represent the first bullet as governing our calls, and we will not until it does.

What we have committed to, and it is unchanged. Your content will be processed through that provider only under a commercial API credential governed by that addendum. We will not process your content through a consumer-subscription credential. Saying so plainly, as this paragraph has always undertaken to: the commercial key is NOT the one in place, so the first bullet does not govern our calls, and we do not represent that it does. What that commitment means in practice while the second class is the live one is that the platform holds no customer accounts and no customer content has been served on it.

5.4 What that means when you ask us to delete

Because the request we send carries no identifier for you, there is no way to point a deletion request at Anthropic's copy — there is nothing there with your name on it to find. That copy is not deleted on demand. What would bound it depends on the account class in Section 5.3, and that class is now the consumer subscription: under a commercial API account the copy expires on the provider's own 30-day cycle; under a consumer subscription no contractual deletion window applies at all, which is the position today. Nothing of yours has been sent under it, because we do not serve customer content on this credential and the platform holds no customer accounts.

We will not tell you otherwise. Deletion inside simse is immediate and verified within the reach Section 9.3 sets out, and Section 9.3 also lists the things it does not reach; the provider-side copy is bounded by the account class above, not by your request.

5.5 The assistant's web tools, the connectors and plugins you configure, and the commands it runs

Anthropic is not the only party outside simse that can receive your content. Five features send text derived from your conversation to a recipient that is not one of the providers listed in Section 6, and this section describes all five of them.

The first two are the assistant's own web tools. It can search the web and fetch pages when a task calls for it.

• Search sends the query text to DuckDuckGo.
• Fetch retrieves a URL that came up in your conversation. The site at that URL receives the request, and we have no contract with it — it is chosen at that moment, by the task, not by us.

The third is one you set up yourself.

• Connectors. You can register a remote MCP server of your own — a name, a URL, and optionally a bearer token and fixed headers — and attach it to a session, or declare one inline on a single API request. Both are done through the API; there is no connector screen in the web app today, so nothing is registered without an API call you made. When the assistant calls one of that server's tools, we send the host you named the tool's name and the arguments the model wrote from your conversation, together with the token and headers you configured. What the host answers with comes back as a tool result and travels on to the model with everything else in Section 5.2. Asking a connector what tools it offers reaches the host as well, and carries no conversation content.

A connector host is a recipient you chose, not a sub-processor of ours. It acts on your instruction and for your purposes, under whatever agreement you hold with it. We did not select it, we do not direct it, we have no contract with it, and we cannot bind it on your behalf. That is why it is absent from the list in Section 6: putting it there would say we vetted it and stand behind it, and we have not and do not. The absence is the position, not an oversight. Section 4 of our Sub-processors list says the same thing.

How much of this reaches a connector host today. The call that carries your conversation into a connector happens only while the assistant is serving, and since 2026-09-15 it is serving — Section 5.3 records the credential class it serves under. So this leg is live rather than dormant, on a platform that holds no customer accounts. The other leg never waited for it: registering a connector and testing it asks the host what tools it offers straight away, and that request carries no conversation content — only the question.

The fourth is another one you set up yourself.

• Plugins. You can install a plugin from our plugin registry. A plugin runs inside a sandboxed WebAssembly host on our side, and it may call out to the vendor it integrates with. When it does, that vendor receives what the plugin sends it, which can include text drawn from your conversation, together with any credential you configured for that plugin. Those outbound calls pass a single chokepoint, and we record the request and the response there — see Section 8 for how long. As with a connector, the vendor is one you chose: we did not select it, we do not direct it, and it is not in the Section 6 list.

The fifth is a command the assistant runs.

• Commands in the sandbox. Tool commands execute inside an isolated virtual machine. That machine can reach the public internet: the policy on it allows DNS plus outbound HTTP and HTTPS, with no per-host allow or deny list and no inspection of the hostname inside an encrypted connection. So a command the assistant writes can send whatever it reads in your workspace to whatever host the command names. The recipient is chosen by the command as it runs, so there is no company behind this path for us to have a contract with, the same as with fetch above. It is a different path from fetch, though: the check that refuses internal, loopback, link-local and cloud-metadata addresses sits on the fetch tool, not on the sandbox's network, and it does not constrain a shell command. No session has yet run through the sandbox boundary at all, so we describe this as designed rather than as something with an operating record. This is also the path a code repository travels. Our Terms name "repositories you point it at" as one of the third parties simse connects to on your instruction; there is no separate repository integration behind that phrase. The assistant clones from and pushes to a remote by running an ordinary command in the sandbox, so whoever hosts that repository is a recipient under this bullet, and the credential the command uses is one you supplied.

The two web tools run when the assistant decides a task calls for them. A connector transmits nothing unless you registered one and attached or declared it, and a plugin transmits nothing unless you installed it, so both of those paths are yours to switch off by not creating them. The sandbox path is bounded by what you put in the workspace and what you ask the assistant to do, not by a setting we offer. If any of this matters for a piece of work, do not ask the assistant to search or fetch during it, do not attach a connector or a plugin to it, and do not ask it to run commands against it.

5.6 Training our own models — none today, and off unless you turn it on

No model training runs today. The jobs that would train a model are switched off.

When training starts, it will use your conversations, your files and the assistant's responses only if you have switched on "Improve simse for everyone" in Account → Privacy. The setting is off for every new account. It is not pre-ticked, and we treat an account that never made an affirmative choice as opted out. The software that selects training data does not yet check that setting. We will not start a training run until it does, and we will update this policy before we start one.

The record is written either way. That setting governs whether your content may ever be used to train a model. It does not govern whether the record is written. For every request you make to the assistant we write the complete exchange to our analytics warehouse before anything has been decided about it — with the setting off exactly as with it on. Section 8 says how long that record lasts; Section 9.3 says what an erasure request does and does not reach.

Once training runs, only a filtered subset of the turns of accounts that have switched the setting on can enter a training set, and only after account identifiers are stripped and obvious credentials are redacted. You can switch it off with one toggle at any time; that stops future use immediately.

One small model does learn from your data today, and it stays in your account. Your adaptive memory (Section 4, purpose 4) includes a ranking model of its own. It learns from the entries in your memory and from your memory searches, and it uses what it learns only to reorder the results of your own memory searches. It is never shared with another account, and it generates no text. The training setting does not control it, because it is part of the adaptive-memory feature we provide under our contract with you, not one of the models this section is about. It is erased with the rest of your memory when you delete your account.

Turning it off does not change your service in any way. Nothing about the product is better if you opt in, and nothing is worse if you do not.

5.7 Embeddings stay with us

The vectors we use for search and memory are computed on our own hardware, in our own cluster: your text is never sent anywhere to be turned into a vector. The vectors for your memory are stored with your memory in our file store; the vectors for your knowledge library and for citations are stored in our vector store. Both are backed up off-site (Section 8.1) — so a copy of them does leave the cluster in a backup, even though the computation never does. The memory text we recall for a session does leave, because it is part of the request — see Section 5.2.

5.8 No automated decisions about you

We make no decision producing legal effects or similarly significant effects based solely on automated processing. The assistant writes code, text and suggestions; you review, accept or reject them. Nothing in simse automatically decides your eligibility for anything, prices you differently, or scores you.

If that ever changes, we will update this policy and put the Art. 22 safeguards in place — human review, the right to contest, an explanation — before the processing starts, not after.

5.9 You are interacting with an AI system

simse is an AI system. Everything the assistant produces is generated by a model. It can be wrong. Check its output before you rely on it.

6. Who receives your data

We use a small set of providers. Each processes personal data only on our instructions and is bound to protections no weaker than our own, and we stay liable for what they do. The agreement and the transfer safeguard are named per provider in the last column — read the row, not this sentence, because one of the six is not yet on the same footing as the other five, and one more is conditional on a credential we do not yet hold.

Two things are worth stating plainly.

Your sign-in link travels by email. It passes through our mail dispatcher on Cloudflare and then through Amazon SES. It is single-use and expires in 15 minutes, but for those 15 minutes anyone holding it could sign in as you. If you would rather your sign-in credential did not travel by email, use Google sign-in instead. Both give you the same access.

We also disclose data where we must. We will disclose personal data to a court, regulator or law-enforcement body where a valid legal obligation requires it, and to our professional advisers, insurers, or a buyer in connection with a corporate transaction, under confidentiality. We will tell you unless we are legally barred from doing so.

We use Atlassian Jira internally to track work. It is not a customer-data processor: enquiry content is recorded there only as far as it is needed to resolve your request.

We do not sell your personal data, and we never have. We do not disclose it for advertising of any kind.

7. International transfers

We process your data on infrastructure we run ourselves and through the providers listed in Section 6. Every one of those providers is in the United States, so your data is processed there as well.

Where you are in the EEA, the UK or Switzerland, we rely on the European Commission's Standard Contractual Clauses, and for UK data on the UK International Data Transfer Addendum. For Switzerland we rely on the same clauses with the Swiss addendum. The instrument for each recipient is named individually in the Section 6 table, because they are not all in the same state, and the two that are not are the ones we would rather you heard about from us.

The exception: our transactional email provider. Amazon Web Services, which delivers your sign-in link, is the one recipient whose safeguard we have determined but not yet evidenced. The instrument that applies is the AWS GDPR Data Processing Addendum, incorporating the EU Standard Contractual Clauses (Module Two) and the UK Addendum; it takes effect on acceptance of the AWS Customer Agreement, so there is nothing to negotiate. What we have not yet done is confirm and file the sending account's agreement state. Until we have, treat that one transfer as determined but not in force, and read the rest of this section as applying to the four recipients whose instruments are in force — Anthropic being the other one that is not, for the separate reason given below. We will update this section when it is confirmed, and if the confirmation shows the sending account is not ours, we will name the correct provider here instead. What travels that path is your email address and the message body; no account identifier goes with it.

The second exception: the model provider. Anthropic's addendum, and the Standard Contractual Clauses it carries, attach to a commercial API account. The credential in place since 2026-09-15 is a consumer subscription rather than a commercial API account, so no addendum and no transfer instrument is in force. This transfer — the one that would carry the most of your content — therefore has no transfer safeguard in force today, and nothing of yours has been transferred under it either, because we serve no customer content on a consumer-subscription credential and the platform holds no customer accounts. We will not describe a safeguard until the commercial account is in place. Section 5.3 sets out both classes and what changes when it is.

We do not rely on the EU–US Data Privacy Framework as our transfer basis. We are not certified to it. Where a recipient is separately DPF-certified, we treat that as an additional safeguard, not as the basis.

You can ask privacy@telor.dev for a copy of the safeguards that apply to a specific transfer.

8. How long we keep things

These are the periods that are actually applied, not aspirations.

8.1 Backups

We back up our databases, our analytics warehouse and our file store so we can recover from a failure. Backups are not edited when you ask us to delete something. A backup taken before your request still contains your data until that backup expires on its own schedule:

Every set but the last is held off-site with Cloudflare, sent there over an encrypted connection, into buckets that each carry a write-once lock window — inside it a stored object cannot be deleted through the storage service, including by us. That is a property of how the bucket is configured, not a claim the copy is beyond our reach in every sense: whoever administers the storage account can change that configuration. The analytics snapshots are the exception on the lock, and only on the lock. They go off-site like the rest — that copy is running and confirmed — but they carry no write-once lock, because the snapshot process has to delete a marker file of its own to finish and a lock would refuse that. Backups are used only to restore, never to serve. The payment-records window is long because the underlying records are the ones we must keep for 7 years by law; the backup window sits above that floor.

A second backup store, inside our own cluster. Besides the off-site copies, we keep a backup store in our own cluster, on a separate disk from the live data (Section 13 says how it is protected). It holds a second copy of each night's analytics snapshot, which expires on the same 30 days; the second copy of our audit record described below; and the database backups taken before 13 August 2026, when our database backups moved off-site. That older history has no expiry date. We keep it as an archive. It holds the data of the accounts that existed before that date, and like every other backup it is not edited when you ask us to delete something.

Separately from backups, a tamper-evident copy of our audit record is written off-site with Cloudflare under the same kind of write-once lock, set to seven years, and a second copy is written to the backup store inside our cluster, under a seven-year lock that its storage service lets no one, including our own administrators, remove early. It holds the entries that record operations on the platform, such as a completed erasure request, and your account's security events (sign-in, sign-out, API-key and account changes) as your user ID, the action and when it happened. It does not hold the IP address or the other details the security audit log records. It is not edited when you ask us to delete something, for the reason Section 9.3 gives for the audit log.

9. Your rights

If you are in the UK, the EEA or Switzerland you have the rights below. We honour them for everyone, wherever you are, because it costs us nothing to do so.

9.1 What you can ask for

9.2 How to exercise them

In the product, without asking us:

The in-product download covers your account domain: profile, sign-in identities, workspaces, API-key metadata, preferences, consent history, sessions, devices, and your audit trail. It never includes credentials or their hashes. It is limited to three exports per day.

By email, for anything else: write to privacy@telor.dev. That is the route for the complete export across every system — conversations, memory, files, billing, analytics — and for any right you would rather we execute for you. It is also the route if you cannot sign in.

A request is valid however you phrase it. You do not need to cite an article or use a form of words. We will read what you are asking for and confirm our reading back to you.

Verifying it is you. A request made from a signed-in session is already verified by that session. An email request is verified by a link sent to your account address — control of the email is the factor, the same one that signs you in. We do not ask for government ID for an ordinary account request. An authorised agent may act for you with proof of authority plus verification of you.

How long we take. We respond within 30 days of verifying you. For a genuinely complex request, or several requests at once, we can extend by up to two further months — we will tell you within the first month, and why. We charge nothing, unless a request is manifestly unfounded or excessive, in which case we will explain the charge or the refusal. If we decline, we tell you why, and how to complain, within one month.

9.3 What deletion actually does

When you delete your account we run one orchestrated erasure across the systems that hold data keyed to you — account, payments, usage, notifications, conversations, adaptive memory, files, your knowledge library, plugins, project store, the managed bridge, cloud sandbox workspaces, the inference orchestrator, and the vector index. The analytics records keyed to your account are erased in the same operation, and the erasure re-counts your rows afterwards and fails if a single one survives.

Deleting your account cancels a paid plan. Your subscription is held by our payment processor, Stripe, and the deletion cancels it there, immediately, before our record of it is erased, so no renewal is charged afterwards. If Stripe cannot be reached, the cancellation is retried and the deletion is not completed until it succeeds. The part of the period you have already paid for is not refunded; the Terms of Service (Section 16.4) say how to use it first. Until 28 September 2026 the deletion did not reach the subscription, and a renewal charged after an earlier deletion is refunded on request.

Deleting your account deletes your cloud sandbox workspaces. When the assistant works in a cloud sandbox, the files it creates or changes there, and the history of their versions, are stored under a key made from your user ID together with the session. The deletion removes every one of them, for every session and in every workspace you have used, and closes any sandbox session still open. Deleting a single conversation removes that conversation's workspace in the same way. A cached copy of a recent version expires on its own within 24 hours. Files a command leaves inside a running sandbox — build output, temporary files — are not stored with the workspace. Those in the conversation's working folder or in its own temporary folder are moved aside when another of your conversations uses the same sandbox — out of that conversation's working folder, though a command run there could still read them if it looked for them — and deleting the conversation deletes them. Files a command writes anywhere else in the sandbox, such as the shared temporary folder or a cache in the home folder, stay visible to your other conversations in that sandbox and are not reached by deleting a conversation; they are gone when that sandbox shuts down, which happens about 30 minutes after the last activity in that workspace, and when you delete your account. Until 28 September 2026 neither deletion reached these files; if you deleted your account or a conversation before then, write to privacy@telor.dev and we will remove them.

Four things the deletion does not do, and we would rather you heard them from us.

1. It does not reach backups. See Section 8.1.
2. It does not reach Anthropic's copy. See Section 5.4. Under a commercial API account that copy expires within 30 days; under a consumer subscription no contractual deletion window applies to it at all. We hold neither class today, and nothing has been sent under either.
3. It does not delete our security audit log or our statutory billing records. The billing records we must keep for 7 years (Art. 17(3)(b) — a legal obligation); the usage records we bill from are kept with them, under a pseudonym (Section 8). The audit log we keep as a security and legal-claims record (Art. 17(3)(e)); your account record is pseudonymised instead. The audit entries survive and keep your user ID and the IP addresses recorded at the time. They are edited in exactly one respect: an entry recorded by an email-change action has the address it captured overwritten with a fixed placeholder, because keeping the row is our security interest and keeping the address is not. Section 8 says the same in the table.
4. The full record we keep of each AI exchange is only partly reached. The exact statement — which entries, and why — is the paragraph immediately below, set outside this list because the AI Transparency Notice (Section 7) reproduces it word for word and the two must stay byte-identical. Sections 5.6 and 8.

It does not reach every entry in the full record we keep of each AI exchange. Most entries carry your account identifier, written at the time of the request: those are the exchanges we served for you, through the app and through our API. Deleting your account erases every entry that carries it — we run the deletion, then re-count the record to confirm nothing of yours is left, and the deletion fails rather than reporting success if anything survives. Entries that carry no account identifier but do carry a reference to one of your conversations are erased through that reference instead. What remains are the entries that carry neither, and we would rather name them than let you assume they do not exist. They are entries written through our API before we added the identifier, which carry no conversation reference either; for those the link to you was never recorded, and we cannot go back and add it. They are not erased on request. They expire on the 90-day window instead.

Our own systems also pass your content back through a model to check it, verify it, score it or summarise it, and those entries used to fall in the same gap. They no longer do: your account identifier now travels with those internal requests, so they are erased with everything else that carries it. The same is true of the two smaller per-generation records described above — both now carry the identifier and are erased with it. Separately, two further classes of entry carry neither identifier, and neither of them is about you. Our own model evaluation and training runs produce entries that come from our scheduled work rather than from anything you did, and hold no content of yours. And we ran a one-time import of transcripts of conversations held outside simse: those entries do carry conversation content, but not yours — the transcripts came from outside this service and were never linked to an account here, so there was no account identifier to record and we will not invent one after the fact. Neither class is erased on request; both expire on the same 90-day window. In every case a backup snapshot taken while an entry was live is not edited either — that copy ages out on the warehouse's own 30-day backup window.

9.4 Complaints

If you think we have got this wrong, tell us first — privacy@telor.dev. We would rather fix it than have you find out from a regulator that we did not.

You do not have to come to us first. You have the right to complain to a data protection supervisory authority:

• UK: the Information Commissioner's Office, ico.org.uk.
• EEA: the authority in the country where you live, where you work, or where the problem happened. We have no lead supervisory authority — Art. 56 fixes one by main establishment in the Union and we have no Union establishment (Schedule A, A-6). Any of the three authorities above is the right one to go to; you are not required to find a single "lead" regulator first.
• Switzerland: the Federal Data Protection and Information Commissioner.

You can also go to court.

10. US state privacy rights

This section is for residents of California, and of every other US state with a comprehensive consumer-privacy law — Virginia, Colorado, Connecticut, Utah, Texas, Oregon, Montana, Iowa, Delaware, New Jersey, New Hampshire, Nebraska, Minnesota, Maryland, Tennessee, Indiana, Kentucky and Rhode Island among them.

Everything in Sections 3 to 9 applies to you too. This section restates it in the terms those laws use.

10.1 Categories of personal information we collect

Over the past 12 months we have collected these CCPA categories:

The retention period or criteria for each is in Section 8.

10.2 We do not sell and we do not share

We do not sell personal information. We do not share personal information for cross-context behavioural advertising. We have never done either. We run no advertising, no ad-tech, and no targeted-advertising programme of any kind. Disclosures to the providers in Section 6 are to service providers, on terms that forbid them using your data for anything but the service they perform for us — that is neither a sale nor a share. The instrument in place for each is named in the Section 6 table, including the one we have determined but not yet confirmed in force.

Because there is no sale or sharing, there is nothing for an opt-out preference signal such as Global Privacy Control to switch off. If your browser sends one, no sale, sharing or targeted advertising is happening to switch off in the first place, and we will not start. We honour it anyway for the one thing it can reach: a browser that sends it never runs Cloudflare Web Analytics (Section 11). Cloudflare processes those measurements for us as a service provider, under its data processing addendum, which is neither a sale nor a share.

10.3 Sensitive personal information

We do not collect sensitive personal information as the CPRA defines it, and we do not use any to infer characteristics about you. We hold no account credentials — sign-in is passwordless — and we collect no precise geolocation, no biometrics, and no health, racial, religious, political, union-membership or sexual-orientation data.

You can type anything into a prompt, and we cannot stop you. We ask you not to (Section 3.4). If you do, we do not treat it as a category, we do not use it to infer anything about you, and we never disclose or sell it for advertising.

The right to limit the use of sensitive personal information therefore has nothing to bite on. Ask us anyway if you want, at privacy@telor.dev, and we will confirm in writing that no qualifying use occurs.

10.4 Your rights in these states

Two ways to submit a request, as California requires: in the product — Account to correct your profile or delete your account, Account → Privacy to download your data — or by email to privacy@telor.dev.

California timing. We acknowledge your request within 10 business days and respond within 45 calendar days, extendable once by a further 45 days with notice. Where more than one law applies to you, we apply the shortest deadline. The right to know covers at least the 12 months before your request, and further back on request where we still hold the data.

Authorised agents may submit a request on your behalf with proof of authority and verification of you.

10.5 Appeals

If we refuse a request, you can appeal by replying to our decision or writing to privacy@telor.dev with "Appeal" in the subject. We will respond in writing, with our reasons, within 45 days. If we deny the appeal, we will tell you how to contact your state Attorney General.

10.6 Non-discrimination

We will not deny you service, charge you a different price, give you a worse product, or retaliate in any way because you exercised a privacy right. We run no financial-incentive or loyalty programme, so there is no "pay for privacy" trade anywhere in simse.

11. Cookies

Our Cookie and Tracking Notice is the full account — every cookie, every browser-storage key, and everything that loads from a third party. It governs where it is more specific than this section. Here is the summary.

We set four first-party cookies on simse.dev and its subdomains, and all four are strictly necessary — the service does not work without them:

The three sign-in cookies are HttpOnly and Secure: scripts cannot read them and they travel only over HTTPS. cookie_consent is set by the page rather than by our server, so scripts on our own site can read it — it holds nothing about you beyond your cookie choice, when you made it, and the version of the banner's categories you answered. All four are SameSite=Lax, so the browser does not attach them to cross-site requests that could act on your behalf.

We used to set a fifth, plan_intent, which remembered which plan you clicked so the choice survived sign-up. It was a convenience rather than a necessity, which meant it was not exempt from consent, so we removed it instead of asking you to accept a cookie for a pre-selected plan card. Nothing replaced it.

We set no advertising cookie, no analytics cookie and no tracking pixel. Two third parties can run scripts on our sites. On the checkout and billing-settings pages we load Stripe's payment library, so your card details go straight to Stripe and never touch our servers. Stripe sets its own cookies on those two pages, for fraud prevention and to keep the payment form working, under Stripe's own privacy policy. If you allow analytics in the cookie banner on simse.dev, Cloudflare adds its Web Analytics script to the simse.dev pages it serves you. It reports to Cloudflare the page's address, the page you came from and how long the page took to load; it sets no cookie and stores nothing in your browser. It does not run without your permission, when your browser sends Global Privacy Control, on the pages where you pay, or on platform.simse.dev or the status page. Cloudflare Zaraz, which ran on every page until 27 September 2026, is switched off. The Cookie and Tracking Notice describes all of this in full. No other third-party script, frame or pixel loads on simse.dev or platform.simse.dev: every page of both carries a content security policy naming the origins a browser may load from, and on platform.simse.dev that list has no third-party origin on it at all.

There is a cookie banner, and it records your answer in cookie_consent across two categories — functional and analytics. The functional category is empty. The analytics category is Cloudflare Web Analytics, above. Nothing in either category runs, and no cookie in either is set, unless you have allowed that category, and before we add anything to either we will update this policy and the Cookie and Tracking Notice and ask you again. Answers given before 27 September 2026, when the analytics category came to cover Cloudflare Web Analytics, are not relied on: the banner asks again.

Clearing session and refresh signs you out. Blocking them means you cannot sign in.

12. If you reached simse through someone else's product

Developers build on our API. If you are the end user of one of their applications, that developer is the controller of your data and we are their processor. We process it on their documented instructions, under a data processing agreement, and we do not decide what it is used for.

Send your request to them. If you send it to us, we will not action it against their data — we will pass it on to them without undue delay and help them answer it. Tell us who they are so we can route it.

13. Security

• Sign-in is passwordless. We store no password to lose.
• Data at rest is on encrypted volumes. The live databases, the analytics warehouse and the object store that holds your files sit on one encrypted volume, and the backup store inside our own cluster — the database backups taken before we moved them off-site on 13 August 2026, a second copy of the analytics snapshots and a second copy of our audit record, all described in Section 8.1 — sits on a second, on its own disk. Both keys are sealed to the machine's security chip, and the off-site backup copies are encrypted at rest by the provider that holds them. This protects your data if a disk ever leaves our control — theft, a returned faulty drive, a decommissioned machine. It is not a defence against someone who has already taken over the running server, and we would rather say that than let the word "encrypted" do more work than it can. Until 29 September 2026 the backup store inside our cluster was not encrypted at rest. Our secret store adds a second layer of encryption over service credentials, and every stored credential is encrypted again underneath that by the cluster itself.
• Traffic between you and us is TLS, terminated at our edge provider and carried into our cluster over an authenticated tunnel. Between the two, the edge provider, Cloudflare, handles the traffic unencrypted (Section 6).
• Every internal service call carries a short-lived cryptographic identity that the receiving service verifies, and network policy restricts which services can talk to which.
• Your data is scoped to your user ID in the stores that hold your account, your conversations, your files and your memory. In the full record we keep of each AI exchange, the scoping is partial and we would rather say so than let you assume otherwise: entries written for a request we served for you carry your user ID, and so do the entries our own systems produce by passing your content back through a model — to check, verify, score or summarise it — because that identifier now travels with those internal requests. Entries written through our API before we added the identifier carry none for you at all, and neither do the entries from a one-time import of transcripts of conversations held outside simse, nor those from our own scheduled model evaluation and training runs — and neither of those last two holds content of yours. Section 9.3 item 4 says what that means for erasure; see also Section 8.
• Administrative access is restricted to a small operator group, using key-only access and least-privilege credentials. There is no public administrative interface.
• Sign-in links are single-use and expire in 15 minutes. Sign-in endpoints are rate-limited.
• We keep an append-only audit log of account actions. Deleting a row is refused by the database itself — a trigger on the table blocks it, for our operators as much as for the service — and the only way past it is a documented break-glass setting a person has to switch on for the one statement that needs it. Update is deliberately left unguarded, so that an ordinary schema change does not have to reach for the break-glass. One product path uses that: when you delete your account, the erasure overwrites the email address captured by any email-change entry with a fixed placeholder (Section 9.3). Nothing else in the product updates a row.
• Every day we restore the latest backup of each of our five databases into a throwaway environment and verify the result. Every night we also restore the new analytics-warehouse snapshot from its off-site copy into a scratch database, check that every table came back, and discard it. The other stores are not restore-tested: the nightly copy of our file store is compared with the original file by file, by name and size, which shows the copy is complete but is not a restore, and the snapshots of our secret store are not tested.

No system is perfectly secure. If you find a problem, tell security@telor.dev.

If a breach affects your personal data and is likely to result in a risk to your rights, we will notify the relevant supervisory authority within 72 hours of becoming aware, and we will tell you directly where the law requires it.

14. Do you have to give us this data?

No law requires you to give us anything. But we cannot give you an account without an email address — it is how we sign you in and how we contact you about your account. That is a contractual requirement: without it there is no account.

Everything else is optional. You do not have to set a display name. You do not have to sign in with Google. You do not have to opt into marketing or model training, and declining either changes nothing about the service you get. You choose what to put in a prompt.

15. Children

simse is a professional developer tool. It is not directed to children and we do not knowingly collect personal data from anyone under 16. If we learn that we hold a child's personal data, we delete it. If you believe a child has given us personal data, tell privacy@telor.dev and we will remove it.

16. The command-line tool

The scribe CLI keeps its own working state on your machine, in three places:

• your sign-in token, and any instructions file (SCRIBE.md) you write for every project, in ~/.scribe in your home folder;
• your session history, installed plugins and settings, in your system's configuration folder — ~/.config/scribe on Linux, ~/Library/Application Support/scribe on macOS, and %APPDATA%\scribe on Windows;
• settings for a project, in a .scribe folder inside that project.

We do not collect these files as such. But the CLI sends some of what they hold to the platform as part of your prompts: when you resume a session, its earlier turns go with your next prompt; and your instruction files (~/.scribe/SCRIBE.md, and a project's SCRIBE.md or CLAUDE.md), together with any agent or skill you use, go with the conversation.

Anything the CLI sends to the platform is covered by this policy in full, including Section 5. Running the assistant locally does not keep your prompts local.

17. Changes to this policy

If we change how we use your data in a way that matters, we will update this policy, change the effective date at the top, and tell you — by email or in the product — before the change takes effect. We will not quietly repurpose data you have already given us.

Section 6 is our list of providers. If we add one, we will update this policy and publish the change before that provider starts processing your data, so you have time to object or to close your account.

18. Questions

privacy@telor.dev — for anything in this document, and for every data-rights request.

We answer.