108 lines
4.4 KiB
Markdown
108 lines
4.4 KiB
Markdown
|
---
|
||
|
|
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 |
|