The seven-level tenant hierarchy

Structure follows the org chart. Enforcement does not.

Every multi-unit enterprise already has a hierarchy; software either respects it or fights it. On the shared platform, organizational structure resolves into seven levels of scope:

1. Consortium — the top-level group that holds the platform relationship.
2. Venture — a distinct business line inside the group.
3. Brand — the hard boundary. Records belong to exactly one brand.
4. Region — a grouping of locations inside a brand.
5. Location — a single operating unit.
6. Department — a functional lane inside a location.
7. Position — the seat an individual operator holds.

The levels exist so that access, reporting, and approvals can be expressed in the language the organization already speaks: "regional managers see their region," "department leads approve for their department." A grant that names a level applies to everything beneath it — and nothing beside it.

The boundary is still the brand

Seven levels of scope does not mean seven levels of tenancy. The isolation boundary sits at the brand, enforced at the database with row-level security: brand context attaches to the query itself, and a missing or mismatched context fails closed rather than returning the wrong rows. The machinery is documented at database isolation mechanics and multi-tenant architecture. Region, location, and department are scopes inside that boundary — they narrow what a grant can reach, but they do not create new tenants, new databases, or new sign-ons to keep in sync.

This distinction is what keeps growth cheap. Adding a region to a brand is a declaration inside an existing boundary. It inherits the sign-on, the approval gates, the audit trail, and the isolation guarantees. Nothing is rebuilt; nothing is copied.

Reading the tree without walking it

Hierarchy questions are constant: every location in a region, every department under a brand, everyone who reports up through a node. Naive implementations answer them by walking the org tree at query time — workable at five locations, expensive in ways that compound at fifty.

The platform indexes hierarchy paths instead. When a node is placed in the tree, its full ancestor path is recorded once, at write time — a closure table, in the database literature's term. Reads then match against stored paths rather than traversing relationships: "everything under this region" is a lookup, not a walk. The design property that matters is qualitative, and it is the one we are comfortable stating publicly: read cost tracks the size of the answer, not the depth of the tree. We publish no latency figures here, because honest ones depend on your data shape and are measured in your deployment, not asserted on a marketing page.

When the organization changes

Org charts are not static. Locations move between regions, brands acquire and divest, departments merge. Because paths are recorded at write time, a move rewrites the paths beneath the moved node — a bounded, auditable change — while the isolation boundary stays exactly where it was. A location that changes regions keeps its brand, its records, and its history; only its reporting line moves.

Divestiture is the stronger test, and it is why the boundary sits where it does. A brand that leaves the platform takes a cleanly bounded set of records, because its data was never interleaved with another brand's in the first place.

What we will not claim

We will not publish performance numbers we have not measured against your hierarchy, and we will not claim the model fits every org chart without conversation. The claim here is structural: seven levels of organizational scope, one hard boundary where isolation is enforced, and indexing designed so that reading the hierarchy does not require walking it.