Data map

Everything we store, and where it sits.

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, your phone number if you chose to give one, how soon you said you need something, 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, anything you chose to write, and a phone number if you gave one. The phone field is optional and exists for one reason: this business argues that whoever answers first wins the work, and until recently it had no way to ring anybody back. It is used to call you about your enquiry and for nothing else.
Can we email you: Implied consent under CASL, which your enquiry creates and which runs out six months after it. Recorded on the row rather than assumed — see lib/consent.ts — so a send that reached a lapsed enquiry would be refused rather than merely unlikely. Replying to us starts the six months again.

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.
Can we email you: Implied consent from running the audit, on the same six-month footing as an enquiry. The audit result itself is sent because you asked for it.

Scope builder

scope_requests · proposals

What: The modules and problems you selected in the scope builder, the timeline shown, and your email if you gave one. If we then sent you a written proposal, that too: what we would build, what it connects to, the one number it is judged on, the fixed price, and — if you decided — which way and when.
Why: To come back with a written scope, to learn which modules people actually want, and so that an approval is a record rather than a sentence in somebody's inbox.
Who can see it: Same as enquiries.
How long: Two years. A proposal you approved is kept for the life of the engagement and two years after, because it is the terms you agreed to and you should be able to retrieve them.
Personal information: Your email, and your name if the enquiry carried one. The scope and price describe work, not a person.
Can we email you: Implied consent from requesting the scope. The plan is yours whether or not you go further, and asking for it is not a subscription.

The AI receptionist

chat_conversations · chat_messages

What: The full transcript of anything typed into a chat widget — ours, or one we run on a client's site — and a one-way hash of the IP address it came from. Each conversation records which business it belongs to.
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: Ali, and — for conversations on a client's own site — that client. A client sees their own conversations and no one else's.
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.
Can we email you: Implied consent from the conversation, and only where you gave contact details in it. A conversation with no address attached is never emailed, because there is nowhere to send it.

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.
Personal information: Your email.
Can we email you: Express consent — a deliberate sign-up, which does not expire and ends when you unsubscribe. The link is in every send, and it is one click with no confirmation step.

Client portal

clients · client_users · client_measurements · client_updates · client_documents

What: 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.
Can we email you: Contractual, not consent-based. These are the people we are working for, and the email is about the work rather than marketing.

Client system events

client_events · client_api_keys · client_agents

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. Where we run an intake agent for a client, this also holds its configuration: the business name it answers as, the knowledge base they wrote and approved, their booking link, and the things they have asked it never to discuss.
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 in the events, 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 reaches this table. The agent configuration is about a business rather than a person, and the knowledge base is written by the client for their own public to read.
Can we email you: None needed, and none held. Nothing in this group identifies a person, so there is nobody here to email.

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. Pages and images are served from its Montreal edge to Canadian visitors, but that is delivery, not processing — the functions that receive your enquiry, run the chat, and talk to the database execute in Vercel's Washington DC region. Moving them to Montreal on its own would not change where your data ends up while the database is in a US region, so we have listed it here rather than fixed half of it.
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 systems that is currently a gap rather than a claim. Our database runs in a US region, and the functions that process what you send us run in one too. Both are listed above rather than left out, and they are one decision rather than two — moving either alone would change the map without changing where your data goes. 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. The only other measurement on the public pages is Vercel's own analytics, which sets no cookies, stores no identifier that follows you between visits, and tells us which pages are read — not who read them. It does not run on the client portal or the internal tools at all.
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.