---
id: SEC-DISAMBIG-001
type: reference
title: "Disambiguation: role, plane, and auth mode"
repo: security-canon
status: draft
created: "2026-09-20"
relates_to: SECURITY-DEC-2026-002
---

# Disambiguation — role, plane, and auth mode

Three vocabularies describe access in this ecosystem. They answer **three
different questions**, and several of their values rhyme. This page exists so
that a reader who meets a familiar word knows which question it belongs to.

| Axis | Question | Owner |
| --- | --- | --- |
| **Auth Mode** | In what *relationship* to the system is authority exercised? | SecurityCanon (architecture) |
| **Canonical Role** | What *lifecycle responsibility posture* does a subject hold toward the product? | InfoTechCanon CARING §11 (implementation) |
| **Plane** | Which *surface* of the system is touched? | InfoTechCanon CARING §22 (implementation) |

They compose. A Maintainer (role) may exercise `OPERATE` (mode) on the Runtime
Plane (plane). None of the three implies either of the others.

## The collisions

### `Operator` is not `OPERATE`

The sharpest one.

- **`Operator`** is a CARING canonical role — one of Creator, Builder, Verifier,
  Maintainer, Integrator, Operator, Manager, Coach, Doer. It describes a
  *lifecycle posture toward a product*.
- **`OPERATE`** is an Auth Mode. It describes *authority to change the running
  state of an instantiated system*.

A Maintainer can exercise `OPERATE`. An Operator can exercise `OBSERVE`. The two
are independent. When ambiguity is possible, write "the Operator role" or
"`OPERATE` mode" — never bare *operator*.

### `Build Plane` is not `CONSTRUCT`

Closest in meaning, still different: the plane names the *surface*, the mode
names the *authority over it*. `CONSTRUCT @ build-plane` is well formed and says
something the plane alone does not.

### `Policy Plane` is not `GOVERN`

The Policy Plane is where policy objects live. `GOVERN` is authority over
authority. An administrator may hold `ADMINISTER` over the Policy Plane —
editing policy objects — without holding `GOVERN`, which decides what the policy
must require. Keeping these apart is the point; see the vocabulary §10.1.

### `Audit Plane` is not `Evidence Boundary`

Genuinely different concepts. The Audit Plane is a surface. The Evidence
Boundary is a *trust question*: can the observed actor alter, suppress or bypass
the evidence used to observe it? A system can have a rich Audit Plane and a
worthless Evidence Boundary.

### `Condition` and `activation`

CARING's Condition dimension and Auth Mode's `activation` overlap
substantially. `activation` is the architecture-layer term with the enumerated
set (`STANDING`, `JUST_IN_TIME`, `BREAK_GLASS`, …); CARING's Condition is the
implementation-layer expression. Use `activation` when describing intent; use
Condition when analysing an implementation.

### `Capability` and `AccessOperations`

CARING's Capability dimension is richer and is the implementation-layer
authority. `AccessOperations` is imported from InfoTechCanon's access-control
model. Auth Mode does not define its own operation vocabulary.

### `Subject` — the one that was renamed

InfoTechCanon's access-control model owns `Actor` and `Subject`, and binds them:

> Subject is the access-control view of an actor.

The Mode of Authority v0.1 draft used the same two words for **two distinct
parties**, one acting on behalf of the other. That would have made `Subject`
mean two different things across the canons, so the vocabulary renamed its
dimension to **`AuthorityContext`**
([SECURITY-DEC-2026-002](../decisions/decisions.md)).

If you are reading the v0.1 draft in `research/`, its `subject =` field is the
current `authority_context =`.

## Quick lookup

| If you read… | It belongs to… | Meaning |
| --- | --- | --- |
| `OPERATE` | Auth Mode | authority over running state |
| Operator | CARING role | lifecycle posture |
| Runtime Plane | CARING plane | surface |
| `CONSTRUCT` | Auth Mode | authority over definitions |
| Builder | CARING role | lifecycle posture |
| Build Plane | CARING plane | surface |
| `GOVERN` | Auth Mode | authority over authority |
| Policy Plane | CARING plane | surface |
| Evidence Boundary | Auth Mode dimension | can evidence be compromised? |
| Audit Plane | CARING plane | surface |
| `AuthorityContext` | Auth Mode dimension | whose authority is drawn on |
| Subject | InfoTechCanon access control | the access-control view of an actor |
| Delegator | CARING §32 | who delegated, for non-human subjects |