Data Processing Agreement

Effective date: 15 September 2026

Revised 29 September 2026 — the node's backup disk, which holds the in-cluster copy of the backups, is now a second LUKS2 volume sealed to the node's TPM like the first. Annex II, sections 1 and 2, and Annex I, section D, say so, and Annex II, section 1 records that the disk was plain ext4 until this date and that the root filesystem remains outside both volumes. This strengthens an existing measure and engages no Sub-processor, so no notice under clause 8.4 falls due.

Revised 28 September 2026 — Annex II no longer says the node's operating system is past end of support: the upgrade to Ubuntu 26.04 LTS was completed and verified on 28 September 2026, and the paragraph now says so and records the period before it.

Revised 27 September 2026 — Annex III's Cloudflare row now names the website-analytics leg: Cloudflare Web Analytics on simse.dev, only for visitors who allow analytics in the cookie banner. That leg carries simse's own controller data about website visitors, not Customer Personal Data, so it is listed for completeness, as the controller-only legs already are (clause 14.3), and is not a change requiring notice under clause 8.4. The same revision corrects the record, and none of these corrections engages a new Sub-processor or changes an existing one's role: Annex III's Cloudflare row now states that Cloudflare handles the full content of every request and response at its edge, where TLS terminates, and that the Cloudflare Data Processing Addendum's scope is confirmed while its acceptance on simse's account is not; the statements, left behind by the 15 September revision, that no inference credential was provisioned are corrected in Annex I, section D and Annex III; clause 9.1 now states that the account export endpoint returns only the authentication service's records, and clause 12.2 follows it; Annex I, section D adds the key-value store; Annex II now states that node-level agents run privileged, the administrative surfaces on the operator network, that the node's operating system is past end of support, that changes land without pull-request review, and that monitoring runs on the production cluster; Annex III, section C names Tailscale as a vendor that is not a Sub-processor; clauses 9.1 and 12.2 state that the operator-run export reaches the object store and adaptive memory only through their owning services; and clause 6.3 and Annex II state that the key-value store's forwarder on the operator network carries no credential. One change is new processing rather than a correction: since 26 September 2026 the object store has been copied nightly to Cloudflare R2, and Annex I, section D, Annex II and Annex III now say so. It extends the backup leg Annex III already discloses to one further store. The platform holds no customer accounts (clause 15.3), so no Customer Personal Data is in that store and no notice under clause 8.4 falls due.

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 Data Processing Agreement ("DPA") forms part of the Terms of Service between simse and the Customer. It applies where the Customer uses the Services to process personal data of the Customer's own end users. For that data the Customer is the controller and simse is the processor.

This DPA is Article 28(3) GDPR terms, the UK GDPR equivalent, and US state-privacy service-provider/processor terms in one instrument. Annexes I, II and III are part of it, and they also populate Annexes I, II and III of the Standard Contractual Clauses incorporated by clause 14.

How to read this document. Clauses 1–17 are the operative terms. Annex I says what is processed and for how long. Annex II says how it is protected. Annex III says who else touches it. Schedule A is the only part that is not yet complete: it holds the incorporating entity's particulars, which the operator fills in before this DPA is offered to a customer.

Schedule A — Entity particulars

The operator completes every row below before this DPA is published or executed. Nothing else in this document is left open.

Where this DPA says "simse", it means the entity named at A-1. simse operates the simse platform and is a product of Telor. The privacy contact for every notice under this DPA is privacy@telor.dev.

If A-4 or A-5 is completed as "None appointed", simse does not represent that a representative has been designated, and the Customer must not state otherwise in its own notices.

1. How this DPA takes effect

1.1 This DPA takes effect when the Customer accepts the Terms of Service, and applies for as long as simse processes Customer Personal Data.

1.2 No signature is required. simse sells self-serve; there is no negotiated form of this DPA and no per-customer variation. Where the Customer requires a signed counterpart for its own records, simse will sign this document unamended.

1.3 If this DPA conflicts with the Terms of Service, this DPA governs for the processing of Customer Personal Data. If this DPA conflicts with the Standard Contractual Clauses incorporated by clause 14, those Clauses govern.

2. Definitions

"Customer Personal Data" means personal data that simse processes on the Customer's behalf through the Services. It does not include the Customer's own account, billing and administrative data, for which simse is a controller under the Privacy Policy.

"Services" means the simse platform reached through api.simse.dev and the developer surface at platform.simse.dev, including inference, conversation and agent-session storage, adaptive memory, file and object storage, the knowledge library, project and workflow storage, the plugin registry, vector retrieval, and usage metering. The Services do not include sending mail or notifications to the Customer's own end users: there is no send API on the public surface, and the in-product notification records the Services generate are read by the account holder.

"Data Protection Law" means the EU GDPR, the UK GDPR and the Data Protection Act 2018, the Swiss FADP, and the US state privacy laws in clause 16, each as applicable to the processing.

"Sub-processor" means a third party engaged by simse that processes Customer Personal Data.

"Personal Data Breach" has the meaning given in Art. 4(12) GDPR.

"Controller", "processor", "personal data", "processing", "data subject" and "supervisory authority" have the meanings given in the GDPR. "Business", "service provider", "sell", "share" and "personal information" have the meanings given in the CCPA as amended by the CPRA.

3. Roles

3.1 For Customer Personal Data, the Customer is the controller and simse is the processor. The Customer determines the purposes and means. simse processes only on the Customer's documented instructions.

3.2 Where the Customer is itself a processor acting for a third-party controller, simse is a sub-processor, and the Customer warrants it has authority from that controller to appoint simse and to give the instructions in clause 5.

3.3 For the Customer's own account data, simse is the controller. That covers the account holder's email address and display name, the Google OAuth subject where Google sign-in is used, platform account and workspace records, API key metadata, billing identifiers, usage counters, security audit records, and support correspondence. It is governed by the Privacy Policy, not by this DPA.

3.4 The Customer is responsible for establishing a lawful basis for its processing, for giving its data subjects the notices Data Protection Law requires, and for the accuracy and legality of what it sends to the Services. simse does not establish a lawful basis for the Customer's processing.

3.5 simse does not answer the Customer's end users directly. A rights request from one of them is handled under clause 9.

4. Subject matter, duration, nature and purpose

4.1 Subject matter. simse's provision of the Services to the Customer.

4.2 Duration. For the term of the Terms of Service, plus the deletion period in clause 12.

4.3 Nature and purpose. Receiving requests the Customer or its end users submit; transmitting them to a large-language-model inference provider and returning the output; storing conversation history, adaptive memory, uploaded files, generated artifacts, library documents, project and workflow records, plugin grants and retrieval vectors; writing the full-fidelity record of each inference call described in clause 9.5 and Annex I, section D; running agent tools the Customer's application invokes; and metering usage for billing. simse does not send mail or notifications to the Customer's end users — the Services expose no send API — so no purpose here covers that.

One of those purposes is simse's own, and is named here rather than folded into the list. The full-fidelity inference record is written to a warehouse table that simse's own model-distillation code reads to build training datasets. The write happens on every inference call, unconditionally, and consults no per-account setting. What clause 15.1 governs is the use of that record: simse does not train, fine-tune or evaluate any model on Customer Personal Data, and will not without the Customer's documented instruction. The record's expiry is in Annex I, section D, and erasure reaches it on the keys in clause 9.5. simse processes Customer Personal Data for no purpose outside this clause.

4.4 Types of personal data and categories of data subjects. Set out in Annex I. simse does not control what the Customer submits, and Annex I therefore describes categories rather than a closed list.

4.5 Retention. Set out in Annex I, section D.

5. Customer instructions

5.1 simse processes Customer Personal Data only on the Customer's documented instructions, including as to international transfers, unless required to do otherwise by law to which simse is subject. Where a law requires it, simse will inform the Customer of that requirement before processing, unless the law prohibits that notice on important grounds of public interest.

5.2 The documented instructions are: this DPA, the Terms of Service, the Customer's configuration of the Services, and each API request the Customer or its application makes. Instructions given any other way must be agreed in writing with simse, and simse may charge for implementing an instruction that requires work outside the Services as provided.

5.3 Instructions the Customer gives by using a feature. Three features send Customer Personal Data outside simse's infrastructure, and enabling or invoking them is the Customer's instruction to do so:

• Inference. Every request submitted through the Services is transmitted to simse's inference Sub-processor. What is transmitted is the request as the platform assembles it: the full conversation history, the system prompt including auto-recalled adaptive-memory entries, the tool definitions, and every content block, including uploaded documents and images and tool results, which is where file contents and command output travel. simse does not redact, minimise or pseudonymise that content, and no account or end-user identifier is attached to the request.
• Agent web tools. Where the agent's web-search or web-fetch tool runs, query text is transmitted to DuckDuckGo and the target URL is requested from whatever host the conversation names. The recipient of a web-fetch is chosen at request time and is not a fixed vendor, so simse has no contract with it and it is not a Sub-processor. See Annex III, section B. The two surfaces differ, and the Customer's control differs with them:
  • On POST /v1/messages the tool set is what the Customer declares in the request's tools array. If the Customer declares no web tool, none runs.
  • On the agent-session surface (/v1/sessions and the agent runtime behind it) web_search and web_fetch are registered in the model's tool set unconditionally, and the model decides when to call them. The Customer has no setting that removes them.
• Connectors — remote MCP servers the Customer names. The Customer may register a connector (a name, a URL, an optional bearer credential and optional fixed headers) and attach it to a session, or declare one inline on POST /v1/messages as mcp_servers[]. Where the model calls one of that connector's tools, simse transmits to the host the Customer named the tool name and the argument object the model composed from the conversation, together with the credential and headers the Customer configured; whatever the host returns re-enters the conversation as a tool result and reaches the inference Sub-processor with the rest of it on the next turn. Enumerating a connector's tools reaches the host as well and carries no conversation content. The two legs are not live to the same extent today. The tool call runs only while the inference path is serving, and clause 15.3 records the credential now provisioned for it and which class it is; the enumeration, including the connector-test endpoint on the public API, reaches the host independently of the inference path and is live now. The host is the Customer's recipient, not a Sub-processor of simse's. The Customer selects it, it processes on the Customer's instruction and for the Customer's purposes, and any agreement governing it is the Customer's. simse does not vet it, does not direct it and cannot bind it on the Customer's behalf, which is why it is absent from Annex III, section A and disclosed in section B instead. Its absence from the Sub-processor list is a determination, not an omission. See Annex III, section B.
• Commands the agent runs in its sandbox. Tool commands execute inside an isolated virtual machine whose outbound network policy is enforced on the host, outside that machine, and is coarse: DNS, plus outbound HTTP and HTTPS to the public internet, with no per-host allow or deny list and no inspection of the hostname inside an encrypted connection. A command the model composes can therefore transmit whatever it reads in the session workspace — file contents, command output — to a host of its own choosing. The recipient is chosen by the command at the moment it runs and is not a fixed vendor, so there is no party for simse to contract with, and it is not a Sub-processor for the same reason the web_fetch recipient is not. This path is distinct from the web tools above: the resolved-address refusal described there sits on the web-fetch tool, not on the sandbox's network, and does not constrain a shell command. No customer session has yet run through that boundary, so the path is stated as designed rather than as operated. See Annex III, section B.

The Customer instructs simse to perform all four. If the Customer does not want content sent to a recipient outside simse's infrastructure, it must not submit that content to the Services, must not declare a web tool on POST /v1/messages, must not use agent sessions at all — because on that surface the web tools cannot be switched off — must not register or declare a connector, and must not direct the agent to run commands against that content. The connector path is the one of the four the Customer controls completely on both surfaces: simse registers no connector of its own, so nothing is transmitted on it unless the Customer creates one, and deleting the connector ends it. The sandbox path is the one the Customer controls least precisely: it is bounded by what the Customer puts in the session workspace and what it asks the agent to do, not by a setting.

5.4 Notice of unlawful instruction. simse will inform the Customer without undue delay if, in simse's opinion, an instruction infringes Data Protection Law. simse may suspend performance of the instruction until the Customer confirms or withdraws it, and may suspend the affected processing entirely where continuing would place simse in breach.

5.5 simse will not sell Customer Personal Data and will not share it for cross-context behavioural advertising. simse uses it only for the purposes in clause 4.3. Two of those purposes are simse's own rather than a service rendered to the Customer, and clause 4.3 states them: the full-fidelity inference record written to the corpus simse's model-distillation code reads, and a second, separately sampled capture on the same serving path which banks the request untruncated alongside the answers produced for it, for comparing candidate models against each other. Clause 15.1 is what bounds it: simse does not train, fine-tune or evaluate any model on Customer Personal Data.

6. Confidentiality of personnel

6.1 simse limits access to Customer Personal Data to personnel who need it to deliver the Services or to comply with law.

6.2 Every person authorised to process Customer Personal Data is bound by a written duty of confidentiality that survives the end of their engagement. simse's Code of Conduct binds all personnel, contractors and agents.

6.3 Personnel with production access are named, and adding one is a reviewed change. The primary route is key-only SSH to the cluster node, restricted to a named operator group, one key per operator and no shared keys. There is a second route and simse names it rather than describing SSH as the only one: an operator-only private network exposes TCP proxies that reach the production databases directly, without going through the node's shell. Access to that network is per-device and separately administered. The database and warehouse credentials behind it are read-only and distinct from the application's; the key-value store's forwarder carries no credential at all, so admission to that network is its only control. Kubernetes access is not per-operator. kubectl runs against the cluster's own administrative kubeconfig, which is readable only as root on the node and is never routed to the edge. Every operator therefore acts as the same Kubernetes identity, Kubernetes authorisation does not distinguish one operator from another, and the API server's audit log attributes an action to that shared identity rather than to a person. Authentication and accountability for administrative access are enforced at the SSH and host-account layer in front of it, not by Kubernetes. On offboarding, simse removes the operator's SSH key and host account from every node, which is what removes their access; there is no separate per-operator cluster credential to revoke.

6.4 simse trains personnel with production access on their obligations under this DPA and acknowledges the Code of Conduct annually.

7. Security

7.1 simse implements and maintains the technical and organisational measures in Annex II, taking into account the state of the art, the costs of implementation, the nature, scope, context and purposes of processing, and the risk to data subjects.

7.2 Annex II describes measures that are implemented and operating. Where a control is planned but not operating, it is not listed. The Customer should read Annex II as the current state of the platform, not as a roadmap.

7.3 simse may update Annex II. An update will not materially reduce the overall level of security. simse notifies the Customer of a material change to Annex II by the mechanism in clause 8.4.

7.4 The Customer is responsible for the security of its own systems, its API keys, and the access its end users have to its application. simse is not responsible for a compromise arising from a Customer-held credential.

8. Sub-processors

8.1 The Customer gives simse general written authorisation to engage Sub-processors. The Sub-processors authorised at the date of this DPA are listed in Annex III.

8.2 simse imposes on each Sub-processor, by written contract, data-protection obligations no less protective than those in this DPA, including the confidentiality, security, assistance, breach- notification and deletion obligations, so far as applicable to the service the Sub-processor provides. simse remains fully liable to the Customer for a Sub-processor's performance of its data-protection obligations.

8.3 The onboarding gate, and where it stands. simse will not engage a new Sub-processor for Customer Personal Data until it has confirmed an executed data processing agreement, a valid transfer mechanism where the transfer is restricted, a current security attestation, a data-minimisation review, and sub-processor transparency terms. That is a forward commitment, and simse states plainly that it has not been met for every Sub-processor already in Annex III: the gate was not run before the inference path and the outbound-mail path were enabled, and simse's own register records it as a fail rather than a pass. The consequence for the Customer is stated on the affected rows of Annex III, not left to be inferred from this clause.

8.4 Change notice. simse will give the Customer at least 30 days' notice before engaging a new Sub-processor for Customer Personal Data or materially changing the role of an existing one. Notice is sent to the email address on the Customer's account, and Annex III is updated at the same time.

8.5 Objection. The Customer may object to a new Sub-processor on reasonable, data-protection grounds by written notice to privacy@telor.dev within 14 days of the change notice. simse will work with the Customer in good faith to address the objection. If simse cannot do so within 30 days of the objection, the Customer may terminate the affected part of the Services on written notice, without penalty, and simse will refund prepaid fees for the unused remainder of the term. An objection not raised within the 14-day window is taken as accepted.

8.6 Emergency replacement. If a Sub-processor ceases to provide its service or suffers a security event that disqualifies it, simse may engage a replacement immediately and notify the Customer without undue delay. The replacement is engaged on the terms in clause 8.2, and the Customer's objection right under clause 8.5 runs from that notice.

9. Assistance with data-subject requests

9.1 What the Customer can do for itself, stated precisely. The public API at api.simse.dev gives the Customer a per-object delete over every object type it has stored, and a per-object read over most of them. Sessions (deleting a session removes its messages with it), files, artifacts, library documents, connectors and workflows each have a per-object GET and a per-object DELETE. Rooms have both, but the whole /v1/rooms surface is closed by a kill switch and returns 403 until an operator enables it. Five object types have a DELETE but no per-object GET: memories, collections, citations, schedules and projects. Those remain readable through their list endpoints — GET /v1/memories, GET /v1/library/collections, GET /v1/library/{id}/citations, GET /v1/schedules and the session's project list — but not object by object. Correction is by rewriting or replacing the object; for memories and citations, which have neither a GET nor a PATCH, that means deleting and re-creating. There is no per-message delete. Deleting a session removes that session's messages; it does not remove the full-fidelity record of the inference calls that session produced, which is a separate store with its own expiry — clause 9.5 and Annex I, section D.

The public API also carries two account-level endpoints, and they do not reach the same data. POST /auth/delete-account, authenticated as the account holder, starts the orchestrated erasure workflow in clause 9.4, which fans out to every simse service holding the account's data. POST /auth/export-data, authenticated the same way, returns only the records held by simse's authentication service — the account and workspace records, API key metadata, linked sign-in identities, preferences and consents, sign-in sessions and devices, and security audit entries. It calls no other service, so it is not an export of the conversations, adaptive memory, files, library documents or other content the account holds. The operator-run export in clause 9.4 covers every database and the analytics warehouse; uploaded files, generated artifacts and adaptive memory, which live in the object store, and the key-value store are exported separately, on request, through the service that owns each. Both endpoints are scoped to the account and cannot be pointed at one of the Customer's own end users, so neither, on its own, satisfies a Customer's request about a single end user. The developer surface at platform.simse.dev exposes neither; it carries keys, usage, docs, the playground and a read-only account page. A request that cannot be satisfied object by object, or that is scoped below the account, is handled under clauses 9.2 and 9.4, and simse's assistance is required for it.

9.2 For everything the per-object endpoints in clause 9.1 cannot reach, simse will assist the Customer, taking into account the nature of the processing, by appropriate technical and organisational measures, so far as possible, to fulfil the Customer's obligation to respond to requests under Arts 15–22 GDPR and the equivalent US state rights.

9.3 If a data subject sends a request about Customer Personal Data directly to simse, simse will not respond to it substantively. simse will tell the requester to contact the Customer, forward the request to the Customer without undue delay, and log that it did so.

9.4 The assisted workflow, and the scope it can actually reach. On the Customer's written instruction, simse will run its orchestrated erasure workflow or produce an operator-run export. The two are built differently, and only one of them is derived from the service contract:

• Erasure is a single orchestrated workflow that fans out to every simse service holding the data. Its required set is derived from the service contract rather than from a hand-maintained list: a service that implements the erasure call but has not been wired into the fan-out is emitted as an unwired target and fails the run instead of being skipped. The workflow verifies each target before reporting completion. Erasure of analytics records is applied to the analytics warehouse synchronously and re-counted; a surviving row fails the operation rather than reporting success.
• Export is not a service fan-out. It is an operator-run tool that queries each database and the analytics warehouse directly, over a maintained inventory of domains with hand-written per-domain queries; it does not call the services' own export interfaces. That inventory is reconciled against the erasure set, and against the DATABASE schemas — a check parses every table out of the platform's own migrations and requires the export to select it — by checks an operator runs before a change lands, rather than being derived from the service contract. The analytics-warehouse tables are not covered by that schema derivation; they are reconciled table-by-table against the erasure set instead. So a database table added without a matching export query is caught, while a store added to the platform without being added to the inventory at all would be missed by both. The run itself is verified: a missing domain or table section aborts the export rather than producing a partial archive.

Both are scoped to the Customer's account, not to one of the Customer's end users. The Services record no identity for the Customer's end users. Stored rows carry the identifiers simse's own credential resolves to — the user record behind the credential, and the workspace the request resolves to (Annex II, section 2) — and the erasure workflow takes that user identifier as its input. simse can therefore run the workflow across the Customer's whole account, or against records the Customer can point to by an identifier the Customer itself placed in the data (clause 9.4a). It cannot separate one of the Customer's end users from another, because the Services record nothing that distinguishes them.

9.4a This is the Customer's design responsibility. If the Customer needs per-end-user export or erasure, it must make its end users separable in what it sends — by attaching its own end-user identifier to each record, or by segregating end users across separate simse accounts. Where the Customer supplies such an identifier, simse will use it to select records out of the account-scoped export the workflow produces. That selection is manual work by simse's operators, not a product feature, and clause 9.6 applies to it. Where the Customer supplies no such identifier, the only scope available is the whole account.

9.5 What erasure reaches, stated precisely. Erasure reaches simse's live stores, including the analytics warehouse, and is verified there rather than assumed: each deletion is counted before it runs and re-counted after, and a surviving record fails the request instead of reporting a clean result.

That reach includes the full-fidelity record of each inference call. For every request the Services make to the inference provider, simse writes the complete exchange — the system prompt, the input messages, the tool definitions, the tool results and the model's reply — to its analytics warehouse, unconditionally, and before any other decision is taken about that request. That table is the corpus simse's own model-distillation code reads; clause 4.3 states that purpose and clause 15.1 bounds it. Erasure reaches those records on two disjoint keys: the account identifier the record carries, and, for calls the platform did not attribute to an account, that account's conversation references. Both are verified by the same residual re-count. The record is also disclosed on an access request. A 90-day expiry the warehouse applies itself bounds it independently, and a snapshot taken while it was live ages out on the analytics-snapshot window in Annex I, section D.

Erasure does not reach:

• Backup snapshots taken before the erasure. Nothing purges a data subject out of an existing backup on demand. Those snapshots age out on the windows in Annex I, section D — except the in-cluster historical copy identified there, which those windows do not prune.
• The copy held by the inference Sub-processor. The outbound request carries no end-user identifier, so a deletion cannot be scoped at the provider. That copy is bounded by the provider's own deletion window, not by simse's erasure workflow — and clause 15.3 states the credential condition that window depends on.
• simse's security audit log. auth.audit_events is an append-only record of account actions, retained as an accountability and security control; it is not deleted, and the account record it references is pseudonymised in place rather than removed. One field in it is not retained: an entry written by an email-change action captured the address involved, and the erasure overwrites that with a fixed placeholder. The entry, its timestamp, its IP address and the user id it references all survive.
• A second capture of a served request that was taken without an account identifier. simse samples a small proportion of served requests into a separate store used to compare candidate models. Where that row carries the account identifier it is erased with everything else that does. Where it does not, nothing reaches it: the row holds no session reference either, so there is no second key to erase it by, and no expiry is applied to that store. simse states this rather than describing the erasure as reaching the whole store.
• Internal evaluation and training runs against no end user. simse runs its own model evaluation, calibration and training-data generation against the Services. Those runs produce records in the same warehouse table described above, but they originate from simse's own scheduled work rather than from any Customer request, and they carry neither an account identifier nor a conversation reference. They are not Customer Personal Data, and the account-scoped workflow correctly does not reach them. They expire on the same 90-day window.
• A one-time operator import of transcripts from outside simse. simse imported a set of assistant transcripts recorded outside the Services into the same warehouse table, to seed the corpus described in clause 4.3. Those rows do carry conversation content, but not a data subject's content submitted through the Services: the transcripts originated outside this platform, were never linked to an account on it, and so carry neither an account identifier nor a conversation reference, and none may be attributed to one after the fact. They are not Customer Personal Data. They expire on the same 90-day window.

9.6 simse charges no fee for assistance under this clause unless the Customer's requests are manifestly unfounded, excessive or repetitive, or require engineering work outside the Services as provided, in which case simse may charge a reasonable fee notified in advance.

9.7 simse responds to a request for assistance under this clause within 10 business days, which is set so that the Customer can meet its own one-month statutory deadline.

10. Assistance with Articles 32–36

10.1 simse assists the Customer, taking into account the nature of the processing and the information available to simse, in complying with the Customer's obligations under:

• Art. 32 (security of processing) — by maintaining Annex II, by responding to the Customer's security questionnaires under clause 13, and by notifying material changes under clause 7.3.
• Art. 33 and Art. 34 (breach notification) — under clause 11.
• Art. 35 (data protection impact assessment) — by providing, on written request, the description of processing in Annex I, the measures in Annex II, the sub-processor and transfer information in Annex III, and simse's own impact assessment of the AI processing in the Services. This is the information a controller needs to assess the Services; simse does not conduct the Customer's assessment.
• Art. 36 (prior consultation) — by providing that same information to the Customer for submission to a supervisory authority, and by responding to reasonable follow-up questions from that authority routed through the Customer.

10.2 simse will notify the Customer without undue delay if simse receives a binding request from a public authority for Customer Personal Data, unless prohibited from doing so. simse will challenge a request that appears unlawful or overbroad, will disclose only the minimum the request compels, and will keep a record of every such request and its response.

11. Personal Data Breach

11.1 simse notifies the Customer of a Personal Data Breach affecting Customer Personal Data without undue delay, and in any event within 72 hours of becoming aware of it. The clock starts at the point simse has reasonable certainty a breach has occurred.

11.2 The notice will describe, so far as known at the time: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point for further information. Where the full picture is not available within 72 hours, simse notifies within the window and supplements as the investigation progresses.

11.3 simse notifies the Customer. simse does not notify the Customer's supervisory authority or the Customer's data subjects, and does not do so on the Customer's behalf. Those are the Customer's decisions and the Customer's notifications. simse provides the information the Customer needs to make them.

11.4 simse maintains a breach register, preserves evidence, and conducts a post-incident review. On the Customer's request, simse provides the incident record relating to a breach that affected that Customer's data.

11.5 A notification under this clause is not an admission of fault or liability.

12. Deletion and return

12.1 At the Customer's choice, on termination or expiry of the Services, simse deletes or returns Customer Personal Data. The Customer makes that choice in writing within 30 days of termination. If the Customer does not, simse deletes.

12.2 Return. Return is by operator-produced export, because the account export endpoint in clause 9.1 returns only the authentication service's records. On written request within the 30-day window, simse will produce a structured, machine-readable export of the Customer's account, including the object-store contents and adaptive memory exported through their owning services, and deliver it over a channel authenticated to the Customer. Before termination takes effect the Customer may also retrieve objects through the GET endpoints in clause 9.1 — per object where one exists, and through the list endpoint for the five types where it does not — but that is not a substitute for the export and simse does not represent that it is.

12.3 Deletion. simse deletes Customer Personal Data from its live stores within 30 days of the earlier of the Customer's deletion instruction and the end of the 30-day window in clause 12.1, using the workflow in clause 9.4.

12.4 What survives deletion, and for how long. Three categories. Two are bounded by a stated window; the third — simse's own second copy of the pre-cutover archives — is not given an expiry, and is described as such below rather than folded into a framing sentence that would imply otherwise:

• Backup archives. Deletion does not edit an existing backup. Snapshots age out on the per-store windows in Annex I, section D. The longest is the payments archive at 3,650 days, which exists because those records carry a statutory financial-retention obligation. The one copy those windows do not prune is the in-cluster historical copy of the pre-cut-over database archives, identified in the same section; simse holds it as its second copy and does not give it an expiry.
• Records simse must keep by law. Billing and tax records, and the append-only security audit log. These are retained for the period the law requires, minimised to what the obligation covers, and not used for any other purpose.
• Internal evaluation and training runs. Records produced by simse's own scheduled model evaluation and training work, which carry no account identifier or conversation reference because no end user is behind them (clause 9.5). They expire 90 days after they are written.
• The one-time operator import of transcripts from outside simse identified in clause 9.5. Those rows carry conversation content that originated outside the Services and no account identifier or conversation reference. They expire 90 days after they are written.

simse will not represent that Customer Personal Data has left every backup at the moment deletion completes, and the Customer should not represent that to its own data subjects.

12.5 On written request after deletion, simse certifies in writing that it has been carried out.

13. Information and audit rights

13.1 simse makes available to the Customer the information necessary to demonstrate compliance with Art. 28 GDPR, and allows for and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates.

13.2 First route: information. simse will respond to a reasonable written request for information about its processing, its security measures, or its Sub-processors within 30 days. That includes completing a security questionnaire, providing extracts from simse's control register and impact assessments, and providing any current third-party audit report or certification simse holds at the time of the request. simse does not hold a SOC 2 report or an ISO 27001 certificate today and does not represent otherwise; where the Customer's diligence requires one, that is a matter to raise before contracting.

13.3 Second route: audit. If the information provided under clause 13.2 does not reasonably satisfy the Customer, the Customer may audit simse's processing of Customer Personal Data, subject to all of the following:

• once in any 12-month period, on at least 30 days' written notice;
• during simse's normal business hours, and conducted so as not to disrupt the Services or the data of other customers;
• by the Customer or an independent auditor that is not a competitor of simse, bound by confidentiality obligations at least as protective as those in the Terms of Service;
• limited to systems, records and personnel relevant to Customer Personal Data, and excluding other customers' data, simse's source code, and any material simse is contractually or legally barred from disclosing;
• at the Customer's cost, except where the audit identifies a material breach of this DPA by simse, in which case simse bears its own costs and reimburses the Customer's reasonable ones.

13.4 The frequency limit in clause 13.3 does not apply where a supervisory authority requires an audit, or following a Personal Data Breach affecting Customer Personal Data.

13.5 The Customer's audit right does not extend to a Sub-processor's premises. For Sub-processors, simse will pass on the Customer's reasonable questions and will provide the audit or certification material simse is entitled to receive from that Sub-processor.

13.6 Audit findings are confidential and may be used only to assess simse's compliance with this DPA.

14. International transfers

14.1 simse operates its production cluster in the country identified at Schedule A, row A-6, processes Customer Personal Data there, and transfers it to the Sub-processors and locations in Annex III — every one of which is in the United States. Those transfers are restricted transfers where the Customer or its data subjects are in the EEA, the United Kingdom or Switzerland.

14.2 The customer → simse leg. The Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914 ("SCCs") are incorporated into this DPA by reference and apply to the extent the transfer from the Customer to simse is a restricted transfer:

• Module Two (controller to processor) applies where the Customer is a controller.
• Module Three (processor to processor) applies where the Customer is itself a processor acting for a third-party controller.

14.3 The simse → Sub-processor legs. simse is a processor of Customer Personal Data. Onward transfers of Customer Personal Data to a Sub-processor are therefore made under Module Three (processor to processor) of the SCCs, or under an equivalent Art. 46 mechanism carried by that Sub-processor's own data processing agreement. The mechanism for each is stated in Annex III.

Annex III also lists Sub-processors that process only simse's own controller data — the account holder's sign-in and notification email. Those legs are Module Two (controller to processor), because on them simse is the controller, not a processor. They are not Customer Personal Data legs and are listed for completeness.

14.4 How the SCCs are completed. The following selections apply, and the Customer is taken to have agreed them by accepting this DPA:

Annex I lettering. This DPA's Annex I runs A–F and does not use the SCCs' own A–C lettering. It maps as follows: SCC Annex I.A (list of parties) is section A; SCC Annex I.B (description of the transfer) is sections B to E together — categories of data subjects, categories of personal data, retention, and frequency; SCC Annex I.C (competent supervisory authority) is section F. Every cross-reference in this DPA is to this DPA's lettering.

14.5 United Kingdom. The International Data Transfer Addendum to the EU SCCs issued by the Information Commissioner under s.119A of the Data Protection Act 2018 (version B1.0) is incorporated and applies to transfers subject to the UK GDPR. Table 1 is completed by Annex I section A; Tables 2 and 3 by clauses 14.2 to 14.4 and Annexes I to III; and in Table 4, neither party may end the Addendum as set out in section 19.

14.6 Switzerland. For transfers subject to the Swiss FADP, the SCCs apply with these adaptations: references to the GDPR are read as references to the FADP; the competent authority is the Federal Data Protection and Information Commissioner; "Member State" is read so as not to deprive a Swiss data subject of the right to sue in Switzerland; and the SCCs protect the data of legal entities until the FADP no longer extends to them.

14.7 Supplementary measures. simse applies the measures in Annex II to transferred data, challenges unlawful or overbroad authority requests under clause 10.2, and keeps a record of every such request and its response. On the Customer's written request, simse states whether it has received any request from a public authority for that Customer's Personal Data, so far as law permits.

14.8 simse does not rely on the EU–US Data Privacy Framework as its transfer basis. Where a Sub-processor is additionally DPF-certified, simse treats that as a supplementary safeguard, not as the operative mechanism.

15. Model training, inference and automated decision-making

15.1 simse does not use Customer Personal Data to train, fine-tune, evaluate or otherwise improve any model operated by simse. This is not a setting the Customer has to turn off. It applies to every model simse operates, including in-house models, adapter training and evaluation sets. simse will not change this without the Customer's documented instruction.

15.2 Adaptive memory is not training. The Services derive memory from the content submitted under an account, to give continuity across that account's sessions. It is scoped to that account and is never pooled across accounts, it is deleted with the rest of that account's data, and it is not used to change any model's weights. It is not scoped to the Customer's end users: memory derived from one of the Customer's end users is recallable in a session for another, because the Services record no identity for them (clause 9.4). A Customer that needs memory kept separate between its end users must separate them itself, on the terms in clause 9.4a.

15.3 The inference Sub-processor, and the credential it runs under. Inference is performed by the Sub-processor named in Annex III over its public Messages API. Two credential classes are possible on that path and they carry different legal consequences, so this clause states both.

• The commitment. Customer Personal Data will be processed through that provider only under a commercial API credential governed by that provider's Data Processing Addendum, which deems the EU SCCs Modules Two and Three executed and carries the UK Addendum. simse will not process Customer Personal Data through a consumer-subscription credential.
• The condition precedent, stated because it is still unmet — the credential exists but is the wrong class. A credential was provisioned on 2026-09-15 and the inference tiers serve on it. It is a consumer-subscription credential, not the commercial API credential the commitment above requires, so: there is no data processing agreement with the provider, no transfer mechanism, and no contractual retention or training term, and the provider's own commercial terms exclude that use. A commercial API credential is also held and cannot serve — it has no credit balance — which is why it is not the one in use. simse therefore still does not accept Customer Personal Data for processing under this DPA, and the Customer must not send Customer Personal Data to the Services until the commercial credential is funded and in place. No Customer Personal Data has been processed under the credential now live: the platform holds no customer accounts. simse confirms the credential class in writing on request, and will notify the Customer under clause 8.4 when it changes. This bullet is written in the present tense throughout and states today's state, so it does NOT survive the commercial credential being funded unedited: the moment it is, the sentences saying the class is wrong and that simse does not accept Customer Personal Data become false. Revising this bullet is part of changing the credential, not a follow-up.
• simse will not enable any provider-side feature that submits Customer Personal Data for the provider's model training.
• Under the commercial terms governing the commercial credential, API inputs and outputs are deleted within 30 days. That window is a term of those commercial terms and does not apply to the consumer-subscription class, for which no retention term exists at all. simse has no mechanism to scope a deletion at that provider for an individual data subject, because the outbound request carries no end-user identifier; once the commercial credential is in place, the 30-day window is what bounds that copy. Clause 9.5 says the same thing from the erasure side.

15.4 Model output. Output is generated by a third-party model. simse does not warrant its accuracy, and the Customer is responsible for how its application uses it. Where the Customer's own notices must disclose the recipients of its end users' personal data, the provider in Annex III is one of them.

15.5 Automated decision-making. simse makes no decision based solely on automated processing that produces legal effects concerning a data subject or similarly significantly affects them. If the Customer builds such a decision on top of the Services, the Customer is the controller of that decision and carries the Art. 22 obligations for it.

15.6 The Customer's content controls. Nothing in the Services scans, classifies or removes personal data from what the Customer submits before it is transmitted for inference. Minimising what is sent is the Customer's control, exercised by what its application puts in the request.

16. United States state privacy law

16.1 This clause applies where the Customer is a "business" under the CCPA as amended by the CPRA, or a "controller" under the comprehensive privacy laws of Colorado, Connecticut, Delaware, Indiana, Iowa, Kentucky, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, Rhode Island, Tennessee, Texas, Utah or Virginia, or an equivalent law of another US state.

16.2 simse is a "service provider" under the CCPA and a "processor" under the other laws in clause 16.1. simse:

• processes Customer Personal Data only to perform the business purposes in clause 4.3, as specified in this DPA;
• does not sell Customer Personal Data and does not share it for cross-context behavioural advertising, for monetary or any other valuable consideration;
• does not retain, use or disclose Customer Personal Data for any purpose other than performing the Services, including not for a commercial purpose other than the Services, and not outside the direct business relationship between simse and the Customer;
• does not combine Customer Personal Data with personal information received from another source, except as CCPA §1798.140(ag)(1)(D) permits a service provider to do;
• engages sub-contractors only on written terms imposing the same restrictions, under clause 8;
• notifies the Customer if simse determines it can no longer meet its obligations under the CCPA;
• grants the Customer the right, on notice, to take reasonable and appropriate steps to stop and remediate unauthorised use of personal information, which is exercised through clauses 13.2 and 13.3.

One retention is named here, because clause 16.2's third bullet would otherwise read wider than the platform is built. The full-fidelity inference record described in clause 4.3 is written to a warehouse table that simse's own model-distillation code reads. simse does not use Customer Personal Data to train, fine-tune or evaluate any model (clause 15.1) and will not without the Customer's documented instruction, so the record is retained but not used for that purpose. simse states the retention plainly rather than resting on the service-provider improvement exception; a Customer that will not accept it should read clause 4.3 before contracting.

16.3 simse certifies that it understands the restrictions in clause 16.2 and will comply with them.

16.4 Where a comprehensive state law requires it, simse: adheres to the Customer's instructions; imposes a duty of confidentiality on personnel (clause 6); engages sub-contractors under contract after giving the Customer an opportunity to object (clause 8); deletes or returns personal data at the Customer's direction (clause 12); makes available the information necessary to demonstrate compliance and allows and contributes to assessments (clause 13); and assists the Customer with consumer requests, security, breach notification and data protection assessments (clauses 9 to 11). An assessment under those laws is conducted under clause 13.

16.5 Consumer requests and appeals. simse assists the Customer with consumer requests under clause 9, on the same 10-business-day clock, which is set so the Customer can meet the shortest statutory deadline that applies to it — the CCPA's 10-business-day acknowledgement and 45-day response, and the 45-day response with a 45-day extension under the laws in clause 16.1. Every law in clause 16.1 gives the consumer a right to appeal a refusal. The appeal is the Customer's to decide, because the Customer refused the request; simse provides the underlying information within the same 10 business days so the Customer can decide it inside the statutory appeal window.

16.6 simse processes no personal information it knows to concern a consumer under 16 years of age. Where the Customer's application is directed to children, the Customer must not submit that data to the Services without first agreeing terms with simse in writing.

17. Liability, term and precedence

17.1 Each party's liability under this DPA is subject to the limitations and exclusions in the Terms of Service, except where Data Protection Law does not permit that limitation.

17.2 This DPA terminates when the Terms of Service terminate and simse has completed its obligations under clause 12. Clauses 6, 11.5, 12.4, 13.6, 14 and 17 survive.

17.3 This DPA is governed by the law and subject to the jurisdiction stated in the Terms of Service, except that clause 14 and the incorporated Standard Contractual Clauses are governed as clause 14.4 provides.

17.4 If a provision of this DPA is held invalid, the rest continues in force.

17.5 simse may amend this DPA where Data Protection Law changes, where a supervisory authority or court requires it, or where a new approved transfer mechanism supersedes one relied on here. simse gives 30 days' notice of an amendment by the mechanism in clause 8.4. An amendment will not reduce simse's obligations below what Art. 28(3) requires.

Annex I — Description of the processing

A. Parties

Data exporter: the Customer, as identified in its account with simse. Role: controller, or processor where clause 3.2 applies. Contact: the account email address. Activities relevant to the transferred data: use of the Services to process its end users' personal data.

Data importer: simse, as identified at Schedule A. Role: processor, or sub-processor where clause 3.2 applies. Contact: privacy@telor.dev. Activities relevant to the transferred data: provision of the Services described in clause 4.3.

Signature and date: the parties' acceptance of the Terms of Service, per clause 1.1.

B. Categories of data subjects

• The Customer's end users, as the Customer defines them.
• Individuals whose personal data appears in content the Customer or its end users submit — including in prompts, uploaded documents and images, source code, file contents and command output returned by agent tools. simse does not control this category and cannot enumerate it.

C. Categories of personal data

No notification category. The Services expose no API by which the Customer can have simse mail or notify its own end users, so no recipient address or message body of the Customer's ever enters simse's mail path. The in-product notification records under Annex I, section D belong to the account holder and are simse's own controller data under clause 3.3, not Customer Personal Data.

Special categories of data. simse does not solicit or intentionally process special-category data. It may appear incidentally inside free-text content. simse applies no Art. 9 condition to it and relies instead on the measures in Annex II and on the Customer's own controls over what it submits. The Customer must not use the Services to process special-category data as a category of processing without agreeing terms with simse in writing.

D. Retention

Retention is by store. "Life of the account" means the data is held while the Customer's account is open and is removed on termination or on an erasure instruction, whichever comes first.

Backup archives. Backups are continuous write-ahead-log archiving plus daily base backups for each of the five database clusters, written over HTTPS to Cloudflare R2 — one bucket per cluster, under per-bucket write-once lock rules. Cloudflare therefore holds a complete archive of every database-resident store listed above, including conversation history, library documents and retrieval vectors; it is disclosed on that basis in Annex III. The analytics warehouse has its own daily snapshot job, and its offsite leg is armed and running: each night the job writes the warehouse to a sixth Cloudflare R2 bucket as well as to the in-cluster copy, so Cloudflare also holds a nightly copy of the usage and product analytics and of the full-fidelity inference record listed above. Since 26 September 2026 the object store is copied offsite as well: each night a job writes a complete, dated copy of it to a seventh R2 bucket and verifies that copy object by object against the source. The object store holds uploaded files and generated artifacts, the per-user search indexes of the knowledge library, adaptive memory, and the files of each agent session's workspace, so Cloudflare holds a nightly copy of each of those as well. The key-value store is a short-lived cache and is not backed up. Archives age out on these windows and are not edited on erasure:

The ten-year payments window is set above the seven-year statutory retention obligation for the live financial record. Where a Customer or a data subject asks how long a payments residual can persist in an archive, the answer is ten years, not seven.

Eight of the nine R2 buckets simse uses carry a write-once lock window, inside which a stored object cannot be deleted through the storage API, including by simse's own credentials. They are the five per-cluster database buckets; the object-store bucket, locked for 14 days; and two buckets that are not backups of the stores in the table above — nightly snapshots of simse's secrets store, and the offsite export of simse's append-only platform audit log, which records actors, operations and the identifiers of affected records. The audit-log bucket is locked for seven years and nothing deletes from it at the end of that period. It is not a claim that the archive is beyond simse's reach in every sense: the lock is a property of the bucket's configuration, and whoever administers the storage account can change that configuration. That is a floor on how early an archived record can disappear; the windows in the table above are the ceiling. Both bound the same residual, from opposite ends. The warehouse-snapshot bucket carries no such lock, and simse says so rather than implying a uniform floor: the warehouse's backup engine writes and then deletes a marker object inside each snapshot, which a lock rule would refuse, so a lock cannot be applied there without breaking the backup outright. A warehouse snapshot in R2 can be deleted at any point inside its 30-day window.

A second copy of the backups is retained inside the cluster, on a dedicated disk in the node, and it is not the same in every respect as the offsite copy. Warehouse snapshots are written there nightly and pruned on the same 30-day window. The database-cluster archives written there before the offsite cut-over are kept as the historical copy and are not pruned by the per-cluster windows in the table above, which the clusters now apply against the offsite bucket instead. That in-cluster copy is encrypted at rest on its own volume — see Annex II, section 1. The object store's nightly copy is written offsite only.

E. Frequency of transfer

Continuous, for the duration of the Services.

F. Competent supervisory authority (SCC Clause 13)

Where the Customer is established in the EEA, the competent supervisory authority is that of the Member State in which the Customer is established. Where the Customer is not established in the EEA but has designated an Art. 27 representative, it is the authority of the Member State in which that representative is established. Where the Customer is not established in the EEA and has designated no representative, it is the supervisory authority of the Member State in which the data subjects whose data is transferred are located.

For transfers subject to the UK GDPR, the competent authority is the Information Commissioner. For transfers subject to the Swiss FADP, it is the Federal Data Protection and Information Commissioner.

Annex II — Technical and organisational measures

These measures are implemented and operating. A control that is designed but not operating is not listed here.

1. Pseudonymisation and encryption (Art. 32(1)(a))

• Encryption at rest, and the one filesystem it does not cover. The node volume holding every database cluster, the analytics warehouse and the object store is a LUKS2 volume (AES-XTS) whose key is sealed to the node's TPM, so that key is never written to the disk in plaintext. The node's second physical disk, which holds the in-cluster copy of the backups (Annex I, section D), is a second LUKS2 volume sealed the same way (since 29 September 2026; before then it was plain ext4). Neither is full-disk encryption of the node: each LUKS volume is a container file on an unencrypted filesystem, and the root filesystem itself is not encrypted, so Kubernetes state other than Secrets is not covered by this layer — Secrets are covered by the separate etcd layer below. The archives on the backup volume carry no server-side encryption of their own at the object layer. Decommissioning the root disk is therefore not a cryptographic erase, and simse has no documented disposal procedure for it — no destruction or wipe step is specified or evidenced today — and states that rather than name a control it does not operate. Annex II describes measures that are implemented; this is a gap in that set, recorded here.
• Encryption of platform secrets. Kubernetes Secrets are encrypted with an AES-CBC encryption configuration wired into the API server, applied as they are written into the Kubernetes datastore. This is a second independent layer over the disk encryption. Its scope is Secrets only: every other Kubernetes object in that datastore is stored in the clear on the unencrypted root filesystem described above.
• Recurring verification of both at-rest layers. Both are checked on every deployment by an automated gate. For the LUKS layer it reads the kernel's device-mapper identifier for the storage volume — not the device name, which any volume can carry — and additionally fails if a pre-migration plaintext copy is left beside it. For the Secret layer it asserts two independent facts: that the bytes already stored carry the AES-CBC encryption prefix, and that the API server is still configured to apply that provider first, so that neither historical rows nor a present configuration can satisfy the check alone. Where the gate cannot read what it must, it fails rather than passing. This replaces the position stated before 20 August 2026, when both layers had been verified only by hand at enablement and simse produced no recurring machine evidence of either. Clause 13.2 governs what simse can supply on request.
• Secret custody. Platform credentials live in OpenBao (KV-v2, one path per service, with auto-unseal and a snapshot job) and are delivered into per-service Kubernetes Secrets by the External Secrets Operator. No credential is committed to source.
• Encryption in transit, public leg. HTTPS/TLS terminated at the Cloudflare edge and carried to the cluster over an outbound-initiated Cloudflare Tunnel whose only ingress rule delivers to the gateway. Because TLS terminates at the edge, Cloudflare handles the content of every request and response in readable form there; the tunnel re-encrypts it between the edge and the cluster, and Annex III records Cloudflare on that basis. Outbound calls to the inference Sub-processor and to the mail path are over TLS.
• Internal service traffic — not encrypted, and stated as such. Service-to-service gRPC runs as plaintext h2c across the cluster's private pod network. There is no mutual TLS and no datapath encryption. The per-call control is authentication instead: each pod presents its projected Kubernetes ServiceAccount token, which the callee verifies RS256 against the cluster's OIDC key set, namespace-scopes, and matches against that service's authorised-caller set. Ingress to each service is additionally constrained by Cilium network policy. simse does not claim confidentiality of the internal leg, and the Customer should not assume it.
• Outbound egress is not restricted. Pod egress is broad-allow. There is no outbound allowlist and no per-service destination tiering at the cluster network layer, so this is not an Art. 32 measure simse offers. The controls that do bound outbound content are the redaction on internal write paths below and the fact that the outbound recipients are enumerated in Annex III. The agent sandbox does NOT narrow this: its egress policy allows DNS plus outbound HTTP and HTTPS to the public internet with no per-host list, as Annex III records.
• Pseudonymisation on erasure. Where a record must be retained for an accountability or statutory reason, the identity is removed rather than the record: the account row's canonical email is replaced with a one-way keyed HMAC, the usage ledger is pseudonymised, and per-user retrieval vectors are deleted outright.
• Redaction on internal write paths, and it is not uniform. SECRET patterns — API keys and tokens — are stripped on every one of these paths. PERSONAL-DATA patterns — email addresses, IPv4 and IPv6 addresses, card numbers and phone numbers — are stripped from the analytics warehouse's event rows and from vector-store metadata, and from the full-fidelity inference record. They are not stripped from the per-generation engine trace or from the sampled second capture, both of which hold the request text with secrets removed but personal-data patterns intact. None of this applies to what is sent to the inference provider; see clause 5.3.

2. Confidentiality, integrity, availability, resilience and restoration (Art. 32(1)(b) and (c))

• Tenant isolation — two scope dimensions, and where scope is crossed. User-data rows are scoped on the platform account (the authentication and billing identity) and on the workspace (the data scope every request resolves to, taken from the API key it was minted for or from the caller's default membership, never from a client-supplied header). A platform account can own more than one workspace, and the session, connector, memory, plugin, project and document stores carry the workspace identifier alongside the user identifier. There is no public API by which the Customer creates or manages a workspace or its membership, so the Customer cannot use that dimension to separate its own end users, and neither dimension separates one of the Customer's end users from another inside a workspace (clauses 9.4 and 15.2). Some surfaces cross that scope rather than enforce it. The ones below are named because they are the load-bearing ones, not because the list is exhaustive — simse does not represent it as complete. A room is a shared object: it belongs to a workspace with no single owner and can carry participants whose home workspace is a different one. The /v1/rooms surface is closed by a kill switch and returns 403 until an operator enables it, and erasure anonymises a user's room messages and removes their membership rather than deleting the shared room. Separately, a grant registry lets one workspace authorise agents in another workspace to invoke its own; it is default-deny, fails closed on any error, and is consulted only for a call that crosses workspaces.
• Authentication. End-user authentication is passwordless: Google OAuth with a single-use state parameter bound to the callback (PKCE is not implemented; the authorization-code exchange is made server-side by a confidential client holding the secret, and state is what binds the request to the response), or a single-use email magic link with a 15-minute expiry, rate-limited against enumeration. simse stores no password and no password hash. API access is by API key scoped to a platform account and workspace.
• Administrative access. Apart from the gateway routes described at the end of this item, no administrative surface is reachable from the public internet, and the Kubernetes API server is not reachable from the edge — the tunnel's only ingress rule points at the gateway. The operator-only private network described in clause 6.3 does carry administrative surfaces, and simse names them: the web console of the in-cluster backup store, which holds the in-cluster copy of the backups (Annex I, section D); the dashboard of the fault-injection tool used to test the production cluster; raw-TCP forwarders to the application database, the analytics warehouse and the key-value store; and a forwarder to the secrets store's API. Each is reachable only from a device admitted to that network. The database and warehouse forwarders are used with read-only roles distinct from the application's credentials; the key-value store's forwarder connects with no credential, so network admission is its only control. Administration of the node is key-only SSH to the cluster node, one key per named operator, followed by kubectl against the cluster's administrative kubeconfig, which is readable only as root on the node. That kubeconfig is a single cluster-scoped credential common to the operator set, so Kubernetes authorisation does not distinguish one operator from another; the control that does is the named-operator SSH and host-account layer in front of it (clause 6.3). On Kubernetes there is no per-operator credential to revoke and none to share. On the gateway there IS a shared administrative bearer token: a small set of operator-only HTTP routes on the public API are gated by a single static token held in the service's environment, not by an operator identity. An action taken through them is attributable to whoever held the token, not to a person. It is not reachable without that token, and the routes do not expose Customer content, but simse states its existence rather than letting the sentence above imply there is no shared administrative credential anywhere.
• Host hardening. Default-deny ingress firewall on the node, brute-force protection on SSH, and least-privilege service users. The node runs a vendor-supported operating system release, Ubuntu 26.04 LTS, and applies its security updates automatically. From July to 28 September 2026 it ran a release past its vendor's end of support, so host-level fixes published in that period were applied only by the upgrade, which was completed and verified on 28 September 2026. Software inside the cluster is patched on its own image schedule.
• Workload hardening. Every simse service workload applied to the cluster today carries a pod security context: non-root, privilege escalation disabled, capabilities dropped, and a read-only root filesystem where the image permits. Node-level agents are the exception, and simse states it: components that operate on the node itself rather than as a simse service — among them the disk-health and GPU-metrics exporters and the agent that configures the node's container runtime to trust the in-cluster image registry — run as root or privileged in the cluster's system namespace, because reading node hardware or changing node configuration requires it. The security context is set per workload rather than enforced at admission — the namespace that runs simse's services pins the restricted Pod Security Standard in audit and warn mode, with enforce deliberately unset — so this is a property of the current workload set, not an admission control that would reject a workload lacking it.
• Agent isolation. Code the agent executes runs in a Firecracker microVM, separate from the platform services. The isolation is the boundary itself — a separate kernel and a separate network namespace — not a destination filter: the sandbox's egress policy allows DNS plus outbound HTTP and HTTPS to the public internet with no per-host list (Annex III).
• Availability. Pod lifecycle, health checking and restart are owned by the Kubernetes kubelet and scheduler. The edge absorbs volumetric load.
• Backup. Continuous write-ahead-log archiving plus daily base backups for every database cluster, written offsite over HTTPS to Cloudflare R2, one bucket per cluster, under per-bucket write-once lock rules. The analytics warehouse has a daily snapshot job whose offsite leg to a sixth R2 bucket is operating; that bucket carries no write-once lock, for the reason given in Annex I, section D. Since 26 September 2026 the object store is copied in full each night to a seventh R2 bucket under a write-once lock, and the job fails unless the copy matches the source object by object. A second copy of the database and warehouse backups is retained in-cluster on the node's backup disk, on its own encrypted volume (section 1).
• Restore. Restore is proven nightly, not periodically. An automated drill per cluster restores the latest backup into a throwaway namespace, verifies row counts against the live source, and fails the job on a missing table or a short count. The run history and each drill's pass/fail assertion are the evidence. The object store's copy is verified against the source when it is written but is not restore-drilled.

3. Testing and evaluating effectiveness (Art. 32(1)(d))

• Dependency scanning on every change. cargo audit across every Rust crate and bun audit for TypeScript are part of the pre-merge gate suite an operator runs against every change before it lands. A vulnerability advisory fails that suite. Two qualifications, because the scan is not "deny everything": a small, individually reasoned list of advisories is explicitly ignored and recorded in the gate itself; and cargo audit classes unmaintained and unsoundness advisories as informational, so those print as warnings and do not fail the suite. simse states that rather than implying the scan blocks on every finding.
• Change management. Changes reach the production branch as commits authored and signed by the repository owner, after the operator-run gate suite has passed against them. There is no pull-request review step and no second reviewer: the production branch receives direct commits. The source host's own rules refuse a force-push to or deletion of that branch, and refuse an unsigned commit on every branch. The gate suite — lint, test, service-boundary and retention-coverage checks — is operator-run, not hosted CI: the hosted workflows are manual-dispatch only, so the suite is a step in the change procedure rather than an automated status check. Its content is machine-enforced where it runs: a service may not take a code dependency on another service.
• Monitoring. First-party service telemetry plus an OpenTelemetry collector feed metrics, logs and traces to a monitoring stack with threshold and anomaly alerting, and paging for high-severity events. That stack runs on the production cluster itself. A separate management cluster is designed and its preparatory steps are in place, but it has not been built, so monitoring shares the production node's failure domain and does not survive the loss of that node.
• Audit logging. Account actions — sign-in, sign-out, API key creation and revocation, account changes — are recorded with the actor, timestamp and source IP in an append-only table whose rows cannot be deleted. Cluster administrative actions are recorded in the Kubernetes API server audit log; those entries name the shared administrative identity described in section 2, not the individual operator, so attribution of a cluster action to a person comes from the node's SSH and host-account records rather than from that log.
• Risk review. A documented risk assessment and a control register covering the platform, each with a defined review cadence and a defined re-evaluation trigger on a material architecture change. What operates is the document and its cadence; the change trigger is a procedural step an engineer takes, not an automated one, and simse does not represent it as automated.

4. Data minimisation, deletion and retention

• Erasure. A single orchestrated workflow fans out to every service that holds the account's data. The required set is derived from the service contract rather than a maintained list, and the workflow verifies each target before reporting completion, so it fails rather than reporting a false success. Analytics erasure is applied to the warehouse synchronously and re-counted; a surviving row fails the operation. Its scope is the account, per clause 9.4.
• Scheduled disposal. The windows in Annex I, section D are applied by three mechanisms, not one: the owning service's own sweep, where it has one; a server-side time-to-live on the analytics warehouse tables; and a central retention registry with a nightly enforcement job that writes an append-only audit row per run. Registry coverage is checked by a gate in the operator-run pre-merge suite described in section 3 — every governed table must carry a policy row or a recorded disposition, and a reversion of the enforcement switch fails that gate.
• Analytics minimisation. Analytics are aggregated where attribution is not required, and identifiers are stripped from values written to the warehouse.
• Notification minimisation. This applies to simse's own account mail, not to Customer Personal Data — the Services send nothing to the Customer's end users (clause 4.3). No user identifier is attached to an outbound message, and the deduplication key is a digest rather than the recipient address.

5. Organisational measures

• Confidentiality. Written confidentiality obligations bind all personnel, contractors and agents, surviving the end of the engagement.
• Access provisioning and revocation. The operator set is a named roster; adding an operator is a reviewed change. Offboarding removes the operator's SSH key and host account from every node, which also removes their Kubernetes access, because that access is reached through the node (section 2). Withdrawing it from a departing operator who had taken a copy of the cluster kubeconfig off the node would require rotating that shared credential; simse does not represent that rotation as a routine offboarding step.
• Vendor management. A single sub-processor and vendor register, recording for each vendor the data it receives, its transfer instrument, and the state of the onboarding criteria in clause 8.3. The register is the control that is operating. The onboarding gate is not: it was not run before the two Sub-processors on the Customer Personal Data path were engaged, and no periodic review of the register has yet been performed, so neither is listed here as a measure. Clause 8.3 states the forward commitment and Annex III states the consequence per vendor.
• Incident response. A documented breach-response runbook with severity classes, a defined on-call and escalation path, an evidence-preservation step, the 72-hour notification decision tree, a breach register and a post-incident review.
• Data-subject-request handling. A documented procedure with identity verification, a request register kept independently of the subject's own data, and a 30-day response clock running from verification.
• Documented procedures. Operating runbooks for host hardening, breach response, risk assessment, export and erasure, retention enforcement, and business continuity.

6. Measures a Sub-processor must provide

simse requires each Sub-processor to maintain measures no less protective than those above, so far as applicable to the service it provides, and to notify simse of a personal-data breach without undue delay so that simse can meet clause 11.1.

Annex III — Authorised Sub-processors

A. Sub-processors

Authorised as at the date of this DPA. Changes are notified under clause 8.4.

On the "In the Customer Personal Data path?" column. Two Sub-processors process Customer Personal Data: the inference provider, and Cloudflare — which both carries every request and response, in readable form, at the edge and holds the offsite backup archives of every database cluster, the analytics warehouse and the object store. The other four process only simse's own controller data — the account holder's sign-in, notification and billing records. They are listed because they are simse's Sub-processors and the Customer is entitled to see the whole set, not because Customer Personal Data reaches them. The transfer-module column follows that distinction: Module Three where simse transfers as a processor, Module Two where simse transfers as a controller.

B. Recipients that are not Sub-processors

These receive data derived from the Customer's content, but not on simse's instruction and not for simse's purposes. They are not Sub-processors, are not covered by clause 8, and are disclosed here because the Customer's own notices must account for them.

Why the connector host is not in section A. It is the only recipient in this section that simse could in principle have contracted with, so its placement here is a determination rather than a fallback. The Customer chooses the host, holds whatever agreement governs it, and instructs it through its own configuration; simse neither selected nor vets it and cannot bind it for the Customer. Naming it in section A would represent it as a Sub-processor simse has put through the clause 8.3 onboarding gate, bound by written contract under clause 8.2 and remains fully liable for under that same clause. simse has done none of those things for a host the Customer named, and is not in a position to.

Who controls whether these run. On POST /v1/messages, the Customer does: the tool set is what it declares in the request. In an agent session, the Customer does not. web_search and web_fetch are registered in the agent's tool set unconditionally at service start, and the model decides when to call them. There is no Customer-facing setting that removes them, and simse does not offer one. A Customer that will not accept conversation-derived text reaching these recipients must not use agent sessions. Clause 5.3 states the same thing from the instruction side. The sandbox row is not controlled by a tool declaration at all: it is reached by any command the agent runs, so what bounds it is what the Customer places in the session workspace and what it asks the agent to do. The connector row inverts that on both surfaces: simse registers no connector, so a connector appears in the tool set only where the Customer attached or declared one, and deleting it removes the path.

C. Vendors that are not Sub-processors

simse uses Atlassian Jira for internal issue tracking, GitHub for source control and CI, and Tailscale for the operator-only private network. None of them processes Customer Personal Data: traffic on the private network is encrypted end to end between simse's own devices, so Tailscale does not see its content. If either begins to, it moves into section A first, with a data processing agreement and a transfer mechanism in place before the data flows, and the Customer is notified under clause 8.4.

D. First-party processing that is not sub-processed

Embeddings are computed in-cluster on simse-owned hardware. Retrieval and adaptive-memory vectors are not sent to a third party for computation. The analytics warehouse, the object store, the vector store, the notification service and every application database are first-party and run inside simse's own cluster.

One qualification, because it is the obvious gap in that sentence. Running first-party is not the same as staying in the cluster: the backup archives of every application database, of the vector store, of the analytics warehouse and, since 26 September 2026, of the object store are written offsite to Cloudflare R2, so a complete copy of each of those stores is held by a Sub-processor. That is section A's Cloudflare row, and Annex I, section D gives the windows. The key-value store is the one exception: it is a short-lived cache and is not backed up.

Questions about this DPA, and every notice it requires: privacy@telor.dev.