The Boundary De-Identifier.

The Principle, Shipped

The Boundary De-Identifier

Making regulated data safe to work with by ensuring identity never crosses the line

Ontinuity · grounded from the live build · June 2026

The one-sentence claim

A home-care agency can use an AI-assisted scheduling tool on its caregiver and client data without any private information ever leaving the agency's own computer — because the data is de-identified at the boundary, on the operator's machine, before a single field crosses to the service. The service operates entirely in token-space. Nothing identifiable from that dataset is sent to the service — so there is nothing in it for the service to breach, because the identifying data never crossed.

This is the same principle that governs the larger Ontinuity system — don't make the component trustworthy; structure the boundary so the sensitive thing cannot leak — applied to the narrow, urgent, and heavily regulated problem of protected health information.

The problem it solves

Home-care scheduling is a recurring crisis. A caregiver calls out; the agency owner has to find, within hours, which of her caregivers can cover the open shift — right skills, right area, free in that window, hours remaining — and reach them one by one. Today that is phone-tag that eats one to four hours per incident. The existing scheduling software won't help with the most common version of the question, because it can only operate on shifts that already exist as committed, client-attached records — it cannot answer "if I needed someone Tuesday 9-to-5 in this town for dementia care, who could do it?"

An AI-assisted tool could collapse that scramble to minutes. But the data it would need — caregiver names, client names, addresses, phone numbers, care notes — is exactly the protected information that makes a regulated home-care business unable to put it on someone else's server. The obstacle is not capability. It is data exposure.

The conventional answer is a Business Associate Agreement: the vendor promises to handle the protected data carefully, carries the liability, and the regulated client trusts the promise. That is trust placed in a component. The de-identifier takes the other path: it removes the need for the trust by removing the data from the equation.

How it works

The tool — the Cleaner, or Sanitizer — runs on the agency owner's own computer. It exists in two forms: a Python module, and a single-file HTML application that makes zero network calls (verified by source scan; data goes in via the browser's file reader, comes out as a downloaded file, and never touches a network). Production packaging wraps it as a double-click desktop application that blocks all outbound network traffic at the shell as a belt-and-suspenders guarantee.

The owner exports her caregiver list and schedule from her existing system and runs them through the Cleaner before anything is sent anywhere. The Cleaner then does four things that together make the output safe:

It transforms by declared type. Each column is certified by the owner as a type — name, phone, date, address, free-text, or pass-through — and the tool enforces the transform for that type: a person becomes a stable opaque token ("Person 001"), a phone or email becomes a token, a date is reduced to its year, a street address is dropped, a town is kept (it is needed for matching), and controlled-vocabulary fields like skills pass through untouched. The owner declares the column types and the tool enforces them — which is also how the regulatory liability is correctly placed: the owner certifies, the tool proves it executed the certification, and the record shows it.

The tokens are stable and opaque. "Stable" means the same real value always produces the same token, so the downstream tool can recognize that two records refer to the same (anonymous) person without ever knowing who they are. "Opaque" means the token is just a counter — it carries no information that could be reversed back to a name. The identity-to-token mapping is written to a separate file that stays on the owner's computer; only the clean, tokenized file crosses.

It drops what it cannot safely tokenize. Free-text note columns are the hard case — a note like "needs care for [client name]" hides an identifier inside prose, and deterministic rules cannot surgically excise a name from a sentence without risking leaving part of it. So those columns are dropped entirely rather than half-cleaned. Safe-by-removal beats clever-but-fallible.

It checks its own work with a second, independent pass. This is the part that mirrors the larger system most directly. The tool does not trust its own transformation. After the producer pass de-identifies the data, an independent verifier re-scans the output with detectors shaped for the regulated identifier patterns — Social Security numbers, phone numbers, emails, dates of birth — looking for any residual that slipped through. It returns a PASS or FAIL, and that verdict is written to an append-only record. The producer and the checker are distinct; neither rubber-stamps the other. On the real test data, the verifier returned PASS with zero residual identifiers.

The owner sends only the clean file. The mapping never leaves her office. The service receives caregivers known only as codes, with their skills, the towns they cover, and their availability — enough to match a shift, nothing that could identify a person.

Why this is the right design for regulated data

The standard posture in agentic AI is to take in sensitive data, process it on the service side, and protect it there with access controls, encryption, and contractual promises. Every one of those is a control on data the service holds. The de-identifier's posture is that the service should never hold it at all.

The consequences are concrete. No protected health information from the de-identified dataset is sent to the service, so there is nothing in it to breach, subpoena, or leak. The heaviest regulatory obligations are reduced at the root rather than managed downstream, because the trigger for them — the service processing protected data — does not occur. And the whole arrangement is auditable: every run writes a record of which columns were sanitized, which were dropped, a cryptographic correspondence proof that the output corresponds to the input without storing either, and the verifier's verdict. An auditor can confirm the boundary held without ever seeing the underlying data.

It is the difference between a vault with very good locks and a building that simply never takes the valuables inside.

Where it sits

The de-identifier is one membrane in a larger design. A second membrane handles live messaging — when the tool texts caregivers about an open shift, a broker on the owner's side resolves tokens to real phone numbers at the moment of sending and strips inbound numbers back to tokens before any reply crosses, so identity never enters the service even in the live loop. Between the membranes, the actual matching of caregivers to shifts is deterministic code, not a model — the same inputs always produce the same ranked list, fully auditable, with no possibility of a hallucinated match. Models appear only at the two seams where human language has to be understood (parsing an availability note, classifying a text reply), and at each seam the model is held to a fixed output contract: it returns a valid structured shape or the case falls to a human. Comprehension by model; consequence by code; the human as the final judgment on anything ambiguous.

That is the same architecture as the broader Ontinuity system, scaled down to one urgent problem: the sensitive or consequential work is structured so that no single fallible component — including the AI — is the thing you have to trust. The de-identifier is the first shipped, tested instance of that principle in a regulated domain. The status today: built and tested against real-world data shapes, verifier passing, with production packaging and the live-messaging membrane as the next build steps.

The general point

De-identification at the boundary is not specific to home care. Any field where AI assistance would be valuable but the data is too sensitive to expose — healthcare, legal, financial, any regulated record-keeping — has the same shape: the obstacle is not whether the AI can help, but whether the sensitive data can be put in front of it safely. The boundary de-identifier answers that by changing where the line is drawn. The model never needs to be trusted with the identity, because the identity never reaches it. Build the boundary correctly, and the question of trusting the AI with protected data simply does not arise.