Trust
The reasonable fear about putting an AI in front of your patients is that it will confidently say something you never said. This page is about how that is prevented, and about what is not finished yet.
It answers from your knowledge base and nothing else
The assistant is given your treatment menu, your opening hours, your team and your policies. It is not given general knowledge about aesthetics to fall back on, and it is instructed that a blank field means it does not know.
Where something is unrecorded, the assistant is shown an explicit list of what it does not know for that treatment, under an instruction not to guess. The absence is described to it rather than left to be inferred from silence — that difference is most of the reason it defers instead of improvising.
Two things it can never be allowed to do
Medical advice and candidacy — whether a treatment is right for a particular person — is always routed to a consultation. Handing off to a human is always available; a patient can ask for your team at any point.
Neither is a setting. There is no column in the database that could turn them off and no screen that offers to. The portal shows both as Locked rather than hiding them, because a clinician deserves to see the guardrail rather than take it on faith.
It will not invent a price
A practice that has chosen not to publish prices gets an assistant that says so and offers a consultation. A treatment priced per unit with no published figure is described exactly that way. Neither is treated as missing data to be filled in with a plausible number.
A blank is never turned into an answer
Every field the assistant reads is stored so that “nobody has told us” is a distinct value from “no”. If nobody has recorded whether a treatment is suitable during pregnancy, the assistant says it will check — it does not say yes, and it does not say no. The database columns are deliberately nullable with no defaults so that this distinction survives all the way to what a patient reads.
Separation between practices
Enforced by 111 row-level security policies in the database rather than by application code. Every query asks for all rows and the database returns only yours. A mistake in our application cannot leak another practice’s data, because the application is not what is enforcing the boundary.
Patient data needs a second factor
Conversations, messages and patient records return nothing at all to a staff account that has not signed in with an authenticator. That is a restrictive policy in the database, so it applies to every query the product makes, including ours.
How this is verified
The codebase carries an automated suite that runs on every change. It includes deliberate self-checks — tests that break the system on purpose to prove the tests would notice. That matters because the failure we take most seriously is not a broken check but a check that quietly stops testing anything and keeps reporting success.
What is not finished
Being straight about the gaps is worth more than a longer list of claims.
- No third-party audit. No SOC 2, no HITRUST, no ISO 27001, no commissioned penetration test. HIPAA itself has no certification scheme, so nobody can hold one.
- Revenue attribution is not built. The portal can show you what was asked and what the assistant offered. It cannot yet tell you what a conversation was worth, and where a figure is unavailable it says so rather than showing zero.
- Booking is a handoff, not an integration. The assistant offers to book and sends the patient to your existing booking link. It does not write into your practice management system.
- Onboarding is manual. There is no self-serve signup. Every practice is provisioned by hand, which is slower and is how the paperwork stays ahead of the data.
Reporting something
To be completed before launch: a security contact address and a stated response window for vulnerability reports. Publishing a channel we are not yet staffed to answer would be worse than publishing none.