Every client is handed one of these at launch. This is ours — the same document, about us, including the bits we would rather were different.
The legal version is the privacy policy. This is the operational one: table by table, who can read it, and how long it lives.
Enquiries and leads
leads · lead_notes · lead_events · lead_messages
What
Your name, email, the business you described, and whatever you wrote in the form. Alongside it: the emails we have sent you, our internal notes, and a timestamped record of how the enquiry moved.
Why
To answer you, to follow up, and to be able to say honestly how long you waited — the response time we publish is measured from these rows rather than asserted.
Who can see it
Ali, and anyone on the allowlist for the internal portal. Two addresses today. Not readable by the public site, by clients, or by any signed-in account outside that list.
How long
Kept while the enquiry is live and for two years after, so a conversation resumed next year still has its history. Ask and it is deleted sooner.
Personal information
Yes — name, email, and anything you chose to write.
Operations Audit answers
audit_submissions
What
Your six answers, the score they produced, and the leaks the scoring identified.
Why
To email you the results and matching playbooks, and — in aggregate, across everyone — to see which problem the market keeps arriving with.
Who can see it
Same as enquiries.
How long
Two years.
Personal information
Your email. The answers describe your operation, not any individual.
Scope builder
scope_requests
What
The modules and problems you selected, the timeline shown, and your email if you gave one.
Why
To come back with a written scope, and to learn which modules people actually want.
Who can see it
Same as enquiries.
How long
Two years.
Personal information
Your email, if you provided one. The scope itself is not personal.
The AI receptionist
chat_conversations · chat_messages
What
The full transcript of anything typed into the chat widget, and a one-way hash of the IP address it came from.
Why
Transcripts so a conversation can be picked up by a person and so we can see where the agent answers badly. The hash exists only to stop one source flooding a paid endpoint.
Who can see it
Same as enquiries.
How long
Transcripts for one year. The hash cannot be reversed to an address at any point.
Personal information
Only what you typed. We never ask for identifying details in chat, and the IP is hashed rather than stored.
Playbook list
newsletter_subscribers
What
Your email and the page you subscribed from.
Why
To send the playbooks.
Who can see it
Same as enquiries.
How long
Until you unsubscribe. The row is then kept with an opt-out timestamp rather than deleted, so we can prove the opt-out happened and never mail you by accident.
The engagement, who can sign in to see it, the numbers the build is measured against, progress notes, and links to handover documents.
Why
So a client can see where their system stands without asking, and so the before-and-after report is continuous rather than a one-off attachment.
Who can see it
The client's own signed-in users see only their own engagement, and Ali. Every query is scoped to the signed-in address's client — there is no shared view.
How long
For the life of the engagement and two years after, so a former client can still retrieve their handover material.
Personal information
The names and work emails of the people who sign in.
Client system events
client_events · client_api_keys
What
Timestamped events reported by a client's own system — a lead arrived, a lead was answered, a booking was made — plus an opaque reference that means something only inside their system.
Why
To compute their response times and volumes without anyone typing numbers into a form.
Who can see it
The client, and Ali.
How long
Two years.
Personal information
None, by design. The endpoint accepts four fields and ignores everything else, and the table refuses anything outside them. No names, numbers, or message content from a client's own customers ever reaches this database.
Where it physically is.
Database
Supabase (PostgreSQL), hosted on AWS in the United States. Supabase does offer a Canadian region and we have not moved to it yet — see the note below.
Email
Resend, with delivery through Amazon SES in us-east-1. Our mailboxes themselves are with Hostinger.
Hosting
Vercel, serving from its Montreal edge for Canadian visitors.
AI
Anthropic's API. Conversations are processed to generate a reply and are not used to train models.
Where we do not yet meet our own standard
We say “Canadian data residency where available” on this site, and for our own database that is currently a gap rather than a claim: it runs in a US region. It is listed here rather than left out. Client systems we build are configured for Canadian residency where the underlying tool offers it, and the data map you receive at launch states the answer for each tool by name.
What holds across all of it.
·No public table can be read by anyone who is not signed in and on an allowlist. Row-level security is on across every table, and the four that accept form submissions can accept an insert and nothing else — they cannot be read back.
·The chat endpoint hashes the caller's IP rather than storing it, and no other visitor tracking runs on this site.
·Client system events carry no personal information at all, and the endpoint drops any field it does not expect rather than storing it.
·Every automated email says it is automated. The AI never claims to be a person.
·Ask us to delete anything about you and we will, and confirm when it is done.
Something here look wrong, or want your data removed? hello@axrategy.com — a person reads it, and we will confirm when it is done.