Privacy Policy

Last updated 6 September 2026

What we hold

For each identity: a name, an email address, the roles held, and the tenancy. Optionally a mobile number, where one has been given for notices that ride SMS. Where a person was invited from another organisation, which organisation that is and on what basis they hold access here. Nothing else about a person is asked for.

Security records accumulate against an identity because they are what protects it: the devices a sign-in has come from, any passkey or authenticator enrolled, the risk assessment that decided whether to challenge, and a count of failed attempts. Whoever pays also has the card reference described under sub-processors — never the card number.

What the record contains about people

Every event names its actor, because an audit record that cannot say who did something is not an audit record. That attribution is the point of the system and cannot be switched off. It is visible to those in your tenancy whose role permits it, and to nobody outside it.

Communication

The platform delivers by email and in the console. SMS, push and WhatsApp are in the notification catalogue and have no carrier behind them on this deployment: a notice routed to one of those is recorded as dispatched and not transmitted, and you can see that on your own delivery record rather than having to infer it from silence. Most of what is sent is subject to your preferences, which you set per category and per channel. A defined set of notices is not: security events, payment failures, compliance breaches, and data-protection notices such as a deletion request. You are entitled to be told your account was locked whatever you have muted, and a preference control that could suppress that would be a control that harms you.

Marketing mail is separate and consent-based, with a working unsubscribe on every message and a permanent withdrawal until you re-subscribe. Mandatory notices carry no unsubscribe link, because an unsubscribe that cannot work is worse than none.

What we do not do

• We do not sell personal data, and we do not share it with advertisers.
• We do not train models on your project data.
• We do not use geolocation to decide what language to show you — that asks where somebody is standing to answer what they read, and is wrong for every expatriate engineer on a project.
• We do not send project figures by email. The weekly issue is role-targeted, not data-personalised, because a message leaves the platform's access controls behind the moment it is sent.

Your rights

You can request an export of the personal data we hold about you, and its deletion. Deletion of an identity removes the person's contact details and credentials. It does not rewrite the event chain, because doing so would destroy the integrity of a record other parties rely on — the events retain an actor reference, and the person behind it is no longer resolvable.

Sub-processors

Email is delivered through an SMTP relay you can see named in your own delivery log. AI actions are executed by the provider recorded on the event, with the model class and cost. Every channel that has no provider configured records as dispatched-not-transmitted rather than as delivered.

Depending on how a deployment is configured, these others may also receive data. Each is listed with what it receives, because a list naming two of nine is not a disclosure:

• Payment processor. Card details are entered on the processor's own page and never reach us. What we keep is the customer and payment-method reference, the card brand, its last four digits and its expiry, so a subscription can be collected each month and you can see which card it is.
• Object storage. Where configured, evidence is held there, and a copy of the event journal and site media is shipped off the machine on a timer so the record survives the loss of a host.
• File signature scanner. Every uploaded file is streamed to a scanner before anything reads it. A file that could not be scanned is recorded as unscanned rather than treated as clean.
• Shared cache. Where more than one process runs, sign-in failure counts are held centrally so a lockout cannot be escaped by reaching a different replica. It holds counters against an identity, not content.
• Telemetry collector. Where configured, counters, request timings and the security event stream, so a fault can be diagnosed after it has happened.
• Uptime monitor and alert channel. A heartbeat carrying the commit and event count, and alerts naming the on-call person. No project data is in either.

Anything not configured on a deployment receives nothing and is not a sub-processor of it. Which are configured on yours is answerable from the platform rather than from this page.

This document describes how the platform behaves. Where it states a technical guarantee — chaining, redaction, tenancy isolation, notice handling — that behaviour is implemented and tested, and the corresponding test is the thing that keeps this page true.