Grants

A grant is how access is actually given. It is the atomic unit of authorization, and it answers four questions:

1. Who — a person, or a group.
2. What role — one of the roles.
3. Where — the scope the grant is placed at.
4. How far — whether it reaches only that scope, or the whole subtree beneath it.

Everything a person can do is the sum of the grants held by them and by every group they belong to. There is no separate "home" scope and no hidden default access: a person with no grants can authenticate but see and do nothing, which is exactly the intended starting state.

How far a grant reaches: cascade

The single most important rule about grants is that reach depends on the axis, because sub-scopes are often more sensitive than their parents — automatic downward access would defeat the purpose of the tree.

Role axis	Does it cascade down the tree?	Why
Data access (Reader, Editor)	No. Applies only to the named scope.	A Reader at a customer scope must not automatically become a Reader of that customer's classified sub-scope. Each data grant is deliberate.
Quality (Curator, Arbiter)	No. Applies only to the named scope.	Review pools are scope-specific; reviewing one level does not qualify someone to review a more sensitive one.
Administrative (Operator, Admin, Owner)	Yes — downward. Covers the scope and its descendants, but stops at organization boundaries and sealed scopes.	Administrative responsibility spans a company's own structure — but not the separate companies nested beneath it.
Billing	No. Applies only to the named scope.	Cost visibility at a parent should not automatically expose each child's breakdown.

Reading data you inherit is different from cascade

Don't confuse cascade with inheritance. A Reader grant where a person actually works lets them read up the ancestor chain automatically — one grant deep in the tree already sees every less-sensitive level above it, and the shared graph at the top. That upward visibility is inheritance, it is always safe, and it cannot be switched off for a particular ancestor. Cascade is about reaching downward, which is the thing held deliberately in check.

Extending a grant to a subtree

Sometimes you do want a data, quality, or billing grant to cover a whole subtree — an agency lead who should read every current and future client, say. That is possible, but only as an explicit choice at grant time: "Reader at Atlas Agency, including sub-scopes."

Property	Rule
Default	Off. A plain grant covers only the named scope. Subtree reach is never implicit.
Future scopes	A subtree grant covers descendants created after it — the point of the feature: new client scopes are covered without re-granting, as long as they remain in the same organization.
Organization wall	A subtree grant stops at a nested organization boundary, exactly as administrative reach does. You cannot reach access into a separate company nested beneath you.
Sealing	A subtree grant does not penetrate a sealed scope.
Best used for	Organizationally uniform trees (an agency and its clients, a group and its shared data). Avoid it across sensitivity tiers — that is exactly where the per-scope default protects you.

Where reach stops

Two things halt the downward reach of administrative and subtree grants:

• Organization boundaries. Access never crosses into a nested organization from outside it. To place access inside a separate company nested beneath you, someone with authority there must grant it. (A narrow, loud, appointment-only exception exists so an operator can restore a locked-out customer's first administrator — it grants no data access and is heavily audited.)
• Sealing. A scope with its own administrators can be sealed, after which administrators above it can no longer manage it or grant themselves access into it. Sealing is how sensitivity tiers protect themselves even from their own parents. The full mechanics live in the administration guides.

Access is only ever added

iontos has no concept of a "negative grant" that subtracts one role from someone. You give access by placing grants; you take it away by removing them. When someone should have less than a group provides, the answer is a finer group or an exclusion, never a per-person subtraction — which keeps "what can this person do?" a simple sum rather than a puzzle of overrides.

A few example grants

Grant	Effect
Reader at Northwind Bank	Reads Northwind's data plus everything it inherits from above. Cannot see Meridian Bank. Does not reach Northwind's sub-scopes.
Reader at Atlas Agency, including sub-scopes	Reads Atlas and every client kept in Atlas's own organization — including clients added later — plus inherited data. A client that is its own organization is not reached.
Admin at Atlas Agency	Manages Atlas and every sub-scope in its organization: create scopes, manage people and groups. Grants no data access — an Admin still needs a Reader grant to read the graph.
Owner at a customer scope with a classified sub-scope	Full authority at the customer scope, but the classified sub-scope, once sealed, is administered only from within itself.