AI Transparency Notice

Effective date: 27 September 2026 · Version: 1.3

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.

Revised 28 September 2026 — rooms: the API now refuses a posted message that declares the assistant role, so §1, §2 and §6 limit the rooms qualification to entries posted before this date.

Revised 27 September 2026 — §2 no longer says that no generation is served: it has been served since 15 September 2026, as the rest of this notice already said. §7 now says that no training run is running, that the Training data preference is not yet read by the step that would select training data and that no run will start until it is, that a per-account ranking model learns from your memory entries to order your own memory searches, and that the sampled record for comparing candidate models and our own evaluation and training runs are switched off and write nothing. §1, §2 and §6 no longer present role as proof of model output in a room, where a message posted through the API declares its own role. §3, §6 and §9 now name the marketplace plugin that can generate images, which is switched off for every account.

This notice tells you how simse uses artificial intelligence, what the system can and cannot do, and how generated output is marked. It applies to simse at simse.dev, the scribe command-line client, and the API at api.simse.dev.

It sits alongside the Privacy Policy (what we collect and why), the Terms of Service (the contract), and the Acceptable Use Policy (what you may build). Where this notice and the Privacy Policy both describe the same processing, the Privacy Policy governs the data-protection position and this notice governs the AI-specific one.

Schedule A — Entity particulars

The operator completes this block before publication. Nothing else in this document is left open.

References below to "simse", "we" and "us" mean the entity named at A-1.

No AI Act authorised representative is listed here, and that is deliberate rather than an omission: Art. 54 attaches to providers of general-purpose AI models placed on the Union market. simse does not place a model on the market — it uses a third party's (§2) — so the appointment is not owed.

At a glance

• Every answer you get from simse is written by an AI model, not a person (§1).
• The model is Anthropic's, not ours. Your prompts, files, tool output and conversation history are sent to it verbatim on every request (§2, §3.1).
• The assistant's web tools send data out too — the search query it composes, and the address of any page it fetches — to parties we have no contract with (§3.2).
• The output is often wrong. Read it, test it, do not ship it unread (§4, §5).
• Generated responses are marked as model output in the API response itself. The response also repeats back the model name your request asked for; that is your own string returned unchanged, not our statement about what ran (§6).
• We keep a full record of each exchange for 90 days. Most entries carry your account identifier, so deleting your account erases them; a residual set carries neither that identifier nor a reference to one of your conversations, is not erased on request, and expires on the 90 days instead (§7). No model training runs today, and we will not train a model on your content without your opt-in. The one exception is a small model per account that learns from your memory entries and searches only to order your own search results (§7).

1. You are interacting with an AI system

Every response simse gives you is generated by an AI model. Nothing the assistant generates for you is written by a person. The plans it proposes, the code it writes, the explanations it gives and the actions it takes through tools are all model output.

One qualification, in rooms, for entries before 28 September 2026. Until that date a message posted to a room through the API could declare its own role as the assistant's, so a room entry from before then shown as the assistant's is not guaranteed to be model output (§6). Since then the API refuses that role.

We tell you this at the point you first meet the system, not only here:

• scribe says it in the welcome banner, before your first prompt.
• The web app says it in the empty conversation, before your first message.
• Rooms say it in the empty transcript, because a room can be opened directly.

2. Which models generate the output

User-facing generation is served by Claude models operated by Anthropic, over Anthropic's public Messages API. simse routes your request to one of four serving tiers depending on the work. Whichever tier takes it, the request reaches Anthropic and nothing inside simse generates the answer. simse does not run a generative model of its own on any user-facing path.

Generation has been served since 15 September 2026. Requests to the assistant are answered by Anthropic under a consumer-subscription credential. What that credential class is, and what it decides about the terms your content is processed under, is set out in the Privacy Policy (Section 5.3) and on the Sub-processors page.

Search and memory embeddings are computed on our own hardware, in our own cluster. They are not sent to a third party.

The response's model field is the string your request sent, returned unchanged. We do not validate it against our tiers on the generation endpoint and we do not replace it with what actually ran, so it is not a statement by us about which model produced the content. Two consequences worth being explicit about, because neither is obvious from reading a response:

• If you send an Anthropic model name, we route it to the tier we map that family to and return your name to you. The name you get back can therefore be a real model id that is not the one that ran.
• One tier is configured to complete a turn on a second model when the first declines it. A response from that tier can have been produced by either, and nothing in the response distinguishes them.

Nothing in the API identifies the model that served a given request. If you need that guarantee, we cannot give it today — treat the field as an echo, and treat role on a generation response as the marking that the content is model-generated. In a room transcript that holds for entries from 28 September 2026 on; earlier entries posted through the API could declare the role (§6).

Anthropic is listed as a sub-processor in the Privacy Policy.

3. What we send outside simse

Four paths carry your content out of simse today: the model provider, the assistant's web tools, a connector you configured, and a command the agent runs inside its sandbox. Each has its own section below.

A fifth is built and switched off for every account: a marketplace plugin that would send a prompt the model wrote from your conversation to Cloudflare Workers AI, under your own Cloudflare credentials (§6). Nothing travels on it today, and this notice changes before anything does.

3.1 To the model provider

To generate a response, simse sends the provider the request as it assembles it. That includes:

• the full conversation history — every earlier message in the thread, yours and the model's;
• the system prompt, including any memory entries simse has recalled for you;
• the definitions of the tools the assistant may call;
• every content block you supplied — text, and any documents or images you uploaded, byte for byte;
• tool inputs and tool results, which is where file contents and command output travel.

Nothing on that path is redacted, minimised or pseudonymised. If you paste a secret, a customer record or a private document into a conversation, it is sent.

We do not attach your account identifier or email address to the request. The provider receives the content, not a name for you.

That has a consequence you should know: because the request carries no identifier for you, we cannot ask the provider to delete one specific past request on your behalf. Deletion of your account data in simse's own stores works normally and is described in the Privacy Policy, which sets out what it does not reach — including the exception described in §7 below, which you should read. The provider's own handling and retention of what it receives is governed by the provider's terms.

Do not put data into simse that you are not permitted to disclose to a US processor.

3.2 To the web, through the assistant's tools

The web tools send data out too. The assistant has a web search tool and a web fetch tool, and it decides when to call them. On your own machine you can switch them off with a deny rule in scribe's settings, which every path honours — including the unattended ones. Where simse runs the agent on its own servers, there is no per-account setting for them.

• Search. The query the assistant composes — written from your conversation — is sent to DuckDuckGo.
• Fetch. The page named in the conversation is requested from whoever hosts it. That recipient is chosen at the moment of the request and can be any site on the internet.

We have no contract with either recipient, and neither is a sub-processor of ours. What they do with what they receive is governed by their own terms, not by ours, and is outside our control. Where the assistant runs on our servers the request leaves from us; where it runs in scribe on your machine it leaves from you.

Do not ask the assistant to search for, or to fetch, something you are not permitted to disclose to a stranger.

3.3 To a connector you configured

You can register a remote MCP server of your own and make its tools available to the assistant: a name, a URL, and optionally a bearer token and fixed headers. A connector is attached to a session, or declared inline on a single request. Both are done through the API. There is no connector screen in the web app today, so if you are looking for one to check what is attached, look at the session or the request instead.

• Listing. Before a turn can use a connector, we ask the host you named what tools it offers. That request carries no conversation content.
• Calling. When the model calls one of those tools, we send the host the tool's name and the arguments the model wrote from your conversation, with the token and headers you configured. What the host answers with comes back as a tool result, and travels to the model on the next turn together with everything else in §3.1.

The connector host is not a sub-processor of ours, and the reason differs from the one in §3.2. A web-fetch target has no fixed company for us to contract with. A connector host does — but you named it. It acts on your instruction and for your purposes, and whatever governs it is your agreement with it rather than ours. We do not vet it, do not direct it, and cannot bind it for you, which is why it is absent from our sub-processor list and disclosed here instead.

Which of the two legs is live today. The calling leg happens only while the assistant is serving, and since 2026-09-15 it is: a credential is provisioned and a request to the assistant is answered rather than refused. So both legs can reach a connector host you configure. The listing leg does not depend on that — registering a connector and testing it asks the host what tools it offers straight away, and that request goes out now, carrying no conversation content.

A connector transmits nothing until you create one. Do not attach a connector to a conversation you are not permitted to disclose to the company behind it.

3.4 To a host a command the agent runs reaches

When the assistant runs a tool command, that command executes inside an isolated virtual machine. That machine has outbound network access, and the policy on it is coarse: DNS, plus outbound HTTP and HTTPS to the public internet. There is no per-host allow or deny list on it, and nothing inspects the hostname inside an encrypted connection. The Acceptable Use Policy states the same policy from the sandbox side.

So a command the model writes — a curl, a git push, a package publish — can send whatever it reads in your workspace to whatever host it names. The recipient is chosen by the command at the moment it runs. There is no fixed company behind this path for us to contract with, exactly as in §3.2, and it is not a sub-processor of ours for the same reason.

This is not the same path as §3.2. The web tools are two named tools whose destinations we can describe: a fixed search provider, and a URL the conversation named after our own check refuses internal, loopback, link-local and cloud-metadata addresses. A shell command is arbitrary, that check does not sit on it, and we do not enumerate what it may reach.

What is true of it today. No customer session has yet run through the sandbox boundary at all, so this path has no operating record behind it — and while the assistant does now serve — a credential was provisioned on 2026-09-15 — no customer session has run through this boundary, so no model has composed commands to run on anyone's content but our own. That is why the path is described here as designed rather than as observed.

Your control over it. Do not ask the assistant to run commands against content you are not permitted to disclose, and treat a workspace you give it as a workspace whose contents a command could send outward.

4. What the output can get wrong

Model output is a prediction, not a lookup. It is wrong often enough that you must treat it as a draft.

• It fabricates. It will confidently name functions, flags, files, packages, APIs and sources that do not exist.
• Generated code can be defective. It can contain bugs, race conditions and security vulnerabilities, and it can reproduce patterns whose licensing does not suit your project. It is not audited before you receive it.
• It is not repeatable. The same prompt can produce a different answer.
• It has no live view of the world. Its knowledge has a cutoff. Where the assistant searches or fetches the web, it is reading third-party pages we do not vet, and it can be misled by them.
• It can misread what you asked for and act on the misreading, including through tools that change files or run commands.
• It is not professional advice. Output about legal, medical, financial, tax or safety matters is not advice and no professional relationship arises from it.

5. Review the output before you rely on it

You are responsible for what you accept. Read generated code before you merge it, test it before you ship it, and verify facts before you repeat them.

Where the approval prompt sits differs by surface, so it is worth stating plainly:

• On your machine (scribe). The client asks for your approval before it writes a file or runs a shell command. Unattended invocations — scribe --print, the ACP server your editor connects to, the remote daemon — refuse a call that would need approval rather than proceeding without it. That gate covers what the assistant decides to do. It does not cover a command sent to the remote daemon over the dashboard channel: the daemon runs those on your machine as issued, with no prompt. The daemon is off unless you start it, and any valid credential for your account can drive it — so start it only on a machine you are content to let your account command.
• On our servers. Where simse runs an agent for you server-side, tool calls are not gated by an approval prompt. They execute, and you see the result afterwards. Scope what you give those runs accordingly.

6. How generated output is marked

The EU AI Act requires providers of systems that generate synthetic content to mark that content in a machine-readable form. simse marks at the boundary it controls — the response.

Machine-readable. Every response from the generation endpoint is a JSON object in which role is "assistant". We set that field; it is always "assistant" on generated content, and the published API schema requires it. The model field alongside it is your request's own string, returned unchanged. We neither validate it against our tiers on this endpoint nor overwrite it with what ran, so it identifies nothing about the model that served you (§2).

Two limits on that, stated rather than left for you to discover. The schema requirement covers the buffered response; the published schema does not currently describe the events of a streamed response at all, so on a stream the two fields rest on our practice, which is to put both on the opening message_start event every time. And a client parsing a simse response learns that the content is machine-generated, without inspecting the text and without a detector of its own — it does not learn which model produced it.

In the interface. Each turn in the conversation is labelled — your turns as yours, the model's as the model's.

Replayed transcripts. When simse replays a stored conversation back to you — resuming a session, loading a room's history — assistant turns carry the assistant role marking.

In a room, the marking holds from 28 September 2026. A message posted to a room through the API may declare the role user, moderator or system; assistant is refused, so the only assistant entries are the replies a room turn generates. Before that date the API accepted assistant from whoever posted, so a room's earlier assistant entries are not guaranteed to be model output.

What we do not do, and why. We do not embed a watermark inside the generated text or inside generated source code. Two reasons, both structural:

1. The only technique proposed at scale for natural-language text is applied at sampling time by whoever runs the model. simse does not run the model on any user-facing path (§2), so it has nothing to watermark into.
2. For source code there is no accepted technique at all. A mark placed inside code is either a syntax error or a comment — and a comment is not a marking scheme: it is removed by ordinary editing and it changes the artefact you asked for.

The Act requires marking that is effective and robust so far as is technically feasible, taking the state of the art into account. Marking the response is what is feasible and robust today; we do it, and we commit to keeping role and model on every generated response — buffered and streamed — for as long as this notice stands.

Today we generate text and source code only. No path that serves you produces an image, audio or video. simse can read an image you upload.

One marketplace plugin can generate images, and it is switched off. The plugin, wai, generates text and images with Cloudflare Workers AI, using your own Cloudflare credentials. It ships with the product, but its tools are switched off for every account and nothing switches them on. Before we switch it on we will update this notice, including how the images it generates are marked.

7. Records we keep, and training

Running your prompt through a model to answer you is not training. It is how the product works, and it happens on every request.

We keep a full record of each request and response. For every generation, simse writes the complete exchange to its own analytics warehouse: the system prompt, your messages, the tool definitions and tool results, the model's text, and its usage and cost figures. That record is what we use to debug failures, measure quality, and — subject to the paragraph below — build any future training set. Before it is written, the text is passed through automated redaction that replaces detected secrets and detected personal-data patterns with [REDACTED]. The record is kept whether or not the Training data setting described next is on.

We keep two smaller records of the same exchange, and their redaction is weaker. One is written on every generation we serve. The other is designed to be written on a sampled fraction of them, to compare candidate models; its sample rate is set to zero everywhere, so it is switched off and nothing is written to it today. Each holds, or would hold, your request text with detected secrets removed — but not with personal-data patterns removed. Both carry your account identifier and are erased with everything else that does.

That record is bounded by time, and partly by an erasure request. We keep it for 90 days, after which it is deleted automatically. What an erasure request reaches inside those 90 days is stated below, in the same words the Privacy Policy uses.

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.

This paragraph is reproduced word for word in the Privacy Policy (Section 9.3, item 4); if the two ever differ, treat that as a defect in one of them. So this record sits partly inside the deletion position in §3.1 and partly outside it — say which part, rather than rounding it to either end. Erasure of your account data in simse's other stores is described in the Privacy Policy and is unaffected by this paragraph.

No model training runs today. The jobs that would train a model and promote it into service are switched off, and no model that generates output in the product is trained or fine-tuned on customer conversations. The models that answer you are the provider's (§2). The paragraph reproduced above names entries from our own model evaluation and training runs. Those runs are switched off as well: they would produce such entries, and today they produce none.

One small model does learn from your content, and only for you. Each account has its own ranking model, which reorders the results of that account's memory searches. It learns from your memory entries and from your searches. It is never shared with another account, it generates nothing, and it is erased with your account. It is part of how memory search works, so the Training data preference below does not control it.

Beyond that model, training is opt-in. Your content will be used to train or fine-tune a model only if you switch the Training data preference on, under Account → Privacy, where it reads "Improve simse for everyone". The default is off. Switching it back off is one click, the same as switching it on, and it stops future use. Content used with your consent is used to improve the models behind this product and for nothing else; a new purpose requires fresh consent.

That preference is not yet read by the step that would select training data, so no training run starts until it is. The selection today checks only an internal eligibility flag, not your answer. We will not start a training run until it reads the preference, and this notice changes before the first run starts.

simse does not ask for special-category data (health, politics, biometrics and the rest) and has no use for it. Do not paste it in — the redaction pass above is pattern-matching, not judgement, and it will not catch everything.

8. Decisions about you

simse makes no decision about you that produces a legal or similarly significant effect by automated means. The assistant produces work you accept or reject. There is no automated determination of eligibility, credit, employment, pricing or account standing.

If that ever changes, this section changes before the processing starts, not after.

9. Our position under the EU AI Act

For readers who need the classification in the Act's own terms:

If you build on simse, read this part. simse is a general-purpose tool. If you embed it in a system that performs a high-risk function under Annex III — for example an automated employment-screening or creditworthiness tool — you are the provider of that high-risk system under Art. 25, and its obligations fall on you, not on us. simse's intended purpose is planning and executing software work at a developer's direction. Building outside that purpose is your decision and your responsibility, and the Acceptable Use Policy says so.

10. Reporting a problem with AI output

If simse produced output that caused harm, misrepresented itself, or was attributed to a person, tell us: legal@telor.dev. For product defects and plainly wrong answers, support@telor.dev reaches the same team faster. For anything about your personal data, privacy@telor.dev.

11. Changes to this notice

We revise this notice when the AI surface changes — a new model provider, a new output type, a change to how output is marked, or a change to what is sent outside our systems. The version and effective date at the top move with each revision. We will tell you about a material change before it takes effect.