Scopes and the data tree

What a scope is

A scope is a container for knowledge-graph data — the entities, facts, and relationships iontos builds and maintains. Every piece of data in the platform lives in exactly one scope. A scope can be a whole customer, a division inside a customer, a single project, or a sensitivity tier — the same idea covers all of them.

Scopes are also the unit of accounting: when a scope is the thing a customer owns and pays for, that is simply a role the scope plays. There is one concept — the scope — not a separate "tenant" or "account" object sitting beside it.

Scopes form a tree

Scopes are arranged as a tree. At the very top is the platform root, which holds the shared graph — broadly useful, public-grade knowledge that everyone benefits from (public company registries, open reference sources such as Wikidata and GLEIF, and other openly available data). Beneath the root sit customers, and beneath those, any structure a customer needs.

The root sits on top. A scope looks up to read the data it inherits; administrative authority reaches down to sub-scopes. Siblings never see each other.

The tree can be as deep as you need. There is no difference in behaviour between three levels and ten — the same rules apply at every level, and iontos does not cap the depth.

Reading the tree: what "up" and "down" mean

The root sits at the top, exactly as folders do in a file explorer. Throughout these docs, up means toward the root (a scope's parent and ancestors) and down means toward the leaves (its sub-scopes and descendants). Two things travel in opposite directions: a scope looks up to read the data it inherits, while administrative authority reaches down to the sub-scopes beneath it.

The three rules of the tree

Everything about how data moves (and doesn't) comes from three rules:

1. You inherit everything above you. A scope sees its own data and all of the data in its ancestors, all the way up to the shared graph. A team working in a deep sub-scope automatically has the shared graph and every intermediate level available to them — no configuration required.

2. Siblings are isolated. Two scopes under the same parent cannot see each other's data. Northwind Bank and Meridian Bank, side by side under the same operator, are completely separated.

3. Data never flows downward on its own. A parent does not automatically see its children's data. Placing a scope beneath another one does not expose the child's contents to the parent.

Read together: a scope's view reaches up the tree (its ancestors) — never sideways (siblings), never down (its sub-scopes). This is what makes the tree safe for sensitivity tiers — a more sensitive scope can live underneath a general one and still keep its contents to itself.

Nesting patterns

Because the same rules hold at every level, a single model expresses very different real-world shapes:

Shape	Example
Single customer	One scope for the whole organization.
Divisions	A customer with internal teams, each its own scope, sharing the customer's common data above them.
Agency and clients	An agency scope with a client scope beneath it for each engagement — clients isolated from one another, all inheriting the agency's shared material.
Corporate group	A group scope with a scope per subsidiary — subsidiaries isolated, all inheriting group-wide data.
Sensitivity tiers	A customer scope with public, restricted, and classified scopes beneath it — each tier inheriting the less-sensitive levels above, none exposing itself downward or sideways.

When facts disagree across levels

Because a scope inherits ancestor data, it can hold a fact that conflicts with one inherited from above (the same entity, the same kind of fact, a different value). iontos does not silently let the lower scope overwrite the inherited fact — both remain visible, so nothing is quietly hidden. How a merged view presents or ranks competing facts is part of how iontos resolves knowledge quality, covered elsewhere; here it is enough to know that inheritance never erases what a scope adds, and a scope's own additions never erase what it inherits.

What the tree does not decide

The tree decides how data is inherited and isolated. It deliberately says nothing about which people can see each other, or whether two neighbouring scopes belong to the same company. That is a separate axis — the organization boundary — which is the subject of the next page.

Access to a scope's data is never automatic either: inheriting data requires a grant somewhere in the chain. How access is placed and how far it reaches is covered in Grants.