Every row belongs to one organization
Documents, pages, search indexes, fixes, jobs, conversations, and sync history all carry an organization. There is no shared pool that a filter has to remember to exclude you from.
Security
Service companies compete with each other. Some of them will be on this platform at the same time. So isolation is not a setting here — it is the shape of the schema.
Documents, pages, search indexes, fixes, jobs, conversations, and sync history all carry an organization. There is no shared pool that a filter has to remember to exclude you from.
Search narrows to your organization first, and only then ranks. Ranking first and filtering afterwards is how one company’s manual ends up in another’s answer, so the order is fixed and tested.
Row-level security policies apply the same rule independently of the application. A bug in one layer does not become a leak, because the other layer still says no.
PDFs sit in a private bucket with no public URL. Every open or download is authorised per request and produces a link that expires. There is nothing permanent to share by accident.
A technician reaches a job because there is a row saying so — not because the interface showed them a link. A job they are not on is reported as not found, so a guessed identifier discloses nothing.
Cloud-provider tokens are encrypted at rest and are never returned by the API. Invitation links are stored only as hashes, so a database copy cannot be replayed into an account.
We would rather be useful to your security review than impressive in a sales deck.
No. Every document, fix, job, and conversation belongs to exactly one organization, and every query is filtered by that organization before anything is ranked or returned. The database enforces the same rule independently through row-level security, so a mistake in the application is not enough to cross the boundary on its own.
Management can see the whole document library, every job, and every submitted fix. A technician sees the jobs they are assigned to, the approved fixes, and their own submissions. Job access is granted per technician per job, and it is enforced by the server on every request rather than by hiding buttons.
No. They are stored in a private bucket with no public URL. Opening or downloading one goes through the API, which checks your membership and then issues a link that expires shortly afterwards. There is no permanent URL to leak.
Your documents are used to answer your own technicians’ questions. They are not shared with other customers and are not used to train a shared model.
Removing them from your organization removes their job assignments in the same operation and ends their access. Management can also suspend an account, which keeps the record and stops the access.
Not today, and we will not claim otherwise. What we can describe precisely is the architecture: per-organization isolation enforced in both the application and the database, private document storage reached only through short-lived links, encrypted cloud-provider tokens, and invitation tokens stored only as hashes. We are happy to walk your security team through it.
We will walk your team through the architecture, the isolation model, and exactly where your documents live.