# Privacy notice

Published **13 October 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 not yet settled it is in
[What is not settled yet](#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
<mailto:callum@reynforce.com>.

## What Reynforce is, which decides most of what follows

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.** For our own sales we do keep one list of
people we have written to first, and it is described in full in
[If we emailed you first](#if-we-emailed-you-first). There is no tracking on
this website, no analytics, and no cookie that is not strictly necessary.

## What we hold

### 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**,
and that address is 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**. Sign-in runs 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.

### Your register

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.

### 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 lines your agents could say. **We read
it and throw it away: we keep the suggested lines and the name of the document
each came from, never the text.** Each line is a suggestion until somebody in
your company accepts it.

**When your workspace's AI model reader is on, the text is sent to Anthropic**
to propose those lines, at most 40,000 characters of one document. 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.

### The record of promises

What was committed, which agent or person committed it, 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.

### 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 itself is shown once and never
stored, so we cannot recover it and neither can anybody who reads our disks.

### 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.

### Email we send you

The recipient's address and the message, through Resend. See
[Email](#email) below.

### 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.

### When somebody checks a promise on our verification page

**This is the one place we process something about a person who is not our
customer**, and it is the only part of this notice addressed to them.

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.**

| | |
|---|---|
| what we keep | that a question was asked about that company, which of the answers came back, how long the paste was, and when |
| what we **do not** keep | **what was pasted.** It is compared and discarded — not hashed, not truncated, not kept for a day. There is no field for it in the record's own schema, which is what makes this checkable rather than a promise about our habits |
| what the company sees | the count and the answers. **Not what was asked** |
| how long | with that company's other records, under *How long we keep it* below |
| the lawful basis | our legitimate interest in letting a buyer check a claim made to them, which is also the reason there is nothing to keep: the shortest possible record does the job |

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 lines that company has
chosen to publish are answered about.

## What we never hold

- **The contents of your email or your CRM.** A mailbox connector asks for
  metadata only — the body is not requested rather than requested and
  discarded — and never asks for a subject line. A CRM connector asks only for
  the fields you have mapped.
- **Your agents' messages.** We keep **the sentence a promise was made in,
  capped at 1,000 characters**, so that what was promised can be checked. 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.

## 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

| | |
|---|---|
| the record of promises | **24 months**, then deleted — with two conditions below |
| your register and account details | while your account is active |
| a request for access that never became an account | **12 months** |
| a cancelled account or an expired trial | recoverable from a snapshot, then destroyed — see below |
| technical logs | held by our hosting provider rather than by us; we write no log file |

**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.

| | what they hold | where |
|---|---|---|
| **Fly.io** | the deployment, and the volume your data is on; also Fly's own copies of that volume | London (`lhr`) for the deployment and the volume. **Fly's own copies of the volume and its control-plane records are held in the United States**, whatever the region, by Fly's own security questionnaire |
| **WorkOS** | sign-in, and the directory a role is read from | not yet confirmed |
| **Resend** | email in flight, and 30 days of logs | **United States** |
| **Stripe** | billing details and invoices, once payments are live | not yet confirmed |
| **Cloudflare** | this website, and a nightly backup of your store, encrypted by us before it is sent | backups running every night; the storage region is **not yet confirmed** |
| **GitHub** | the code, and the workflows an operator runs | — |
| **Anthropic** | what you give us to read when you set up an agent, while your workspace's AI model reader is on — see above. Also Claude, used to build the product | not yet confirmed |

### Encryption, stated accurately

- **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.

## Email

Sent through **Resend**, and **eight messages are the whole list** — 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 lines whose revalidation is due (`revalidation_digest`),
and a daily digest of the actions your agents were refused
(`refusals_digest`). **No marketing mail is sent to customers**, and none of
those eight carries an unsubscribe link, because each one is about something
you asked for or paid for. The one list you *can* be on is separate, and it is
the next section.

**The last two are the only recurring ones, and each can be switched off per
person** on your own settings page. They are **on** by default, which is a
decision rather than an oversight: an owner who never finds that page is
exactly the owner whose lines go overdue, so off by default would make the
product's main failure silent.

### The Agent Incidents list

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

| | |
|---|---|
| what is kept | **your email address**, the date you gave it, and the words you were shown when you gave it |
| why | to send you Agent Incidents, and nothing else |
| how long | **12 months**, and no longer |
| how to get off it | the link you land on carries `/incidents/unsubscribe`, and so will every message. It **deletes** your address rather than marking it — there is no suppression row with your address in it |
| what has been sent | **nothing, to anybody.** The first issue is not published. Collecting is not sending |

**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.**

**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.

**Resend keeps email and log data for 30 days**, against our 24 months for the
record of promises. Two numbers about two different things: the 30 days is a
copy of a message in Resend's system, and the 24 months is a record of a
commitment in ours.

## 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.

| | |
|---|---|
| what is kept | **your name, your work email address, your company and your role**, where we found them, and the date we first wrote to you |
| where we found you | **Treg**, a business contact data provider, or **your public LinkedIn profile**, found by hand. The email you received says which |
| what we know about your company | sentences from your company's **public web pages**, and which systems your company's **public DNS and homepage** show as configured. That is about the company and not about you, and it is what the email opened with |
| why | to write to you about Reynforce as a business contact. Our lawful basis is **legitimate interests** |
| how long | **until two months after our last email to you**, and then your row is deleted, whatever the outcome. If you reply and it becomes a conversation, that conversation is kept as correspondence |
| how to get off it | **reply and say so**, in any words, or write to <mailto:callum@reynforce.com>. Your right to object to direct marketing is absolute, and you will not be written to again |
| who else handles it | **Smartlead**, which sends the email from our mailboxes, and **Google**, which hosts those mailboxes. Smartlead in turn uses the sub-processors it lists on its own page, which include hosting in the United States, an email-verification service, OpenAI and Anthropic |

**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 above,
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 <mailto:callum@reynforce.com>.

**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.

**One thing to know about leavers:** 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 prevent.

| | |
|---|---|
| the controller's **full legal name and trading address** | a notice should name them; this one names the business and the contact address. To be filled in before a customer's own privacy review relies on this page |
| the **ICO registration number** | we registered on 15 October 2026. The number is on the ICO's public register and we give it on request; it is not printed here |
| whether we are a **controller or a processor** for a buyer's name that arrives inside your activity data | we do not collect those people's details — they arrive in data you send or connect — and which of the two we are for them is a question for a solicitor, not for us |
| the **transfer safeguard** each supplier relies on, for Fly.io, WorkOS, Stripe and Anthropic, and **where Anthropic processes** what it is sent | Resend's is quoted above because they publish it. The others are not quoted because we have not read their pages, and a safeguard recalled from memory is worse than one marked unread |
| where **Smartlead** holds what it is sent | its own pages disagree. Its data processing agreement, updated 18 September 2026, says it stores UK data *"in data centres located inside and outside the European Union"* and names an Amazon Web Services region in Sydney; its sub-processor page lists Amazon Web Services in the United States. The safeguard is not in doubt: that agreement processes UK data under the EU standard contractual clauses and *"the UK Addendum VERSION B1.0"* |
| how Smartlead **spells** the setting that turns tracking off | our code reads each campaign before adding anybody to it and stops unless open and click tracking are both off. Smartlead's own pages spell that setting two ways, so both are accepted until a real campaign has shown which one comes back |
| how long **technical logs** live | our hosting provider's answer rather than ours; we write no log file |
| how **erasure** interacts with a record you are required to keep | the hardest question on this page. Our answer above is that the name leaves the directory and the record stops identifying anybody; whether that is sufficient for a particular record is not ours to settle |

## 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.

**27 October 2026** — the supplier table now says that **Fly's own copies of
your volume and its control-plane records are held in the United States**,
which Fly's own security questionnaire states, and that **nightly backups to
Cloudflare have run since 24 October 2026**; the row had said they were not
yet set up. Both backups and snapshots were already described above; what
changed is where this notice says they are.

**26 October 2026** — *When you pay* is now written from the payments plan
rather than by hand, so it says what the trial takes today. It had said a card
was taken at sign-up while the rest of the site said none was needed. Nothing
about what we hold changed.

**25 October 2026** — **we now keep a list of people we write to first**, for
our own sales: [If we emailed you first](#if-we-emailed-you-first) says what is
held, where it came from, how long, and how to get off it. Nothing has been sent
from it yet.

**22 October 2026** — setting up an agent can now read your website, a link,
files and past questionnaires to suggest register lines, and **the text can be
sent to Anthropic** to propose them while your workspace's AI model reader is
on. We keep the lines, never the text. Before this, nothing was sent to a model.

**13 October 2026** — the trial now takes a card at sign-up rather than at the
end, so Stripe hold a payment method from the moment you sign up. Nothing else
about what we hold changed, and card details still never reach us. The
11 October version said the card came at the end.