Skip to content

Sibyl

Privacy Policy

Effective date: 29 July 2026 · Last updated: 29 July 2026

This policy explains what Sibyl collects, why, who else sees it, and what you can ask us to do with it. It is written to be read rather than skimmed past, so it describes what the software actually does rather than what a policy template usually says.

Sibyl is operated by [LEGAL ENTITY NAME] ("Sibyl", "we", "us"). It forms part of our Terms of Service, and uses the same meanings for the same words.

Sibyl is in public beta. Where something is not built yet, this policy says so rather than reserving the right to do it quietly.


The short version

  • Your cases are private to your account. There is no sharing feature, no public case, and no other user can read yours.
  • The text of your situation goes to Anthropic, our AI provider, because that is what generates the forecast. It is not used to train anyone's model.
  • Analytics runs only if you accept it. If you decline, or have not been asked, nothing is loaded and nothing is sent. There is no advertising and no tracking across other websites.
  • Analytics records which features are used, never what you write. It cannot see your situation, your updates, or your forecasts.
  • The only cookies Sibyl sets before you choose are the ones that keep you signed in.
  • We do not sell anything to anyone, and there is nothing to sell — Sibyl has no advertising business.

1. What Sibyl collects

1.1 Account information

When you create an account we store:

WhatWhere it comes from
Email addressYou, at sign-up — or from Google if you use "Continue with Google"
PasswordYou. It is hashed by Supabase Auth; we never see or store the plain text
Display nameYou, at sign-up, and editable on your account page
Whether your address is confirmedSet when you follow the confirmation link
Account creation dateRecorded automatically
PlanCurrently "free" for every account. It governs rate limits, not billing

Sibyl does not ask for your real name, date of birth, address, phone number, or payment details, and has no field to put them in.

1.2 The content you submit

This is the material Sibyl exists to work on, and the most sensitive thing it holds:

  • The situation you describe — between 80 and 10,000 characters of your own account of what is going on.
  • Your answers to the three multiple-choice questions Sibyl asks, and which of the three statements you ticked.
  • Updates you add later — up to 5,000 characters each, describing what has happened since.
  • Outcomes you record — whether a prediction happened, did not happen, or is still pending, and when you said so.

People describe relationships, families, jobs and businesses in these fields. We treat everything in this section as sensitive regardless of what it contains.

1.3 What Sibyl generates from it

A case accumulates material that Sibyl produced rather than you:

  • The reading — Sibyl's summary of what it thinks is going on.
  • Competing explanations and their weights — the reasoning the probabilities are computed from. These are stored but deliberately not shown on screen.
  • Predictions, each with a probability, a time horizon, and the conditional judgements its number was derived from.
  • Revisions. Each time you add an update, Sibyl re-reads the whole case. The previous reading is kept rather than overwritten, along with what the revision decided about each prediction and why anything was retired.
  • Proposals — where a revision thinks an update settled a prediction. A proposal is a suggestion; nothing is recorded as an outcome until you confirm it.

This history is what makes a case worth returning to, and it is also why a case grows over time. It is stored under your account like everything else.

1.4 Technical information

  • Request logs. Sibyl writes structured logs to its own server output: a request id, the route, the status, timings, and error classifications. They carry no story text, no answers, no updates, and no model output, and credential-shaped strings are filtered out before anything is written.
  • Error reports. See Sentry below.
  • Rate limiting. To cap what a single account can spend, Sibyl counts recent requests in the server's memory, keyed by account id (or by IP address for the health endpoint, which needs no account). These counters are never written to disk and disappear when the process restarts.
  • Duplicate-request keys. So that pressing a button twice does not create two cases, each write carries a random key. The key and a short description of the action are stored for 24 hours and then deleted. Neither contains your words.
  • A security audit record. Sibyl records one kind of event: an attempt to open a case that does not belong to your account. The entry holds your account id, the case id, and the time — no IP address, no device information, and none of the case's content.

1.5 What Sibyl does not collect

To be explicit, because the absence is a design decision rather than an oversight:

  • No advertising cookies, no ad network, and no tracking of you across other websites. The only third-party script Sibyl ever loads is PostHog, and only after you have accepted analytics.
  • No IP address in error reports or in the logs about your activity.
  • No location data, contacts, camera, microphone, or device sensors — the site tells your browser to refuse all of them.
  • No file uploads. There is no way to attach a document or an image to a case.
  • No marketing email, newsletters, reminders, or notifications of any kind. See Emails we send.

2. Why we use it, and on what basis

PurposeWhat it uses
Producing a forecast, and re-reading a case when you update itYour case content
Keeping your cases available to you and nobody elseAccount information, case content
Signing you in and keeping you signed inAccount information, session cookies
Keeping the service up and diagnosing failuresRequest logs, error reports
Preventing abuse and controlling costRate-limit counters, the audit record
Understanding which features are used, only with your consentProduct analytics events

Where data protection law requires a legal basis, ours is the performance of our contract with you for the first three rows, and our legitimate interest in running a secure and financially viable service for the next two. The last row rests on consent alone: you are asked before anything runs, and you can withdraw it at any time with immediate effect.

We do not use your case content for advertising, profiling, or automated decisions with legal or similarly significant effects. Sibyl produces forecasts for you to read; it makes no decisions about you.


3. Accounts and authentication

Authentication is handled by Supabase Auth. Four flows exist:

Email and password. Passwords must be at least 12 characters and are hashed by Supabase. We never receive the plain text, so we cannot tell you what your password is — only help you set a new one.

Email confirmation. You must confirm your address before your first sign-in. The link in that email lands on a Sibyl route that redeems the one-time token on the server and then sends you on to a normal page, so the token never reaches JavaScript in your browser, your browser history, or the referrer header of a later request.

Password reset. The same one-time-link mechanism. Setting a new password signs out every other session on your account, which is what you want if you are resetting because you think someone else has access.

Continue with Google. If you choose this, Google tells us your email address and basic profile information, and confirms that you are signed in to that account. We receive nothing else: no contacts, no calendar, no Drive, no access to your Google account. Google's handling of the sign-in is covered by Google's Privacy Policy. This option is only shown when the deployment has been configured for it.

Emails we send

Sibyl sends transactional email only, through Supabase: address confirmation and password reset. That is the entire list. There is no newsletter, no product announcement list, no reminder to check in on a case, and no automated nudge when a prediction's horizon passes. If you receive anything else claiming to be from Sibyl, it is not from us.


4. Cookies and local storage

Sibyl uses the smallest set of browser storage it can.

Essential — always on

Session cookies set by Supabase Auth. These hold your access and refresh tokens, and they are what keep you signed in between page loads. Without them you would have to sign in on every request, so they cannot be turned off while you are using an account. They are marked Secure over HTTPS, are scoped to this site, and are refreshed automatically while you browse.

Optional — off unless you accept

Product analytics, through PostHog. These tell us which parts of Sibyl people actually use — how many people finish a case, how often forecasts are revised, where things fail — so we can decide what to build next.

Nothing about it runs until you choose "Accept analytics". Before that, and after a refusal, the PostHog code is not downloaded at all: it is not on the page, it sets no cookie, and it sends nothing. Declining is a complete answer and Sibyl works identically either way.

If you accept, PostHog sets cookies and local storage entries in your browser to recognise the same person between visits, and we send it the events listed in what analytics records below.

If your browser sends a Do Not Track signal, analytics stays off even if you accept. We treat that as an answer you have already given.

Your cookie choice itself is stored in your browser's local storage under sibyl.consent, alongside the date you chose and the version of the choice. It is not a cookie, is never sent to our server, and exists only so the banner stops asking. Clearing your browser storage resets it and the banner returns.

You can change your mind at any time — see your choices below.

What analytics records

Only that something happened, and a few non-identifying numbers about it. The complete list of what we send:

AreaEvents
AccountsSigning up started and completed, signing in, signing out, password reset requested and completed, email address confirmed — each with the method used (password or Google), never the address
CasesA case started, a case saved, a case opened — with how many predictions and questions it had
ForecastsA forecast generated, a forecast revised — with how long it took and how many predictions resulted
ProblemsA forecast or revision that failed, and a rate limit being hit — with a category such as "timeout", never an error message

What analytics never receives, as a matter of how it is built rather than policy:

  • The situation you described, your answers, your updates, or any text you wrote.
  • Sibyl's readings, explanations, predictions, or probabilities.
  • Your email address, name, or anything from a Google profile. You are identified to PostHog by an internal account identifier and nothing else.
  • The page addresses you visit, which are stripped from every event before it is sent.
  • Automatic click or keystroke capture and session replay, both of which PostHog supports and both of which are switched off — they would record the contents of your screen, which is the thing this whole section exists to prevent.

5. AI processing

This is the part of Sibyl that involves another company seeing your words, so it is worth being precise about.

What is sent. When you ask for a forecast, Sibyl sends the text of your situation to Anthropic. When you answer the questions, it sends the situation plus your answers and ticks. When you add an update, it sends the case — the original account, the current reading, the standing predictions, and the update you just wrote — so the model can re-read the whole thing.

What is not sent. Your email address, your name, your account id, and your case ids are not part of any prompt. Anthropic receives the text of the case and nothing that identifies whose case it is.

What Anthropic may do with it. Anthropic processes the request, returns a response, and retains data only as its own terms and our agreement with it provide. Our arrangement does not permit training on the content we send.

What we do with the result. The response is validated, the probabilities are computed from it, and the result is stored in your case. We do not review your cases, and no one at Sibyl reads them as a matter of routine. We may look at a specific case if you ask us to for support, if we are required to by law, or if we have to investigate a serious abuse report — and we will keep that as narrow as the situation allows.

Automated, and not reviewed by a human. Every forecast is generated without human review. It is a probabilistic estimate that may be wrong, it is not advice, and you remain responsible for your own decisions — see the AI-Generated Forecasts section of the Terms of Service, which governs this.


6. Third-party processors

Sibyl runs on services operated by other companies. Each one is engaged as a processor: it handles data on our instructions and for our purposes.

ProviderWhat it doesWhat reaches it
SupabaseAuthentication, and the Postgres database your cases live inYour account details and all case content
AnthropicGenerates the forecasts and revisionsCase text, as described above
RailwayHosts the applicationRequest traffic, including the IP address your browser connects from
Google"Continue with Google" sign-in, if you choose itThe fact that you are signing in, and your basic profile
SentryError and performance monitoringTechnical error data only, filtered as described below
PostHogProduct analytics — only if you acceptEvent names, the non-identifying numbers listed above, and your internal account identifier. Nothing you wrote

Sentry deserves the detail. Error reporting is the one thing Sibyl transmits to a third party that is not needed to serve your request, so it is filtered by an allowlist: every field that leaves is one that was explicitly named as safe, rather than everything except a list of known-bad fields. The practical effect is that error reports cannot contain request bodies, prompts, model output, session cookies, email addresses, account ids, IP addresses, or query strings. What they do contain is the exception type, a stack trace, the route pattern, and a request id that lets us find the matching server log.

These are our current providers, not a permanent list. If we change one, or add another that handles personal data, we will update this policy. Where the change materially affects how your data is handled, we will tell you before it takes effect.


7. Security

The measures below are the ones that materially protect your cases:

  • Cases are isolated at the database level. Postgres Row-Level Security means a query for someone else's case returns nothing, and every route also checks ownership before it answers. Neither depends on the browser behaving.
  • Every route that costs money requires a verified session, and Sibyl checks the session against Supabase rather than trusting a cookie's contents.
  • HTTPS everywhere, with strict transport security, so a browser that has seen the site once refuses to talk to it in plaintext.
  • A strict Content-Security-Policy with a fresh per-response nonce, which is what stands between an injected script and your session token.
  • Request size and rate limits, so one account cannot exhaust the service.
  • Secrets are held server-side only and are never shipped to the browser or baked into the deployed image.

No system is perfectly secure, and we do not claim otherwise. If you believe you have found a vulnerability, please tell us at [CONTACT EMAIL] before disclosing it publicly, and we will work with you on it.


8. Data retention

WhatHow long
Your account and its casesUntil you ask us to delete them
Case history — earlier readings, revisions, recorded outcomesFor the life of the case; it is part of the case
Duplicate-request keys24 hours, then deleted automatically
Rate-limit countersMinutes. They live in memory and vanish on restart
The security audit recordKept as a security record. On account deletion the entry is de-identified — your account id is removed and the bare fact that an event occurred remains
Server logsShort-lived operational logs, held by our hosting provider
Error reportsRetained by Sentry for the period its retention settings define, then deleted
Analytics eventsRetained by PostHog for the period its retention settings define. Deleting your account also removes the analytics identifier that links these events to you
Database backupsCases deleted from the live database persist in routine backups until those backups age out

We do not keep case content "just in case". If you delete your account, its cases go with it.


9. Your rights

Depending on where you live, you may have the right to access a copy of your data, correct it, delete it, restrict or object to how we use it, receive it in a portable form, or complain to a data protection authority. We honour these requests wherever we can, regardless of whether the law where you live requires it of us.

What you can do yourself

  • See your data. Everything Sibyl holds about a case is on the case's page, and everything about your account is on your account page.
  • Correct your display name, or change your password, from your account page.
  • Add to a case. Cases are append-only by design: the original account is never rewritten, because it is the anchor a revision is measured against.

Your choices

  • Cookies. Select Cookie Preferences in the footer of any page to reopen the choice and change it. It is there on every screen, including inside the application.
  • Withdraw consent. Declining stops analytics immediately: PostHog is opted out, the identifier it stored is cleared, and nothing further is sent. You do not need to sign out or contact us.

What you have to ask us for

Sibyl does not yet have a self-serve button to delete a case or an account, or to export your data. We handle those by hand while the product is in beta. Email [CONTACT EMAIL] and we will:

  • Delete your account and its cases — permanently, and confirm when it is done.
  • Export your data in a machine-readable format.
  • Answer questions about what we hold on you.

We aim to respond within [N] business days and to complete the request within 30 days. We may need to confirm you control the account's email address before acting, which protects you from someone else deleting your cases.


10. International transfers

Sibyl's providers may process data outside the country you live in, including in the United States. Where a transfer is made from a jurisdiction that restricts it, we rely on the safeguards our providers offer for that purpose, such as standard contractual clauses. If you would like the specifics for a particular provider, ask us.


11. Children

Sibyl is for adults, and our Terms require you to be 18 or older. We do not knowingly collect information from children. If you believe a child has created an account, contact us and we will delete it.


12. Changes to this policy

Sibyl is under active development and this policy will change with it. When it does, we update the "Last updated" date above. Where a change materially affects how your data is handled — a new processor, a new purpose, a longer retention period — we will give you reasonable notice by email or in the application before it takes effect.

Where the change is to something you consented to, we ask again rather than carrying the old answer forward. That is what happened when analytics was added: everyone who had answered the earlier cookie banner, which was asked while Sibyl ran no analytics at all, was asked again — an agreement to something hypothetical is not an agreement to a real processor.

Previous versions are kept and available on request.


Contact

For anything in this policy — access, deletion, export, a security report, or a question about how something works:

  • Email: [CONTACT EMAIL]
  • Operator: [LEGAL ENTITY NAME]
  • Address: [POSTAL ADDRESS]

If you are in the UK or the EU and are not satisfied with our response, you may complain to your local supervisory authority.

Read the Terms of Service

  • Privacy Policy
  • Terms of Service

Sibyl generates forecasts with AI. They are estimates, not advice.

Cookies

Sibyl uses essential cookies to keep you signed in — those cannot be turned off. We would also like optional analytics, which tells us which parts of the service people use. It never records what you write. Learn more