Roles
Access in iontos is expressed as roles. A role says what a person can do — read data, edit it, review quality, administer a scope, see costs. Roles are deliberately kept small and composable rather than bundled into a few all-or-nothing tiers.
Three independent axes, plus billing
Roles are organized on three independent axes. A person holds at most one role per axis, and the axes do not imply one another — this is the most important thing to understand about the model, and the one that most often surprises people:
Holding an administrative role does not give you access to read the data. Being able to manage a scope's users is a different thing from being able to see its knowledge graph, and the two are granted separately.
Data access — what you can see and change
| Role | What it allows |
|---|---|
| Reader | Read-only access: browse, search, and explore entities and relationships. The role for dashboard viewers, analysts, and API consumers. |
| Editor | Everything a Reader can do, plus manually creating, editing, and deleting data. Editor changes are applied directly and are fully recorded in the audit trail — the role for trusted domain experts correcting or adding data. |
Quality — participation in data-quality review
| Role | What it allows |
|---|---|
| Curator | Reviews data-quality tasks (such as possible duplicates or competing facts) from a work queue. Curators have read access to their scope for context, but do not browse an administrative interface. |
| Arbiter | Everything a Curator can do, plus resolving cases where curators disagree. A senior, occasional role — it activates only on disagreement. |
Administrative — configuration, people, and destructive actions
This axis is a ladder: each level includes the ones below it.
| Level | Role | What it adds |
|---|---|---|
| 1 | Operator | Configures how knowledge is built for a scope — ingestion, extraction, and vocabulary settings. The knowledge-engineering role. |
| 2 | Admin | Everything an Operator can do, plus managing people and groups, adjusting scope settings, creating sub-scopes, and granting roles to others (up to their own level — an Admin cannot create Owners or grant themselves a higher role). |
| 3 | Owner | Everything an Admin can do, plus destructive, irreversible actions such as deleting data or removing a scope. Reserved for a small number of highly trusted people. |
Billing — standalone
| Role | What it allows |
|---|---|
| Billing | See cost and usage attribution for a scope. Confers no access to the knowledge graph — a billing contact cannot read a single entity or fact. |
Roles combine into profiles
Because the axes are independent, real people hold a combination. A few common profiles:
| Profile | Data access | Quality | Administrative | What they are |
|---|---|---|---|---|
| Dashboard viewer | Reader | — | — | Reads the graph, nothing else. |
| Fact-checker | Reader | Curator | — | Reviews quality tasks; reads for context. |
| Knowledge engineer | Editor | — | Operator | Shapes the pipeline and corrects data. |
| Scope manager | Reader | — | Admin | Manages people and settings; reads but does not edit. |
| Scope owner | Editor | Arbiter | Owner | Full authority at a scope. |
| Finance contact | — | — | — | Billing only; no graph access. |
How far a role reaches
A role is always granted at a specific scope. How far it extends from that scope depends on the axis:
- Administrative roles reach downward through the tree (bounded by organization walls and sealed scopes).
- Data access, quality, and billing roles apply to the named scope only — they do not cascade.
The next page, Grants, covers exactly how a role is attached to a person or group and how its reach is determined.