Privacy Policy
This policy says what Theruka Holding SpA collects when you use Decision Memory, why, who else touches it, and how to get it back or have it destroyed. It states limits as plainly as it states capabilities.
Version 2026-08-31.2 · in effect from 2026-08-31 · Terms and Conditions · Data Processing Addendum · Trust and data handling
1. What we collect
Your workspace: portfolios, projects, milestones and their full date history, risks and their mitigations, decisions and the outcomes recorded against them, uploaded plan files, report and share links.
Account data: the email address you sign in with, the people you invite and their roles, your account's plan, and your billing records.
Operational records: sign-in attempts, and a log of payment events received from our payment provider. These exist so we can answer "what happened to my account" and "was this payment applied".
2. What we do not collect
The only personal data we hold about you as an individual is the email address you sign in with, and a display name where one has been set. There is no field in this product for a password, a phone number, a postal address, a date of birth or a job title, so there is nothing for us to collect.
We do not ask for or store a password. Sessions are a signed cookie holding an email address and an expiry - there is no server-side session store.
We receive no profile data from Google beyond the confirmation of an email address. Not your name, not your picture, not your contacts, not your calendar, not your Drive.
We never store cardholder data. No card numbers, no expiry dates, no security codes, no bank details. Payment details go to Lemon Squeezy as Merchant of Record and never enter our systems, so no part of this product is in scope for PCI DSS.
We never store health or medical data. The product is not designed, offered or suitable for information covered by HIPAA, we will not sign a Business Associate Agreement, and putting such data into it is a breach of the terms.
Your programme content is a separate matter from the two paragraphs above. What you type into a milestone or a risk is your choice - if you put personal data about other people in there, that was your decision and you need a lawful basis for it. We do not inspect it and we do not use it for anything but showing it back to you.
3. Payment, tax, and the Merchant of Record
Subscriptions, seats and AI credit packs are sold through Lemon Squeezy, who act as the Merchant of Record. They are the seller of record: they contract with you, take the payment, issue the invoice, and appear on your statement.
They are also responsible for calculating, collecting and remitting VAT, GST and sales tax in the jurisdiction that applies to you. Tax invoices and receipts come from them, not from us.
What reaches us is an entitlement - which plan, how many seats, how many credits, when it renews, whether it is live - plus a log of payment events so an unapplied payment can be investigated. That is the whole of what we hold about a purchase.
4. How your data is kept apart
Every record we store is owned by an account and is written and read by that account's identifier. Queries are scoped to it on the server, on every request, rather than filtered in the browser.
One account's content is never merged with another's, never pooled to produce a shared result, and never used to answer another account's request. Sharing happens only where you create it deliberately - by inviting somebody, or by issuing a share link.
Nothing you write is used to build a cross-customer dataset or a training set. We do not train or fine-tune AI models on your content, and we do not sell it.
There is one exception and it is counts, not content: the pattern library in the next section. If you would rather not take part in that, it is a single setting.
5. The pattern library
This product judges whether a mitigation worked - held, partial or failed - from evidence it already has: whether the same problem came back, and whether the milestone landed on the date it was re-committed to. When a mitigation of yours is judged, we add one row to a shared count: the risk's classification, the mitigation's classification, the verdict, and the month. Four values, every one of them chosen from a fixed list this product defines.
What does not go with it: the text of the risk, the text of the mitigation, the milestone, the project, the portfolio, the dates, your account, your company, or anybody's name. There is no free text in that row, and no field describing what your programme is about.
We keep an internal reference to your workspace for two reasons only: a verdict changes as evidence lands, so the count has to be corrected, and deleting your account has to take your contribution with it. That reference is never exposed and never used to answer another account's request.
We show a figure drawn from the library only where it rests on at least five separate accounts and thirty judged outcomes. Below that it stays hidden - a rate over three decisions is noise dressed as evidence, and a figure drawn from two accounts can be traced back to them.
What you get in return is the library itself. A new account can see what has actually worked against a kind of risk before it has any history of its own, which is the whole reason it exists.
You can turn this off in your workspace settings, and the workspace owner is who decides it. Doing so stops any further contribution and removes the counts already made. Nothing else about your account changes, you keep full use of the library itself, and we will not ask you to reconsider.
6. Google user data
Where you sign in with Google, we request the minimum scopes needed to confirm who you are: your email address, and the basic profile scope Google requires alongside it.
We use that email address for one purpose - to identify your account and sign you in. We do not use it for advertising, we do not sell or transfer it, and we do not use it to build a profile of you.
We do not transfer Google user data to third parties except the sub-processors listed below that are needed to run the service, and we do not use it for serving advertisements. Our use of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.
7. Why we hold it
To provide the product to you - which is the performance of our contract with you under these terms.
To take payment and keep the records the law requires us to keep.
To keep the service secure and to investigate problems, which is our legitimate interest in running a service that works.
To learn which kinds of mitigation actually work, from the anonymous counts described in section 5. This is our legitimate interest in making the product's advice better than a guess, and we have weighed it against your privacy: what leaves your workspace is four values from fixed lists, with no content and nothing that identifies you. You can object at any time by turning the setting off, and nothing else about your account changes if you do.
8. AI, and what is sent
AI features run on OpenAI's API. Each feature sends only what that feature needs, and each one is triggered by a person. Nothing is sent in the background.
Classifying a risk sends that risk's text. Drafting a mitigation sends the risk's text. A milestone pre-mortem sends that milestone's fields, its dependency chain and the risks linked to it. An executive summary sends a digest of the projects in scope: names, statuses, milestone counts and dates, and risk text. Cause attribution and timeline summaries send the milestone history and risk text for the period concerned.
Uploaded files are parsed by us, not by the AI provider. Billing records, email addresses and sign-in data are never sent to it.
OpenAI states that data submitted through its API is not used to train its models. We do not fine-tune, and we do not send your data to any other model provider.
An account set to test mode sends nothing to the AI provider at all, and every AI feature is disabled for it, unless someone with owner rights explicitly opts that account in.
9. Who else touches it
| Provider | What it handles | Where |
|---|---|---|
| Railway | Runs the application. All request traffic passes through it. | United States |
| Neon | The Postgres database. Your workspace is stored here. | United States |
| OpenAI | The AI features only, and only the content listed above. Never the whole workspace. | United States |
| Sign-in. Google confirms an email address; we receive no other profile data. | United States | |
| Resend | Transactional email: magic-link sign-in and the weekly digest. | United States |
| Lemon Squeezy | Payment and subscription billing. Card details go to them, never to us. | United States |
We do not sell data, and we do not share it with anyone not on this list.
10. Who can see your workspace
A workspace is reachable only by its members. Roles are owner, editor and viewer, and they are enforced on the server for every request, not in the browser.
Reports and program reviews can be shared by link with people who have no account. Those links are frozen snapshots, not live windows: somebody opening one next month sees what was sent, not today's plan. Every share link can be given an expiry and can be revoked.
11. How long we keep it
Your workspace is kept for as long as your account exists.
Operational logs are trimmed on a schedule - sign-in attempts, payment event logs, AI job records and health snapshots are removed after their retention period rather than kept indefinitely.
Billing records and your acceptance of these documents are kept after an account is deleted, because we are required to keep the first and because the second is the record that you agreed.
12. Getting it back, or having it destroyed
You can export your workspace from the product at any time.
An account owner can delete the account from the billing page. Deletion is permanent and immediate: the workspace and everything in it is erased and we cannot recover it afterwards.
If you want a copy of what we hold about you, or want it corrected or erased outside the product, write to support@theruka.com and we will respond within 30 days.
13. Where your data is, and how it lawfully gets there
All of it is stored and processed in the United States, by the providers listed above.
If you are in the European Economic Area, the United Kingdom or Switzerland, that is a transfer of personal data outside your region, and it needs a lawful basis of its own. We rely on the European Commission's Standard Contractual Clauses, incorporated into our data processing agreement with each sub-processor that handles personal data on our behalf. For transfers from the United Kingdom the same clauses apply as modified by the UK International Data Transfer Addendum, and for Switzerland with the amendments the Swiss Federal Data Protection and Information Commissioner requires.
Where a sub-processor is separately certified under the EU-US Data Privacy Framework, that certification may also cover the transfer. It does not replace the clauses above; it sits alongside them.
We do not rely on your consent as the basis for these transfers. Consent is a derogation intended for occasional, one-off cases, and every transfer described here is continuous and structural - so treating your acceptance of this policy as the mechanism would be the wrong instrument, and would leave you with a protection you could withdraw by accident.
You can obtain a copy of the safeguards themselves. The Standard Contractual Clauses are published by the European Commission and we will send you the version we use, and tell you which mechanism covers a particular sub-processor, on request to support@theruka.com. Where a copy of a specific agreement cannot be given in full because it contains another company's commercial terms, we will provide the data protection provisions of it.
14. Changes, and how to reach us
This policy has a version and a date. Where a change materially affects what we do with your data, we will ask you to accept the new version before you continue using the product.
Questions, or a request about your data: support@theruka.com.
Theruka Holding SpA · support@theruka.com
Back to the site