Platform
Security
Who can read what, decided by the record's owner, enforced by the server, and visible afterwards.
01
The three rules
- Consent is the model
- Cross-party reads happen because they were granted, can be paused, and can be revoked — by the party whose data it is, not the party reading it.
- The server decides
- Access is enforced where the data lives. A client that forgets to hide something must not be able to read it either.
- Reads are visible
- A grant leaves a trail, and so does a refusal — written to the trail of the tenant whose data was read, carrying the reason it was refused. That answers who looked and when, rather than only who currently holds access.
02
Where data lives
Each product runs its own deployment and its own database, under a role that cannot reach the other's. Nothing is shared between them at rest.
03
Separation is enforced by the deployment, not by a setting
Each product runs its own deployment against its own database, under credentials that cannot reach the other's. That is not a permission an administrator could grant by accident, because there is no connection for it to be granted over: the boundary is the process, the database role and the signing keys, rather than a filter applied to a request the deployment could otherwise have served.
The same rule decides what the platform itself may serve: a process must be one product or the other before it will start. A neutral mode exists for local development, and it serves neither product's exclusive content rather than both — so a misconfigured process is visibly empty instead of quietly wearing the wrong brand. In production it is refused outright, and before a production process will boot it must also prove that its product name, its dashboard host, its allowed origins, its signing keys, its database name, its storage bucket and every address it sends mail from are its own.