Privacy notice

Published 5 November 2026. It has not been reviewed by a solicitor yet; one will review it before Reynforce is sold to more than a handful of customers, and this notice will say so when that happens.

Every factual statement below is a statement about code in a repository rather than an intention. Where something is built but not yet in use, the notice says so. Where something is not settled it is in What is not settled yet rather than written as though it were.

Who we are

Reynforce is a trading name of a business based in the United Kingdom. The controller for the purposes of UK data protection law is the owner of that business, trading as Reynforce. Anything in this notice, including a request about your own data, goes to [email protected].

Reynforce records what a company's software and people commit to on that company's behalf. The data it holds is the customer's own: claims the company makes about its own product, the authority it has granted its agents, and a record of what was committed and under which authority.

It is not a marketing tool. We keep two lists for our own purposes, each described in full below: the Agent Incidents list, which you join yourself, and the people we write to first. There is no tracking on this website, no analytics, and no cookie that is not strictly necessary.

How we read what your agents say

Most of what Reynforce handles about people other than our customers arrives the same way, so the pattern is described once here.

1. The words arrive, or we fetch them. An agent hands us the words of a message — with its check before sending, or after it went out — or a tool you connect sends them to us, or tells us a message went out and we fetch the words from that tool with a key you gave us. Connections says which does which.
2. Personal details are removed first from a message that has gone out. Before it is read we replace email addresses, phone numbers, the path of any link, and the names of people we already know about: your workspace's people, and the person and company the agent named when it checked. A text message loses more — the name after a greeting (Hi …) and before a sign-off (Thanks, …). We keep how many of each were removed, never what they were. A draft an agent sends with its check, before sending, is read as it arrives, without this step, so a quotation kept from a draft can carry a name or an address the draft contained.
3. The words are read for promises. When your workspace's AI model reader is on, the text is sent to Anthropic to be read — and on one trial workspace of our own, a draft goes to two of their models, to compare them; with it off, nothing is read and the record says so. On a call only your agent's own words are read: the other side is never read for promises.
4. We keep each promise as a quotation, capped at 1,000 characters — the sentence a promise was made in, so that what was promised can be checked — with a fingerprint of the text (a one-way hash; a short text could be matched by somebody who already holds a candidate for it), how long it was, how many personal details were removed, and what differed from what the agent declared.
5. The text itself is thrown away. It is not written to the record, to a log or to an error message.
6. The record is kept for 24 months, and a promise nobody has closed is never deleted on age — see How long we keep it.

After sending, we ask agents for excerpts rather than whole emails: up to ten sentences of at most 300 characters each, holding only what was promised. If you turn on spot-checks, a share of emails is also read in full beside the excerpts, to measure what the excerpts left out; this is off unless you switch it on.

Connections

Every way your agents and the tools you connect send us words, and every way we reach the people who approve what they do. Where a tool sends to us, the address it sends to is shown to you once and we keep only a fingerprint of it. Every key or secret you give us is stored encrypted, never shown again, and deleted when you disconnect. What a tool keeps is under your own agreement with it, not ours: we receive a copy, and they keep theirs.

What we collect

Your account

When you ask for access: the company name and the email address of the person responsible. That is the whole of it — the form's own shape refuses a source address or a browser string, so neither is held.

When an agent signs your company up: the company name and the email address of the person it names as owner, held only until the invitation to that person is sent. After that we keep the domain, not the person — the half after the @. Nothing records which agent named whom.

When a person signs in: an identifier, a work email address, a display name, and the groups their own identity provider says they are in, through WorkOS. A role is read from your directory rather than maintained by us, so adding somebody to your own deal desk group is what grants them that authority here.

When you invite a teammate: their email address, who invited them, when, and whether it is pending, accepted or revoked; no period is set for these yet. WorkOS sends the invitation.

Agent keys: a one-way hash of the key, not the key, with when it was created, who created it, and when it was revoked. The key is shown once and never stored, so we cannot recover it and neither can anybody who reads our disks.

Your register and your record

The register is the statements your company stands behind, who owns each one, and when each was last checked. An owner is held as an identifier and a role, and as a name only where somebody typed one.

The record is what was committed, which agent or person committed it, who it was said to, what it relied on, and who approved it — as their user identifier and the role they held at the time, never as a name. A record is written once and is never edited. The words it keeps are the quotations described in How we read what your agents say.

What you give us to read when you set up an agent

Your company's own website, a link, files, a past security questionnaire or pasted text, given to us to suggest the facts your agents could say. We read it and throw it away: we keep the suggested facts and the name of the document each came from, never the text. Nothing else is kept: no copy, no temporary file, and nothing in our logs. Each fact is a suggestion until somebody in your company accepts it.

When you give us your agent's instructions, we also keep the one sentence each suggested rule came from. You see it next to the rule, so you can tell why we suggested it.

When your workspace's AI model reader is on, the text is sent to Anthropic to propose those facts, at most 40,000 characters of one document. The words of your agents' messages go to Anthropic on the same terms. Anthropic's own words on what happens to it, read from their pages on 22 October 2026:

For Anthropic API users, we automatically delete inputs and outputs on our backend within 30 days of receipt or generation, except:

Anthropic may not train models on Customer Content from Services.

Their exceptions to the first sentence are listed on the same page, among them content flagged as breaking their usage policy, which they say they may keep for up to two years. With the reader off, nothing is sent and the text is read by rules on our own deployment. The website we read without being asked is your company's own: the domain of the address you signed in with, never a personal mail domain, and only its public pages.

When you pay

Nothing is sent to Stripe yet. Once payments are live, Stripe will hold a billing name, an email address and a subscription status, and a payment method only if you add one — no card is needed to start the 14-day trial, and nothing is charged during it.

Card details never reach us. Payment runs on Stripe's own hosted checkout, so the card is typed into Stripe's page and not into ours; the key this platform holds can read customers and subscriptions and nothing else. That holds whenever a card is added — what decides is whether Stripe are given one, never whether we see it.

Technical logs

One deliberate line per significant event, carrying no claim, no cookie and nobody's address. The register's own request log is switched off on purpose: a request log of a register is a list of what somebody looked at.

Sign-ins, downloads and changes to settings

Each workspace keeps an audit log of who signed in, who tried to sign in and was turned away, who signed out, who downloaded data, who opened a settings page, and who changed settings, people, access, permissions, rules, agent keys or connections. Each entry holds the person's identifier (or nobody, for a refused sign-in), when it happened, which page it was, the IP address the request came from, and the description your browser sends of itself. Only the Owner of the workspace can see it.

It is kept apart from the record of promises, which never holds an IP address or a browser description. Each entry is kept for 24 months and then deleted, and each deletion is itself written to the log. It leaves your deployment with the nightly backup.

Supplier questionnaires you answer

When somebody in your workspace uploads a buyer's supplier questionnaire, we keep the spreadsheet as it arrived, which can carry the buyer's staff names and contact details, the buyer's company name as your colleague typed it, who uploaded it, and for each question the fact matched and, once accepted, the answer's words, who accepted it and when. An answered questionnaire is kept until somebody in your workspace deletes it, which removes it at once; nothing deletes it on age. Each accepted answer is also in the record of promises, naming the buyer's company.

What we never hold

• The contents of your email or your CRM. We keep the sentence a promise was made in, capped at 1,000 characters, and nothing else of a message — that cap is in the record's own schema, which is what makes this sentence checkable rather than a policy.
• Card numbers. They never reach us, by construction.

When somebody checks a promise on our verification page

This part is addressed to a buyer who uses our verification page, rather than to our customers.

A buyer who has been told something by a company's agent can paste that line on our verification page and be told whether that company publishes it. The page asks for two things: the company, and what they were told. It does not ask for a name, an address or anything else, and there is no field for one.

The page answers a limited number of questions about each company each day. A buyer is told nothing about the register itself — not what it holds, not how close they got, and not whether a company is a customer of ours: a company we have never heard of and a company that has not switched the page on are given the same answer, deliberately. It is off until a company turns it on, and only facts that company has chosen to publish are answered about. It is built, and not yet in use.

Where it comes from

From you and your people when you sign up, sign in and use the screens; from your identity provider, for names, addresses and groups; from your agents and the tools you connect, as set out in Connections; and, for the website reader, from your company's own public pages. A buyer's name or address that reaches us does so inside what you or your agents send us — we do not collect those people's details ourselves, and from a message that has gone out they are removed before anything is read.

Why we use it

To provide Reynforce to the customer who signed up for it: to keep their register and record, check their agents' actions, read what their agents said, tell their approvers, sign their people in, and bill them. The verification page, the Agent Incidents list and the people we write to first each state their own purpose and lawful basis in their own section.

Cookies

One cookie, set when you sign in, and nothing else. It carries a signed session, is HttpOnly and SameSite=Lax, and is Secure wherever the screen is reachable over a network. There is no analytics cookie, no advertising cookie and no third-party cookie, because there is no third party on the page: this site loads nothing from anywhere — no font, no script, no pixel — and its content security policy is default-src 'none'.

How long we keep it

Two conditions on the 24 months, and both are built rather than promised:

• A record of a promise nobody has closed is never deleted on age. If somebody is still waiting on a promise made in your name, the record of it stays. This is derived from the records themselves rather than stored as a flag, because a stored flag becomes wrong the moment the promise is closed.
• Every deletion is itself recorded, with the count read off the file before it goes — the one number a deletion cannot recover afterwards.

Nothing has been deleted yet, and nothing in the code can delete it. The module that answers these questions holds no deletion primitive at all and imports nothing that could delete a file. The policy and the exemption are true from the first customer; the first sweep is due in 2028.

On cancellation the record is kept for the same 24 months, and you can export everything while you can still sign in. A trial that expires is destroyed after a snapshot is taken. We aim to keep that snapshot for 30 days; until provisioning sets the period explicitly it is the provider's default, which is 5 days. That is written here as two numbers rather than one because 30 days we chose and 5 days we inherited are different facts.

Where it is held, and by whom

Your register, your mandates and your record sit on your own deployment — one application and one volume per customer, in London. That is a decision about blast radius: secrets and networks are isolated per application, and a credential belonging to one customer is refused at the door of another.

A tool you connect yourself — Smartlead, Twilio for your agents' own texts and calls, ElevenLabs, Retell, Slack — is not on this list, because the data and the agreement with that provider are yours; we hold your key, encrypted, on your deployment.

International transfers

Resend stores data in the United States. Their own security page, read on 10 October 2026:

"Stored data is held in the United States. The region you select when adding a domain controls where email is sent from, not where it is stored. Transfers are covered by Standard Contractual Clauses and the EU-U.S. Data Privacy Framework."

So sending from eu-west-1 is a deliverability decision and not a residency one, and this notice says so rather than implying otherwise. Fly's own copies are in the United States, as the table says. The safeguard each other supplier relies on is in What is not settled yet.

Security, in brief

• In transit: everything, over TLS.
• At rest: your register, your record and your directory sit on encrypted storage provided by Fly.io — that encryption is theirs, with their keys, and this notice does not claim it as ours.
• Encrypted by us, with our own keys: the credentials we hold for systems you have connected, and every backup, before it is written anywhere.
• A backup never carries a credential. The secret store is excluded by path, because a token in object storage outlives the revoke that was meant to end it.
• Each customer is isolated: one deployment each, and a key or sign-in from another customer is refused at the door.

Email

Sent through Resend. Apart from telling an approver that a request is waiting (see Connections), ten messages are the whole list. They are all built, and not all of them are in use yet. They are: an owner claim, a trial reminder, a receipt, a cancellation, one nudge if you leave a first-run step unfinished, one saying your workspace is ready, a weekly digest of the register facts whose revalidation is due (revalidation_digest), a daily digest of the actions your agents were refused (refusals_digest), your report (regular_report), and an alert when something breaks (broken_alert). No marketing mail is sent to customers, and none of them carries an unsubscribe link, because each one is about something you asked for or paid for.

Four of them come again and again, and you can turn each one off in Settings, under How we reach you, then Reports and digests:

• The weekly digest comes once a week. The daily digest comes once a day, and not at all on a day with nothing in it. Both are on until you turn them off, because an owner who never finds the settings page is exactly the owner whose facts go overdue.
• Your report says what your agents did, next to the time before. It comes once a week, or once a month if you get the owner's page.
• The alert says when something in your agents' set-up has broken. It comes at most once a day, and only when something is broken.

The report and the alert are off until you turn them on. We are not sending either of them to anybody yet.

Resend keeps email and log data for 30 days, against our 24 months for the record of promises: the first is a copy of a message in their system, the second a record of a commitment in ours.

The Agent Incidents list

This is the one list you can join, and it is separate from everything above. If you type your address into the form on our Agent Incidents page:

You are not profiled and nothing is shared. The address is not joined to anything else we hold, no analytics sees it, and it is not passed to any third party other than the sending provider named above when a message is eventually sent.

One thing we would rather state than have you find. Keeping a list of addresses is the processing that ICO registration is about. Collection started on 14 October 2026, the day before we were registered, as a decision taken with that open rather than as an oversight. We registered with the ICO on 15 October 2026.

If we emailed you first

This is the list of people we approached, and it is separate from everything above. If you received an email from Callum at Reynforce that you did not ask for, this is what we hold about you and why.

If you ask us to stop, we keep one row on purpose: your email address and the date, and nothing else. It is checked before any future list is used, so a later purchase of contact data cannot put you back on, and it is never deleted on a schedule. That is the opposite of the Agent Incidents list, and deliberately so: you asked to join that one, and we approached you here, so forgetting you would be how you got written to again.

What we do not do. No tracking pixel and no link that carries anything about you; the email has no per-person identifier in it. We write only to people at companies: someone in business on their own account is treated as an individual for email marketing, and we do not write to them. We do not sell or share the list.

Nothing has been sent from this list yet. This section is published before the first email rather than after it, because you are owed it at the first contact.

Your rights

Access, rectification, erasure, restriction, portability and objection, in the usual terms. Write to [email protected]. Export is built, not promised: any signed-in member can download the whole store at any time, without asking us.

Removing a person's name. You can ask us to remove or replace a person's name and email address. We do that in the directory, which is where names live. The record of what was promised refers to people by an internal identifier, so removing the name from the directory leaves the record complete and stops it identifying them.

We cannot change or delete a record of a promise. It is append-only by design, which is the whole reason it is worth anything: a record somebody can edit afterwards is not evidence of what was promised. Where a record must stop identifying somebody, the directory is the place that happens. When somebody leaves, their directory entry is suspended rather than deleted, because a two-year-old record that resolves to nobody is worse than one that resolves to somebody who has left. Suspension and removing a name are separate requests and we will do either.

You can complain to the Information Commissioner's Office — https://ico.org.uk — and we would rather you wrote to us first.

What is not settled yet

Named here rather than smoothed over, because a notice that reads as finished when it is not is the failure mode this section exists to address.

Changes

This notice is dated at the top. A change that affects what we hold or how long we hold it will be emailed to the owner of each account.

• 5 November 2026: backups are now kept 35 days, then deleted. Says plainly that a document we read is not kept anywhere, and that we keep the sentence each suggested rule came from in your agent's instructions.
• 3 November 2026, afternoon: audit log entries are now kept 24 months. Adds two emails, your report and the alert, which stay off until you turn them on. Says where in Settings you can turn off any of the four emails that repeat.
• 3 November 2026: adds the audit log: sign-in, download and settings records now hold the IP address and browser description, kept 12 months; and says how long answered supplier questionnaires are kept.
• 29 October 2026, evening — rewritten for clarity; adds Twilio and Smartlead fetching, how an approver is told and answers by Slack or text message, invitations, and how long backups are kept; Instantly is no longer offered. It describes what the code now does — the Twilio, Smartlead and approval channels were built on 29 October and none of them is in use yet — and it corrects Retell, whose calls are not read, and drafts, which are read without personal details removed.
• 29 October 2026 — agents asked for excerpts rather than whole emails, personal details removed before anything is read, and connected sending tools and voice platforms described.
• 27 October 2026 — Fly's own copies of your volume held in the United States; nightly backups to Cloudflare scheduled since 24 October 2026.
• 26 October 2026 — When you pay written from the payments plan, so it says what the trial takes today; nothing held changed.
• 25 October 2026 — the list of people we write to first added.
• 22 October 2026 — setting up an agent can read your website, a link, files and past questionnaires, and the text can be sent to Anthropic while your workspace's AI model reader is on.
• 13 October 2026 — the trial took a card at sign-up rather than at the end; card details still never reach us.