Care software asks a provider to hand over the most sensitive data they hold about the most vulnerable people they serve. The least we can do is publish the terms before you ask for them.
All three are drafts prepared for signature: published so a DPO or commissioner can read them before any conversation, not presented as executed contracts.
The contract between the care provider (controller) and WellDash (processor): what we may do with care data, the security measures we commit to, every sub-processor we use, and what happens to the data when the contract ends.
Read the DPAThe risk assessment the law requires before high-risk processing begins: what the system does with health data about vulnerable adults, the ten risks we identified, what we do about each one, and what risk is left over.
Read the DPIAWhy care data can be structured by AI providers outside the UK without exposing anyone: what actually leaves the country, what the receiving provider can and cannot do with it, and the code-level controls an auditor can check rather than take on trust.
Read the TRAThese documents were written before parts of the system settled. On 12 August 2026 every factual claim in them was re-checked against the running system. Eight claims described a control more strongly than the code implements it. Rather than quietly leave the old wording up, the published pages carry the accurate version and list every change here.
The earlier wording said: No record is saved to the database without a human swipe.
What the system actually does: The AI proposal is written to the person’s record immediately in a pending state so nothing observed is lost, and becomes a confirmed care record only on the carer’s swipe. Pending rows are excluded from care surfaces, the medication register and the analytics.
The earlier wording said: redact=pii is enabled on every Deepgram call.
What the system actually does: A targeted list of identity entity classes is redacted — names, emails, phone numbers, addresses, postcodes, coordinates, usernames, URLs. The broad PII group was dropped in July 2026 because it also destroyed times, dates, durations, ages and occupations, which are clinical content.
The earlier wording said: An edge-runtime, zero-PHI relay with no database connection for health data and no access to the person’s name.
What the system actually does: A Node serverless function that does hold a privileged database connection and does read the person’s stored names — in order to fetch their own care plan, stamp the write, and build the redaction list. What it never does is put any of that into an AI prompt, tool schema or payload.
The earlier wording said: No single server-side component holds both the health observation and the person’s identity.
What the system actually does: No AI sub-processor holds both. Inside our own server, one process necessarily holds both; the enforced boundary is the AI interface, not the server.
The earlier wording said: Output is schema-pinned so invalid tokens cannot be generated.
What the system actually does: The model composes through a function-call interface with the live columns and enumerated values in its prompt; validity is then enforced at write time by server-side schema checks and PostgreSQL ENUM and check constraints. Layered, not absolute.
The earlier wording said: Every committed record’s reasoning inputs are reconstructable.
What the system actually does: The clinical content, target table, lifecycle and human attribution are reconstructable, and proposal decisions are written to an audit log. The model prompt and the model’s reasoning are not retained.
The earlier wording said: Two sub-processors: Deepgram and z.ai.
What the system actually does: Four more are named in DPA Schedule 1B — Supabase, Vercel, Resend and Stripe. They process personal data as ordinary infrastructure and Article 28 requires them to be listed. Email intake in particular carries identified care content and is outside the identity firewall.
The earlier wording said: Access is restricted by role-based access control and row-level security.
What the system actually does: True as of 11–12 August 2026: row-level security is now enabled on every care table and the public browser keys hold no grant and no schema access. Application access is enforced per request by a server-side person-scope check, not by row-level security, because the application connects with a privileged key.
Publishing the pack is not the same as being finished. These are the gaps we know about.
Documents emailed to a per-person intake address reach the email provider with sender, subject, body and attachments intact. The identity firewall protects the AI path, not this one. Decide explicitly how it is governed, or restrict it.
Access, rectification and erasure requests, and deletion on termination, are serviced today by administered database operations. Agree the process and its service level before production; do not assume a button exists.
Supabase, Vercel, Resend and Stripe are now named, but their contract references and transfer mechanisms are marked to be completed. That paperwork must be closed before signature.
We hold that neither AI transfer carries personal data, so Chapter V is not engaged. A regulator could take a different view. Deepgram’s SCC-bearing DPA is the documented fallback; there is no equivalent signed instrument for Singapore yet.
If anything in this pack does not match what your own review finds, tell us and we will correct the document.