# Working with a client's Reynforce, as a partner

**You are a named person in your client's directory, with the roles they give
you.** There is no partner account, no partner portal, and no view of several
clients at once — and each of those is a decision rather than something not
built yet.

## Why it is shaped that way

**The client always holds the account and is billed directly.** The register is
their record of what their company stands behind, and a partner holding the
account would mean an agency controlling which of their client's claims are
current. That is the one line in our partner programme that is a decision
rather than a proposal.

The useful consequence for you: **your access ends when your client ends it**,
not when somebody at our end remembers. It is their directory, so removing you
is a thing they do.

## What you can do

Whatever the roles your client gives you allow, on their workspace:

- **read the register** — every claim with its owner, the date it was last
  checked, and its state
- **propose claims from a document**, which land as *proposed* and stay there
  until a person at that company accepts them
- **accept, assign an owner, revalidate or contest** — if your client gives
  you a role that carries it. A partner employee in their directory **is** a
  person at that company, which is the honest version of *only a person can
  accept a claim*
- **read the record** of what their agents have committed to

## What you cannot do

| | |
|---|---|
| hold the client's account, or be billed for it | it is their record |
| reach a client's register without being in that client's directory | there is no partner-side key |
| take a cut of a client's own referrals | the referral is between those two companies |
| put our register inside your own product, with our name off it | see below |

**On the last one, the reason is not commercial.** A buyer cannot check a
promise against a record they cannot see. A register with our name taken off it
is one that our verification page cannot answer about — so it is a change to
what the product is, rather than a pricing decision.

## Signing in

**Today: one workspace at a time.** You sign in to your client's workspace with
your own email, and your roles there are the ones their directory gives you.

**`[unread]`, and said plainly rather than smoothed over:** whether one person
can hold memberships in several organisations at our identity provider, and
whether a sign-in can name more than one, has not been read from their
documentation. If you need two clients' workspaces in one day today, sign in
to each. We will say what the answer is when a run has quoted it; we will not
describe how their product behaves from memory.

## What we ask of you

**Tell your client what is not settled.** Two things are, as of 25 October
2026, and a reviewer will find both:

- the terms of service are a **draft** and say so on the page
- we hold **no certification of our own** — no SOC 2, no ISO

**Never present any of those as done.** The first finding of our own register
test was a borrowed certification — a supplier's standing, read as though it
covered the company — and it was the first thing a procurement team would have
asked about. We are not going to be the company that does it on a partner call.

## Where to send a reviewer

- `/get-an-ai-agent-approved-by-legal.html` — the five questions a reviewer
  asks, and what to have ready for each
- `/trust.html` — what we hold, where it lives, who can reach it, and draft
  answers to the usual security questionnaire
- `/privacy.md` — the full account, including the supplier table

Those are the one copy of each of those answers. If something here disagrees
with one of them, they are right and this is stale.