Privacy Policy

This policy explains what personal data Cratis Studio ("the Service") collects, why, how it is protected, how long it is kept, and how you get it removed. It is written to be read — the mechanisms described here are the ones the Service actually implements, not aspirations.

1. Who is responsible for what

For the account data we need in order to run the Service — who you are, which organization you belong to, what you bought — Cratis is the controller. For the content your organization puts into the Service — models, documents, comments, and any personal data inside them — your organization is the controller and Cratis is the processor. We act on your organization's instructions and do not decide what goes in.

If you are a member of an organization and want something removed from its content, ask the organization's administrators first; they control that content. We will help them, and we will act directly on a request where the law requires us to.

2. What we collect

Identity and account data. Your name, email address, and the stable subject identifier issued by the identity provider you sign in with. We never receive or store your password — authentication happens at your identity provider.

Organization data. The organization name, its members and their roles, invitations sent and accepted, and which version of the terms and privacy policy was accepted, by whom, and when.

Billing data. The seats purchased, the billing cycle, subscription and payment status, and the identifiers our payment provider issues. Full card details are handled by the payment provider and never reach our systems.

Your content. Everything your organization creates in the Service. This is yours; we process it only to run the Service.

Operational data. Logs, error reports, and performance metrics needed to keep the Service running and secure. These can include IP addresses, timestamps, and request paths.

Optional feature data. If you use dictation or spoken explanations, the audio or text involved is processed to produce the result and is not retained afterwards beyond what is needed to return it.

We do not use tracking or advertising cookies, and we do not sell personal data.

3. Why we process it, and on what basis

Purpose | Basis

Giving you access to the Service and to your organization — Performance of the contract

Billing, invoicing, and collecting payment — Performance of the contract

Keeping the Service secure, available, and abuse-free — Legitimate interests

Recording who accepted which version of the legal terms — Legal obligation and legitimate interests

Meeting accounting and tax obligations — Legal obligation

Product and service announcements — Legitimate interests (you can opt out)

We do not use your content to train machine-learning models.

4. How personal data is protected — encryption per person

The Service is event-sourced: what happened is recorded as an append-only sequence of events, and the state you see is derived from that sequence. An append-only log cannot simply have rows edited or deleted, so personal data is protected by a mechanism designed for that model rather than by after-the-fact deletion.

Every value that identifies a person is classified as personal data at the point it is defined, and is encrypted individually before it is written.

• Encryption is applied per data subject — the individual the data is about. Each person's values are encrypted under a key belonging to that person, so one person's data cannot be read using another's key.
• Keys are held per organization in HashiCorp Vault, a dedicated secrets store, separate from the systems that hold the data. Neither the event store nor the databases holding derived state ever contain a key.
• Encryption is applied wherever the value travels — inside events, inside nested structures, and inside the derived read models built from them. It does not depend on anyone remembering to annotate the next place the value appears.
• Decryption happens only when data is served to someone entitled to see it, and only for the subject in question.

The practical consequence: a copy of the raw data store — a stolen disk, a leaked snapshot, an old backup — contains personal data only as ciphertext, and is worthless without the key material held separately in Vault.

Alongside this, data is encrypted in transit (TLS) and at rest at the storage layer, access is restricted to the small number of personnel who need it for operations, and each organization's data lives in its own isolated namespace.

5. Credentials you give the Service

Some features only work if your organization hands the Service a credential belonging to it — an API key for a language model provider, for example. A credential is not personal data, but it is the key to someone else's account, so it is handled as a secret rather than as ordinary configuration.

• Encrypted before it is stored. A credential is encrypted while the request that supplies it is being handled, under a key belonging to your organization. What reaches the event log, and every derived read model built from it, is ciphertext. The plaintext exists only in memory, only for the moment it takes to encrypt it.
• Never returned to the browser. No screen and no API the frontend can call gives back a stored credential. The settings screen lets you set one and replace it; it never shows you the one already there, because there is no path that reads one back out.
• Decrypted only at the point of use. A credential is decrypted on the server, at the moment a request is made to the provider it belongs to, and the decrypted copy goes no further than that request. It is never written to a log.
• What an operator can see. Personnel with access to the raw data store see ciphertext. Reading a credential additionally requires your organization's key material, and access to that is limited to the small number of people who need it to run the Service.

Delete the organization and its stored credentials go with it. We recommend also revoking the credential at the provider that issued it — that is the only thing that stops it being used elsewhere, and it is outside our control.

6. Your rights, and how erasure actually works

You have the right to access, correct, export, restrict, or object to the processing of your personal data, and the right to have it erased.

Access, correction, and export. Most of it you can do yourself from your profile and your organization's settings. For anything else, contact us and we will respond within 30 days.

Erasure — "the right to be forgotten". Because the event log is immutable, erasure is not performed by deleting rows. Instead, the encryption key for that person is destroyed.

Once the key is gone, every value encrypted under it — across the event log, across every derived read model, across every existing backup — becomes permanently unreadable, immediately and everywhere, with no migration to run and no copy left behind that can be decrypted later. Reading such a value afterwards returns an empty value rather than an error, so the surrounding history stays intact: the record that something happened survives, while the personal detail of who it happened to does not.

This is deliberately irreversible. Erasure cannot be undone, so we confirm the request before carrying it out.

Where a specific event payload rather than a person must be removed, we can additionally redact it: the payload is replaced in place, its position in the sequence is preserved, and the redaction is itself recorded — so the history remains auditable and does not silently change shape.

Some records survive an erasure request because the law requires it — invoices and other accounting records in particular. We keep the minimum needed and for no longer than required.

7. Backups — continuous, and what they mean for you

All data in the Service is backed up continuously. This is not a nightly snapshot: the databases run with replication and point-in-time recovery, so writes are captured as they happen and the system can be restored to a chosen moment rather than to the last time a job ran.

• Coverage — the event log, every derived read model, and operational metadata. Nothing that carries your organization's data is left out.
• Retention — backups are retained on a rolling window of 35 days and then expire automatically. A restore is possible to any point inside that window.
• Isolation — backups are stored encrypted, separately from the live systems, with their own access controls.
• Verification — restores are exercised periodically. A backup that has never been restored is not a backup.
• Personal data in backups — because personal values are encrypted per person before they are ever written, they are already ciphertext in every backup. Destroying a person's key therefore renders their data unreadable in every backup that exists, not just the live system. This is the reason erasure can be honored immediately rather than "once the backups roll over".

Encryption key material itself is backed up separately under stricter controls, because losing it would make your organization's data unreadable. A key destroyed to satisfy an erasure request is destroyed in those backups too.

8. Who else processes your data

We use a small number of sub-processors, each under a data-processing agreement and each limited to what it needs:

• Cloud infrastructure provider — Hosting, storage, and backups
• Payment provider — Processing subscription payments
• Email delivery provider — Transactional email — invitations, notifications
• Identity providers — Authenticating you when you sign in
• Language model providers — Only where you use an AI-assisted feature that requires one

AI-assisted features send only what is needed to produce the requested result. Where a self-hosted model is available it is used in preference to an external one. Content sent to an external model provider is not used by them to train their models.

The current list is available on request. We give notice before adding a sub-processor that materially changes how your data is handled.

9. Where data is processed

Data is processed within the European Economic Area. Where a sub-processor operates outside it, the transfer is covered by an adequacy decision or by Standard Contractual Clauses together with the technical measures described in section 4 — which, given that personal values are encrypted per person before they leave our systems, means the data transferred is ciphertext.

10. How long we keep it

• Account and organization data — for as long as the organization exists, then 30 days (see the terms), then deletion.
• Your content — the same, unless erased earlier at your request.
• Billing and accounting records — as long as tax and accounting law requires, typically five years.
• Operational logs — 90 days.
• Backups — 35 days on a rolling window (section 7).

11. Children

The Service is not intended for children under 16 and we do not knowingly collect their personal data. If you believe we have, contact us and we will remove it.

12. Breach notification

If a breach occurs that is likely to result in a risk to people's rights and freedoms, we notify the relevant supervisory authority within 72 hours of becoming aware of it, and we notify affected organizations without undue delay — with what happened, what data was involved, and what we are doing about it.

13. Changes to this policy

We may update this policy. Every version carries a version marker, and the version you accepted is recorded against your organization together with who accepted it and when. For material changes we give at least 30 days' notice and ask for acceptance of the new version.

14. Contact

Privacy questions, and requests to access or erase your data: privacy@cratis.io

You also have the right to lodge a complaint with your local data protection authority.