Privacy Policy

Draft · Last updated 4 October 2026 · Applies to https://app.adaptiwise.com

What personal information Adaptiwise AI collects, why it collects it, who else touches it, how long it is kept, and how to see or erase it.

Draft - a lawyer has not settled this document. It is published because the alternative is worse: under PIPEDA the purposes have to be stated and the policy has to be reachable, and a messaging carrier will not review a program that has neither. Every clause below describes Adaptiwise AI as it is actually built. The terms the operator had to choose - who we are, the governing law, the liability cap and who answers privacy and security questions - were chosen by the operator, not settled by a lawyer. The clauses about health information are the ones that most need a lawyer, and have not had one.

1What this covers, and who is accountable for what

Adaptiwise AI runs bookings, customer records, messaging and payments for small businesses and clinics at app.adaptiwise.com. Personal information reaches it by two different routes, and different organisations are accountable for each. Which one you are decides which paragraphs below are about you.

Your Adaptiwise AI account: The operator of this deployment is accountable for it: your name, email address, the hash of your password, your sessions and which workspaces you belong to. That is a direct relationship between you and us.
A business's customer records: The business is accountable for the people in its own records. Adaptiwise AI handles them as that business’s service provider, on its instructions, to run the service it is paying for - and for nothing else.
A clinic’s clinical records: The clinic is the health-information custodian for its patients. Adaptiwise AI is its service provider. If you are a patient asking about your chart, the clinic is the organisation that answers, and section 10 says how we help them do it.

2What is collected, and why

PIPEDA requires the purpose to be stated before the collection, so here it is, category by category. Nothing below is collected for advertising, and none of it is sold.

Account and sign-in: Name, email address, a hash of your password (never the password), and for each session its expiry, the address it was created from and the browser that created it. Purpose: to let you in, to keep other people out, and to let you see and end your own sessions.
The business itself: Business name, locations, addresses, opening hours, services, prices, staff members and their working hours. Purpose: to draw the booking page and decide what can be booked when.
Customers and bookings: Name, email address, phone number, appointment times, the service booked, notes the business records, intake answers the business asks for, and which of the consents below were given. Purpose: to take the booking, to keep the business’s record of it, and to send the messages about it.
Clinical information, where a clinic records it: Visit notes and, where the clinic asks for it, a personal health number. Purpose: the clinic’s own record of care. It is visible only to people the clinic has given the clinical-notes permission, and it is never used for anything else. See section 11.
Payments: Amount, currency, status, the processor’s reference, and what kind of payment it was. Card numbers are never collected - see section 5.
Messages: What was sent, to which channel, when, and what the provider said happened to it. Purpose: so a business can prove what a customer was told, and so a failed reminder can be seen rather than assumed.
Technical records: Server logs with a request id, the route, the status and the timing; rate-limit counters keyed on the requesting address, and - for somebody signed in to a business console - on their account rather than their address, so that one person going too fast does not slow their colleagues down; and an audit trail of who changed what. Message bodies are not logged, and monitoring metrics deliberately carry no identifier for a person - not an email address, not a phone number, not a booking link.

4Text messages and email

Messages are sent by Adaptiwise AI on behalf of the business you booked with, and carry that business’s name.
STOP stops them. It suppresses that channel for you immediately, cancels reminders already queued for you, and every later message on that channel is refused and recorded rather than sent. HELP is answered by the carrier.
Text messages that are not about an appointment already made are held between 21:00 and 08:00 in the location’s own timezone and sent when that window closes.
Standard message and data rates may apply.

5Payments and card details

No card number ever reaches Adaptiwise AI. The browser exchanges the card with the processor and hands us a token that stands for it; the token is what is charged. We keep the amount, the currency, the outcome and the processor’s reference, so a business can reconcile its takings and issue a refund.

When the deployment is in sandbox mode there is no processor, no card and no charge - the amounts on screen are simulated, and are labelled as simulated.

6Cookies, storage and tracking

One cookie: the session cookie that keeps you signed in. It is HttpOnly, Secure and SameSite=Lax. Unless you ask to be remembered on the device, your browser holds it only until the browser closes and never writes it to disk; if you do ask, it is written with the session’s own expiry, which is at most twelve hours after signing in. Signing out clears it.
The console remembers which workspace you last used in your browser’s local storage. It never leaves your browser except as the workspace identifier on your own requests.
There are no advertising cookies, no third-party analytics and no tracking pixels. The pages carry a content-security policy that forbids loading anything from another origin at all, so there is nothing on them that could report to one.
That is also why there is no cookie banner: there is no non-essential cookie to ask you about.

7Service providers

Adaptiwise AI uses a small, fixed set of providers, and no others. Each row says what the provider is for, what reaches it, and where it is processed. Most of them receive nothing at all until this deployment is configured for them, and the row says which ones and what turns them on.

Everything below that carries a message, a charge, a review or a model request is switched off by sandbox mode, which is how this deployment runs today: the work is simulated inside the system and no packet leaves the server. The one provider that is not conditional on anything is the hosting, because the server has to be somewhere.

Twilio: Text messages: appointment confirmations and reminders, waitlist offers, and the code that verifies a phone number. The recipient’s phone number, the text of the message, and what the carrier reported back about delivering it. Processed in the United States. Nothing reaches Twilio while the deployment runs its messaging in sandbox mode, which is how it runs today: the message is recorded as sent and no packet leaves the server.
Resend: Email: booking confirmations and reminders, receipts, password-reset links and account notices. The recipient’s email address, the subject, the body, and whether the message was delivered, bounced or was reported as spam. Processed in the United States. Nothing reaches Resend while the deployment runs its messaging in sandbox mode, which is how it runs today.
Stripe: Card payments: the deposits and prepayments a business takes through its booking page, and that business’s own subscription to Adaptiwise AI. The card details, which travel from the payer’s browser to Stripe and never reach Adaptiwise AI, together with the amount, the currency and a reference for the booking. For a subscription, the account holder’s email address and billing details. Processed in the United States. In sandbox mode no card is charged and no money moves.
Google (sign-in): Signing in to the console with a Google account, where a business chooses to. Google tells us the name, email address and a stable account identifier for the person signing in. We send Google nothing about a business’s customers. Processed in the United States and wherever else Google operates. Only on a deployment that has been given a Google client. Without one the button is not shown and no request is made.
Google (address lookup): Suggesting and checking a business address as somebody types it in the console. The partial address being typed. It is a business’s own address, typed by its own staff; no customer address is sent. Processed in the United States and wherever else Google operates. Only on a deployment that has been given a Places key. Without one the address field is an ordinary text box.
Google (Business Profile): Reading the reviews a business has already received on its own Google listing, so they can be seen in the console. We read from Google rather than writing to it. What is sent is the business’s own listing identity; what comes back is a review and its author’s name as Google already publishes them. Processed in the United States and wherever else Google operates. Only on a deployment whose owner has connected a Google Business Profile.
OVHcloud (the server): Hosting. The application and its database run on one OVHcloud virtual server. Everything the product holds sits on that machine. OVHcloud does not process any of it; it hosts the machine it sits on. Processed in Canada (Beauharnois, Quebec).
OVHcloud (backups, Toronto): Holding the off-box backups of the database, away from the server that made them. A complete copy of the database - but encrypted on the server before it is uploaded, so what OVHcloud holds is ciphertext it has no key for. Processed in Canada (Toronto). Only once the operator has installed the backup job. Until then the only copy of the database is on the server itself, which is a different risk and not a smaller one.
Anthropic: The language model behind the AI assistant features. Whatever is in the conversation the assistant is asked to work on, which can include a customer’s name and what they wrote. Processed in the United States. Nothing in the booking product sends a model request: reminders, deposits, availability, the public booking page and the console’s own screens never reach it. Only the assistant does, and only on a deployment that has been given a key and has recorded a signed data-processing agreement with Anthropic; without the agreement no request is sent, whatever else is configured.
ntfy.sh (error reports): Where a crash or a server error is announced, so that somebody finds out rather than the fault sitting in a log nobody is reading. Reports go to a private topic whose long random name is the only key to it, and arrive on the operator’s phone. A stack trace. Email addresses, phone numbers, card-shaped runs of digits, session cookies, tokens and database passwords are removed before it leaves the server - which is best-effort, because scrubbing free text always is. ntfy.sh keeps a message for 12 hours and does not log its content, by its own privacy policy. Processed in the United States (a DigitalOcean server in the New York area). Announced on 1 October 2026 and switched on no earlier than 31 October 2026, after the notice below. Until then nothing is sent and faults are written to the server’s own log only.
Healthchecks.io (uptime and scheduled-job monitoring): Raising an alarm when the server’s own minute-by-minute health check stops reporting or reports a fault, and when a scheduled job stops running. The public address of this deployment, whether a check passed, and the alert sentence, which names a condition such as a stalled worker and never a person. No personal information is involved, which is why the row is short rather than because it is vague. Processed in the European Union (a Hetzner data centre in Falkenstein, Germany). Operated by SIA Monkey See Monkey Do in Latvia. This deployment has reported to it since 30 September 2026.

A new provider is announced 30 days before it receives anything. This list changes first, the change is recorded below with its date, account holders are told, and only then is the provider switched on. That order is the commitment: a business writes its own privacy notice from this list, and a vendor appearing without warning is that business finding out its notice has been wrong for a while. The same promise is in the Terms of Service. Every change to the list so far:

1 October 2026: Two empty slots named. The uptime monitor is Healthchecks.io (SIA Monkey See Monkey Do, Latvia; servers in Germany). It has received this deployment’s health-check results since 30 September 2026 and this list should have said so that day; it receives no personal information - the site’s address, whether a check passed, and alert sentences that name conditions, never people. Error reports will go to ntfy.sh (ntfy LLC, United States). It is announced today and switched on no earlier than 31 October 2026, after the 30-day notice; until then error reports stay in the server’s own log.
19 September 2026: Corrected and completed. The email vendor is Resend, not Postmark: Postmark was the first adapter written and was never the account this deployment holds, so the previous list named a company that has never had anything. Google was added three times over, because signing in, looking up an address and reading a business’s own reviews are three different disclosures. Anthropic, the Toronto backup storage, the error-report destination and the uptime vendor were added. No vendor began receiving anything because of this change - the list was wrong, and this is the correction.
24 August 2026: First published, with four names: Twilio, Postmark, Stripe and OVHcloud.

8Where the data is held

The application and its database run on a single OVHcloud virtual server in Canada. Every connection to it is over TLS. Each workspace’s rows are separated in the database itself by row-level security, so a request scoped to one business cannot read another’s even if the application asks it to.

The providers listed under Service providers above are not all in Canada, and each row names the country rather than leaving it to be assumed. Information handed to a provider outside Canada - for a text message, an email, a card payment or a model request - is processed there and is subject to the law of that place, which can include lawful access by a foreign government. The off-box backups go the other way: where they are switched on they stay in Canada, in a different city from the server, and they are encrypted before they leave the machine that made them.

9How long it is kept

Business records - customers, bookings, notes, payments - are kept until the business deletes them or asks for them to be erased. Nothing in this product deletes a chart, a visit or a payment record on a timer, and this policy will not pretend there is a schedule over them. A clinic has its own retention obligations, and deciding them is the clinic’s. Where a clinic has recorded its own periods with us, they are a statement of what that clinic keeps and why - not an instruction to this product to delete anything, because it deletes none of it.
The wording of a message does expire, and that is the one thing here that does. Past a period set for each business - a year unless it is changed for that business, never under thirty days and never over ten years - the text of a reminder we sent, its subject, the address it went to, and the text of a reply sent back are all replaced with a marker. What is kept is the record that it happened: which customer, which channel, which direction, the outcome and the times. A daily housekeeping pass does the replacing, so the text goes within about a day of the period being reached. The period can only be changed by the operator of this deployment; there is no screen for it, so it is the default year unless a business has asked for something else. An internal note a staff member filed is not a message and is never touched by this, and neither is the record of an opt-out or of a consent - those are the proof that an instruction was given, and redacting them would destroy the only evidence of it.
Sessions end twelve hours after they are created, or after thirty minutes of not being used, whichever comes first. A session past either bound stops working at once and the row is deleted by housekeeping, so what it carried - the address and the browser it was used from - does not sit there afterwards.
Short-lived operational records - a held booking slot, the key that stops a retried payment charging twice - expire on their own within hours.
The audit trail of who changed what, and the record that a message was sent, to which customer and with what outcome, are retained: they are the evidence a business needs about its own actions. What the message SAID is on the timer above; the fact of it is not.

10Seeing, correcting and erasing your information

Ask the business you booked with. They hold the record and they are the organisation accountable for it, so a request to see, correct or erase it starts with them - and there is no separate Adaptiwise AI portal to sign into instead.

The business can produce everything held about one person - visits, messages, notes, intake answers and consents - as a single export, from the console.
The business can correct any of it in place.
The business can act on an erasure request, which redacts the identifying fields rather than merely hiding the record.
If you cannot reach the business, or you are asking about your own Adaptiwise AI account rather than a booking, write to info@adaptiwise.com and we will answer within thirty days.

Some things cannot be erased on request, and we would rather say so here than in a reply: an opt-out record (erasing it would erase your instruction not to be contacted), and records a business is required by law to keep, such as payment and clinical records within their retention period.

11Health information

Where a clinic uses Adaptiwise AI, the clinic is the health-information custodian and Adaptiwise AI is its service provider. We handle visit notes and personal health numbers only to provide the service to that clinic. We do not use them for anything else, and we do not disclose them to anyone outside the clinic’s own workspace.

Clinical fields are separated per business by row-level security, and reading them requires a clinical-notes permission the clinic grants explicitly, person by person.
A clinical note, its earlier versions, an intake answer, a personal health number and an insurance note are stored encrypted, with the key held outside the database - so a stolen copy of the database is not by itself a disclosure of them. The rest of a record, including a name, an email address and a phone number, is not: the search, the duplicate check and the matching of a reply to the person who sent it are all built on those fields.
Reading a chart is written to the audit trail, and so is every change to one: who opened it, whose record it was, when, and through which screen. A clinic can ask who has been in a patient’s record and be answered.
Where a clinic records a personal health number or asks a clinical question when somebody books, it has to be agreed to first: a separate consent, in plain words, readable before it is accepted, and kept with the record of when it was given.

12How it is protected

TLS on every connection between a browser and this service. The application and its database run on one machine and talk to each other over a private network on that machine, not over the internet.
Passwords are stored as hashes and are never recoverable, by us or by anybody else.
Anybody signing in can turn on a second factor: a six-digit code from an authenticator app, with eight printed recovery codes for a lost phone. The secret it is built from is encrypted in our database.
A clinic can require it of anybody who can open a customer record. While that is on, those staff cannot use the product until they have turned it on. It is off unless the business switches it on, and staff who never see a clinical note are not affected by it.
A session lasts at most twelve hours, and ends after thirty minutes of not being used, so a browser left open on a shared front-desk machine does not stay signed in. Both bounds are applied on every request, so neither can be extended by the browser holding the cookie for longer.
Each workspace is separated in the database by row-level security rather than by application code remembering to filter.
Every screen and every route is behind a permission the business grants, and a request for another workspace’s data is answered as though the data did not exist.
The product pages load nothing from another origin - no fonts, no scripts, no analytics - which removes the most common way a page leaks who is reading it.
Secrets live in the deployment’s environment, never in the code and never in a page.

No system is perfectly secure, and this one is young. Section 14 says what happens when something goes wrong.

13Children

Adaptiwise AI is sold to businesses and is not directed at children. A business may hold a record about a minor - a clinic treating one, for instance - on the basis its own professional obligations require, including a parent’s or guardian’s consent. That is the business’s decision and its responsibility, not something the software collects on its own.

14If something goes wrong

We contain it first, and find out what was reachable.
We tell the affected businesses without undue delay, with what we know and what we do not.
Where a breach creates a real risk of significant harm, PIPEDA requires a report to the Office of the Privacy Commissioner of Canada and notice to the people affected. We support the accountable business in doing that, and where the account is directly ours we do it.
A record of the breach is kept - of every breach of security safeguards, including one judged not to create that risk, for twenty-four months, which is what PIPEDA requires whether or not anything is reported.

The full procedure is on the Security page: who decides that something is reportable, the clocks we work to, which duty is ours and which belongs to the clinic that holds the record, and where a copy of your information can still be after the original is gone. That page is also how to report a security problem to us.

15Changes to this policy

When the product changes what it collects, who touches it or how long it is kept, this page changes and the date at the top moves with it. A change that materially affects an account holder is notified to the account holder rather than left to be found here.

16Questions and complaints

Adaptiwise AI is operated by Adaptiwise AI Inc., of Vancouver, British Columbia, Canada. Privacy questions about your own Adaptiwise AI account go to the Privacy Officer at info@adaptiwise.com. Questions about a booking or a clinical record go to the business you booked with, which holds it.

A security problem is different and has its own address: a way into data that should not be open, or a reason to think somebody has already been in it, goes to info@adaptiwise.com - see the Security page. Do not put anybody’s personal or health information in that email; a description is enough.

If a Canadian organisation has not answered you properly, you can complain to a privacy commissioner, free of charge. Which commissioner depends on where the business that holds the record operates, and on whether the record is a health record - British Columbia, Alberta and Québec each have their own private-sector privacy law and their own commissioner, Ontario has one for health records specifically, and everything else - including any complaint about Adaptiwise AI itself rather than about a business using it - goes to the federal commissioner. You do not have to work that out before you write: a commissioner who is not the right one will tell you who is.

Canada (federal): Office of the Privacy Commissioner of Canada - priv.gc.ca. The default, and the one for a complaint about us.
British Columbia: Office of the Information and Privacy Commissioner for British Columbia (OIPC BC) - oipc.bc.ca.
Alberta: Office of the Information and Privacy Commissioner of Alberta (OIPC Alberta) - oipc.ab.ca.
Ontario: Information and Privacy Commissioner of Ontario (IPC), for a health record held by a clinic - ipc.on.ca.
Québec: Commission d’accès à l’information du Québec (CAI) - cai.gouv.qc.ca.

The terms of the service itself are in the Terms of Service.