Where your data is,
and who can read it.

Each workspace's imported tables live in a database schema of their own, and every other row we keep for you carries your workspace's id, with a policy that checks it on every read. A request is resolved to exactly one workspace before it touches any data; an address we don't recognise never reaches one.

Every read is checked twice. The database checks your role's grant on each table with row-level security. The layer that writes the queries refuses a table your role can't read before anything is compiled. Both ask the same question of the same grants, so they cannot disagree — and when either is unsure, the answer is no.

To understand a table, the model is sent its name, its column names and types, simple statistics and the names of related tables. If your workspace allows it, it also sees up to 20 example values per column — never from a column marked sensitive. To propose a role, it is sent labels and descriptions, no values. When it answers a question it reads through the same layer you do, with your grants: what your role can't read, it can't either. Both switches are in your workspace's settings.

Nobody changes a row by asking — not a member, not an admin, not the model. Imported tables can be read and nothing else; rows arrive only through an import somebody approved, and the approval is recorded with their name.

Sign-ins, imports, grants, shares, exports and every refused question are written to an audit trail your admin can read. When the Grovely team loads files for you, that is in it too, under their names. To load a file they see its structure and any rows that failed to load — never a dashboard or an answer — and your admin can switch that off.

A workspace can be moved to a database of its own. Nothing else about it changes, which is the point.