What we actually do, and what we do not claim.

If you make a good-faith effort to follow this policy while researching, we will treat your research as authorised. We will not pursue legal action against you, and if a third party does, we will make clear that you were acting within this policy.

Please do not do any of the following, because they cause harm rather than demonstrate it:

• Access, modify or delete data belonging to another person. Prove the issue with your own account.
• Run denial-of-service tests, load tests, or automated scanners that generate high volumes of traffic.
• Use social engineering, phishing, or physical attempts against our staff or suppliers.
• Publish details before we have had a chance to fix the issue.

Some things are outside scope because they are not weaknesses we can act on: missing security headers with no demonstrated impact, results from automated scanners without a working proof of concept, reports about software we do not control, and issues that require an attacker to already have physical access to a person's unlocked device.

We do not currently run a paid bug bounty. We would rather tell you that plainly than imply a reward that does not exist.

Every one of our sites is served over HTTPS only. All four send HTTP Strict Transport Security, so a browser that has visited once will refuse to connect over plain HTTP afterwards, even if a link tries to.

The coaching platform and Legacy Builder both enforce a Content Security Policy that names, explicitly, every external origin allowed to run a script, load a font, open a connection or embed a frame. Anything not on that list is blocked by the browser. This is the control that limits the damage of an injected script.

All four sites also send X-Content-Type-Options: nosniff, a referrer policy that withholds the full path from other sites, and a permissions policy that switches off camera, microphone and location by default.

The browser is a suggestion. The server is the authority. Hiding a button in the interface is presentation, not protection, because anyone can type a URL. So every request that returns or changes information belonging to a person is checked on the server, against the person making the request.

In practice that means a query for your messages is constrained by who you are, rather than by an identifier we accepted from your browser. Asking for someone else's record by changing a number in a URL returns nothing.

Access levels are declared in one place and read by both the interface and the API, so the button you can see and the answer the server gives cannot disagree. Sensitive rooms and financial data are restricted to owner accounts, and no invitation can create one.

Invitation links are stored only as a SHA-256 hash, expire, are single-use by default, can be bound to one email address, and can be revoked instantly. Reading our database would not let anyone mint access.

Nothing about price, plan or entitlement is decided in your browser.

These are working features in the coaching platform, not promises to handle a request by hand:

• Export everything we hold about you. A subject access request you can run yourself.
• Delete your account. Erasure is scheduled and carried out; you do not need to email anyone.
• Object to marketing. Objection is enforced at the point of sending, not merely recorded as a preference.
• Opt out without an account. A public endpoint honours the request whether or not you are a member.

Members never receive each other's email addresses. Directory and community screens identify people by a one-way hash of their address, so a member's photo can be shown without publishing how to contact them.

Several parts of our products use AI models: the coaching assistant, the platform guide, and the generation lane inside Legacy Builder. It is worth being precise about what that means for your information.

What is sent. When you use one of these features, the text of your request goes to a model provider so it can answer. In Legacy Builder that is the brief you write about your business. Where a screenshot or recording is supplied as a visual reference, that file goes to the build engine.

What is not sent. Your password is never sent to a model, because we never hold it in a readable form. Payment card details are never sent, because they go directly to our payment processor and we never see the full number.

What we ask of it. Generated pages are instructed never to invent a credential, testimonial, figure or claim you did not supply. That rule is enforced in the prompt and checked afterwards, because a site that invents a statistic about your business is a liability we are handing you.

We do not run our own data centres. Delivering these products means a small number of suppliers necessarily process information on our behalf — hosting, database, payments, transactional email and AI model providers among them.

The categories, and the safeguards that apply when information leaves your region, are set out in our Privacy Policy, section 09, and international transfers in section 11.

We are preparing a named, per-supplier list to publish here, along with the purpose each one serves. We would rather publish that once it is complete and accurate than publish a partial one now.

Security pages tend to imply more than they say. So, plainly:

• We are not SOC 2 certified. We have not undergone a SOC 2 Type I or Type II audit.
• We are not ISO 27001 certified.
• We do not commission annual third-party penetration tests. Our testing is performed internally.
• We do not operate a paid bug bounty programme.

These are the things a much larger company would list, and we will not borrow their credibility by staying vague. What we have instead is a small, closely-held system where the controls described above are real, tested, and written down.

For a security issue, use the address in section 01 — it reaches us fastest.

Machine-readable contact details are published at /.well-known/security.txt, following RFC 9116.