Privacy & Trust

Trust Centre · Last updated: 2026-10-31

Mental-health software is full of claims nobody ever checks. This page is the opposite: a single place that states plainly what Healing Space UK has, what it does not yet have, and where the evidence lives. If we cannot support a claim, we do not make it — and the application's build fails if unsupported claims appear on these pages.

Privacy, as something to earn

Vulnerability is not a commodity. The version of privacy worth having is not a promise in marketing copy — it is what the architecture actually enforces, and what we are prepared to be held to:

• Therapeutic continuity without surveillance. Knowing is not monitoring, monitoring is not sharing, and sharing is not acting. Healing Space may keep some context so a later conversation does not start from nothing; that does not, by itself, turn it into a tracked metric, send it to a clinician, set off an alert or prompt an intervention. Remembered context is in the patient's own words, visible to them, and theirs to correct or remove.
• Private by default. Shared deliberately. Reflections, notes, check-ins, mood and sleep records and questionnaire answers stay private to the patient. Nothing reaches a clinician until the patient approves a briefing for a session, in their own words and order; the clinician can read it from two hours before the appointment, enforced on the server. No alert or notification is raised by anything a patient writes or answers.
• The conversation is not a clinician feed. No clinician surface shows the patient's conversation, the context remembered from it, or the support priorities they have written. There is no exception: nothing from the conversation is passed to a clinician by alert or notification.
• No data farming. No advertising against therapeutic data, no sale of it to advertisers, insurers or data brokers, and no revenue anywhere that depends on how long someone stays in the app. The intended model is that services pay a per-clinician licence and patients never pay.
• No casual staff access. Access runs through one central authorisation policy across every patient route, developers hold no standing access to clinical data, and sensitive clinician views of a record, such as Session Prep, are logged.
• Data minimisation. For a conversation reply the AI provider receives the patient's message, the last few turns of that conversation, their first name, short excerpts from their remembered context that relate to what they are talking about now (the same excerpts the patient can see), the support priorities they wrote, and their clinician's shared summary and agreed actions from the last session. The application never adds their surname, date of birth, contact details, NHS number, address or account identifiers, and the raw conditions field is never sent.
• Named processors, not vague reassurance. They are listed below and in the privacy policy.
• The direction of travel. We intend to move more processing to local or Healing-Space-controlled infrastructure where that is feasible. That is an intention, not a current capability, and it is listed here as one.

What we will not tell you: that nobody except you and your clinician can ever access your data. Hosting, email delivery and the AI conversation involve third-party infrastructure, staff with operational access exist in any real system, and a sentence that ignores both would be marketing rather than truth. What we will tell you is exactly who those parties are, what they see, and what is done to keep that set as small as possible.

Who processes what

The privacy policy sets out lawful bases, retention and your rights, including how to make a subject access request or ask for erasure.

Where AI is, and what governs it

• It is not a therapist and not a companion product. A language model powers a supportive conversation informed by CBT principles. It does not diagnose, does not prescribe, does not treat, and is not a crisis service.
• The continuity record is computed, not generated. Session intervals, counts, dates, comparisons between two points in time and the Therapeutic Memory and Session Prep surfaces are retrieval and calculation over what was recorded — not model output. Deterministic code is used wherever a model is not needed.
• Support is offered with restraint. The conversation may point to one of five patient-led supports (guided breathing, urge surfing, sleep hygiene, activity scheduling, gratitude), chosen only from a list the application builds for that turn. It makes no unprompted offer on the opening turn, never two in a row, holds back after a decline, and offers nothing when a crisis phrase is present. Mood check-in is reachable by hand and is never offered. Opening a support records only that it was opened.
• A model may propose; the application decides; the patient confirms. Where a conversation contains something the patient clearly stated — a mood rating, hours slept, an item for the next session — it can be offered back as a suggestion. Deterministic application logic validates it against the patient's own message (a mood value must be a rating they actually gave; hours must be hours they actually stated; an agenda item is a verbatim excerpt of their own words), and nothing is written until the patient confirms it. Inferred, rounded or rephrased values are discarded, and an agenda item keeps the patient's wording rather than being rewritten into clinical language.
• No automated decision is made about anyone's care. Where a model drafts anything for a clinician it is advisory and requires their review before any clinical use.
• We do not interpret your history. The platform helps patient and clinician revisit the record. It does not diagnose, infer causation, judge whether therapy is working, or decide that separate experiences are the same recurring issue.

Voice: built, being evaluated, not switched on in production

Talk runs through a voice service Healing Space operates itself, hosted in the EU. The patient's device sends audio to that service, which detects when they have finished speaking (Silero voice-activity detection), transcribes the turn (NVIDIA Parakeet, running inside the service), and returns the text. Audio is held in memory only and discarded; it is never written to disk or logged. The application never receives audio — only the text of a completed turn, which then goes through exactly the same governed path as typed text. No outside speech provider is used, and there is no fallback to one. The browser's own speech recognition is not used.

Current status: the voice pathway has been built and tested in an evaluation environment and is still being evaluated. It is not switched on for patients: where Talk appears, it tells the patient it is unavailable and offers Type. We will not describe voice as generally available until it is.

What we will never pretend

• This is not an emergency service. Nobody is watching a screen waiting for you, and there is no continuous clinical monitoring. If you are in danger: 999, Samaritans 116 123, or text SHOUT to 85258.
• It is not therapy and not a therapist. It is designed to work alongside a clinician — never instead of one.
• Screening is not diagnosis. PHQ-9, GAD-7, CORE-10 and the other questionnaires are implemented as screening support; a score is a conversation prompt, never a label.
• No crisis monitoring and no alerts. Healing Space does not monitor conversations or questionnaire answers for risk, and nothing a patient says or does alerts or notifies their clinician or anyone else. If someone talks about being in danger, the AI points them to real-world help such as 999, Samaritans or someone they trust. That is all it does.
• It is not an EHR. It is a lightweight continuity layer around existing clinical work, not a replacement for a records or practice-management system.
• We have no outcome evidence. We have not shown that preserving therapeutic context improves therapy, and we do not claim it. Healing Space is in early-stage evaluation preparation: we are demonstrating it, with synthetic data only, to clinicians, researchers and people who evaluate health technology, and seeking evaluation partners. No clinical pilot is running. Those are conversations about evaluation, not endorsements, approvals or partnerships, and no organisation or individual is named here for credibility.

External assurance status

None of the following has been obtained yet. Each is on the roadmap, and we will state it here the day it changes — not one day before.

Engineering controls we have built

These are implemented and tested by us. Implemented means the control exists and our automated tests exercise it — it does not mean independently verified, and we do not claim that it does.

• Every state-changing API route carries an authorisation guard, verified by a generated route matrix that fails our build if a route regresses.
• A public-claims gate: our build fails if prohibited claims (e.g. "NHS-approved", "clinically validated") appear on public pages — including this one.
• Automated accessibility (axe-core, WCAG 2.1 A/AA rules) scans of core pages in a real browser on every change; we design against WCAG 2.1 AA but do not claim conformance until independently audited.
• Session-bound CSRF protection, strict security headers, rate limiting on sensitive and expensive endpoints, and audit logging of accountable actions.
• Sensitive fields encrypted at rest where applied (Fernet/AES-128-CBC); all traffic encrypted in transit (TLS).
• No alerting path: no conversation, questionnaire answer or use of the SOS button creates an alert, a notification or an email to a clinician. The earlier crisis system — safety checks, safety plans, risk scores, alerts and escalation — was removed on 30 October 2026; the few internal remnants are switched off and scheduled for removal, and our tests check that nothing raises an alert.
• Honest statements: nothing in Healing Space says or implies that a clinician has been notified, that anyone is watching, or that help is on its way.
• Attributable records: entries keep their date and author, and the original stays reachable behind every line of Session Prep; nothing a patient writes reaches a clinician except the briefing they approve, released two hours before the session.
• Governed capability suggestion: the model can name a support only by an identifier the server gave it for that turn, the server checks the answer against the same list, and the model never receives a route or anything executable. Support priorities have no clinician reader, scheduler or notification path.
• Governed capture from conversation: model output is treated as untrusted. A proposal is accepted only if deterministic validation finds the value in the patient's own message, is written only on the patient's explicit confirmation, and leaves a private provenance record on the patient's side — it is not a clinician route back into the conversation.
• A differential privacy harness: each clinician-facing surface it covers is rendered, undisclosed patient data is inserted, the surface is re-rendered, and the test asserts nothing changed — with guards proving the test can detect change when there is some.
• No third-party scripts, fonts or trackers load on any page — no analytics, no advertising, no data sale.

Documents

• Privacy policy (draft — awaiting sign-off)
• Terms of service (draft — awaiting sign-off)
• Cookies & local storage (draft — awaiting sign-off)
• Accessibility statement

Talking to us

If you are a therapist, a service, a researcher or an evaluator and would like to see this working — including to tell us the premise is wrong, or to discuss an evaluation or pilot — you can book a walkthrough or write to cs@healing-space.org.uk. For research or academic collaboration: research@healing-space.org.uk.

Reporting a security concern

Please report vulnerabilities privately to dev-team@healing-space.org.uk with "SECURITY" in the subject line. Do not open public issues for security or patient-data concerns. We will acknowledge your report and keep you informed.