Legal
Sub-processors
Every third party that touches data, what it sees, and where it operates.
Last updated 28 July 2026
Rows last checked: [Date – set when this list is published]
1. How to read this list
1.1 What this page is, and where it is not yet complete. It names the companies that handle personal data for us, with what each one sees, where it runs, and what we rely on if information leaves the European Economic Area.
It is not a complete list of recipients yet, and we say so here rather than let the sentence above cover the gap. Thirteen companies are named: nine in the two tables in section 2, and four more in the table at 4.2, which have no row in section 2 because their location and their transfer instrument are not settled. The nine is a count of companies and not of rows: Cloudflare holds two rows, because two of its services are at different stages. Beyond those thirteen, two kinds of recipient appear here as gaps rather than as names, because we have not chosen them. There is an unknown number of further model providers, and clause 3.2 explains why we cannot name them and what has to be true before we can; no report about a named individual will be sold while that number is unknown. And there is the screening provider our Privacy Policy commits us to using before an order is accepted, which clause 2.4 explains; no order will be screened before that company has a row here.
Every commitment on this page reaches every recipient named on it, whether or not that recipient has a row in a table. Where another page of ours describes recipients or transfers differently, this page governs, and the other page is corrected in the same release rather than left standing.
1.2 What the word does not mean here. "Sub-processor" is the word people look for, so it is the word on the door. It is not quite the right one. Usually the customer is the controller and the seller is their processor. Here we are the controller, including for information about people who are not our customers. These companies act on our instructions and what they do is our responsibility. So a buyer is not our controller, we are not a buyer's processor, and no data processing agreement arises between us; 6.3 explains why. One company below, our payment processor, is also a controller in its own right, and its row says so.
1.3 Almost none of this has happened yet. The website is live. There is no checkout, no account, no report pipeline and no email. Only the companies in the first table handle anything today, and what they handle is website traffic. The pipeline described on this page has never run: nothing has been sent to a search provider, to a model provider or to an assistant provider, and no report has ever been produced for a buyer.
The sample reports published at /samples are marketing material we wrote, and none of them came out of the pipeline described here. Six are about companies. The seventh was a scored assessment of a living named individual until 30 July 2026 and is now about a person who does not exist, which is why this clause no longer carries an exception: no sample discloses personal data about anybody, so serving those pages discloses none to the companies in the first table. Our commitments elsewhere that a report is delivered to one buyer and is neither published nor indexed describe the reports we produce and sell, and they now describe the samples too.
[RESOLVED 30 July 2026, no longer a question for counsel: the sample about a living named individual was replaced with an invented subject (ADR-050), so there is nothing to weigh. Recorded here rather than deleted so that a later reader can see the question was answered by removing the exposure and not by accepting it. If a real natural person is ever proposed as a sample subject again, this note is the one to re-open, and the following was what it asked: the basis for publishing a scored assessment of an identified natural person on the open web, the personality-rights exposure in each market where the page is served, and the notice owed to that individual, which is a different and heavier notice than the one this set is drafted for.]
1.4 What is in force, and what is not. No data processing agreement has been negotiated and executed with any company on this page, and no transfer instrument has been executed with any of them either. That replaces an earlier statement on this site saying each recipient was already bound by one; the correction is recorded with its date in the change log at 5.5.
One of them, Cloudflare, is nevertheless receiving personal data today, because it carries the traffic to this website and serves it: every visitor's address, user agent and requested page reaches it. We say that in this clause rather than let a table imply a safeguard that is not in place. Some providers publish data processing terms that are incorporated when an account is opened rather than signed separately, and where that is so here, those terms and not a negotiated agreement are what we rely on. Nobody has yet read the terms actually incorporated and recorded the date, so this page does not claim it. Until that is done the row carries the status Outstanding and the table says why.
No company on this page receives production data of any kind before the instrument for it is in force and the safeguard in its row is recorded as in place. We state it that broadly on purpose. A narrower promise, limited to information about a report or a report subject, would leave the buyer's own payment data outside it and would let us take a charge before our payment processor's row was settled, so the condition covers a buyer's data as well as a subject's. It reaches every recipient named anywhere on this page, including the four in section 4 and the routed providers in 3.2 that have no row in section 2 yet, and the screening provider in 2.4 that has no row either. The only recipient outside it is the one in 2.1, which is already receiving data: it carries a status of its own for that reason rather than being excused by it.
``
1.5 Transfers, and what we will not assert. Where information goes outside the EEA we rely, in this order: on an adequacy decision covering the recipient; otherwise on the European Commission's standard contractual clauses for a controller transferring to a processor, with an assessment of the recipient's country on file. Where a recipient is certified under a transfer framework we may rely on that instead, and where we do, the clauses are executed as well and held as the fallback, because a framework can be struck down and a fallback negotiated afterwards is not a fallback.
Two things follow for how this page reads. The safeguard named in a row is the one actually relied on for that recipient at the date at the top of this page, never a description of what is available in principle. And we publish no company's certification status, because it can be withdrawn without notice: we check it, and record the result with its date.
If you are a buyer, a person a report names, or a supervisory authority, write to us naming a recipient on this page and we will tell you in writing which basis we rely on for it and when we last checked, within one month. Where a request covers a large number of recipients we may need longer, and we will say so, with the date we expect to answer, before that month is up. We do not undertake to correspond generally about our contractual position, and we do not publish the agreements themselves.
1.6 How to read the last two columns. A location is a fact only where the row says it is configured; everywhere else it is what we intend, and the row says so. An intention marked as one is better than a region nobody has checked.
The last column states the position of that row at the date at the top of this page, in one of four words.
Executed means the instrument in 1.5 is in force for that recipient, with a country assessment where 1.5 requires one, and the row carries the date. No row carries it today.
Required means the instrument must be in force before that company receives anything, and nothing has been sent to it.
Outstanding means the company is already receiving personal data and no instrument has been verified as in force. It applies to the two rows in 2.1 and to nothing else, which is why those two rows are in a table of their own.
EU region describes where data is held and never appears on its own. A provider whose corporate home is outside the EEA can hold data in an EU region while its own staff reach that data from a third country, and access from a third country is a transfer whatever the storage region says. An EU region reduces a transfer; it does not remove the need for an instrument, and this page does not say anywhere that no safeguard is needed.
``
2. The list
2.1 In use today. This one handles traffic to this website and serves it. Nothing else on this page is running.
| Provider | What it does | What it sees | Where it runs | Safeguard status |
|---|---|---|---|---|
| Cloudflare | Hosts this website and serves it, on Cloudflare Pages, and provides the domain's DNS and the network layer in front of it. Will also provide the bot check on the sign-in and checkout forms | Every request that reaches the site, being the address, the user agent, the page requested and anything else the request carries, and every response we send back. Cloudflare terminates the encryption between a reader and us, so it does not merely route traffic past itself: it is in a position to see the pages, including a report opened in an account and a report served under a share link. We say it here rather than let a row about DNS and a network layer imply that only addresses pass through it | A United States company operating a global network, so a request may be handled outside the EEA | Outstanding. Receiving data today. Standard contractual clauses with a country assessment required and not executed. Whether the provider's own terms already incorporate an instrument has not been read and recorded |
2.2 Engaged when the product runs. None of these has received anything. Cloudflare appears again because two of its services are at different stages. Nine companies are named in the two tables; four more are named in section 4, an unknown number in 3.2 and one unchosen screening provider in 2.4, so the tables are not the whole list. Sections 3 and 4 exist because a footnote is the wrong place for the recipients that receive a named person's name.
| Provider | What it will do | What it will see | Where it will run | Safeguard status |
|---|---|---|---|---|
| Hetzner | Provide the machine and the storage that everything of ours runs on: the database, the application, the worker that runs the scheduled tasks, the container that renders a report to a file, and every other container we run there. We install, configure and administer all of them; Hetzner operates the hardware underneath them and has the access that implies | Everything the database holds, in the sense that it holds the disk it sits on: accounts, orders, briefs, reports, findings, evidence, scores and the system log. For a report about anyone other than the buyer, that includes the address we wrote to for consent and the record of the answer – see 2.5 | Hetzner Online GmbH, a German company. This machine is in its Helsinki facility in Finland, confirmed from the host itself, so the data does not leave the EU | Required. Nothing sent. The provider offers a data processing agreement and it has not been concluded. Being inside the EU settles the transfer question and not the agreement – see 1.4 |
| Cloudflare R2 | Store the evidence bundle and the report's preview image. Separately, in a second bucket with its own credentials that the application's credentials are refused by, hold our daily encrypted database backup | The text of pages we fetched, and the name of a report's subject where it appears in that text. And, in the backup bucket, an encrypted copy of the whole database, which includes the full text of every live report: the private half of the encryption key is not kept on the machine that writes the backup, so what this company holds there is a file neither it nor a compromised host of ours can read. We state it rather than let this row imply that a report exists in only one place. No report, and no file rendered or exported from one, is written to either bucket. A file is rendered on the machine that holds the report and streamed to the reader by our own application, so no storage address for a report, or for a file made from one, is ever handed to a reader, and writing such a file here would make this company the holder of a complete analysis of a named person. That last part states a condition and not a fact today, in the same way clause 2.6 does; 2.7 says why we hold to it, and clause 9.2 of the Security notice states it from the other side | EU jurisdiction restriction intended for both buckets. Neither created yet | Required. Nothing sent. An EU region is not on its own a safeguard – see 1.6 |
| Stripe | Take payment, calculate the tax shown at checkout, and issue invoices and receipts. Also a controller in its own right for its own fraud, risk and regulatory purposes | The buyer's email, name, billing address and country, any VAT number given, the amount, and the card details, which we never see. From us, one opaque reference to the order and a fixed product name, and nothing from the brief. Not the report subject's name, in any field. That last sentence states a requirement and not a fact today: clause 2.6 says why and what has to change first | United States and the European Union. The entity that contracts with us and its place of establishment are named here before the first charge | Required for what it does on our instructions, and the instrument depends on which entity contracts with us – see 1.4. For what it does as its own controller, its own terms and safeguards apply and ours do not |
| Serper | Return search results for queries built from the brief | The report subject's name and other query terms | United States | Required. Nothing sent |
| OpenRouter | Route each model call to the provider that serves the chosen model | The brief, including the buyer's free-text context, the text of the evidence we collected, and the subject's name | United States, and onward to whichever provider serves the model | Required. Nothing sent. A separate basis is needed for each onward provider and none can be named until the routing is pinned – see 3.2 |
| Resend | Send transactional email: sign-in codes, order confirmations, the consent request in 2.5, the message that a report is ready, the share link itself to the reader a buyer names, the code that reader confirms their address with before the first view, and any later notice that the report was corrected or withdrawn | The recipient's email address, the subject line and the delivery result. For a consent request the recipient is the report subject, so the fact that we approached that person is visible to our email providers. For a share link the recipient is somebody the buyer named who is not our customer, so the fact that we wrote to that address is visible to our email providers too: the buyer gives us the address and we send the link rather than handing the buyer a token, which is the whole reason the address is ours to hold. For every other message, nothing in the envelope may carry a report subject's name; that states a requirement and not a fact today – see 2.6 | A United States company. EU sending region intended in our configuration notes; not provisioned | Required. Nothing sent |
| Amazon SES | Deliver the mail our email provider sends, and receive the bounce return path | The same email metadata as Resend | EU region endpoint intended; not provisioned. Amazon Web Services is a United States company | Required. Reached through Resend, so its onward-transfer obligations apply. Named for the reason in 3.3 |
| PostHog | Product analytics. Not switched on | An opaque account identifier, event names and their properties. The code that would send an event refuses any event whose identifier is shaped like an email address. That guard covers the identifier and not the properties, so what keeps an email address out of a property is the rule we apply when an event is written rather than a control that would catch a mistake. No event has ever been sent | EU cloud | Required. Nothing sent. An EU region is not on its own a safeguard – see 1.6. See also 2.9: this provider's own AI features cannot be turned off, which is a condition on switching it on rather than a fact about today |
| Sentry | Error monitoring. Not switched on | Stack traces and an opaque account identifier, with email addresses, codes and tokens removed before sending | EU region required by our configuration; not created | Required. Nothing sent. An EU region is not on its own a safeguard – see 1.6 |
2.3 What a table cannot show. The database will hold one class of record made up entirely of information about people who are not our customers: what we hold about a report subject. Different classes are protected by different controls, some inside the database and some in the application, and we do not claim protection is uniform. Which applies to which is in Security, which states plainly that this class sits outside the controls that separate one customer's records from another's.
That leaves the retention schedule doing most of the work, so we would rather set out what it does and does not cover than let a single figure stand for all of it. Ninety days is the life of a report, of the evidence behind it including the assistant answers in section 4, and of the logs of the automated model calls made while it was produced, which the schedule destroys with the report rather than holding longer.
It is not the life of everything that carries a subject's name, and the exceptions are better named here than discovered. Email delivery records run two years, with anything in them naming a subject removed when that report expires or is deleted. The record of a rights request or a correction runs three years. The do-not-report list runs for as long as the request stands, because that is what the request is. The consent record described in 2.5 stays with the order where the person confirmed, and runs twelve months where they declined or did not answer, so that a second order cannot be used to put the same request to the same person again. The buyer's brief also sits with the accounting record, and the schedule reduces that copy to a record that a brief existed, carrying no name, at the expiry of the report, its deletion, or a request from the person named in it, whichever comes first. And deletion is not instantaneous everywhere: we take our own rolling backups of our own database and hold them with the object-storage provider named above, which the schedule bounds at thirty-five days.
One thing carrying a subject's name is not ours to bound at all. A file a buyer downloaded before the report expired is the whole report, no period on this page or in the schedule reaches it, and we make no claim to have destroyed it; clause 4.3 of the schedule says what does apply to it.
Every period, class by class, is in the Data Retention schedule, which governs on periods where it and this page ever differ, while this page governs on recipients.
One thing about that schedule belongs here rather than only there. Expiry is a scheduled job. It does not run today, and until it exists, has been observed to run against real records and its runs are recorded, a period is a policy rather than a mechanism. No report about a named individual is sold before then, and the date the sweep was first observed to run is recorded in the change log at 5.5 so that the claim carries a date a reader can check.
(/legal/terms) puts the obligation to destroy a downloaded copy and to recall what was sent on the buyer, which is all we have. Confirm, in one answer: what we must tell a report subject who asks what happened to their report, when the honest answer is that our copy is gone, every link is dead and one file is outside our reach; whether our record of each download and each link view must be offered to that person unasked rather than on request; and that describing our own deletion as complete, in any document of ours, is now something we must not do. Separately, where a payment is disputed, the Data Retention schedule, the Payment Terms, the Refund Policy and the Terms of Service now all say the same thing – access is suspended and the material is held rather than deleted while the dispute runs – and the build is the outlier, which is an engineering correction and not a drafting one. Confirm the basis for holding a document about a person who is not our customer in order to answer somebody else's payment dispute, for how long, and how that hold sits with an erasure request from that person. This page must not state a retention position that the schedule does not also state.]
2.4 Companies that are not on this list. Our fonts are built into the site rather than fetched from a font service, so no visitor's address is disclosed to one. No third-party script runs on this site today: no tag manager, no advertising pixel, no session recorder. Nothing has ever been sent to the analytics provider named above. What the site stores on a device is in the Cookie Policy.
Three absences are worth naming rather than leaving to be inferred, because the absence of a row does not mean the absence of a risk.
The bot check in the Cloudflare row will be the first third-party script this site loads, and it will load on the sign-in and checkout pages only, never site-wide. Before it does, the Cookie Policy will list whatever it stores on a device and the Privacy Policy will name it as a recipient on those two surfaces. Neither document lists it today, and this page is where that was found.
No company on this page screens the subject of a report against a sanctions or restricted-party list, and no such screen runs today. That is a gap rather than a settled position. Clause 5.4 of the Privacy Policy and clause 14.5 of the Terms of Service commit us to screening the subject's name and the buyer's details before an order is accepted, against list data licensed from a screening provider. We have not chosen that provider, so it has no row and we do not name one we have not selected. It receives the name of a report subject when it runs, which makes it a recipient on the same terms as every row in section 2, and it gets its row here before the first check rather than after it. Until then the position rests on the buyer's representation in clause 14.2 of the Terms of Service, our payment processor screens the buyer for its own purposes and that tells us nothing about who a report is about, and we make no representation that any subject has been screened.
No accountant or bookkeeper has a row on this page. Where we engage one, they receive the order and payment records, which name a buyer and, once the copy of the brief held with the order is reduced under the Data Retention schedule, name no report subject. That is a recipient like any other and it has a row here before it receives anything. The Payment Terms tell a buyer that the people who keep our books see those records and send them here for the names, so this is where the answer belongs and where its absence is admitted.
``
2.5 The consent request, and what it adds to this list. A report about anyone other than the buyer will not be produced unless the person it is about has confirmed to us, by email, that they agree. We will write to the named person with a plain description of what the report is and who asked for it, and generation starts only when they confirm. If there is no confirmation within the window, the order is cancelled and refunded in full.
Three consequences for this page, none of them cosmetic. Our database will hold the address we wrote to and the record of the answer, which is information about a person who is not our customer, and the Hetzner row says so. Our email providers will carry a message addressed to that person, so they see the address and the fact of the approach, and the Resend row says so. And the person a report is about will know we exist before anything is produced, which is why clause 5.3 can promise to use an address we hold and why 6.1 does not depend on somebody discovering us by accident.
One consequence runs the other way and we would rather state it than let the paragraph above read as though the step only protects. To ask the question at all we have to send a message to an address the buyer gave us, so a person who has agreed to nothing is written to, and their address reaches our two email providers, before they have had any say. That is the smallest approach we could design and it is still an approach. If they decline, or say nothing within the window, the order is cancelled and refunded in full, no report is produced, no company in section 4 is queried about them, and what we keep is the record described in 2.3, held so that a second order cannot be used to put the same request to the same person again and used for nothing else. We do not add that address to any list and we do not market to them.
None of this is built. The flow is described here because it changes who receives what, and this page is where that belongs.
``
2.6 Two cells above state a requirement rather than a fact, and we would rather mark them than let them read as done. The subject of a report is not a party to the buyer's payment and agreed to nothing, so their name has no business on the payment record: an invoice travels to a bank, to a card scheme and, for a business buyer, to a bookkeeper, none of which appears on this page and none of which we could then account for. The rule is that everything we send our payment processor identifies the order and the product and nothing identifies the subject, in any field: the invoice line description, the product name, the statement descriptor, the customer name, the payment description, and any metadata key or value. The invoice line description specified in our engineering documents today does the opposite: it is the product name followed by the report subject's name. Checkout does not open until the code matches the rule and a test that fails the build asserts it.
The same rule applies to email. Nothing we generate in a message envelope may carry a report subject's name: not the subject line, not the preheader, not the sender or reply-to name, and not any header we set. A report-ready message names the product and the order reference and links to the report, and the subject's name appears only inside the report, behind sign-in. The consent request in 2.5 is the one message addressed to the subject themselves, and it is not an exception to the rule so much as a case where the recipient address is the subject's own. Until an automated test enforces the envelope rule, the Resend cell states a requirement.
2.7 The renderer is a container of ours, not a company, which is why it has no row. A report can be downloaded as a file from this release, so something has to draw it. That something is a browser engine in a container we build, install and administer, on the same machine in Helsinki as the database and the application. It is not a separate company and not a separate legal person, it acts on nobody's instructions but ours, and it is therefore not a sub-processor. A company that listed its own software here would be naming itself twice and telling a reader nothing.
It is covered by the Hetzner row instead, which is written as a role rather than as a list of containers for exactly this reason: Hetzner operates the hardware everything of ours runs on, this included.
An earlier version of this clause promised that if a renderer were ever reintroduced, wherever it ran, it would have a row on this page before the first render. That promise is withdrawn now rather than broken in a month. It offered more than the rules require, and it would have been false on the day the file shipped. A page that says which promise it took back is worth more than one that quietly keeps a promise it has already broken.
What replaces it is narrower, is a condition of the export rather than a description we will restate afterwards, and is a rule we can keep. The file is produced by the application that already holds the report, on our own machine, and travels from there to the reader. No company outside this page renders, stores or serves a whole report or a file made from one, and no storage address for a report, or for a file made from one, is ever handed to a reader, because an address we do not serve is a link we could not revoke and everything this set promises about stopping a link depends on our serving every view. If a rendering service, a document API, or a storage product a reader addresses directly rather than through us is ever introduced, that company has a row on this page and the instrument in 1.5 is in force before the first file rather than after it, and the change is published under 5.4. The same condition is stated from the other side in clause 9.2 of the Security notice.
2.8 One provider's AI features cannot be switched off, and we state it as a condition rather than as a fact. Our product analytics provider applies its own AI features to the data in an analytics project, and there is no setting that disables them. Today that reaches nothing: analytics is not switched on, no event has ever been sent, and the row above says so. So this is not a disclosure about processing that happens – it is a term of switching the provider on.
The condition is this. Before a single analytics event is sent, either the provider's AI processing is covered by the data processing agreement we conclude with them and named on this page as part of their role, or analytics is not enabled at all. We will not enable it and describe the AI processing afterwards, and we will not describe the provider's role on this page as narrower than what its product actually does with what we send. If that means running without product analytics, we run without product analytics.
We write it here rather than leave it for a reader to discover because the honest version of a sub-processor page has to include the thing a provider does that we cannot control, and the point at which we stop being able to say "nothing sent" is the point at which this clause has to have been answered.
3. Onward recipients
3.1 The rule. Our providers use providers, and a recipient's recipient is still a recipient. Naming only the company we contract with would look complete without being complete. Three kinds arise here.
3.2 The model providers our router routes to. Every model call will go through one routing provider, which forwards it to the company that serves the model. Those companies receive the brief, the evidence text and the subject's name, and they are recipients in their own right. We cannot list them yet and we will not guess. What makes the list possible is a fixed allow-list of permitted providers, named one by one in the request rather than left to whichever the router selects, enforced by an automated test. Until it exists and passes, the recipient set is unknown. No report about a named individual is sold while it is unknown, and each pinned provider then has its own row in section 2. Clause 1.1 records that this page is not a complete list of recipients until that is done.
3.3 Our email provider's provider. Transactional mail will be handed to Amazon SES for delivery and bounces return through an Amazon endpoint, so it is in the table above rather than hidden behind the company we contract with.
3.4 A disclosure that is not to a provider at all. Producing a report will mean fetching public web pages. Every site we fetch will see a request from us: our address, and a user agent that names LeMans Labs and links to a page explaining the fetch. We chose an agent that identifies us rather than one that hides.
Two things follow, and we would rather state both than only the easier one. Fetching a person's own site tells whoever runs it that someone is looking. And the address we request is itself a disclosure: a report about a person has to be anchored to a resolvable profile address rather than to a name, and such an address commonly carries the person's name in its path, so for those pages the name reaches that host's logs as part of the request. We send no separate field carrying the name and no referring address that would reveal what we read before, but we do not claim the name never reaches a fetched host, because for the pages that identify the subject it does. Some pages come from results the search provider returned, so they are hosts we did not select. Everything retrieved will be treated as material to read and never as an instruction to follow; what that protects and what it does not is in Report Accuracy and Public Data and AI Transparency.
3.5 What never goes anywhere, and the one thing that does. We supply personal data to no advertising network and to no data broker. We take part in no cross-site data-sharing arrangement. We sell no list, feed, dataset, extract or derived index of personal data, to anyone, at any price, in any form. And we disclose personal data to nobody for their own independent purposes, other than our payment processor as its row describes and the hosts of the pages we fetch as 3.4 describes.
What this page does not say is that we do not sell personal data, because in this business that sentence would not be true. A report about a named person is that person's personal data, and we supply it to the buyer who ordered it for money. It is the product rather than an incident of it, and a page that denied it would be denying what we do for a living. What is true and testable is the paragraph above, together with the restriction in section 8 of the Terms of Service, which prohibits the buyer from republishing or reselling a report about a natural person and obliges them to withdraw it on our written request. Where another page of ours states that we do not sell or share personal data, that statement is withdrawn and this clause governs. Every report is sold everywhere: clause 14.6 of the Terms of Service states that there is no territorial limit on any of them.
``
``
4. Providers we query about a named subject
4.1 The unusual one. Part of a report measures how AI assistants answer questions. For a company the prompts do not contain the subject's name. For a person some of them do: a founder report will send eight prompts containing that person's name to each of four assistants, and record the answers as evidence.
4.2 Which four, and on what basis each receives the name. ChatGPT (OpenAI), Claude (Anthropic), Gemini (Google) and Perplexity. They are named in the product description, so they are fixed rather than interchangeable, and replacing one is a change to the product and to this page under section 5 rather than an operational detail. Naming a vendor identifies the model queried and implies no affiliation with it and no endorsement by it. We publish no ranking between them.
Each receives the name of an identified individual and is a recipient on the same terms as every row in section 2, so each has a row here. Where a cell is not yet a checked fact it says so rather than guessing, and no report about a natural person is sold while any of them is unfilled.
| Assistant | Entity we contract with | What it will see | Where it will run | Safeguard status |
|---|---|---|---|---|
| ChatGPT | [Entity and country of establishment – recorded with the date checked, before the first founder report] | Eight prompts naming the report subject, and the answer to each, which we record as evidence. Nothing about the buyer or the order | [Recorded on that check. Outside the EEA on the information we hold] | Required. Nothing sent. Whether it receives the name as our processor or as a controller in its own right is recorded on the same check |
| Claude | [As above] | The same | [As above] | Required. Nothing sent |
| Gemini | [As above] | The same | [As above] | Required. Nothing sent |
| Perplexity | [As above] | The same | [As above] | Required. Nothing sent |
4.3 What this means for a person a report is about. To measure whether an assistant says anything about you, we have to ask it about you. Your name goes to four more companies, as the subject of a question. Under 2.5 you will have been asked first and will have agreed, and the request we send you will say that this is part of what producing the report involves, so that it is not something you discover afterwards.
What comes back is stored in two places and we set out both rather than the one that sounds better. The answers themselves are evidence behind the report. The record of the calls that produced them, which includes the prompts carrying your name, is a model-call log. Under the Data Retention schedule both are destroyed with the report at ninety days, so there is one period here and not two. That schedule governs if this page and that one ever differ, and where another document of ours still states a longer period for the model-call log, the schedule is right and that document is corrected in the same release. What you can do about any of it, including asking us to erase both copies without waiting for the period to run, is in If a Report Names You.
``
4.4 What can come back, and the rule on the write. Asking an assistant who a named person is can return material we are not willing to hold at all: material revealing health, political opinions, religious or philosophical beliefs, trade union membership, sex life, sexual orientation, or racial or ethnic origin. Our own Privacy Policy records that this happens routinely rather than rarely, and treats a discard rate of zero as a fault in the control rather than a clean run. The rule is that such material is refused at the point an answer is written to the evidence store, so that it is discarded rather than stored and suppressed later when a report is composed. That control does not exist yet, and no report about a named individual is sold before it does and has been observed to work. What we would record is the number of items discarded and never their content. Agreement to a report is not agreement to our holding material of that kind, which is why the control sits on the write rather than on the wording of the consent request.
4.5 How they are reached, and why this page states the recipients rather than the route. Whether these four are reached through the routing provider or called directly is fixed in code before the first report about a named individual is sold, and this clause states which. The recipients are the same either way: four more companies receive the name. The route matters to one thing, which is the instrument, because an onward transfer through the routing provider and a direct contract with each provider are not the same instrument; the answer is recorded in the table at 4.2 in the same change that settles this clause. Where another document of ours states the route before this one does, this page governs and that statement is to be read as describing the intended design rather than the built one.
``
5. When this list changes
5.1 The rule, and its one exception. This page changes before a new company receives production data, not afterwards. There is one exception and it is stated here rather than left to a later clause: where a provider fails, withdraws a service or is suspended, and work already paid for cannot be finished or protected without substituting another, we may substitute first and publish afterwards. That is the only circumstance in which this page changes after the fact. It reaches work already in progress and never new orders, and 5.4 sets out what it permits and what we then owe.
5.2 How it is kept. This list lives in the same repository as the rest of these documents. Every change is a dated entry in the log below, and the page carries the date its rows were last checked. That is a commitment a company of our size can keep and demonstrate. An undertaking to send individually addressed advance notice to everyone affected is not, and a promise nobody can keep is worse than a smaller one that holds.
5.3 Who we tell. If you hold a report that has not expired, we will email you where a change is material: a new recipient outside the EEA, or a new class of information going to an existing one.
For a person a report is about, the position follows from 2.5. A report about anyone other than the buyer will not be produced unless we have written to that person and they have confirmed, so for those reports we will hold the address we wrote to. Where we hold an address for you – because we wrote to you for consent, or because you have written to us to object, to ask for a correction or to ask us not to produce a report about you – and a change on this page is material to you, we will use it. We do not go looking for an address we do not hold, because finding one in order to send a notice would be a greater intrusion than the notice is worth, and where we hold none the change is published here instead, on a public page that needs no account. We will not tell you we cannot reach you when we can.
5.4 Substitution at short notice. Where the exception in 5.1 applies, a substitute may receive personal data before this page is updated only where all of the following hold: it performs the same function as the row it replaces; it is in the European Economic Area, or in the same country as the row it replaces with an instrument at least equivalent to that row's in force before it receives anything; and it is used only to finish or protect work already under way. A substitution never enlarges what a recipient sees beyond what the row it replaces describes.
Anything outside those limits is outside this clause, and 5.1 applies to it without exception. In particular, a substitute in a country the replaced row did not name, with no instrument in force, does not receive a report subject's name at all: the work in progress fails and the affected orders are refunded in full instead, on the generation-failure ground in the Refund Policy, which is automatic and does not depend on anybody asking for it. We would rather refund an order than move a named person's analysis to a company we have not assessed and have not named.
Every substitution is published here as soon as it is made and in any event within two working days, with the date, the reason, what the substitute received, the safeguard relied on and the period it covered. A substitution is a material change for the purposes of 5.3, so where you hold a report that has not expired we email you on the same timetable. That the substitution was an emergency is not a reason the notice is not owed.
5.5 Change log.
| Date | Change |
|---|---|
| [Effective date] | First published as a page of its own. It replaces the recipient and transfer statements previously carried elsewhere on this site, one of which said that every recipient of personal data was bound by a data processing agreement. That was published from [date first published] to [date corrected] and was not correct: none had been executed then, and none has been executed since. Clause 1.4 is the corrected position, and the same correction is made in the Privacy Policy and in Security in this release. |
| [Date] | [Reserved: the date the retention sweep described in 2.3 was first observed to run against real records.] |
| [Date] | Corrected rather than changed. This page now records two things that were already true and unstated: our daily encrypted database backup is held in a separate Cloudflare R2 bucket and contains the full text of every live report, and Cloudflare terminates the encryption on this site and is therefore in a position to see the pages we serve and not only the requests for them. Neither is a new recipient and neither began on this date. Because the classes of information named for an existing recipient have changed, clause 5.3 applies and we email everyone holding a report that has not expired. |
| [Date] | A report can be downloaded as a file and shared with a reader the buyer names, whom we email the link and who confirms that address with a code before the first view. No company was added to this page. The renderer is a container of ours and clause 2.7 explains why it is not a sub-processor and withdraws the earlier promise that any reintroduced renderer would have a row here wherever it ran. Our email provider now also carries the link, the confirmation code and any later correction notice to a reader who is not our customer, and the Resend row says so. |
6. If you object to a sub-processor
6.1 If a report names you. You do not have to work out which of the companies on this page concerns you, and you should not have to. Object to the processing itself, or ask us not to produce a report about you, and we treat your message as reaching every recipient named here. It is free, it needs no account and no particular form of words, and the route is at If a Report Names You. Where a report was about you rather than about the person who bought it, you will already have heard from us under 2.5 and can simply reply.
We consider each objection on its own facts rather than deciding the answer in advance on this page. Where we cannot demonstrate grounds that override your interests, rights and freedoms, we stop and delete, including where that means withdrawing a report a buyer has already paid for and refunding them, which is a cost we carry rather than an argument we make. Nothing in any customer's contract with us limits or affects that.
``
6.2 If you are a buyer. You have no veto over the companies we use, and we would rather say so than imply one. What you have is this page before you buy, and 5.3 for how you hear about a change afterwards. This page is not a term of your contract, and clause 2.4 of the Terms of Service does not treat it as saying nothing either: what it tells you about recipients and transfers is a statement we made to you before you bought and you may rely on it, and 5.3 and 5.4 are commitments we owe you rather than descriptions of a preference.
We do not restate your refund rights here. They are in the Refund Policy, which is the only place we state them, and a shorter version on this page would be a second version of the same promise. Two things are better said plainly than left to be discovered. A change to this list after your report has been delivered is not by itself a ground for a refund. And no refund arises as of right once a report has been delivered at all: that is our position, whether it holds against you turns on what the checkout captured from you rather than on anything this page says, and we would rather record that dependency than assert the outcome.
``
6.3 If your procurement asks for a data processing agreement. We do not offer one, and the reason is not administrative. For information about a report subject we are the controller and you are not. An agreement describing you as the controller and us as your processor would be untrue, and would put obligations on you towards a person you have no relationship with and no way to answer to. Instead we answer questions about this page in writing on the terms in 1.5, and we publish a change of basis for any recipient under 5.3 and 5.4. Our respective roles are fixed in clause 5.5 of the Terms of Service.
6.4 Complaints. Write to [email protected] or to [email protected]. Those are the only two addresses this business publishes, both reach the same team, and a message counts as received on the day it arrives at either, so you never need to use more than one. If an address we publish ever fails to accept your message, tell us at the other and we will treat your request as made on the day of your first attempt. If you are not satisfied you can complain to a supervisory authority, and the Privacy Policy says which one and how. A complaint to us uses up no other route and no deadline.
``
This list is part of the LeMans Labs legal set and should be read together with the Privacy Policy, which explains why we hold anything at all; If a Report Names You, written for a person who did not buy anything; Security, which describes the controls that apply to what is stored; the Data Retention schedule; AI Transparency and Limitations, which covers the models and the routing; and Payment Terms for what our payment processor does.