Every control in the technical register carries a build-status label. Legal commitments remain as published: a missing test or an unavailable implementation status does not suspend a contractual commitment.
Privacy Policy
What personal data we hold, why, and for how long. Session contents are covered separately by the data processing agreement, because there we are a processor acting on your instructions rather than a controller.
We collect the minimum to run accounts and bill them: identity from your login provider, contact details, and usage telemetry. We do not sell data, we do not run advertising trackers, and we do not train on your session contents.
A summary is not the agreement. Where the two disagree, the clauses below govern.
1 What we collect
What we collect
Two categories, kept deliberately separate. Account data is about you: name, email, organization, login provider identity, billing details, and the audit trail of actions you take in the console. Session data is what your agents do, and for that we are a processor under the DPA rather than a controller.
Billing runs through Polar, our merchant of record: card details go to Polar and never touch KeepState; what we keep is your credit ledger, immutable usage statements, and the purchase receipts Polar issues. Transactional email (signup, receipts, alerts) is sent through Azure Communication Services with authenticated outbound (SPF, DKIM, DMARC; the delivery gate).
| category | retention | basis |
|---|---|---|
| Account and contact data | life of account + 6 y | contract |
| Billing records | 7 years, under legal obligation | legal obligation |
| Console audit log | append-only; category not stated in policy v1.0 | legitimate interest |
| Product telemetry | 13 months | legitimate interest |
| Session contents | while the account exists; no automatic expiry | processor, see DPA |
2 What we do not do
What we do not do
This section exists because the absences matter more than the presences.
No advertising or cross-site tracking pixels anywhere on this site or in the console.
No sale or sharing of personal data with third parties for their own purposes.
No model training on your session contents, by us or by any subprocessor: a launch commitment, restated as binding when the service takes customer data.
No dark patterns in consent: analytics are off until you opt in, and the console works identically either way.
3 Who else touches it
Who else touches it
A short list of subprocessors, published separately and updated whenever it changes. Each one has a stated purpose, a region, and a data category. We give 30 days notice before adding a subprocessor that handles session contents, so you can object.
4 Where it lives
Where it lives
Account data is stored in the EU. Session contents live on the KeepState fleet in Microsoft Azure in Europe, stated from observation of the running deployment. Region CHOICE (pinning enforced at the scheduler, so a checkpoint could not be written outside the region you pin) remains planned: one region operates today, and this page will say so the day a second one does.
4a Workspace content under the hosted model
Workspace content under the hosted model
When you run a session, three categories of your content reach our infrastructure: the workspace you chose to send (named flag by flag when you started the session), the checkpoints of your sessions, and the event ledgers. They are processed only to run, store, and restore the sessions you asked us to run. How long each category is kept, and what deletion does to it, is the approved matrix in section 4b, which is the only retention answer this site publishes. We run no third-party analytics on any of it, no advertising trackers anywhere on the service, and we do not train models on your content. The same matrix, with the same evidence links, is stated on the Security page.
4b Retention and deletion policy v1.0
Retention and deletion policy v1.0
Retention and deletion policy v1.0 · approved 2026-09-09. This is the company's stated policy, published exactly as ruled. Legal holds are not currently supported; retention proceeds as stated unless law requires otherwise.
This policy was approved on 2026-09-09 and published as final on 2026-09-14. The commitments below remain in force as published. Implementation gaps are stated separately and do not amend the policy.
A cell reading "not stated in v1.0" is a question this version does not answer. It is printed rather than filled, because filling it would be inventing policy; it is answered in a versioned reissue, never in place.
| category | retained | deletion | backups | evidence |
|---|---|---|---|---|
| Checkpoint content | while the account exists; no automatic expiry | deletable by the customer, per session; the key is destroyed on account deletion | encrypted, and unreadable once the key is destroyed; backup retention 30 days | account deletion: er-1c-green, er-1c-prod-green; per-session deletion: er-1s-green (bench); served in production since 2026-10-06 (docs/deploy-2026-10-06.md) |
| Provider credentials | same as checkpoint content | same as checkpoint content | same as checkpoint content | account deletion: er-1d-green, er-1d-prod-green |
| Ledgers and billing aggregates | 7 years, under legal obligation | the identity is tombstoned on deletion | not stated in v1.0 | tombstone: er-1c-prod-green |
| Service logs | 30 days | not stated in v1.0 | not stated in v1.0 | no gate yet |
| Support tickets | 2 years | not stated in v1.0 | not stated in v1.0 | no gate yet |
| Console audit log | 2 years | the identity is tombstoned on account deletion | not stated in v1.0 | tombstone: er-1c-prod-green |
| Account data | while the account exists | deleted on account deletion, except the tombstone id and the billing aggregates already covered above | not stated in v1.0 | account deletion: er-1c-prod-green |
| Telemetry | 13 months, then deleted | first-party, cookieless, and carries no identifiers, so there is nothing to tombstone | not stated in v1.0 | no gate yet |
4c What the policy rests on, and what is not built yet
What the policy rests on, and what is not built yet
The rows in section 4b are the commitment. Below are the dated historical results and known implementation gaps. A historical test does not establish current production assurance. The commitments remain as stated and require remediation where implementation is missing.
Historical evidence: account deletion made the tested checkpoint backup unreadable in a synthetic production check. This proves the tested account-deletion behavior, not per-session deletion or every possible backup.
Historical evidence: stored provider credentials were protected per account and a tested database backup became unreadable after deletion. This depends on keeping account keys outside the database backup set and removing independent key copies.
Historical evidence: account deletion removed personal identity fields while retaining the tombstone needed for ledger consistency. Ledgers and billing aggregates have a separate retention commitment.
Evidence: deleting a session erases the checkpoint content only that session held, served in production since 2026-10-06; sessions saved earlier were re-sealed on 2026-10-10 so it covers them. Content a surviving fork shares stays that fork's. A production check through the customer deletion route is still owed. Stopping or killing a session does not delete its stored content.
Implementation gap: no automatic expiry job is established for these categories. The 30-day backup and service-log periods and the two-year support-ticket period remain policy commitments; current evidence of procedural enforcement is not available.
Legal holds are not currently supported; retention proceeds as stated unless law requires otherwise.
5 Your rights
Your rights
Access, correction, deletion, portability, and objection, exercised by emailing privacy@keepstate.ai. We answer within 30 days. What deletion does to each category of your data is the matrix in section 4b and nothing else on this page: no period, category or exception appears here that the approved policy does not carry, and a legal hold is not among them because policy v1.0 rules on none.
6 Contact and complaints
Contact and complaints
Our data protection contact is privacy@keepstate.ai (inbound confirmed 2026-09-03). If we handle a request badly you may complain to the Information Commissioner’s Office in the UK, or to your own supervisory authority in the EU.
Control status register
reg Control status register
technical register, not part of the agreement
Every control this document names, with the deployment state derived from the same capability source /security and /proof render. Implementation evidence is dated separately from the legal commitments above. Missing evidence does not amend those commitments; gaps require remediation and communication of customer impact.
| control | status | evidence |
|---|---|---|
| No model training on session contents The published commitment not to train models on session contents remains as written. Current implementation evidence is not available; provider processing is governed by the applicable provider terms. Evidence register dated 2026-10-23; current implementation not independently verified. The published commitment remains. | production state unavailable | none · plan, not proof |
| Audit trail of staff actions against customer data Built and running in production: every write a staff member makes through the admin console is logged with who, what and why, and the admin console's gates (ad-1 to ad-4, under ADR-022) proved it on the bench, sabotage runs included. No dedicated public gate covers staff access outside the admin console. Evidence register dated 2026-10-23; current implementation not independently verified. The published commitment remains. | production state unavailable | /evidence/phase-ad |
| Encryption at rest with per-organization keys Historical production checks report per-account checkpoint encryption and account deletion that made the tested saved content unreadable. Continued protection depends on key custody; this is not evidence of per-session deletion. Evidence register dated 2026-10-23; current implementation not independently verified. The published commitment remains. | production state unavailable | none · plan, not proof |
| Published, versioned subprocessor list The versioned subprocessor list and its stated notice periods remain binding. The register is an editorial policy record, not a technical test. Evidence register dated 2026-10-23; current implementation not independently verified. The published commitment remains. | production state unavailable | none · plan, not proof |
Version history begins at v1.0, effective 2026-09-03; no earlier version exists. Material changes are announced 30 days before they take effect, by email to Owners and in the changelog.
v1.0 · effective 2026-09-03 · no prior versions