Multi-tenancy & grants
How PIE isolates organisations at the database level and how producers share specific products with specific buyers.
Multi-tenancy is the most important property of PIE: every organisation's data is isolated from every other's, and that isolation is enforced in the database — not in application code that could be bypassed.
Organisation scoping
Every request is authenticated to a principal carrying an organisation id, taken only from the validated credential (JWT or API key) — never from the request body or query parameters. The API opens a tenant-scoped database connection for that organisation, which sets a session variable the database's row-level security (RLS) policies read. Every table holding customer data has an org_id and an RLS policy that filters to the current organisation, so a query can only ever see its own tenant's rows.
This is why a buyer cannot reach another buyer's data, and why a producer's draft products are invisible to everyone else — the boundary is structural.
Grants: controlled sharing
Producers need to share specific products with specific buyers. That is what a grant is: a producer exposes a set of products to a buyer organisation. Grants are read through grant-aware RLS — the buyer's tenant connection can see a producer's product row only when a grant links the two organisations. A buyer's "granted catalogue" is therefore not an application-side filter that could leak; it is the only thing the database will return.
A few resources are deliberately not grant-scoped — for example a buyer's own quality profiles — so a buyer's own writes never resolve across organisations.
Public surfaces
Some data is meant to be public — Digital Product Passports, brand portals, and print catalogs. These are served through a separate, read-only public database role that can see only published, allowlist-projected data, snapshotted at publish time. Nothing private can reach a public surface.
Lifecycle & governance
An organisation can be suspended (writes frozen, reads and data-subject exports still reachable) and offboarded (a previewed, confirmation-gated export-then-tombstone). Personal data across every table is classified in a registry that CI keeps complete, so data-subject access and erasure can never silently miss a table. See Security & governance.