Privacy Policy

1. Controller

Email: me@till-it-works.de · Phone: +49 1577 5976707

2. Overview

This policy has one part for each: Part A covers the website korpus.cloud. Part B covers the Korpus app: the web app at fra.korpus.cloud, its API at api.fra.korpus.cloud and its MCP server at mcp.fra.korpus.cloud. What applies to both, such as contact, your rights and changes, is in Part C.

In short:

• Your account and your content are stored with Amazon Web Services in Frankfurt (region eu-central-1). Email you write to us lands in our mailbox at Google (B.14).
• No cookies, no tracking, no analytics, no advertising.
• We may check content, catalog submissions and support tickets automatically, also with AI models, by default on Amazon Bedrock in the EU, otherwise at Anthropic, for security, abuse and quality. Your content never trains a model (at Anthropic, training is opted out), and a person decides what follows (B.7). Other AI apps reach your content only when you connect them yourself (B.4).
• We do not store IP addresses.
• We do not sell or share personal data.
• The paid plan, Pro, is sold by Sold through Link, LLC, a Stripe company, as merchant of record. Your payment details never reach us (B.5).

Part A · The website korpus.cloud

A.1 Hosting

The website is a static site, served from Amazon S3 through Amazon CloudFront by Amazon Web Services EMEA SARL, 38 Avenue John F. Kennedy, L-1855 Luxembourg. To deliver a page, CloudFront has to process your IP address, the requested address, time, browser type and data volume. We have not switched on access logs, so we do not keep these data.

The site is stored in Frankfurt. CloudFront may deliver it from an edge location in Europe or North America; see C.4 on transfers. We have a data processing agreement with AWS under Art. 28 GDPR.

Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is to deliver the website securely and reliably.

A.2 Fonts

The fonts are served from our own domain, on the website and in the app. No request goes to Google or any other third party.

A.3 Cookies and local storage

The website sets no cookies. If you choose a light or dark theme, the choice is saved in your browser's local storage and never leaves your device. This is needed for the function you ask for (§ 25(2) no. 2 TDDDG).

A.4 Links

The website links to the Korpus app (Part B) and to external sites, whose operators are responsible for their own privacy practices.

Part B · The Korpus app

B.1 Your account

To use Korpus you create an account. We store:

• your email address,
• the username you choose (it cannot be changed later),
• an internal account ID,
• your plan and the date you signed up,
• which version of the Terms of Service you accepted, and when.

Sign-in runs through Amazon Cognito, with a passkey or with a one-time code sent to your email address. For a passkey, Cognito stores only its public key. The codes and other account emails (sign-up, change of email address) are sent through Amazon SES from no-reply@fra.korpus.cloud. We send no newsletters or marketing email.

Signing in with Google. If you choose “Continue with Google”, Google tells us your email address, whether Google has verified it, and Google's ID for your Google account; we ask for nothing else (no name, photo, contacts or other Google data). Cognito stores Google's ID with your Korpus account, so a later Google sign-in reaches the same account; your account then works as described above, and a passkey and the emailed code still work beside it. An address Google has not verified is refused. Google learns that you signed in to Korpus and processes this as a controller of its own, under its own privacy policy. We keep the link as long as the account (B.12).

Legal basis: Art. 6(1)(b) GDPR (performance of the contract).

B.2 Content you store

In a bundle you store concepts (markdown documents), the relations between them, and files kept with the concepts that describe them (assets: a PDF, a spreadsheet, an archive). Korpus keeps only the current version of each concept and each file; a change replaces what was there. Korpus records who made each change, so every write carries:

• the account ID of the person who made it,
• for an agent, the agent's name, as in "@mara via archivist",
• and the time.

Everyone who reaches the bundle can see this attribution. Every change is also recorded in the bundle's change log: when it happened, who made it (account ID, the agent's name, and for a change made with a key, that key's ID), which concept path it touched, whether it created, changed or deleted it, and the one-line description of the change the writer gave. The log holds no earlier versions of a concept. It is the bundle's history, so it is kept for as long as the bundle exists and deleted with it. The legal basis is Art. 6(1)(b) GDPR: the log is part of the shared bundle the members use. When someone @mentions you, a notification is stored for you.

A concept also records which members of its bundle its text @mentions, by account ID, never by name or email address, so the bundle can show them under their current username and find where someone is mentioned. The record is worked out from the text on every change: it goes when the mention is taken out of the text, or when the concept or the bundle is deleted. The links from one concept to another are recorded the same way, from the text. The legal basis is Art. 6(1)(b) GDPR: it is part of the shared bundle the members use.

Files are stored in Amazon S3 in Frankfurt and encrypted at rest. Each is read and written only through a link we sign for one request, valid for 15 minutes to upload and one minute to download, after we have checked that you may read or change the concept it belongs to. A file goes with its concept: replacing it or deleting the concept deletes it, and so does deleting the bundle. Deleted files can be recovered by us for 30 days, then they are gone. The legal basis is Art. 6(1)(b) GDPR: keeping the file is what you asked us to do.

Anyone who can read a bundle can export it: we build a zip of its concepts, their files, its index and its change log (with the usernames of who made each change), keep it in Frankfurt for one day so the link we hand you can fetch it, then delete it. The legal basis is Art. 6(1)(b) GDPR: you asked for a copy of the bundle you use.

Personal data of other people in your content. If you store personal data of other people in Korpus, for example names in a runbook or notes from a customer call, you decide why and how it is processed. If you do so for a business or another organisation, in a team on a paid plan, we act for that content as your processor under Art. 28 GDPR, under our data processing agreement, the AVV (English translation), which is part of the Terms. On the free plan, the Terms (§ 6) allow such content only for purely personal or household use.

No health data. Korpus is not made for special categories of personal data under Art. 9 GDPR, such as health data, or for protected health information under the US HIPAA; the Terms (§ 8) forbid storing them. We sign no business associate agreements.

Legal basis for your own data: Art. 6(1)(b) GDPR.

B.3 Teams, shares and publishing

Every bundle is in one team. Every account has a personal team named after its username, holding the bundles you make for yourself; it has no members. You can also make a shared team: we store its handle and name and who owns it. For each member we store their account; for each person invited, what the owner typed (a username or an email address, an address with no account yet until that address signs up, then the account instead) and whether they accepted. For each bundle we store who maintains it: the person who made it, or the member its team's owner named. Members see the team's name and handle, its owner's username, the other members' usernames, the names of the team's bundles with what members get of each and who maintains it, how much of the plan's space, bundles and people the team uses, and the bundles other teams shared with the team. Only the owner sees pending invitations and what was typed. Invitations are shown in Korpus (in the app and through its tools); we send no email for them. The team and its member list are kept until the owner deletes the team or their account; a membership until the person leaves or the owner removes them; a pending invitation until it is accepted, declined, withdrawn or claimed by the account that confirms the address, and at most 7 days: one nobody answered by then is deleted by us within a day. The owner can offer the team to a member: we store whom it is offered to and when. If the member accepts, they become its owner and the former owner stays a member. If they decline, they stay a member, and we store that they declined (their account) and show it to the owner until the owner offers the team again or withdraws. An offer nobody answers ends after 7 days.

A bundle can be shared with people and with teams. For each share we store the bundle, whom it is shared with (what was typed: a username or an email address, an address with no account yet until that address signs up, then the account instead; or a team), what it gives (read, write, or up to five paths with their rights), who shared it and when, whether it was accepted, and, for a share made by opening a join link, which link (kept with the share after the link ends, so its list says it came by link). The bundle's maintainer and its team's owner see its shares. The person it is offered to, or the owner of the team it is offered to, sees the bundle's name, the team it is from and what it gives, and says yes or no. Shares are shown in Korpus; we send no email for them. A share is kept until the maintainer, the team's owner or the one it is shared with ends it, until the bundle, the team or the account it names is deleted, or, for a member of the bundle's team, until they leave the team. A share still waiting for its yes after 7 days is deleted by us within a day; whoever offered it can offer it again. In November 2026 sharing was rebuilt: the members of a shared team were given each of its bundles to write; shares in effect of a whole bundle to a person were kept, at the same access; shares with teams, shares of only some paths, shares not yet answered, the notes and answers kept with shares, the members a team's owner had named to maintain a bundle, and settings that kept a bundle from its own team were deleted.

A share waiting for your yes also shows the username of the person who offered it. You can decline all waiting shares at once, or block the person who offered one: we store that you blocked them, the reason you give and when. Blocking declines every share they offered you, or a team you own, that is still waiting, and hides the shares they offer you after; they are not told, and see their offer as waiting until it ends after 7 days like any other. Only you see whom you blocked, in Settings. A block is kept until you unblock them, or until your account or theirs is deleted. Unless you untick it, a block also reports them to us (B.9). To keep shares from being used to flood people, each person may have at most 10 shares outside their teams waiting for a yes, and offering them is limited per minute and per day: those counters hold only the account ID and are deleted after their window. Legal basis for blocks and counters: Art. 6(1)(f) GDPR; our legitimate interest is to protect people from unwanted offers and the service from abuse.

The owner of a team can make a join link: we store the team, how many may join with it and how many have, when it ends (at most 30 days), who made it and when, the bundles it shares and what it gives of each, if any, and only a one-way hash of the link itself, which is shown once. Anyone signed in who opens it joins the team, or, when it names bundles, gets those shared with them instead; they appear under the team's people, or under the bundle's shares, like anyone else. A link is deleted when the owner deletes it, or by us on the day it ends. The owner also sees which of the agents of the people who reach the team's bundles work there, and a bundle's maintainer and its team's owner which work on that bundle, a person outside the team with a share included: the person's username, the agent's name and what it may do, read from the agents themselves (B.4) and not stored again.

Anyone who reads all of a bundle can copy it: a copy is a new bundle of the person who made it, holding the content as it was, and records which bundle it came from; the original's owner does not see the copy. To show what changed since your last visit, we store when you last opened each bundle you reach; it is deleted with the bundle or your account.

If you publish a bundle to the Korpus catalog, each version is a copy of the bundle's current content. Our reviewers read each version before it appears. Once approved, the newest version is listed in the catalog inside the Korpus app, for signed-in users only: its title, summary, category and tags, your username as publisher, and how many concepts it holds. Nothing of it is published outside Korpus. Only you and our reviewers read the version itself. A newer version replaces the listing; the listing goes when the version is removed or taken down.

Other users can use a published version as a template: they clone it into a bundle of their own. A clone is the other user's own bundle from then on. It stays with them when you remove the version or delete your account.

Legal basis: Art. 6(1)(b) GDPR.

B.4 Agents and connected apps

You can create agents in Korpus (a name, a job and the bundles it reaches, each with what it may do there, for an AI app, an automation or a program acting for you) and connect apps to them, or to your own access (me), over MCP or the API, for example Claude, ChatGPT or Cursor. You yourself connect by signing in through our own OAuth server. An agent connects the same way, at its own address and with your approval, or with a short code you approve for a device that has no browser, or, for a job on GitHub Actions or AWS you trust, by trading the token that platform gives the job, or, as a last resort, with a key you create for it. For agents and connections we store:

• the agent's name and job, and the bundles it reaches, each with what it may do there (read, write, or up to five paths with their rights); kept until you delete the agent or your account, and a bundle goes from it when the bundle is deleted. The owner of a team sees an agent's name and what it may do when it reaches one of the team's bundles (B.3),
• for each connection: the access it is for, the door it is bound to (API or MCP), how it signs in (sign-in, trust or key), the name the app gave itself or the label you gave the key, the host it signs in from, when it was created, when it expires, when it was last used,
• for each key: its label, its agent, when it was created, when it expires and when it was last used (to the hour),
• for a device sign-in waiting for your approval: the app's name, the agent it asks for, the username its link named (if any), the short code, when the device last asked and, once you approve it, your account ID; it stops working after 10 minutes and is deleted within a day,
• for each workload you trust: the GitHub repository's name and numeric IDs and the environment, branch or pattern you chose, or the AWS account's issuer address and the role names, the address its tokens must name (which contains your username), when you added it and who added it; kept until you revoke it, delete the agent or delete your account,
• for each token traded by a trusted workload: the trust it came through and the workload's identity as its platform names it (the AWS role or the GitHub repository and job context), valid for 1 hour; and a one-way hash of the platform token itself, so it cannot be traded twice, deleted within a day,
• access and refresh tokens and keys, as one-way hashes only.

Until November 2026 a shared team could hold agents of its own; they were deleted then, with their connections, keys and trusts.

An access token is valid for 1 hour. A refresh token is valid for 30 days and changes on every use. A key is valid until the expiry you chose when creating it (30 days, 90 days or 1 year), unless you revoke it first, and also stops working once it has gone unused for 90 days. It is shown to you once and never again. An app registration that is never used expires after 90 days. An app that names itself by the address of a description it publishes (a client metadata document) has that description fetched by us and kept for a day; it holds the app's name and addresses, nothing about you. To check a trusted workload's token we fetch the public signing keys of GitHub or of your AWS account's issuer; to add a public GitHub repository we read its IDs from GitHub's public API. Neither request carries anything about you.

What reaches us from the app. Over MCP an app such as Claude sends us tool calls (and a program over the API, the same calls as plain requests): which operation to run, on which bundle and path, with what arguments. We answer with the result. We never receive your conversation with the app, your other prompts, or files you have not passed to a call. What a call writes is stored as content (B.2); what it only reads is not kept, except the usage counters (B.10) and, for some actions, an audit entry (B.8). All of it is processed and stored in Frankfurt (eu-central-1) and kept as described in B.12.

Disconnecting. Remove the connector in the app, and revoke its connection under Agents in Korpus (or delete the agent); a revoked connection's tokens stop working at once. A key is revoked the same way. Removing the connector only in the app leaves the refresh token to expire unused after 30 days. Deleting your account (B.12) removes everything the connection could reach that you own alone.

Keys found in public. GitHub scans public repositories, gists, packages and Actions logs for Korpus keys and sends us each one it finds, with the public address where it was found and what kind of place it was (for example a file or a commit). We revoke the key at once, email your account's address which agent and key it was and where it was found, and keep that place in the audit trail (B.8). Neither GitHub's message nor ours carries anything else about you, and the key itself is never stored or sent on. Legal basis: Art. 6(1)(f) GDPR; our legitimate interest is to stop a key that anyone can read from reaching your content.

What the AI app does with your content. A connected app reads and writes your content within the limits you set for its agent. What the app and its provider do with that content is governed by your own agreement with that provider. That provider is not our processor, and you decide which apps you connect. You can revoke a connection at any time.

Legal basis: Art. 6(1)(b) GDPR.

B.5 Payments (Pro and Business)

Pro is sold through Stripe Managed Payments. The merchant of record is Sold through Link, LLC (link.com), a Stripe company, 354 Oyster Point Blvd, South San Francisco, CA 94080, USA. It sells you the subscription, takes the payment, issues receipts and invoices, and handles taxes. For that sale it is a controller of its own; its privacy policy applies. Payments are processed by Stripe Payments Company or Stripe Technology Europe, Limited.

Pro is bought for a team by its owner, and each team has its own Stripe customer. When you start a checkout, we give Stripe your email address, your account ID and the team's ID, so the subscription can be matched to the team and to you as its owner. Your card or other payment details go to Stripe directly and never reach us. We store, with the team:

• its Stripe customer ID and subscription ID,
• the subscription's status, whether it is cancelled at the end of the period, and when the period ends.

Only the owner sees where a team's Pro stands; its members see only that it is on Pro. When a team is handed to a member, which is possible only once its Pro has ended, the team drops the former owner's customer ID; the new owner's first checkout makes a new one. These data are kept as long as the team, and deleted with it or with the owner's account.

Legal basis: Art. 6(1)(b) GDPR.

Business is not sold through Stripe. It is agreed with us in writing and invoiced by us directly. For that we keep the contract, the customer's name and billing address, the name and email address of its contact person, and our invoices and payments. We use them to perform and bill the contract, and keep invoices and the records they rest on for 10 years, as German tax and commercial law requires (§ 147 AO, § 257 HGB).

Legal basis: Art. 6(1)(b) and (c) GDPR.

B.6 Cancellation and withdrawal

You can cancel or withdraw from Pro without signing in, on the page Cancel or withdraw contracts here. The form asks for your name, your email address, whether you cancel, withdraw or cancel for cause, and, for a cancellation for cause, your reason.

We use these data to find the subscriptions of every team you own and carry out your declaration for each. A withdrawal declared within 14 days first cancels Pro to the end of the paid period; the confirmation email carries a link, and opening it ends Pro at once and refunds you in full. Until the link is used, and for at most 7 days, we keep the withdrawal with your name, the address, the subscription and the time you declared it, so that only the holder of the account's mailbox can complete it; it is deleted when used or after those 7 days. We confirm receipt by email to the address you gave, sent through Amazon SES, and send a copy to our own inbox. The declaration is recorded in the audit trail (B.8). To stop the page from being used to flood a mailbox, we remember the address for 15 minutes and send one confirmation per address in that time.

Legal basis: Art. 6(1)(c) GDPR, together with § 312k and § 356a BGB, which require this page and the confirmation.

B.7 Operation and moderation

Korpus is run by the controller named in section 1, the operator. To support you when you ask, the operator can open your bundle, read only, on your instruction (for business use on a paid plan, under AVV § 3(4)). To keep the service secure, act on abuse or illegal content, meet legal duties, or review a submitted publication, the operator can open any bundle, read only, as far as needed for that purpose. The operator opens bundles only in the web app or through Korpus's interfaces, never through an AI app. The one exception is a version you submitted for publication in the catalog: to review it, the operator may also open it through an AI app, whose provider then receives what is read of that version and handles it under its own terms. Your bundle itself, and anything you did not submit, is never opened that way. Every such opening is logged in the audit trail (B.8); on request we tell you the openings of your bundles.

Automated checks and AI. To run the service, keep it secure and keep up its quality, we may check content automatically, also with AI models: for example to detect abuse, security risks and illegal or harmful content in bundles, to check a version submitted for the catalog before it is reviewed, and to sort and classify support tickets and feedback (B.9). A check reads only what it needs. We use AI models only at the providers listed in B.14: by default through Amazon Bedrock, only in AWS regions within the EU (Anthropic's models included), otherwise directly at Anthropic, whose processing takes place in the USA under standard contractual clauses. Neither uses the data to train models: at Anthropic, training is opted out, so your data is not used to train its models. The result of a check is a hint for the operator: every step that affects you, such as rejecting a publication, blocking an account or deleting content, is decided by a person, so no decision about you rests solely on automated processing (Art. 22 GDPR). An automated check is not an opening of your bundle; if the operator then opens it, that opening is logged as above. A check's result is kept no longer than what it checked.

The operator can block an account. A block stores when it was made, by whom, and an optional note about the reason. When a team's owner can no longer act (for example, they left the company), the operator can hand the team and its bundles on to one of its members; the former owner stays a member. For good cause, the operator can also delete an account; see sections 8 and 11 of the Terms of Service.

Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is to run the service securely and lawfully.

B.8 Audit trail

A few events are written to an audit trail, so we can tell later who did what and when:

• sign-up, username and email changes, plan changes (with the team whose plan it is), accepted Terms, account deletion,
• bundles created, deleted, cloned, copied or exported, and moved to another team (with both teams),
• bundles shared, shares accepted and ended (with whether it was a person or a team), senders of shares blocked (with how many waiting shares that declined) and unblocked, teams created, deleted and handed on, an offer of a team declined, people invited (how many), joining, people removed, join links made and deleted (before November 2026 also: a bundle's maintainer named, and the agents of shared teams, asked for, answered and ended),
• agents created, changed and deleted, keys created, apps connected to an agent or approved by device code, workloads trusted and revoked, tokens traded by a trusted workload (with the trust and the workload's identity), connections revoked, keys found in public and revoked (with where they were found),
• publications submitted, approved, rejected or taken down,
• operator actions: opening a bundle, blocking and unblocking an account, giving an account a role (admin, support) or taking it back, handing a team on to one of its members,
• cancellation and withdrawal declarations,
• messages sent with the contact form and feedback filed by your agent (B.9): their ticket number and topic, or kind and severity.

Each entry holds the account ID, the time, the event and, where it applies, the username at sign-up or when you choose it after signing up with Google, the agent and the door used (the web app, the API or MCP). It holds no email address and no content.

The audit trail is kept for 2 years, also after an account is deleted. Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is to keep the service secure and to be able to explain changes and resolve disputes.

B.9 Contact form in the app and feedback from your agent

Signed in, you can write to us from the app ("Help & contact"). The form sends your message and the topic you picked, with your account ID, your username and the email address of your account, which is where our answer goes. If you leave the box ticked, it also sends the path of the page you were on and your browser's version. It never sends the contents of a bundle.

The message reaches our inbox by email, sent through Amazon SES. We keep it as described in C.1. To stop the form from being used to flood our inbox, we limit how many messages you can send in an hour; the count holds only your account ID and is deleted after the hour. Each message is recorded in the audit trail (B.8) by ticket number and topic, never by its text.

Your agent can also file feedback for you over MCP (send_feedback), when you allow the call: a bug, something confusing, a missing feature or an idea. The ticket holds what your agent writes: what you wanted, what it expected, what happened, the calls that reproduce it with their answers, the error, and where it happened (a bundle ID and concept paths). Those calls and answers can contain excerpts of a bundle, as much as your agent includes. We add your account ID, username, plan, the email address of your account, the agent and the connection it used, and the request ID that leads to our server log of the failed call. The ticket is stored in our database in Frankfurt (Amazon Aurora PostgreSQL, eu-central-1) so that we can reproduce and resolve it. Our inbox gets only an email naming its ticket number, kind, severity and your email address, never what your agent wrote. When we close it, we add to it a short note of how it was resolved (what we fixed or decided, or the earlier ticket it repeats) and when; the note never repeats what your agent wrote. The ticket is deleted automatically after 1 year, with its note. It counts against the same hourly limit as the form. Messages and tickets may be sorted and classified automatically, also with AI models (B.7).

When you block a person who offered you a share (B.3) and leave the report ticked, we file a ticket the same way: it holds what we add about you to feedback (account ID, username, plan, email address, the agent and connection used), the account ID and username of the person you blocked, and the reason you gave; never anything of a bundle. Our inbox gets only an email naming its ticket number. We use it to decide whether to block that account from Korpus (B.7). It is kept and deleted like the feedback above, and counts against the same hourly limit; when it is used up, the block stands and no ticket is filed.

Legal basis: Art. 6(1)(b) GDPR where your request concerns your account or your subscription, otherwise Art. 6(1)(f) GDPR. Our legitimate interest is to answer you, to find and fix what went wrong, to see when a problem comes back, and to protect the form from abuse.

B.10 Usage metering

Every plan has a request rate, to stop a runaway program. To apply it, we keep counters per account: your short-term read and write rates, and nothing about what was read or written. They are kept until you delete your account. Legal basis: Art. 6(1)(b) GDPR.

B.11 Security and technical data

IP addresses. Amazon's services process your IP address for as long as it takes to deliver a request and to apply request limits. We do not store it.

Signed-in browsers. For each browser you sign in with, we store its device description (the user agent) and when it was first and last used. This lets you see your sign-ins and end them. Each record is deleted 30 days after it was last used.

Error logs. Our servers log errors without request contents and keep them for 7 days.

Legal basis: Art. 6(1)(f) GDPR. Our legitimate interest is to run the service securely and reliably.

B.12 How long we keep data

• Account data: until you delete your account. That includes the record of the Terms you accepted, your billing references, usage counters and any block.
• Senders you blocked: until you unblock them, or your account or theirs is deleted. Share counters: until the minute or the day they count ends.
• Offers waiting for a yes (a share, an invitation into a team, a team offered to a member): 7 days; then it can no longer be seen or accepted, and we delete it within a day. That a member declined a team: until the owner offers it again or withdraws.
• Current content: until you, or the owner of the bundle, delete it.
• Change log entries: as long as the bundle exists; deleted with it.
• Mention notifications: 30 days.
• Mentions recorded on a concept: as long as its text names you; deleted with the concept or bundle. After your account is deleted, they show as "deleted user".
• Signed-in browsers: 30 days after last use.
• Tokens: 1 hour (access) or 30 days (refresh), then invalid. Keys: until the expiry you chose, at most 1 year, then deleted. Connections last until you revoke them.
• Error logs: 7 days.
• Results of automated checks (B.7): no longer than what they checked.
• Bundle exports: 1 day.
• Deleted or replaced files: recoverable for 30 days, then deleted.
• Audit trail: 2 years, also after your account is deleted.
• Backups: the central database can be restored to any point in the last 35 days, so deleted data can survive in backups for up to 35 days.

When you delete your account, we end any Pro subscription at once, delete the bundles you own alone, with their files, and remove you from all other bundles and teams. A shared team you own is deleted with its bundles, so its members lose them too: hand it to a member first if they should keep it. We also revoke your connections and delete your agents, keys, sessions and account records.

Content you wrote in bundles that other people own stays there, because it is part of their record. It keeps your former account ID, which from then on shows as "deleted user".

Receipts and invoices for Pro are issued and kept by Sold through Link, LLC (B.5), under the retention periods that apply to it. Our own invoices for Business are kept for 10 years (B.5).

B.13 Cookies and local storage

Korpus sets no cookies. The app keeps a few entries in your browser's local or session storage:

• your sign-in tokens, in session storage, or in local storage if you choose "Stay signed in",
• that choice itself,
• your theme,
• the bundle you last opened,
• whether you dismissed the welcome note,
• scroll positions and view state,
• while you sign in with Google, a one-time check value, in session storage, deleted when you come back.

The one exception to “no cookies”: if you sign in with Google, the sign-in passes through our sign-in address at Amazon Cognito (auth.fra.korpus.cloud), which sets short-lived cookies there to protect that sign-in against forgery and to remember it for about an hour. They are needed for the sign-in you asked for and are not used for anything else.

These entries are needed to provide the service you ask for (§ 25(2) no. 2 TDDDG) and never leave your device, except the sign-in token, which is sent with each request. No consent banner is required.

B.14 Processors and recipients

We have a data processing agreement under Art. 28 GDPR with AWS (the AWS Data Processing Addendum), with Anthropic (the Anthropic Data Processing Addendum) and with Google (the Cloud Data Processing Addendum); transfers to the USA rest on the EU-US Data Privacy Framework (AWS, Google) and standard contractual clauses. We use no other processors. For content you store as a controller, AWS and Anthropic are our sub-processors under the AVV (annex 3); Anthropic receives only what an automated check sends it (B.7); Google gets no content of bundles or tickets.

Part C · Both

C.1 Contact by email

If you write to us, we process your email address and your message to answer it.

Legal basis: Art. 6(1)(b) GDPR where your request concerns a contract, otherwise Art. 6(1)(f) GDPR. Our legitimate interest is to answer requests. We delete the message once it is dealt with, unless we must keep it by law.

C.2 Your rights

You have the right to:

• access your data (Art. 15 GDPR),
• have inaccurate data corrected (Art. 16 GDPR),
• have your data erased (Art. 17 GDPR),
• restrict processing (Art. 18 GDPR),
• data portability (Art. 20 GDPR),
• object to processing based on Art. 6(1)(f) GDPR (Art. 21 GDPR).

You can read out all your content at any time through the web app, the API or MCP, and you can delete your account in the app. For anything else, write to me@till-it-works.de.

You need to give us an email address to have an account; without one we cannot provide the service. We make no automated decisions under Art. 22 GDPR.

C.3 Right to lodge a complaint

You can complain to a data protection supervisory authority. The authority responsible for us is:

C.4 Transfers to third countries

The website, your account and your content are stored in the EU (Frankfurt). AWS is part of Amazon.com, Inc., a US company. CloudFront may deliver a response from an edge location outside the EU. Sold through Link, LLC and Stripe Payments Company are US companies. Such transfers rest on the EU-US Data Privacy Framework (an adequacy decision under Art. 45 GDPR) and on standard contractual clauses.

C.5 Changes

We update this policy when the service or the law changes. We tell account holders about material changes by email or in the app. The current version is always at korpus.cloud/privacy.