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 — record which pages get visited, and nothing that identifies you.

We use Vercel Web Analytics, which counts page views and where visitors arrived from. It is cookieless and assigns you no identifier, so it cannot follow you between visits, and it exists on no other website you might use. We added it because we could not otherwise tell whether anyone was reading these pages.

There is no tag manager, no advertising pixel, no session recording, and no chat widget. Nothing here is sold, shared with a data broker, or used to build a profile of you.

CareOS does not record your IP address. One thing reads it. When a sign-up or an email confirmation is submitted, the application takes the address the request arrived from and turns it into a fingerprint, so that it can count how many attempts come from the same place within fifteen minutes and refuse the rest. The address itself is never written down: what the counter holds is that fingerprint and a number, and nothing else about you. Your browser string is not read at all. Vercel briefly uses your IP address to work out a country and to count you once rather than twice, and states that it does not store it. Separately, the servers and networks the site runs on keep their own operational logs, as any web infrastructure does, and those sit outside what CareOS itself records.

There are two forms on this site that anyone can use without an account, and they behave differently. The difference is the important part, so it is stated plainly rather than summarised.

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 does not ask for a phone number, and there is no hidden field capturing anything else.

A demo request is stored. It goes into the CareOS database when you submit it, and you are shown a reference number for it. Stored with it are that reference, whether anyone at CareOS has picked the request up yet, which member of staff handled it and when, the times it was created and last changed, and any working notes staff write while dealing with it. Those notes are ours rather than yours — they are what someone jots down before calling you back — but they are attached to your request and this page would be incomplete without saying so.

Storing it does not depend on anything being switched on. Whether an email notification also reaches staff depends on the transport described in section 7; the record above is written either way.

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

The contact form works the other way round. It asks for your name, your email, a subject and your message, and optionally a phone number and a category. Unlike the demo form, it stores nothing: nothing you type there is written to the CareOS database. The message is turned into an email and passed to the transport in section 7, and if that transport is not configured the form tells you it could not send rather than pretending it did.

One of the categories that form offers is Security or privacy. Choosing it does not route your message anywhere special, and it does not reach a dedicated privacy team — there is no such team and no dedicated address yet, which section 12 says plainly. It reaches the same people everything else does, who are the people who built CareOS.

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 preference, not “essential”, and not analytics. We checked this against a production build rather than assuming it.

The analytics described in section 2 is deliberately a cookieless one. It was picked on that basis: a product that needed a banner would have cost more than knowing our page views is worth.

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.

Every third party CareOS uses is named in this section, together with the condition under which it is used. They are named rather than counted, deliberately: a count describes how things happen to be configured on a given day, and this page is meant to describe how the system is built. Three are in use. A fourth is built in and not currently switched on.

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.

Vercel runs the website and provides the page-view analytics described in section 2. No agency data and no health information passes through the analytics — it sees public marketing pages only.

Resend is the fourth. It is the service that would carry email — a notification to CareOS when someone submits either of the forms in section 3, and a confirmation back to whoever sent a contact message. It is built into CareOS but is not currently configured, so at the time of writing no mail is being sent through it at all. It is named here anyway, because it is part of the system and a reader deserves to know what would carry their message — the same reason section 8’s AI provider is named whether or not an agency has switched WISDOM on.

There is no advertising network, no data broker, no email marketing platform, and no customer-data platform. Resend is a transactional relay — it carries a message someone asked us to send — and is not any of those things. If this list changes, this section changes with it, as it did when analytics was added and again when Resend was named.

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.