Many clients, one platform, strict separation

All clients share one engine. But the database itself keeps the data, the phone numbers, and the reputation of each client separate. The separation does not depend on careful application code.

Shared parts and separate parts

Three parts are shared, and one copy of each part serves all clients:

the service that does the work;
the scheduler that keeps long jobs in operation;
the database that records all the data.

One copy of each part makes the platform economical and easy to improve. Each fix goes to all clients on the same day.

Each client owns three parts separately:

Their leads and call records. These records stay separate inside the shared database.
Their AI voice agent — the script, the voice, and the behaviour. The client selects the agent for each campaign.
Their phone numbers, together with the carrier identity that proves who makes the call.

The phone numbers have the strictest rule of the three. A number belongs to exactly one client, always. The database does not accept the same number for two clients. This rule is necessary because the signed caller-identity guarantee of the carrier must point to exactly one owner.

Three clients each have their own voice agent and their own phone numbers, and the diagram shows them fully separated. All three use one shared engine, and the engine writes into one shared database. Inside the database, the records of each client stay in a separate area, and each record has an owner label. A panel below states that the database checks the owner label before it returns a record. The panel also states that the database account of the engine has limited permissions, and thus no request can skip the check. — The diagram shows what all clients share, and what no client shares. **The database itself** checks the owner label on each record before it returns the record. The database account of the engine has intentionally limited permissions. Thus no request can skip the check, not even because of an error.

The separation is in the database, not in the application

Each record has an owner label. The separation holds for four reasons:

The rule is inside the database engine itself. The rule filters records by owner. The rule is not in the platform's own code, where one forgotten line can weaken it. The database applies the rule to each question that it receives.
The platform cannot bypass the rule. The platform connects to the database with an account that has intentionally limited permissions. This account does not have the permission to bypass the rule. Thus a defect in the application cannot send the records of one client to a different client. The request comes back empty.
Tests prove the rule. Automated tests prove that a request without a client identity returns zero records. The tests prove this each time they run.
The wider view of the operator is checked. The platform operator can see more than one client. The platform grants this view for each request separately, and only after it verifies the identity of the operator. The view is a checked exception, not permanent unchecked access.

A safe switch between organizations

Some persons belong to more than one organization. An example is an agency that manages two brands. A switch between organizations is not a menu choice that the browser keeps. The server issues a new signed proof of identity for the person. The role in that proof always comes from the membership record, never from a claim by the browser.

This has a precise result. A person can be an administrator in one organization and a standard member in a different organization. In the second organization, that person holds only the permissions of a member. Permissions do not move with the person. Permissions come with the membership.

The platform operator can switch the view to any organization, or to a view of the full platform. This switch never gives the operator a client role.

LeadRefinery staff can also close an organization off, from the control room. A closed organization keeps every dial refused and every one of its campaigns stopped, and it locks every one of its members out of the workspace, while its data stays exactly as it was. A member locked out this way can still switch into a different organization they belong to.

One intentional exception to the separation

The separation has exactly one exception, and the exception is for safety information only. The platform records a suppression platform-wide because the suppression is true for each client that dials the number next. This occurs when a number:

appears on a federal do-not-call list;
gets a flag as the number of a known litigator;
now belongs to a different person;
tells any client's agent, mid-call, to stop calling.

The rule is simple: business data stays with one client. Safety data goes to all clients. This matters most for the fourth case: two different clients can legitimately hold the same person as a lead at the same time, on separate lists they each built independently. If that person tells one client's agent to stop calling, the platform marks the number for every client that holds it, the same minute — never only for the client on the call.

Why it matters: protection of reputation

Caller-number reputation is the most fragile asset of the platform. Two real clients never share a number or a carrier identity — the platform refuses outright to add a number to a second real client's pool. Thus a spam complaint against one client cannot decrease the reputation of the numbers of a different client. The cryptographic signature of the carrier on each call points to the one client that has the right to make the call. Only a demo or test organization's number can be shared, and only after a staff member confirms it; the platform then protects every holder together instead: a spam label on that number removes it from service for all of them at once, so no holder is left dialling a number the others have already lost.

Sign-in, invitations, and passwords

A dedicated, self-hosted identity service manages identity. This service is the only system that sees a password. The platform itself never processes a password. The platform only verifies the signed proofs of identity that the identity service issues.

Team invitations and password resets arrive as branded emails that contain one-time links. A reset request never shows if an account exists. The platform slows down repeated requests.

The technical bit, translated

PostgreSQL Row-Level Security is the separation mechanism: rules inside the database filter each request by the owner of the record. This is necessary because one line of code can omit an application-level filter. No code can omit a database-level rule.
An intentionally unprivileged database account connects the platform to the database. This account cannot bypass the rules. The owner of a table can bypass the rules. Thus the platform account is intentionally not the owner.
GoTrue, a part of the self-hosted Supabase stack, is the identity service. It stores the passwords. It creates the signed proofs of identity (JSON Web Tokens) that hold the role and the active organization of each person. Thus the platform never processes a password.
Retell and Telnyx are the voice-AI service and the carrier service. Each client has its own agents and, normally, its own numbers in these services, so the clients do not share conversation behaviour or caller reputation.

Two notes. The plans state that each client, in a later phase, holds its own provider credentials. The plans also state that an exit test at client onboarding proves the isolation from end to end at run time; this test is also planned for a later phase. Today the provider credentials are platform-level. The numbers, the agents, and the data are already separate for each client. For very large clients, or for clients with heavy regulation, the plans keep the option of fully separate databases.