What CareOS does with personal information.

CareOS deals with three different groups of people, and this policy means something different for each. Blurring them is how privacy policies become uninformative, so they are separated here.

Visitors to this website. Anyone reading these pages or requesting a demonstration. This policy governs that relationship directly.

People who use CareOS at an agency. Owners, administrators, schedulers, and caregivers with accounts. This policy covers the account itself; the working relationship is between them and their agency.

Clients and their families. People receiving care, whose records an agency keeps in CareOS. We hold that information on the agency’s behalf, not our own. We do not decide what is collected about a client, and we cannot answer a request about their records directly — that has to go to the agency providing their care. Section 11 explains what we can do.

These public pages — this one, the homepage, the security page and the demo page — do not collect anything about you as you read them.

There is no analytics package, no tag manager, no advertising pixel, no session recording, and no chat widget. That is not a setting we chose in a dashboard; there is no such code in the site.

We do not record your IP address or browser. The application does not read either. Be aware that the servers and networks the site runs on keep their own operational logs, as any web infrastructure does, and those are outside what CareOS itself records.

The demo form asks for seven things: your name, your work email, your agency’s name, roughly how many caregivers you have, your role, optionally what is most frustrating about your current setup, and optionally when suits you.

It deliberately does not ask for a phone number, and there is no hidden field capturing anything else.

We would use those details to arrange and prepare for the demonstration. You would not be added to a mailing list, and there is no automated follow-up sequence.

An agency account holds a work email address, a role, which agency the account belongs to, and whether the account is active.

Passwords are never stored in CareOS. Authentication is handled by Supabase Auth, which holds the credential; the CareOS database has no password column to leak.

When someone is deactivated, their sessions stop working immediately rather than lasting until they happen to expire.

An agency using CareOS records clients, caregivers, schedules, visit documentation, incident reports, messages, pay and billing rates, invoices and payroll. Much of that is health information about identifiable people.

We process it so the agency can run its operation. We do not sell it, we do not use it to advertise, and we do not use one agency’s records to build anything for another.

Documents an agency uploads are held in Supabase Storage and are reachable only through short-lived signed links generated for a specific authorised request — not through a public URL.

The public pages of this site set no cookies. None at all — not analytics, not preference, not “essential”. We checked this against a production build rather than assuming it.

That is why there is no cookie banner. There is nothing to consent to, and a banner asking permission for cookies that do not exist would be theatre.

Signing in is different. The application uses a session cookie to keep you signed in, and remembers whether you last had the sidebar open or closed. Both are necessary for the product to work, neither is used for tracking, and no third party can read them.

Two, and they are both named here because there are only two.

Supabase provides authentication, the database and file storage. Agency data, including health information, is held there.

OpenAI answers WISDOM requests, and only when an agency has turned WISDOM on. Section 8 explains exactly what reaches it.

There is no advertising network, no data broker, no analytics provider, no email marketing platform, and no customer-data platform. If that changes, this section changes with it.

WISDOM is optional. An agency that would rather not use an AI assistant can leave it off, and the rest of CareOS works identically.

Where it is used, the operational summary WISDOM reasons from has client and caregiver names removed before it leaves our infrastructure. That de-identified version is a separate stored representation rather than a filter applied on the way out — the distinction matters, because a filter fails silently when it meets something it did not anticipate, and a missing field does not compile. An automated test enforces it.

What a person types into the assistant is sent as written. If someone types a client’s name into the chat box, that name goes to the AI provider. We say so in the product, next to the input, rather than only here.

One agency’s records are separated from every other agency’s by two independent layers — the application scopes each query, and the database applies the same rule again on a connection that cannot override it. Both would have to fail together for records to cross.

Restricting a caregiver to their own clients is enforced as its own rule, not assumed as a side effect of that separation.

Changes that modify data are written to an audit log the agency reads itself, without asking us. That log records who, what and when — it does not record IP addresses or device details, because CareOS does not collect them.

When our staff need to look at an account to help with a problem, that access is time-limited, requires a written reason, is read-only unless write access is explicitly requested, and is recorded in the agency’s own audit log as well as ours.

Application logs are structured so that health information cannot be written into them — enforced by the type system rather than by remembering.

No independent security audit or penetration test has been carried out. The security page lists what is and is not in place.

Two things we can already say. Archiving a person inside CareOS keeps their history rather than erasing it, because a visit that was paid and billed cannot honestly disappear. And health information is subject to record-keeping obligations that generally require retention for years, so any future policy will be constrained by law rather than by preference.

If you use CareOS at an agency: you can see and correct your own account details, and export records you have access to as CSV from every module. Requests to delete your account go through your agency, since your employment record is theirs rather than ours.

If you receive care from an agency that uses CareOS: your records belong to that agency, and requests to see, correct or delete them should go to them. They can act on your request in CareOS themselves. If they ask us for help doing so, we will help them.

If you asked for a demo: you can ask us to delete your details. At present there is nothing to delete, because the form does not store anything (section 3).

If an agency stops using CareOS: their data remains theirs. CareOS supports exporting records from every module.

On the status of this page. It is an accurate description of what the software does, written by the people who built it. It has not yet been reviewed by a lawyer, and it will need to be — a description of practice and a legally sufficient privacy policy are not the same document. That review is required before launch.

When this policy changes we will update the date at the top. For changes that meaningfully affect how information is handled, we will tell affected agencies directly rather than relying on you noticing a new date.