Engrym — Data Processing Addendum (DRAFT skeleton) + Sub-processor Schedule
Provider / Processor: RTK AI Labs Ltd, a company registered in England and Wales under company number 17179962, provider of Engrym.
Customer / Controller: the entity or person agreeing to Engrym's Terms of Service.
Governing-law context: RTK AI Labs Ltd is established in England and Wales (United Kingdom); the UK GDPR is the primary processor-side regime, with the EU GDPR and the EU SCCs (plus the UK International Data Transfer Agreement / Addendum) engaged for transfers and EU-resident data subjects (see §8). [COUNSEL: finalize the governing-law clause and the transfer-mechanism set for an England & Wales processor; the domicile is confirmed.]
Purpose. This is a skeleton DPA plus a code-verified sub-processor schedule, written so outside counsel can adopt a standard DPA (or the EU SCCs as a module) on top of an accurate factual base. It is not an executed agreement. Team/Studio/Enterprise are not built; no DPA-on-request, audit-rights, or SLA capability is promised here beyond what the live product supports. Note: the white paper lists "Custom DPAs, data residency options, audit log exports, SSO/SAML" as future Enterprise items and SOC 2 as a roadmap item — none of these are shipped, and this draft promises none of them.
1. Subject matter and roles
RTK AI Labs Ltd processes personal data on the Customer's behalf to provide the Service described in the Terms of Service. For that personal data, the Customer is the controller and RTK AI Labs Ltd is the processor. For RTK AI Labs Ltd's own account/billing/operational data, RTK AI Labs Ltd is the controller (see the Privacy Policy). [COUNSEL: confirm the controller/processor split, especially for account-identity data which may be RTK AI Labs Ltd-as-controller rather than processor.]
2. Nature and purpose of processing
Storage, synchronization, AI-extraction of Atoms from Documents, semantic and keyword search, duplicate detection, contradiction-finding, export/portability, billing, and support — as configured by the Customer.
3. Categories of data subjects
The Customer's authorized users, and any individuals referenced within the Customer's Documents/Atoms. [COUNSEL: the Customer controls Document content; advise on a Customer warranty that it has a lawful basis for any personal data it uploads.]
4. Categories of personal data
- Account identifiers (email, auth identifiers).
- Customer content (Documents, Atoms, verdicts, intents, sessions, imported media) — which may contain personal data the Customer chooses to include.
- Billing metadata (via Stripe).
- Not processed: source code (see §11, the transient-sensor boundary); full card numbers (held by Stripe).
5. Special-category data
Not intended. The Customer should not upload special-category data. [COUNSEL: include a prohibition/limitation on special-category and other high-risk data, or a specific handling clause if it cannot be excluded.]
6. Duration
For the term of the Customer's subscription plus the deletion/export window defined in Privacy Policy §5 (the single source of those windows; the Terms §5.4/§9 cite the same figures). [COUNSEL: do not insert a separate window here — cite the one defined in Privacy Policy §5 so the Terms, the Privacy Policy, and this DPA all carry the identical figure.]
7. Processor obligations (skeleton — counsel to expand to the applicable DPA standard)
- Process on documented instructions only. RTK AI Labs Ltd processes Customer personal data only to provide the Service and on the Customer's documented instructions (these terms and the Customer's use of the Service).
- Confidentiality. Personnel authorized to process Customer data are bound by confidentiality.
- Security. RTK AI Labs Ltd maintains appropriate technical and organizational measures (§9).
- Sub-processors. RTK AI Labs Ltd uses the sub-processors in the Schedule (§10) and gives notice of changes (§8.4).
[COUNSEL: general vs specific authorization; objection window.] - Assistance. RTK AI Labs Ltd assists the Customer, taking into account the nature of processing, with data-subject requests and with security/breach/DPIA obligations.
[COUNSEL: scope and any fee.] - Breach notification. RTK AI Labs Ltd notifies the Customer without undue delay after becoming aware of a personal-data breach.
[COUNSEL: define timeline and content.] - Deletion/return on termination. On termination, RTK AI Labs Ltd deletes or returns Customer personal data per the Customer's choice, subject to legal retention. The Git Mirror and export features (ToS §7.2) are the Customer's self-service return mechanism.
- Audit / information. RTK AI Labs Ltd makes available information necessary to demonstrate compliance.
[COUNSEL: a two-person company cannot support on-site audits at scale; advise on a documentation-based audit-support clause and avoid over-promising — no SOC 2 report exists yet (it is a roadmap item).]
8. International transfers
RTK AI Labs Ltd is established in the UK, and the core platform processors are in the EU/UK: Supabase (AWS eu-west-1, Dublin), Vercel dashboard + API (dub1, Dublin), and Fly (lhr, London). Because the controller may be in the EU while the processor and one transfer (Google, Platform-Key path) sit outside, the transfer regime must cover both UK→third-country and EU→third-country flows.
[COUNSEL: with the UK establishment confirmed, set the transfer mechanism set — the EU SCCs **and** the UK International Data Transfer Agreement / Addendum where data leaves the UK/EEA. Confirm regions for Stripe, Sentry, Better Stack, Resend, and Google. The Google Platform-Key path (Atom text → Google) is the single most important transfer to paper, because it is the one path where Engrym sends Customer content to a third-country provider on its own account.]
8.4 Sub-processor change notice
[COUNSEL: specify the mechanism (e.g. a published sub-processor page + email to billing contact) and the advance-notice period and objection right.]
9. Technical and organizational measures (grounded in the live code)
- Encryption in transit: all Service traffic is over HTTPS (Vercel/Supabase).
- BYOK key encryption at rest: AES-256-GCM in a two-key envelope — a random 256-bit per-Project key encrypts the Customer's BYOK secret, and that per-Project key is wrapped under a master key held only in deployment secrets, never in the database (
packages/auth/src/internal/crypto.ts). Plaintext keys are decrypted single-use, never logged, never persisted in plaintext, never returned across a process boundary (packages/auth/src/byok.ts). - Row-Level Security: Postgres RLS isolates tenants; the API can additionally run personal-project requests under a per-request user-scoped client so RLS evaluates under the caller's identity (
API_RLS_USER_SCOPED_PERSONAL_PROJECTS). - Secret custody: application/provider secrets live in Vercel env / Fly secrets, never committed (
.env.example,infra/secrets/). - Telemetry minimization: error telemetry excludes Customer content, keys, and email-in-body; the local Sync Daemon ships without third-party telemetry (
infra/observability/sentry.md). - Backups: Supabase point-in-time recovery; production is not reset (
infra/deploy/supabase/). - Code-data exclusion: by architecture, no source code is processed or stored (§11).
[COUNSEL: present these as the TOMs annex; confirm before representing any as a contractual guarantee. Note pending hardening items exist in internal backlog — do not over-state maturity.]
10. Sub-processor Schedule (verified against live code/deploy config)
Verified from
.env.example,infra/deploy/,infra/observability/, and thepackages/*adapters.[VERIFY]= a legal/operational fact (DPA executed, processor's data region) the team has not confirmed in-repo.
10a. Core platform sub-processors
| # | Processor | Personal data processed | Purpose | Region (repo-verified) |
|---|---|---|---|---|
| 1 | Supabase | Account identity, Documents, Atoms, verdicts + path:line pointers, intents, sessions, billing metadata, encrypted BYOK ciphertext, imported media. No source code. | Primary DB, Auth, Realtime, Storage, RLS. | EU — AWS eu-west-1 (Dublin). [VERIFY DPA + AWS chain.] |
| 2 | Vercel | Requests/responses, session cookies, content in transit, app/build logs. | Hosting (dashboard, landing, API). | Dashboard + API EU — dub1 (Dublin); landing global CDN. [VERIFY DPA + log retention of bodies.] |
| 3 | Fly.io | Git Mirror export payload (Documents, Brain, decision log, activity stream). No source code. | Git Mirror worker host. | EU — lhr (London). [VERIFY DPA.] |
| 4 | Stripe | Email, subscription status, payment method (held by Stripe), Stripe IDs, invoice metadata. No card numbers stored by Engrym. | Subscription billing (Solo tier). | Stripe-determined. [VERIFY DPA + MoR/VAT.] |
| 5 | Sentry | Error events only (stack traces, spans, redacted breadcrumbs). No content/keys/email-in-body. | Error tracking. | [VERIFY DPA + US/EU region.] |
| 6 | Better Stack | Uptime/availability signals. No content; log shipping off at v1. | Availability monitoring + status page. | [VERIFY DPA + region.] |
| 7 | Resend | Email + consent state + delivery events. Newsletter only. | Newsletter delivery. | [VERIFY DPA + region + newsletter-only.] |
10b. AI provider sub-processors — BYOK vs Platform Key (kept separate)
| # | Path | Processor(s) | Personal data | Whose key | Region |
|---|---|---|---|---|---|
| 8 | BYOK inference — extraction (Documents→Atoms) + contradiction-finding judge | Anthropic / OpenAI / Google (Customer's choice) | Document text; Atom-pair text. No source code. | Customer's key (encrypted at rest; single-use decrypt). | Provider-determined; governed by the Customer's own agreement with that provider. [COUNSEL: sub-processor characterization of transiently-dispatched BYOK content.] |
| 9 | Platform-funded inference — semantic-search embeddings + claim-merge duplicate judge | Google (Gemini): gemini-embedding-001 (embeddings) + gemini-2.5-flash (claim-merge judge) | Atom text only. No source code; no Document body beyond Atom text. | Engrym's Platform Key. | Google-determined. [VERIFY Google DPA + no-training terms + transfer mechanism — this is the key transfer to paper.] |
Code-grounded separation note: the contradiction-finding judge (
find_contradictions) runs on the Customer's BYOK key (Anthropic Haiku preferred, Google-Flash fallback) — row 8. Only the claim-merge equivalence judge runs on the Platform Key — row 9. (packages/api/src/composition/brain-seams.tsvsclaim-merge-seams.ts.) An earlier outline conflated these; this schedule corrects it.
11. The transient-sensor boundary (data RTK AI Labs Ltd does not process)
By design, RTK AI Labs Ltd does not read, store, embed, index, cache, or persist any representation of source code — no file contents, AST, call graph, import graph, file tree, snippet, or code text in a verdict beyond the path:line pointer (non-goal #7; white paper §16.8). Reconciliation runs in the Customer's own agent session; RTK AI Labs Ltd receives only the verdict. Source code is therefore outside the scope of this DPA because it is never processed by RTK AI Labs Ltd.
FLAG-FOR-COUNSEL (DPA + sub-processors)
Processor entity and domicile are now KNOWN: RTK AI Labs Ltd, registered in England and Wales, company number 17179962; UK establishment → UK GDPR primary, EU GDPR + EU SCCs + UK IDTA/Addendum for transfers. The items below are genuine legal calls; the governing-law/transfer-regime item is now "set the mechanism," not "establish the domicile."
- Controller/processor split (§1) — confirm, esp. account-identity data.
- Customer warranty re: personal data in Documents (§3) — advise.
- Special-category data handling/exclusion (§5) — advise.
- Duration / deletion / export window — DEFINE ONCE, IN PRIVACY §5 (§6) — this DPA cites Privacy Policy §5; the identical figure must appear (by reference) in the Terms §5.4/§9. Do not state a divergent number here.
- Sub-processor authorization model + change-notice + objection (§7.4, §8.4) — specify.
- Assistance scope + breach-notification timeline (§7.5, §7.6) — define.
- Audit-support clause for a two-person company; no SOC 2 yet (§7.8, §9) — avoid over-promising.
- International transfers + SCCs / UK IDTA/Addendum — SET THE MECHANISM (domicile known) (§8) — UK establishment confirmed; counsel sets the EU SCCs + UK transfer-tool combination and confirms regions for Stripe/Sentry/Better Stack/Resend/Google. The Google Platform-Key transfer remains the most important to paper.
- TOMs annex (§9) — confirm which measures are contractual guarantees; do not overstate maturity (hardening backlog exists).
- Execute/confirm DPAs and data regions for all eight+ sub-processors (§10).
- BYOK sub-processor characterization (§10b row 8) — transiently-dispatched content.
- Google no-training + DPA on the Platform-Key path (§10b row 9) — the most important single confirmation.