Engrym Privacy Policy

Controller: RTK AI Labs Ltd, a company registered in England and Wales under company number 17179962 ("RTK AI Labs Ltd," "we," "us," "our"), provider of Engrym (the "Service"). Registered office: 66 Paul Street, London EC2A 4NA, England.

Last updated: 5 September 2026

Applicable regime: RTK AI Labs Ltd is established in the United Kingdom, so processing is primarily governed by the UK GDPR, and by the EU GDPR for users in the European Union.

Scope: the Free and Solo Builder tiers. The Team tier is shown in-product as "coming soon" and is not purchasable; this policy does not describe capabilities that are not yet available.

1. Data we collect

1.1 Account data

Your email address; your password (held by our authentication provider as a salted hash; we never see or store it in plaintext) or, where you choose social sign-in, your GitHub or Google sign-in identity; and the authentication identifiers used to create and secure your account. Password reset and email verification run through the same authentication provider by email.

1.2 Content data

• Documents you create or import (markdown with optional frontmatter).
• Atoms extracted from your Documents: decisions, conventions, constraints, and context entries.
• Reconciliation Verdicts (upheld / violated / uncertain) and their Evidence Pointers: short path:line locator strings that point to a place in your code, and never contain code text.
• Intents and sessions: coordination metadata about your Project work.
• Imported media and attachments that accompany Documents you import.

1.3 Billing metadata

Customer and subscription identifiers, subscription status, and the email associated with billing. We do not receive or store your full card number; card data is held by our payment processor.

1.4 Provider keys

If you configure your own AI provider key (a "bring your own key" or BYOK key), we store it only as ciphertext. Your key is encrypted at rest using strong, industry-standard encryption, is never stored in plaintext, and is used only momentarily, in memory, to dispatch a request on your behalf (see Section 4). If your Project runs in agent mode (Section 3c), no provider key is required at all, and we never receive the credentials of your AI subscription.

1.5 Server-side operational logs

Our API emits one structured log line per request: a request identifier, the HTTP method and path, the response status, the request latency, and, for authenticated requests, your user, Project, and API-key identifiers. Authorization headers, cookies, API keys, and idempotency keys are always redacted before any log line is written, and request bodies are not logged by default, so your Document and Atom content does not enter the request logs. These logs stay within the logging facilities of our hosting providers (Section 3a); no separate error-monitoring or telemetry service receives them.

1.6 Measurement on public pages, and nothing elsewhere

We run no third-party analytics anywhere in the Service: no analytics vendor, no advertising cookies, no tracking pixels, no session recording, and no third-party error-telemetry. Nothing about your visit is sent to another company for measurement. On the landing site and in the dashboard we run no page-view measurement of any kind.

On public pages that a customer has chosen to publish (Section 3d), we record one measurement event on our own systems when the page is shown, and one when a link on it is followed, so that we can tell whether a published page was actually read. Each event contains: which published page it was; whether a link on it was followed, and which; the host name of the site the visit came from (for example slack.com), never a full address; and a coarse classification of what made the request (a browser, a link-preview fetcher, an automated crawler, something else, or unknown). It does not contain your IP address, in any form, hashed or otherwise, and it contains nothing that identifies you.

This measurement sets no cookie and reads nothing from your device: no cookie, no local storage, no device fingerprinting of any kind. The two values above are taken from the request headers your browser already sends, not from anything on your device. If your browser sends a Do Not Track or Global Privacy Control signal, we record nothing at all. These events are never combined with an account, never used for advertising or profiling, and never shared with anyone.

The lawful basis for this measurement is our legitimate interest in understanding whether published pages are read and in protecting a public surface from abuse. You can object at any time using the privacy contact in Section 7.

1.7 Newsletter

If you subscribe to our newsletter, we collect your email address and your consent state through a double opt-in (a confirmation email, then your click to confirm), together with delivery signals such as bounces and complaints. We use our email provider for the newsletter only; we do not route account or billing email through it.

1.8 Supporters-wall opt-in (Founding Supporters only)

If you are a Founding Supporter (Terms, Section 5.5) and you explicitly opt in, at checkout or from your account settings, we store a minimal record of that consent: your user id, the display name shown for you (your account's display name, or "Anonymous" where none is set), and the moment you opted in. Nothing else. This record exists solely to render the public supporters wall, which displays the opted-in display names of current Founding Supporters and nothing else: never an email address, never payment data, never any subscription identifier. If you do not opt in, no record is created and you are never named. Withdrawing (from your account settings, at any time) deletes the record outright; deleting your account deletes it automatically. The lawful basis for this processing is your consent, which you may withdraw at any time with effect for the future.

1.9 Public share records

If you publish an Atom to a public page (Terms, Section 7.5), we store a share record: which Atom was published, which Project it belongs to, the public link identifier, who published it, when, and, if it is later revoked, when. We keep the record of a revoked link after revocation, permanently, for one reason: it is what guarantees that a revoked link stays dead and its identifier is never issued again. The record contains no Atom content.

1.10 Your Handle and your Public Profile

Claiming a Handle and publishing a Public Profile are optional and are off unless you act (Terms, Section 2.4). If you never claim a Handle, nothing in this Section applies to you and no public page exists for you.

If you claim a Handle, we store the Handle, the account or team it belongs to, and when it was claimed. If you publish a Public Profile, we store only the fields you fill in: a display name, a photo if you upload one, a description, links to your accounts on other services, and any other links you add. Every field is optional and every field starts empty. We also generate the list of your Open Brains from the Brains you have chosen to open; it is not a stored field, and it never includes a private Project or a Closed Brain.

What the Profile record does not contain. It does not contain your email address, your password or authentication identifiers, your billing or payment data, any customer or subscription identifier, your plan or price, your usage, your provider keys, or anything from your private Projects. Those are held elsewhere for the purposes described in Sections 1.1 to 1.5 and are never rendered on a public page.

The lawful basis is your consent, given by claiming a Handle and by filling in each field. You can withdraw it at any time by clearing a field or by taking your Public Profile down, with effect for the future.

The one limit on withdrawing, stated plainly. Taking down your Public Profile removes the public page. It does not remove your Handle from the Origin Credit of a Brain you have already opened or of a Fork someone has taken. Deleting your account does remove your Handle from public display everywhere, and Section 5 sets out exactly what that leaves behind. Terms Section 7.8 says the same thing from the other side. We show you this when you claim a Handle and again when you open a Brain.

1.11 Publication, fork, and transfer records

When a Brain is opened to the public (Terms, Section 7.6) we write a permanent record of the publication: who opened it, what they authorized (reading, and copying if they marked it Forkable), the licence it was published under, the version of the Terms it was opened under, and when. The record is not editable and is not deleted, because it is the evidence of what was granted to everyone who read or copied the Brain while it was open, and those grants cannot be withdrawn from anyone who already received them (Terms, Section 7.7). It contains no Atom content.

When someone Forks a Brain we record which Project was copied from which, so that the Origin Credit can be generated and so the chain from a Fork back to its origin stays intact. When a Brain is transferred we record who offered it, to whom, the status of the offer, and when it expires.

These records name people, and they persist. Section 5 sets out what happens to them if you delete your account, and Terms Section 7.8 sets out what the Origin Credit shows once an account is gone.

2. Data we explicitly do NOT collect: the central guarantee

We do not collect your source code, in any form.

Engrym never reads, stores, embeds, indexes, caches, or persists any representation of source code: no file contents, no abstract syntax tree, no call graph, no import graph, no file tree, no snippet, and no code text in a Reconciliation Verdict beyond a path:line Evidence Pointer.

Reconciliation is performed by your own AI agent, running in your environment, which already holds your repository. Your agent reads the code transiently and returns only a verdict and a path:line pointer. We receive the verdict; we never receive the code.

We also do not store your full card number (this is held by our payment processor), we do not store your provider key in plaintext, and we never receive the credentials of the AI subscription your own agent runs on.

3. Where your data goes

3a. Core platform processors

We use the third-party processors below to provide the Service. Each processes the categories of personal data described, for the stated purpose, in the stated region.

3b. AI provider processors: the paths, kept separate

Agent mode is not a dispatch path. When a Project runs in agent mode, extraction happens inside your own AI agent, on your own AI subscription: Engrym serves the Document text to your agent, your agent runs the model, and the results come back to Engrym as provisional Atoms. We dispatch nothing to any AI provider for that work, and we never receive your subscription credentials.

In plain terms: we never send your source code to any AI provider. In BYOK and mix modes we send your Document and Atom text to the AI provider you choose, using your key, for extraction and contradiction-finding; in agent mode your own agent does the extraction on its own subscription; and, where you have not supplied your own Google key, we send your Atom text to Google, on our key, for semantic search and duplicate detection.

3c. Connecting your AI agent (the MCP connector)

You can connect an MCP-compatible AI tool of your own (for example, Claude Code or Claude Desktop) to Engrym:

• Authorization. The connection is authorized through an OAuth flow: you sign in with your Engrym account, see a consent screen describing the access, and your tool receives an access token scoped to your Engrym account. You can stop using the connector at any time by disconnecting it in your tool.
• What the connector can do. Acting as you, your connected tool can read your Projects' knowledge (Documents, Atoms, decisions, timeline), write knowledge back (documents, brain entries, decisions, intents, session state), submit Reconciliation Verdicts, and, in agent mode, pull extraction work and submit extracted Atoms, which are recorded as provisional pending your review.
• What we never receive. Your AI subscription credentials stay between you and your AI provider. The connector authenticates your tool to Engrym with an Engrym-issued token; it does not give us your Claude (or other provider) account credentials, and we never replay or use your subscription.
• Auto-pull consent. By default your agent pulls extraction work only when you ask it to. Automatic pulling is a per-Project, off-by-default setting you control from the dashboard, including an optional in-session re-confirmation and an eagerness level.

3d. Public pages you choose to publish

A member of your Project can choose to publish a single Atom to a public web page at engrym.com/a/<link>, and a Project's owner can choose to open its whole Brain at a public address. Publishing is always an explicit act with a preview of exactly what will be public; nothing is published automatically, and the default for every Atom and every Project is private.

A published page is rendered by our hosting provider (Vercel) in the European Union (Dublin) and is then cached on that provider's global content-delivery network so it loads quickly wherever it is opened. Its preview image is generated in the same region and cached the same way. This means that while a page is published, its content and a preview image derived from it may be held at cache locations around the world. That cache holds only content that is already public: nothing private, and nothing about you, is placed on it.

Anyone with the address can read the page. There is no sign-in. Share Links for single Atoms are long, random, and are not listed in search engines, but they are not secret. An Open Brain's address is chosen by its owner and is meant to be found. A Brain its owner has closed answers as an address that never existed, and nothing further is served from it.

When a link is shared into another service, that service keeps its own copy of the preview. Slack, LinkedIn, iMessage, Notion, and similar tools fetch the page and store the title, the preview image, and a short excerpt of the content in their own systems. Those services are not our processors: they act on the instruction of whoever pasted the link, not on ours, and we have no ability to reach into or delete what they hold. See Section 5 for what revoking and closing do and do not do.

Who is the controller of a published page. You are. Deciding to publish is a decision you make about your own content, separate from your decision to store it with us, and you need your own lawful basis for any personal data it contains, including personal data about your colleagues, your customers, and anyone named in a Document. We do not review what you publish, and we do not decide what goes on your page. We host it, we serve it, and we can take it down (Terms, Section 3.1).

What we learn about people who read a published page. A reader needs no account and we ask for none. We set no cookie on a published page, we send nothing about the visit to any other company, and we do not build a profile of readers. Three things do happen, and each is stated here. Serving the page produces the same server-side request log every request produces (Section 1.5). We record the measurement event described in Section 1.6, which contains no IP address and nothing that identifies the reader. And to protect public pages from abuse, we rate-limit anonymous requests using a salted one-way hash of the requesting network address: the hash is held in a counter for the current minute, is deleted automatically within minutes, is used for nothing else, and the address itself is not stored.

If your personal data appears on a page someone else published, you can ask us to act, and Terms Section 3.1 says how and what we do. You can also ask the person who published it, who is the controller of that publication.

3e. The public read-only endpoint for Open Brains

An Open Brain can be read by an AI agent as well as by a person. The agent connects to a public read-only address for that Brain. No account and no credential is involved, we do not know who the reader is, and we do not ask.

The endpoint can only read, and only that Brain. It answers questions about the Atoms in the one Open Brain it belongs to. It cannot write anything, it cannot reach any other Project, and it cannot reach anything private. It is not the same connector as the one you authorize for your own account (Section 3c), which acts as you and can write.

What we receive from a reader's agent is the request it makes, which may include the text of a question the reader is asking. That text is used to answer the request and is not stored by us. Where answering involves sending the question to an AI provider to search by meaning, Section 4 says whose key that runs on and what limits apply.

What we never receive is the reader's AI subscription credentials, their identity, or anything from their own environment.

4. How the AI key paths handle your data

• Your-key (BYOK) path. Your Document and Atom text is sent to the provider you chose, using your key. That inference is governed by your agreement with that provider. The content passes through our servers in transit only, to dispatch the request; it is not stored by us and is not run on our account.
• Agent-mode path. Your own agent pulls the Document text from Engrym and runs the model on your own subscription, in your own environment. We make no provider call at all.
• Platform-funded path. Where you have not configured your own Google key, your Atom text and the text of your search queries (not source code, not full Documents) is sent to Google for (a) semantic-search embeddings, (b) turning a search query into something searchable by meaning, and (c) duplicate detection. Query text is not stored; it is held in memory for as long as the search takes, and an identical repeated query may reuse a result held briefly in memory. This path is metered, capped per account, and fails closed at the cap: semantic search degrades gracefully to keyword search, and duplicate detection is skipped. It never overspends.
• Public reads of an Open Brain. When a stranger reads or searches a Brain you have opened, that is not run on your key and is not counted against your limits. Your provider account is never spent on someone else's question, and someone else's use of your Open Brain cannot degrade your own search.

5. Retention, deletion, and export

• Content (Documents, Atoms, verdicts) is retained for the life of your Project: that is, until you delete the Project as described below. The Service preserves version history by design.
• Archiving a Project (self-serve, in the product) removes it from your working set. Archived data is retained rather than purged, and there is currently no self-serve restore for an archived Project. Archiving never leads to deletion by itself, but if you want an archived Project's data gone rather than retained, you can permanently delete the Project yourself: the deletion flow below accepts archived Projects.
• Deleting a Project (self-serve, permanent). A Project's owner can permanently delete it, active or archived, from the Project's settings. Deletion requires typing the Project's name to confirm, and the confirmation shows real counts of what will be destroyed. It then runs in two stages:
  • A grace window first, currently seven days. The moment you confirm, the Project disappears from every part of the Service (dashboard, API, connected agents, and search) and a purge date is scheduled; the product shows you the exact window and purge date. During the window the owner, and only the owner, can restore the Project intact. Restoring counts against your plan's Project limit: at the limit, you need a free slot or an upgrade first.
  • Then an automatic, irreversible purge. After the window ends, an automatic job permanently destroys the Project's data: its Documents (including their version history), its Atoms, its decision and Reconciliation Verdict history, its full event stream, its imported media files, its cross-references to and from other Projects, its Git-export configuration and stored credential, and the Project's stored keys (its encryption keys and any BYOK provider key saved for it). There is no restore after the purge.
• When deletion is refused. If the Project is linked to another Project, deletion is refused until the link is removed; the product tells you which linked Projects block and how many cross-references are involved. In the rare case that a subscription is anchored directly to the Project, deletion is refused until the billing situation is resolved; contact us and we will sort it out.
• What deleting a Project does not touch. Your account, your other Projects, and your connected agents and API keys are untouched (they are account-level; they lose access to the deleted Project because the Project no longer exists). Minimal billing records are retained for as long as the law requires. And we never touch your external Git repository: the Project's export configuration and stored credential are destroyed on our side, but the repository you control, and everything already exported to it, stays exactly where it is.
• What "permanently" means, the honest version. The purge removes the Project's data from our live systems, and nothing in the Service can bring it back. Copies may persist for a limited period in our hosting providers' routine backups, which expire on those providers' backup-retention cycles; we do not restore purged Project data from backups. The Project's encryption keys are destroyed in the purge, which immediately makes the content encrypted with them (the Project's stored provider keys and Git-export credential) permanently unreadable everywhere, including in any backup copy. We will not claim deletion is instantaneous everywhere at once, because that would not be true.
• Deleting your account remains handled on request: email us at the privacy contact below from the email address on the account, and we will verify the request and delete your account and its content, except for minimal billing records retained for as long as the law requires and the records described in the two bullets below.
• What deleting your account does to anything you published. Your Handle stops being displayed anywhere public: it is removed from your Public Profile, which is taken down, and from every Origin Credit in which it appeared. Each of those Origin Credits continues to record that the work originated elsewhere, in a form that does not name you. We keep the publication record described in Section 1.11, which is not published and is not displayed, because it is the evidence of a grant that other people have already relied on and that cannot be withdrawn from them (Terms, Section 7.7).
• What deleting your account cannot reach, stated plainly because it is the part people do not expect. Deleting your account does not close a Brain you opened. If you want a Brain out of public view, close it first (Terms, Section 7.6). A Brain still open when its last member's account is deleted becomes Frozen and continues to be served. And nothing, including closing, deletes the copies other people made of a Brain while it was open: those sit in their own Projects, which are theirs, and may themselves have been opened and copied again. Neither we nor you can recall them. This is why opening a Brain is presented as something you can stop but cannot take back, at the moment you do it, and why we say so again when you claim a Handle. If you need something you published to be removed from our public pages, close it, or ask us at the privacy contact below and we will act under Terms Section 3.1; do not rely on account deletion to achieve it.
• Derived data. Search vectors and other data derived from your content are deleted together with the content they were derived from.
• Public records that outlive the thing they point at. A revoked share record is kept permanently so that a dead link can never be reissued (Section 1.9). A publication record is kept permanently because it is the evidence of what was granted (Section 1.11). Neither contains any Atom content, and neither is displayed publicly.
• Public-page measurement events (Section 1.6) are kept for a limited period, which we will state here once we have fixed it. They contain no IP address and nothing that identifies a reader, they are never combined with an account, and they are used for nothing but measurement and abuse protection.
• Export. You can export your Project at any time, and you may configure a Git export to a repository you control. After cancellation, export remains available for a limited period. The deletion confirmation reminds you that export exists: you can take everything with you before you delete.

6. Cookies and similar technologies

The only cookies the Service sets are authentication and session cookies, which keep you signed in and are strictly necessary for the Service to function. We run no analytics cookies, no advertising cookies, and no third-party tracking pixels (see Section 1.6). Public pages, which need no sign-in, set no cookie at all.

Separately, if you choose a light or dark appearance on the landing site or in the dashboard, that choice is stored in your browser's local storage so that pages can paint in the theme you chose. It is a preference you set, it is read only by our own pages, and it is not sent to us or to anyone else.

7. Your rights and how to exercise them

Depending on where you live, you may have rights to access, correct, delete, port, restrict, or object to the processing of your personal data, and, where processing relies on consent such as the newsletter, to withdraw that consent at any time. The Service is built for portability: the Git export and full Project export give you your data in standard, open formats at any time. To exercise a right that is not yet self-serve (such as account deletion), email the privacy contact below.

Withdrawing supporters-wall consent (Section 1.8) is self-serve: use the wall toggle in your account settings; the record is deleted and your name is removed from the wall.

Taking down your Public Profile and clearing any field on it is self-serve, from your account settings, at any time (Section 1.10). Closing an Open Brain is self-serve, from the Brain's settings (Terms, Section 7.6).

Where you have published something, one right has a limit that we want you to know about before you publish rather than after. You can close an Open Brain, which stops new readers and new copies, and we can stop serving any page (Terms, Section 3.1). What neither closing nor we can do is recall a copy that has already been made, by anyone, anywhere: a Fork taken while your Brain was open is its owner's, and a preview cached by another service is outside our reach. If you are deciding whether to publish something that contains personal data, yours or anyone else's, decide it on that basis.

If your personal data appears on a page someone else published, write to the privacy contact below, or use the reporting route in Terms Section 3.1. The person who published it is the controller of that publication and you can also approach them; we will act on our side under Terms Section 3.1 and will help you reach them where we reasonably can.

RTK AI Labs Ltd is established in England and Wales (United Kingdom), so the UK GDPR is the primary regime; the EU GDPR also applies to users in the European Union.

Privacy contact: privacy requests can be sent to us by email at oussama.berrahal@engrym.com.

8. Changes to this policy

We may update this policy as the Service evolves or as new processors are added. We will give notice of material changes and maintain a current sub-processor list.

9. Document history

• 5 September 2026. Added the public-publishing disclosures. New Section 1.9 covers the share records behind Public Atom Pages, which have been live in the product and were not previously described in this policy. New Sections 1.10 and 1.11 cover Handles and Public Profiles, and the publication, fork, and transfer records. Section 1.6 is rewritten: the former statement that no page-view analytics ran anywhere was no longer accurate once public pages carried a first-party measurement event, and the section now describes that event exactly (no IP address in any form, no cookie, nothing read from the device, Do Not Track and Global Privacy Control honoured) while confirming that no third-party analytics runs anywhere and no measurement runs on the landing site or the dashboard. New Section 3d covers public pages, who controls them, and what we learn about readers, including the short-lived salted address hash used only for rate limiting; new Section 3e covers the public read-only endpoint for an Open Brain. Section 3a's Vercel row and Section 4 are corrected: search query text is sent to Google on the platform-funded path, which was true before this revision and was not stated, and public reads are not funded from your key. Section 5 now says what deleting your account does and does not reach where you have published something, Section 6 discloses the browser-stored appearance preference, and Section 7 says the same from the rights side.
• 11 July 2026. Section 5 rewritten for self-serve Project deletion: a Project's owner can now permanently delete any Project, including an archived one, from the product, with a grace window (currently seven days; restorable by the owner) followed by an automatic, irreversible purge. The former "contact us to request deletion of archived data" path is replaced by the self-serve flow; account deletion remains on request, unchanged. Added explicit statements of what deletion does and does not touch, when it is refused, and an honest statement about backups: the purge clears our live systems, backup copies expire on our hosting providers' retention cycles, and the Project's encryption keys are destroyed at purge.
• 10 July 2026. Added Section 1.8 (the Founding Supporters wall opt-in: minimal consent record, display-name-only public listing, outright deletion on withdrawal) and a self-serve-withdrawal line in Section 7.
• 3 July 2026. Updated to match the live product: removed the analytics and error-monitoring disclosures (no analytics service and no error-telemetry service is integrated in any part of the product today; describing them overstated our collection) and replaced them with the server-side request-log description that is actually true. Corrected the processor schedule: Fly.io hosts the remote MCP connector and the background workers, not only a Git-export worker, and runs in the United Kingdom (London), not the European Union; Supabase and Vercel regions stated precisely. Added Section 3c describing the MCP connector's OAuth flow and agent-mode extraction (your agent runs the model on your own subscription; we never receive your subscription credentials). Retention section now states what exists today: self-serve Project archive with retained data, and account deletion on request rather than self-serve.
• 19 June 2026. First published version.