How the platform keeps client data separate and safe

The platform holds the contact details of many people, for several clients at once. Three separate controls keep one client's data away from another's. This page states what each control does, and what the platform does not yet answer.

The controls, at a glance

This table names each control the way an engineer would, and says whether it runs today. The sections below explain the important ones in plain words. Every line here was checked against the running system on 24 August 2026, not against the plan.

The database refuses the wrong client's data

Every table in the database has a rule attached to it. The rule states which client's rows a request can see. The database applies the rule itself, on every query.

Thirty-one of the 34 tables carry this rule. Three do not: one holding the emergency-stop state, one holding a rehearsal's simulated daily capacity, and one holding phone numbers while an upload is checked for duplicates. The first two hold working state, not contact details. All three are listed as an open question below.

The account the platform uses to read the database cannot turn the rule off. The account is created without that permission. A mistake in the platform's own code therefore cannot expose another client's rows.

The platform sets the client for each request inside the database transaction. The setting ends when the transaction ends. One request cannot leave its setting behind for the next.

Who can do what

Two checks run on every request, in order:

• The first check reads the sign-in token and confirms it is genuine.
• The second check reads the role in that token and confirms the role is allowed here.

The role comes from the token. It never comes from the request body. A caller therefore cannot ask for a higher role.

There are three roles. A platform administrator can reach every client. A client administrator can reach one client. A member can reach less.

The first check also confirms the person is still a member of the organization named on the token, on every single request, not only when the token was issued. Removing a person from a team, or shutting an organization off, therefore takes effect on the person's very next request; the platform also ends every one of that person's existing sign-ins at the same moment, rather than waiting for a token to expire on its own.

The platform limits how fast it will answer

Every request counts against a limit, kept for the signed-in person and their active organization, or for the caller's own address when nobody has signed in yet. A route that calls an outside AI service, or that sends an outbound message, counts against a tighter limit of its own. A caller past its limit gets a plain refusal with a wait time, not an error. One client's own heavy use of the platform never counts against a different client's limit. If the counter itself cannot be reached, the platform allows the request rather than refuse real traffic over a fault in a supporting system.

The platform proves each call event is genuine

Outside systems send messages to the platform when a call starts, ends, or is analysed. Anyone can send a message to that address. The platform therefore proves each one.

• Each message carries a signature. The platform checks the signature against a shared key before it reads the message.
• The check uses a comparison that takes the same time for every input. This stops an attacker learning the key from the speed of the answer.
• The telephone network's messages also carry a time. The platform refuses a message that is too old. This stops an attacker sending a captured message again.
• The voice service signs the tools the agent uses during a call in the same way. The platform refuses a tool request that is older than five minutes, and a second copy of the same request. It takes the client from its own call records, never from the request.

Each check fails closed. If the key is absent, the platform refuses the message. It does not accept the message and continue.

What happens to personal information

The platform stores the words of each call, and the details each client uploads. Three rules apply:

• The platform removes personal details from the words of a call before it sends them to the service that reads them.
• The records that hold personal details are marked in the database. The people who work on the platform can therefore see which records need care.
• Measurement data stays on the platform's own machine. The platform records how long each step takes, and which steps fail. It keeps that record in its own store. It sends none of it to an outside company.

Passwords and keys are never stored in the platform's own source code. The files that hold them are excluded from the code store.

Each client calls with its own identity

Each client has its own telephone numbers, its own carrier settings, and its own voice agent. One client cannot call with another client's number.

The score that the telephone networks give a caller therefore stays with the client that earned it.

What the platform does not yet answer

These questions are open. The platform states them here rather than leave them unsaid:

• Background work runs above the rule. Work that runs on a schedule has no signed-in person, so it sets the client itself and the database rule cannot check it. The platform relies on that code being correct. This pattern is used in 19 files.
• Three tables do not carry the database rule. One holds the emergency-stop state, one holds a rehearsal's simulated daily capacity, and one holds phone numbers during an upload — all three have the rule switched off. The database will not separate clients on these three, so only the platform's own code does. The first two are empty today.
• Links between records do not name the client. A link says which record it points to, but not which client owns it. The database therefore cannot refuse a link that joins one client's record to another's. Nothing has been seen to do this — but the database would not stop it.
• Three groups of pages check the sign-in but not the role. Any signed-in person of any role can reach them.
• This documentation site is behind one shared password. Everyone who reads it uses the same one. The site does not record who read what.
• A person must start the check for personal details. A test puts one phone number through the whole platform. It then reads every measurement record, and proves that the number appears in none of them. The test does not run on its own. Someone must run it after each change to the measurement code.
• No outside party has tested the platform's security. Everything above is the platform's own account of itself.
• Consent for an automated voice is a legal question, not a technical one. The platform records that a client holds consent. It cannot judge whether that consent covers a call made by an automated voice. See staying compliant.