How per-brand data isolation works

The boundary is the brand

Every operational record on the shared platform carries its brand context with it — which brand it belongs to and, where relevant, which location. Location is a scope inside a brand, not a separate tenant. There is no "global" operational view that quietly mixes brands: console work always happens in the context of one brand at a time.

Your overall account and your role on a specific brand stay distinct. Triangle (secure sign-on) establishes who you are; the platform then resolves what you may do for the brand you are working in. Access is never assumed from the first brand you happen to belong to.

Location scoping works the same way, one level down. A location manager's grant names the brand and the location; both travel with every query. Adding a location to a brand is a declaration inside that boundary — it never creates a new tenant, a new database, or a new sign-on to keep in sync.

Enforcement lives in the database

There are two places isolation can be enforced, and they fail differently:

• Application-level filtering checks brand context in code paths the developer remembered to protect. When a path is missed, it fails silently — the query returns data it should not, and nothing looks wrong.
• Database-level enforcement attaches brand context to the query itself. When context is missing or mismatched, the database fails closed — the query returns nothing, and the gap is loud.

We chose the second. Isolation that fails closed is compliance-grade by default; isolation that fails silently is a liability with a user interface.

The same enforcement covers everything that touches the record, not just the console. SDK reads, integrations, reporting queries, and agents acting on an operator's behalf all carry brand context on the same terms. There is no privileged path that bypasses the boundary "for internal use" — a second, looser permission system shadowing the first is exactly the failure mode isolation exists to prevent.

Blocked by default

Access on the platform is deny-by-default. A role sees a brand's records because an explicit grant says so — not because nobody got around to restricting it. Removing a grant removes access; there is no residual "everyone could already see it" state left behind to clean up.

# Illustrative shape only — not a production schema or real policy.
brand: example-brand
locations:
  - id: loc-north
  - id: loc-south
access:
  default: deny
  grants:
    - role: brand-operator
      scope: brand                  # every location in this brand, nothing outside it
    - role: location-manager
      scope: location:loc-north     # one location, inside one brand
    - role: portfolio-finance
      scope: brand                  # separate grant per brand, reviewed separately
notes:
  - brand context travels with every read and write
  - missing or mismatched context fails closed

The shape matters more than the syntax: brand and location scope are declared up front, grants are explicit, and the default in the absence of a grant is denial.

Structuring a new brand

When you add a brand, the decisions that matter are:

1. Records: which record types belong to this brand, and which locations exist at launch?
2. Roles: who operates the brand day to day, and who needs portfolio-level visibility into it?
3. Grants: the minimum set of explicit grants that covers those roles — nothing broader.
4. Shared vs. isolated: sign-on, approval gates, the audit trail, and fee tracking are inherited from the platform; the brand's operational data is isolated from day one.

What you should not do is copy another brand's grant set "to get started." Grants are cheap to add and expensive to walk back, and a copied set is calibrated to somebody else's operation.

What isolation is not

Isolation is not a promise that brands can never share anything. Portfolio-level reporting exists — but it reads across explicit, reviewed grants, not around the boundary. And isolation is not a migration tax: a brand that is sold or spun off can leave cleanly precisely because its data was never interleaved with another brand's in the first place.

What this page does not cover

This is public architectural orientation. Production schemas, enforcement internals, and environment-specific procedures ship with authenticated developer access. No real credentials or endpoints appear here, by design.