# Privacy Policy

**Version 1.10 · Effective 17 September 2026 · Last updated 5 November 2026**

This policy explains what **Thalient Labs Inc.** collects when you use
Hyperresearch, why, who else sees it, how long we keep it, and what you can ask
us to do about it. It covers hyperresearch.ai, console.hyperresearch.ai,
api.hyperresearch.ai, the hosted MCP server, and Hyperresearch Answers: the
MCP server at answers.hyperresearch.ai with its `ask` and `search` tools, and
the `/v1/answers` endpoints of the API.

It is written to be checked. Where the product does not yet do something a
privacy policy usually promises, this page says so rather than promising it.
Those gaps are listed in §9 and we are working through them.

## 1. Who is responsible

Thalient Labs Inc., a Delaware corporation, 1001 S. Main St., Suite 500, Kalispell, MT 59901, United States, is the controller of the personal data described here.
Representative for privacy questions: Jordan Gibbs. Email: support@hyperresearch.ai.

We have not appointed a Data Protection Officer; we are not required to. If you
are in the EU, the UK or Switzerland and need a representative there, we do not
have one yet — write to us and we will handle your request directly.

## 2. What we collect

**Account and identity.** Your email address and whether it is verified, a user
record linked to your Clerk user id, your account-level role, your workspace
names and the members of each workspace, and invitations you send (the invitee's
email address plus a hash of the invite token). Sign-in itself happens at Clerk:
we read your primary email address and its verification status, and nothing
else. We never receive or store your password, and if you sign in with a
passkey, Google or GitHub, we never see the credential.

**What you submit.** Your research questions; the tier, profile and options you
chose; documents and source lists you submit to the verification endpoints;
notes and imports you put in your vault; project names and descriptions; and
your fetch-policy settings, including any domains you add to the denylist.

**What a run produces.** The report; the list of every source read, with URL,
title, fetch time, which provider succeeded, quality score and independence
cluster; the extracted claims and their quoted support; the verification record;
the run's intermediate artifacts; and **the extracted text of the web pages the
pipeline read**, stored as vault notes and as raw fetched bytes. If a source
page contained someone's personal data, a copy of that text is now in your
workspace.

**Answers calls.** When you, or an assistant you have connected, call Answers,
we store the question (for `ask`) or the search query (for `search`), the mode,
the full result we returned (the answer with its quoted evidence, or the
ranked sources with their passages), the call's status, price, duration and
time, the workspace and the key or connection it came through, and a hash of
the request so a retried call is recognised and not charged twice. We keep
them so the call can be fetched again and as the record behind its charge.

**What we receive from AI assistants.** Answers is used from AI assistants such
as Claude, ChatGPT and other MCP clients. From an assistant we receive only
what it sends to the tool: the arguments of the call (the question or search
query and its options), the access token of the connection you authorised, and
the standard protocol details every MCP client sends, such as its own name and
version, which we do not store. We do not receive, and do not ask for, your
conversation with the assistant, its chat history or memory, or your files. If
the assistant puts something from your conversation into the question, that
text is part of the question and is handled as described above.

**Billing.** A Stripe customer reference, your plan, whether a card is on file,
your spend cap, the usage ledger (what was charged, for which run, when), a
mirror of your Stripe invoices including the hosted invoice URL, and refunds and
credits. **We never receive or store your card number, expiry, CVC or billing
address.** You enter those on Stripe's own pages.

For Answers, which is paid for from prepaid credit, we also keep your credit
balance, any amount held for a call in progress, every change to the balance
(top-ups, the free credit, charges for calls, refunds and adjustments), each
top-up and whether you made it or auto-reload did, and your auto-reload
settings. You pay for top-ups through Stripe Checkout, which saves your card
with Stripe so you can top up again and, if you switch auto-reload on, so we
can charge it when your balance runs low.

**Access and security records.** API keys, stored as a salted SHA-256 hash with
a short non-secret prefix for lookup — we cannot read your key back, only revoke
it. Webhook endpoints you register and their signing secrets. Agent and MCP
connections, with every token and authorisation code stored only as a hash,
and, for each app that connects (for example an AI assistant), the client id,
name and sign-in return addresses it registered or published.
Console sessions, stored as a hash of the session cookie together with **the IP
address the session was created from**. Counters, keyed to a salted hash of your
IP address, that rate-limit sign-in attempts and public endpoints.

**The Answers free credit.** An account can receive a one-time free credit the
first time it uses Answers. When the request comes with an API key or from the
console, we store a keyed hash (HMAC-SHA256) of the IP address it came from,
never the address itself, and grant at most one free credit per address per
day, so one person cannot collect it through many accounts. The hash is erased
48 hours after the grant. When you connect through an AI assistant, many people
share the assistant's address, so we neither use nor store an IP address for
the free credit.

**Audit log.** Per workspace, a record of significant actions — keys created,
rotated and revoked; workspaces created, updated and deleted; runs created,
rerun, paused, aborted and expired; vault exports and imports; members added,
removed and re-roled; webhooks created and deleted; refused queries. Each row
carries who did it, what they did it to, when, and the IP address it came from.
You can read and export your own workspace's audit log from the console.

**Server logs.** Our error and operations logs deliberately carry only
identifiers: request id, account id, workspace id, run id, HTTP method, path,
status and our own error codes. **They do not contain your research question,
your report, request bodies, headers, your email address, your IP address or
your user agent.** A redaction layer additionally masks anything that looks
like a bearer token, an API key, a webhook secret, a provider key or a signed
URL before it can reach a log line.

**The waitlist.** If you joined the waitlist on the marketing site we stored
your email address, the question you typed, where you came from (referrer and
source), your browser's user-agent string and the country Cloudflare reported.
That is the one place we keep a user agent.

**How you found us.** If you arrive at hyperresearch.ai from a link that
carries campaign parameters (`utm_source`, `utm_medium`, `utm_campaign`,
`utm_term`, `utm_content`) or a Google Ads click ID (`gclid`, `gbraid`,
`wbraid`), the site keeps them in a first-party cookie, `hr_ft`, for 90 days and
adds them to the sign-in link. If you create an account within 24 hours of
arriving that way, we store them with your account, along with the page you
landed on and when. We use them to see which campaigns bring people who actually
use the product.

**What we tell Google Ads.** If you came from a Google ad, then when you sign
up, start your first run and pay for your first run, our server sends Google
Ads the click ID you arrived with, the name of the event, when it happened and,
for a paid run, its price. That is all. We do not send your name, your email
address, your questions or your reports, and nothing is sent from your
browser. Google uses it to tell us which ads worked.

**What you tell us about a report.** If you rate a report in the console, we
store your rating, your answers to the short questions and your comment against
the run and your account. Each answer is saved as you give it, and a comment is
saved while you type it, so we receive them even if you never press Done. We
also record, in our own database, when you first opened a report, how many times
you opened it, whether its end came into view on your screen and whether you
downloaded its PDF. We use this to see whether reports are useful and to improve
them. Our daily operations email counts these records and lists ratings against
a run ID, without your comment or email address. No analytics vendor is involved.

**What we do not collect.** No ad pixels, no Google tag, no cross-site tracking
scripts or cookies, no analytics SDK, no session recording, no fingerprinting
and no remarketing lists. The console sets one cookie, `hr_session`, which is
strictly necessary to keep you signed in, plus whatever Clerk needs to run
sign-in on its own domain. The marketing site sets `hr_ft` only when you arrive
with campaign parameters.

## 3. Why we use it, and on what legal basis

| What we do with it, and why | Legal basis (GDPR Art. 6) |
|---|---|
| Run the research you asked for, and store and show you the result — it is the service you bought | Performance of a contract |
| Keep your workspace vault, so later runs start from what you already have | Performance of a contract |
| Answer an Answers question or search, keep the call and its result so you can fetch it again, and charge it to your prepaid credit | Performance of a contract |
| Keep a hash of the IP address a free-credit claim came from for 48 hours, so one person cannot collect the free credit many times | Legitimate interests (preventing abuse) |
| Authenticate you, keep sessions, and enforce API key scopes and IP policy — nobody else should be able to read your research | Performance of a contract; legitimate interests (security) |
| Meter usage, charge you, and issue refunds and credits — we have to bill correctly and keep the records behind an invoice | Performance of a contract; legal obligation (tax and accounting records) |
| Enforce rate limits, spend caps and concurrency limits, investigate abuse, and keep the audit log — this is what keeps the platform up and other customers' research private | Legitimate interests |
| Answer your support email | Performance of a contract; legitimate interests |
| See whether reports are useful and improve them, from the ratings and comments you give us and the reading record in §2 | Legitimate interests |
| Diagnose a failure using error logs and a run's stored detail, because a broken run has to be explainable | Legitimate interests |
| Tell you about a change to these terms, an outage, or your billing | Performance of a contract; legal obligation |
| Comply with a lawful request, or defend a legal claim | Legal obligation; legitimate interests |
| Record the campaign and Google click ID you arrived with, and tell Google Ads when an ad led to a sign-up, a first run or a first paid run, so we know which ads are worth paying for | Legitimate interests (measuring our own advertising). You can object; see §7 |

**We do not sell personal data, and we do not share it for cross-context
behavioural advertising.** We have never done either. The Google Ads report in
§2 carries a click ID Google created, an event name, a time and a price. It
measures our ads; it does not build a profile of you for anyone else's.

**We do not use your content to train models.** We run no models of our own. We
send your question and the source text the pipeline read to the model provider
in the table below in order to generate your report, under its paid API terms.
We do not license your content to anyone for training, and we do not run our own
analysis of your research across customers. Providers reached through OpenRouter
are governed by OpenRouter's data policy and by the underlying provider's terms;
we cannot promise you more than the strongest commitment those providers make to
us, so §9 records this as something to keep checking. If you need a specific
provider excluded from your workspace, tell us — the platform supports excluding
providers.

**No automated decisions with legal effect.** The pipeline makes automated
decisions about research — which sources to read, what to write, whether a
citation holds. It makes no automated decision about *you* that has a legal or
similarly significant effect. The one automated decision that touches your
account is a spending or rate limit, and you can ask us to review it.

## 4. Where it is stored

Everything runs on Cloudflare.

| Store | What is in it |
|---|---|
| Cloudflare D1 (`hr-control`) | Accounts, users, workspaces and members, invitations, API key hashes, the run index (including each run's launch parameters, which contain the verbatim research question), verification jobs, the usage ledger, the audit log, invoice mirrors, webhooks, sessions, OAuth and agent-connection hashes, projects, job bookkeeping, Answers calls (each question or query and its result), report ratings, comments and reading records, and the Answers credit balance, credit ledger, top-ups and free-credit grants |
| Cloudflare R2 (`hr-vaults`) | Everything large and everything yours: vault notes and the extracted text of fetched sources, raw fetched bytes and assets, each run's working set including its query file and final report, generated PDFs, verification inputs and receipts, and vault export archives. Every key is namespaced under your workspace id |
| Cloudflare Durable Objects | The per-workspace vault database (notes, sources, claims, tags, links, embeddings) and the live state of each run (its event stream, spend and source evidence) |
| Cloudflare Vectorize | Embeddings of your vault notes, in a namespace per workspace, so vault search works |
| Cloudflare KV | Short-lived operational data only: rate-limit counters (keyed to hashed IPs, ~2 minutes), idempotency records (24 hours), API-key revocation markers, robots.txt and bot-wall caches about third-party sites, and MCP OAuth tokens as hashes |
| Cloudflare Queues | Work in flight: webhook deliveries, billing meter events, vault jobs. Messages carry ids and job parameters and are consumed within minutes |
| Cloudflare Workers Logs | The identifier-only logs described in §2 |

Cloudflare runs this on its global network and data may be processed in any
region Cloudflare operates in, including outside your own country. **We do not
offer a data residency guarantee today.** Cloudflare's own certifications and
its data processing addendum, including EU standard contractual clauses, apply
to that processing. Transfers out of the EEA, the UK and Switzerland rely on
those clauses. Enterprise agreements can add Cloudflare jurisdiction
restrictions; if you need that, talk to us before you sign up.

Data is encrypted in transit (TLS 1.2+, HSTS on every response) and encrypted at
rest by Cloudflare across D1, R2, Durable Objects and KV. The console and API
send strict security headers — a content security policy, `X-Frame-Options:
DENY`, `X-Content-Type-Options: nosniff` and `Referrer-Policy: no-referrer` —
and download links for reports and artifacts are HMAC-signed and expire after
about an hour.

## 5. Subprocessors

These are the third parties that process data for us. Each one gets the minimum
the job needs.

### Platform and account

| Subprocessor | What it does for us | What reaches it |
|---|---|---|
| **Cloudflare, Inc.** (US) | All hosting and storage: Workers, D1, R2, Durable Objects, Vectorize, KV, Queues, Workflows, Containers, Browser Rendering, Workers AI (for the embeddings that make vault search work), AI Gateway, DNS, CDN and WAF. Its DNS resolver also checks every URL we are about to fetch, which is how we stop the pipeline being pointed at a private network. Turnstile guards the public demo | Everything described in §4, plus every URL the pipeline resolves |
| **Clerk, Inc.** (US) | Sign-in and identity for the console | Your email address and its verification status, your chosen sign-in factor, and Clerk's own sign-in telemetry. Clerk runs its own bot protection |
| **Stripe, Inc.** (US) | Payments, subscriptions, Checkout, the Customer Portal, invoicing and tax | Your email address, your card details (entered on Stripe, never on our servers), usage meter events in cents, and invoice records |
| **Resend** | Transactional email: run, billing and account notices | The recipient's email address and the notice content |

### Advertising measurement

| Recipient | What it does for us | What reaches it |
|---|---|---|
| **Google LLC** (Google Ads, US) | Tells us which of our ads led to a sign-up, a first run or a first paid run | For an account that arrived from a Google ad: the click ID Google put on that ad click, the event name (sign-up, first run, first paid run), when it happened, and the price of a first paid run. Sent from our server. No name, no email address, no research |

### Model inference

Every model call except the direct Meta fallback below goes out through
Cloudflare AI Gateway, which holds the provider keys and forwards the request; we send no telemetry about you with it
beyond a run id. The model chain runs through OpenRouter, with Meta called
directly as a fallback, and the run page shows the model ids used for each role.

| Subprocessor | What it does for us | What reaches it |
|---|---|---|
| **OpenRouter, Inc.** (US) | Inference for every pipeline role | The prompts for each step (your question and the source text the step works on) and the completions. The model providers behind OpenRouter receive what OpenRouter forwards: Meta (the muse-spark contributor model) for every role; **Anthropic, PBC** (US; Claude Opus 5.5) for the final edit of a Light report, and for the plan, the rulings on disputed points, the writing and an error check of a Deep report; Anthropic again (Claude Haiku 5.5) as the first fallback in a Deep report when the Meta model cannot be reached; and **OpenAI** (US) in two cases: GPT-6.1 Sol when Claude Opus declines a step, and GPT-6 Luna as a last-resort fallback when the Meta model cannot be reached. Anthropic receives the finished draft, the verified claims and the source list of a Light report. For a Deep report it receives the question, the evidence map and the note index for the plan, the disputed points and the evidence on each side for its rulings, the evidence the run gathered (the text of the sources it read, cut to fit the model's input limit) to write the report in one pass, and the finished report for the error check. If the report is not written in one pass, the Meta model writes it section by section and Anthropic receives that draft to edit it. When Claude Opus declines a step, GPT-6.1 Sol receives the same input that step sent to Claude Opus; if Claude Opus declines or fails to write a Deep report, GPT-6.1 Sol receives the same gathered evidence to write it. Claude Haiku 5.5 and GPT-6 Luna receive the input of the Meta step they stand in for |
| **Meta** | Fallback inference when the Meta model cannot be reached through OpenRouter: the same model, called directly | The prompts and completions of the calls that fall back |

### Research: search, fetching and scholarly lookup

| Subprocessor | What it does for us | What reaches it |
|---|---|---|
| **Parallel Web Systems, Inc.** (US) | Web search: the first search provider for every research run | The search queries a pipeline step generates from your question |
| **Exa Labs, Inc.** (US) | Web search when a search needs more than Parallel found, up to a fixed number of searches per run | The same search queries |
| **Valyu** | Web and data search when a search needs more sources, within a per-run spending limit | The same search queries |
| **OpenRouter, Inc.** (US) | Web search through OpenRouter, as a last resort when the search providers above fail | The same search queries |
| **Firecrawl** | Fetching and extracting the text of pages that block ordinary fetches, and web search, when switched on. Research runs in production do not use it today; Answers does (see below) | The URLs to fetch, and search queries |
| **DataForSEO** | Search-volume figures and local business listings, when a question turns on demand or on local businesses | Keywords and place searches derived from your question |
| **Foursquare** | Place and venue data, when a question turns on local businesses | Place searches derived from your question |
| **Google LLC** (US), through Google Cloud BigQuery and the YouTube Data API | Queries against public datasets (patents, news events) and finding videos | Queries and search terms derived from your question |
| **OpenAlex** (OurResearch, US), **Crossref**, **Unpaywall** (OurResearch), **Europe PMC** (EMBL-EBI, UK), **CORE** (Open University, UK), **doi.org** (International DOI Foundation) | Scholarly metadata, DOI resolution and finding a legally open-access copy of a paywalled paper | DOIs and scholarly search strings derived from your question. No account data |
| **GitHub, Inc.** (US), **Stack Exchange, Inc.** (US), **Algolia** (the Hacker News search API) | Discovering primary and community sources — repositories, issues, Q&A threads, discussions | Search terms derived from your question |
| **X** (the official X API) | Searching posts on X when a question turns on what people said | Search terms derived from your question |
| **SEC EDGAR** (U.S. Securities and Exchange Commission) | Full-text search of company filings, and Form D notices | Search terms derived from your question |
| Public data services listed on [hyperresearch.ai/sources](https://hyperresearch.ai/sources): government statistics agencies, regulators, registers, open-data portals, Wikidata, OpenStreetMap and similar | Finding primary data and records | Search terms derived from your question. No account data |
| **The websites the pipeline reads** | Not subprocessors, but worth saying: the pipeline makes ordinary HTTP requests to third-party sites, from Cloudflare's network. Those sites see the request, not your account | The URL, and our user agent |

Notes on that table. Search and scholarly vendors receive machine-generated
search queries, which are derived from your question and are often close to it;
model providers receive your question itself. Some search providers' terms let
them use the queries they receive to run and improve their own services
(Parallel's and Exa's do); those queries carry no account data. Enterprise customers can bring
their own provider keys through Cloudflare AI Gateway, in which case the model
provider's relationship is with them. We use **no analytics vendor and no error-tracking vendor** — there is no such
integration in the codebase. The one advertising network we deal with is Google
Ads, and all it receives is the row in the table above. We will update this table before
adding a subprocessor that touches customer content, and material additions go
out by email to account owners.

### Answers

An Answers call runs on the platform above (Cloudflare; Stripe for top-ups).
Beyond that, these receive the question or query, or search queries made from
it. None of them receives your name, email address, account or workspace; the
model calls carry only a call id. A provider you have excluded from your
workspace is excluded from your Answers calls too.

| Recipient | What it does for us | What reaches it |
|---|---|---|
| **OpenRouter, Inc.** (US), through Cloudflare AI Gateway | Model inference for every Answers call | The question or query, the text of the sources the call read, and the completions. The model providers behind OpenRouter receive what OpenRouter forwards: **Meta** (the muse-spark contributor model) does the main work of an `ask`; **Anthropic, PBC** (US; Claude Haiku 5.5) writes further search queries for a standard `search` from the query, the objective sent with it (if any) and the titles, sites and short excerpts of the first results, and is the first stand-in in an `ask` when the Meta model cannot be reached, receiving what that step would have sent the Meta model; **OpenAI** (US; GPT-6 Luna) checks answers, ranks search results, and is the last stand-in when the Meta model cannot be reached |
| **Parallel Web Systems, Inc.** (US) | Web search on every `search` call and as the first search of an `ask`; reading a page an `ask` cannot read directly | The question or query, or search queries made from it, and the URLs of pages to read |
| **Exa Labs, Inc.** (US) | Web search on every `search` call, beside Parallel; in an `ask`, when Parallel finds too little; reading a page an `ask` cannot read directly | The question or query, or search queries made from it, and the URLs of pages to read |
| **Perplexity AI, Inc.** (US) | Web search on standard `search` calls (the default mode), beside Parallel and Exa. `ask`, `fast` and `max` calls and research runs do not use it | The query (a `site:` filter goes as a list of domains), and one search query Claude Haiku 5.5 made from it |
| **Valyu** | Web search on `max` searches and when an `ask` needs more; reading pages and PDFs that cannot be read directly | Search queries, and the URLs of pages to read |
| **Firecrawl** | A last resort, within a small per-call and daily limit: reading a page or a PDF that cannot be read otherwise, and a search when every other provider came back empty | The URLs of pages to read, and search queries |
| Public data and reference services: the scholarly, code, Q&A, X and SEC EDGAR sources in the research table above, plus Wikipedia, arXiv, Google Books, Open Library, the Internet Archive, and public statistics, regulatory, filing and registry services such as government statistics offices and company and grant registries | Finding primary data and documents | Search terms made from the question or query. No account data |
| **The websites a call reads** | Not subprocessors, but worth saying: a call makes ordinary HTTP requests to third-party sites, from Cloudflare's network. Those sites see the request, not your account | The URL, and our user agent |

We also use ordinary business tools — email, accounting, source control — that
may incidentally hold your address if you have written to us. They never receive
your research.

## 6. How long we keep it

We would rather tell you what the code does than quote a retention schedule it
does not implement.

| Data | Retention today |
|---|---|
| Reports, run artifacts, vault notes, fetched source text, raw bytes | Kept until you delete the note or the workspace. **There is no automatic expiry today** and R2 has no lifecycle rule |
| Answers calls: the question or query and the stored result | Kept until you delete the workspace the call was made in or close your account. Either one erases the question and the result; the call's price, status and time stay with the billing records below. A single call cannot be deleted yet; see §9 |
| The hashed IP address of a free-credit claim | Erased 48 hours after the credit is granted. The record that the account has had its free credit, and when, is kept so it cannot be granted twice |
| Verification inputs (a document you submitted plus its sources) | Deleted 7 days after the job finishes, unless you asked us to keep it. The receipt is kept |
| Report ratings, comments and reading records | Kept until you close your account, which deletes them |
| Vault export archives | Kept in your workspace until the workspace is deleted |
| Run index and launch parameters in D1, which include the verbatim question | Kept indefinitely today, including after the workspace's content is deleted. This is a gap; see §9 |
| Usage ledger, the Answers credit ledger and top-ups, invoice mirrors, refunds and credits | Kept for at least 7 years — these are the records a tax authority or an invoice dispute is settled from |
| Audit log | Readable for your workspace's audit window, 365 days by default, configurable between 30 days and 10 years. The window clamps what the API returns; rows are not yet deleted when they age out. See §9 |
| Console sessions | Expire 14 days after last use, and 30 days after sign-in at the latest. Expired rows are not yet purged |
| Rate-limit and idempotency records in KV | Minutes to 24 hours, by their own TTL |
| Server logs | Cloudflare's Workers Logs retention. **We have not pinned a period in our configuration, so we do not state one here** |
| Waitlist entries | Until you ask us to remove yours |
| Campaign parameters and Google click ID stored with your account | Until the account is deleted, or until you ask us to remove them. The `hr_ft` cookie in your browser expires after 90 days |
| What Google Ads received | Per Google's retention for Google Ads conversion data, which we do not control |
| Stripe's own records | Per Stripe's retention, which we do not control |

## 7. Your rights

Depending on where you live you may have the right to know what we hold about
you, to get a copy of it, to correct it, to have it deleted, to restrict or
object to some processing, to take it elsewhere in a portable form, and not to
be discriminated against for exercising any of that. If you are in the EU, the
UK or Switzerland these are your GDPR/UK GDPR rights; if you are in California
they are your CCPA/CPRA rights; other US states with privacy statutes give
similar ones.

**What you can do yourself, right now:** export your whole vault as a `tar.gz`
of Markdown; download any report as Markdown or PDF; export your workspace
audit log as NDJSON; delete individual vault notes; see and revoke every API key
and agent connection; see every invoice; ask for a copy of everything we hold
about you across workspaces, which we assemble and hand back as a download link
good for 24 hours; see your Answers balance and the calls it paid for, and
switch auto-reload on or off; disconnect an AI assistant from Answers by
revoking its agent connection; and close your account, which schedules the deletion 14 days
out and can be cancelled from the same screen inside those 14 days.

**What you have to ask us for:** correction of your account record,
deletion of a single workspace (the API can do it; the console cannot yet), and
removing the campaign record from §2. If you object to that record, we delete it
and stop reporting your account's events to Google Ads.
Email support@hyperresearch.ai and we will do it by hand. We aim to respond within 30
days and to complete a deletion within 14 days of confirming it, which is the
same window the self-service route uses. We will ask you to confirm the request
from the email address on the account; we do not charge for this, and we will
not treat you differently for asking.

**What deletion actually deletes today.** Deleting a workspace erases its vault
database, its embeddings and every object under its R2 prefix — reports, notes,
fetched source text, raw bytes, exports — erases the question and the result of
every Answers call made in it, and revokes its keys. It leaves
behind, in D1, the workspace's row as a tombstone and the metadata rows: the run
index and its launch parameters (which contain your question), the usage ledger,
the audit log, verification records, fetch-job parameters, and report ratings, comments and reading records. A deletion request
sent to support is completed by hand and we will remove those rows too; §9
tracks making that automatic. The two halves of your identity are one deletion
either way round: deleting your Clerk sign-in identity closes your account here
as well, and closing your account here deletes your Clerk user when the
deletion completes.

**Complaints.** Write to us first. If you are in the EEA, the UK or Switzerland
you also have the right to complain to your local data protection authority.

## 8. Other things you should know

**Children.** The Service is for people 18 and over. We do not knowingly
collect data from children and will delete it if we learn we have.

**Security incidents.** If we become aware of a breach affecting your personal
data we will tell affected account owners by email without undue delay, and in
any case within 72 hours of becoming aware of it where the law requires that,
with what we know, what we are doing, and what you should do. We will not wait
for a complete picture before telling you something happened.

**Third-party sites in your reports.** A report links to pages we do not
control. Following a link takes you to someone else's site under someone else's
privacy policy.

**Personal data in fetched sources.** The pipeline reads public web pages, and
those pages sometimes contain personal data about third parties. We store the
extracted text in your workspace so the report's citations can be checked
against it. You are responsible for how you use a report that contains personal
data about someone else; §7 of the Terms forbids using the Service to compile
dossiers on private individuals. If you are the subject of material stored in
someone's workspace and you want it removed, write to support@hyperresearch.ai — we can
act on the sources we fetch, and we maintain a denylist of sites we will never
fetch again.

**Changes to this policy.** We will update the version and effective date at the
top, and for a material change we will email account owners at least 14 days
before it takes effect.

## 9. What this policy does not yet promise

These are real gaps between what a privacy policy should be able to say and what
the code currently does. They are here because a policy that quietly claimed
otherwise would be the worse choice.

1. **Closing an account is not instant.** Self-service closure is built — Account in the console — and what it does is *schedule* the deletion 14 days out. For those 14 days the account keeps working and you can cancel from the same screen, so export anything you want to keep inside that window. Nothing is deleted before the 14 days are up.
2. **Deleting a workspace leaves metadata in D1**, including the verbatim research question in each run's launch parameters, the usage ledger and the audit log. A support-handled deletion removes those; the automated path does not yet.
3. **Deleting your Clerk identity gets no grace period.** It closes your account here straight away rather than 14 days out, because the 14 days exist so that you can sign in and cancel and the sign-in identity is the thing that has just stopped existing. Close the account from the console instead if you want the window.
4. **There is no lifecycle rule on stored content.** Nothing ages out of R2 by itself, so reports and fetched sources persist until something deletes them.
5. **Audit rows, expired sessions and processed billing events are not purged.** Their retention settings clamp what is read, not what is stored.
6. **Log retention is not pinned in our configuration**, so we cannot state a period for it.
7. **The subject access export is a snapshot, not a live feed.** You can ask for one from Account in the console; we assemble it and give you a download link that lasts 24 hours. It is what we hold at the moment it is built, and you can ask for a fresh one.
8. **There is no EU, UK or Swiss representative** and no data residency option outside an Enterprise agreement.
9. **A single Answers call cannot be deleted.** Its question and result are kept until the workspace it was made in is deleted or the account is closed. If you need one removed sooner, write to us and we will do it by hand.

## 10. Contact

Thalient Labs Inc., 1001 S. Main St., Suite 500, Kalispell, MT 59901, United States.

For a privacy request, a correction, a deletion, or a question about anything on
this page — email support@hyperresearch.ai and say what you want. A person reads it.