Philosophy
A control that cannot be verified is not a control.
Most security pages are a list of assurances. Assurances are easy to write and impossible to check, which is why they stopped being persuasive. Four commitments shape how CareOS is actually built.
We build a control only when it can be enforced
If a protection cannot be enforced by the system, it does not appear in the product as though it can. CareOS has no multi-factor authentication toggle, because multi-factor authentication is not built — and a switch with nothing behind it becomes a liability the day someone relies on it.
Two layers, because one will fail
Isolation between agencies is enforced in the application and again in the database, on a connection that has no authority to bypass it. We built the second layer after an internal audit found the first one failing silently — which is the honest reason it exists.
Reasoning is not evidence
“It compiles” and “we reviewed it carefully” are not evidence that a protection works. A safeguard is considered finished only once it has been exercised against the real database, and once the test guarding it has been observed to fail against the unfixed code.
We would rather lose a sale than overstate
This page names what is missing. That is not modesty — it is the only way a claim on the rest of the page means anything. If a vendor never tells you what they have not done, you have no way to weigh what they say they have.
Identity & access
People see the part of the agency their job requires.
Access in home care is not one boundary but two: which agency you belong to, and what your role within it permits. CareOS treats them as separate guarantees, because a failure in either is a different kind of harm.
Roles carry real limits
Every account holds one role — owner, administrator, scheduler, clinical supervisor, billing, HR, caregiver, or family. Each role opens only the parts of CareOS that role needs. A caregiver sees the clients they are assigned to, not the agency’s directory; a scheduler cannot open payroll.
These limits are applied on the server, on every request. Hiding a menu item is a courtesy to the user, not a security measure, and CareOS does not treat it as one.
Administrative changes are constrained
An agency cannot accidentally lock itself out: the last remaining owner cannot be demoted or deactivated, and no one can deactivate their own account. Only an existing owner can make someone else an owner.
Deactivating a user ends their access immediately — their active session is revoked rather than left to expire on its own.
Isolation
Your agency’s data is separated twice.
CareOS serves many agencies from one system. The guarantee that matters is that none of them can reach another's records — not by accident, not through a bug in a single screen.
The first separation is in the application: every query is scoped to the agency making the request. The second is in the database itself, which applies its own isolation rules and does not take the application’s word for who is asking. The connection the application uses has no authority to override those rules.
What this means for you: a mistake in one screen cannot expose another agency’s clients, because the screen is not the thing enforcing the boundary. Both layers would have to fail together.
The same reasoning applies inside your agency. Restricting a caregiver to their own clients is enforced as its own separate rule — not assumed as a side effect of agency separation.
A request for client records
Who is asking?
The session is resolved to a user, their agency, and their role.
Does their role allow this?
Checked on the server before any record is read.
Application scopes the query
Limited to the requesting agency — layer one.
Database enforces it again
Rules applied independently, on a connection that cannot bypass them — layer two.
The change is recorded
Anything that modifies data is written to your audit log.
Audit & accountability
A record of what happened — including when it was us.
Accountability is not only about your staff. It also has to cover the vendor, which is the part most software leaves out.
Every change is recorded
Actions that modify data — a role changed, a visit verified, an invoice voided, a payroll run approved — are written to your agency’s audit log with who did it, what they touched, and when.
The log is yours to read inside CareOS. You do not have to ask us for it.
It records what happened, not what was attempted
When an action is refused — someone tries to do something their role does not permit — the refusal happens before anything is written, so no entry appears. The log describes real changes only, which is what makes it usable as evidence.
Support access is visible to you
When CareOS staff need to look at your account to help with a problem, that access is time-limited, requires a written reason, and is read-only unless write access is explicitly requested.
It is also written into your audit log, not only ours. You can see that we looked without having to ask us whether we did.
Support cannot exceed an administrator
A support session never carries owner-level authority, and read-only sessions are refused write access by the database rather than by our staff remembering the rule.
Privacy
Client information stays inside CareOS.
Home care software holds some of the most sensitive information a person has. The question that matters is not only who can see it, but where it is allowed to travel.
Our AI assistant never receives client identities
WISDOM, the assistant built into CareOS, works from a live summary of your agency’s operations. That summary is de-identified before it leaves our infrastructure: it says “a caregiver has not clocked in for a scheduled visit,” never a client’s name.
This is enforced in the structure of the code rather than by a filter that has to catch every case, and an automated test fails the build if a future change tries to send an identifying version instead.
Diagnostic logs cannot carry patient data
Our operational logs — the records engineers read when something breaks — are built so that client information cannot be written into them. The constraint is enforced by the type system: code that attempts it does not compile.
Role limits apply to the assistant too
WISDOM only sees what the person asking is allowed to see. A scheduler’s assistant cannot discuss agency financials, because the financial data is never placed in front of it.
What you type is your decision
The assistant is powered by an external AI provider, and anything a user types into it is sent to that provider to be answered. CareOS says so directly in the product, next to the input box, so the choice is visible at the moment it is made.
On HIPAA
CareOS is built around HIPAA’s technical safeguards — access control, isolation, audit, and least privilege. We do not describe ourselves as HIPAA compliant, because compliance is not only a matter of engineering: it also requires contractual agreements with the providers who host the data, and ours are not yet complete.
HIPAA readiness is an active objective, and we will publish the date those agreements are signed. Until then we will not use the phrase — and it is worth asking any vendor who does to show you the agreement behind it.
Reliability
Recovery is rehearsed, not assumed.
A backup nobody has restored is a belief, not a safeguard. The only useful question is whether the restore has actually been performed.
We have rehearsed a full restore
We have run a destroy-and-restore exercise end to end against our staging environment: data deliberately destroyed, then recovered from backup and checked record by record against what was there before, with the full workflow test suite re-run against the restored database.
We publish this as a rehearsal on staging, at the scale we run today, rather than as a recovery-time promise for a production system carrying your agency’s data. Those are different claims and we will not blur them.
Maintenance makes CareOS read-only, not dark
When the platform needs maintenance, CareOS becomes read-only rather than going offline. A caregiver mid-shift can still see today’s visits and care plans; only changes are paused, and the reason is shown in the product.
Read-only is enforced by the database, so it holds even where a screen forgot to ask.
How we build
Written principles, not undocumented habits.
CareOS is built against a written constitution: a document describing what the product must always be true about, and why each decision was made that way.
Alongside it is a decision log recording the architectural choices made during construction — including the ones that came from finding our own mistakes. Both exist so that the standard does not depend on who happens to be writing the code that week.
One example of what that produces: a compliance figure that could not be calculated correctly was removed from the product rather than displayed as a zero. A number that always reads “0” answers a question it cannot actually answer, and in compliance software that is worse than showing nothing.
“A feature that is 90% correct in a healthcare system is not 90% of a feature. It is a liability with a user interface.”
Full disclosure
What is not in place yet.
This is the section most security pages leave out. These are real gaps, stated before you find them — so that everything above can be read as something other than marketing.
HIPAA Business Associate Agreement — not yet in place
Required before CareOS can hold real patient data, and not yet signed with our infrastructure provider. This is a contractual step, and it gates our first production customer.
Multi-factor authentication — not yet in place
Not built. Accounts are protected by password authentication today. There is no MFA setting in the product, because there is no MFA behind it.
Configurable data retention — not yet in place
Not built. Retention periods cannot yet be set per agency.
Independent security audit — not yet in place
No third-party penetration test or SOC 2 examination has been performed. The verification described on this page is our own, and we would rather say that than imply otherwise.
Production operating history — not yet in place
CareOS has completed engineering certification but has not yet run a live agency. We have no uptime record to show you, and we will not invent one.
Tenant and role isolation — in place
Built, and verified against the real database — including deliberate attempts to read and write across agency boundaries.
Audit logging — in place
Built across every module, readable by your administrators inside CareOS.
Accountable support access — in place
Built: time-limited, justified, read-only by default, and mirrored into your own audit log.
We will update this list as each item changes, rather than quietly removing the rows that stop being flattering.
Questions
Security questions we are asked
Is CareOS HIPAA compliant?
No — and we would be careful with any vendor who answers that question with a simple yes. CareOS implements HIPAA’s technical safeguards, but full compliance also requires a Business Associate Agreement with the provider hosting the data, and ours is not yet signed. We will publish the date it is.
Can another agency see our clients?
No. Records are scoped to your agency by the application and again by the database, which enforces the boundary independently on a connection that cannot override it. Both layers would have to fail at once.
Can CareOS staff read our data?
Only through a support session, which requires a written reason, expires automatically, and is read-only unless write access is explicitly requested. Every session is recorded in your own audit log, so you can see that it happened without asking us.
Does your AI assistant see our clients' names?
No. The operational summary WISDOM works from is de-identified before it leaves our infrastructure — it refers to “a client” and “a caregiver,” never to names. An automated test fails the build if a change attempts to send identifying information instead.
What a user types into the assistant is sent to the AI provider to be answered. We say so in the product, next to the input.
What happens to our data if we leave?
It remains yours. CareOS supports exporting your records, and we treat portability as an obligation rather than a feature to withhold.
You are new. Why should we trust you with patient data?
Partly you should not have to take it on faith — which is why this page describes mechanisms you can ask us to demonstrate, and states what is missing.
We are early, and we are choosing our first agencies deliberately. If being among the first is not the right risk for you right now, we would rather say so than talk you into it.
Who do we contact about a security concern?
Raise it in your demo or with your CareOS contact and it will reach the engineers directly. A dedicated security disclosure address is being established and will be published here.
Bring your hardest security question.
A 30-minute demonstration with someone who built CareOS. We will walk through how your agency’s data would be protected — and tell you plainly if CareOS is not the right fit yet.