---
id: SEC-ADR-002
decision_record: SECURITY-DEC-2026-002
type: adr
title: "Terminology separation between Auth Mode and the implementation layer"
repo: security-canon
status: accepted
decided: "2026-09-20"
implements: SEC-ADR-001 D2
---

# SEC-ADR-002 — Terminology separation

Applies [SEC-ADR-001](adr-001-securitycanon-boundary.md) D2 — *different layers
must not use the same word for different things* — to the concrete overlaps
between the Mode of Authority vocabulary, InfoTechCanon's access-control model,
and CARING.

## Decision

### D1 — `Subject` becomes `AuthorityContext`

InfoTechCanon's access-control model §11.2 owns `Actor` and `Subject` and binds
them: *"Subject is the access-control view of an actor."* The v0.1 draft used the
same two words for two distinct parties. The vocabulary renames its dimension to
**`AuthorityContext`**, with a companion `relation` field taking `DELEGATED` or
`IMPERSONATED`.

`Actor` is kept, because MoA's use is compatible with the Organization Model's
ownership of actor semantics. `AuthorityContext` names what the field holds —
the authority drawn on — which stays accurate when the target is a role or
mandate rather than a person.

Rejected: adopting CARING's `Principal`/`Delegator` naming, which would import
implementation vocabulary into the architecture layer; and changing InfoTechCanon,
which would edit a release-candidate standard and eleven dependent models to
accommodate a draft.

### D2 — Overlapping dimensions are separated, not merged

| Pair | Resolution |
| --- | --- |
| `Operator` role vs `OPERATE` mode | Both kept — different axes. Never write bare *operator*; the [disambiguation page](disambiguation.md) is the required companion. |
| `Build Plane` vs `CONSTRUCT` | Both kept. Plane is the surface, mode is the authority over it. `CONSTRUCT @ build-plane` is well formed. |
| `Policy Plane` vs `GOVERN` | Both kept. `ADMINISTER` over the Policy Plane is not `GOVERN`. |
| `Audit Plane` vs `EvidenceBoundary` | Both kept — genuinely different. A rich Audit Plane may accompany a worthless Evidence Boundary. |
| CARING `Condition` vs `Activation` | Both kept as layer expressions of one idea. `Activation` is the architecture term. |
| CARING `Capability` vs `AccessOperations` | No new term. Imported from InfoTechCanon's access-control model. |
| `Scope` | One definition, InfoTechCanon's, imported. |

### D3 — Namespace

The vocabulary takes `sec-authority:`. `itc-caring:` and `itc-access:` stay with
InfoTechCanon and are not aliased.

### D4 — CARING §32 generalisation is not bundled here

Generalising CARING's `Principal / effective actor / Delegator / audit identity`
role set beyond non-human subjects would be additive and non-breaking, and would
close the human-on-human impersonation gap. It is InfoTechCanon's to accept, and
is raised there as a demand signal on its own merits. **Nothing in SecurityCanon
blocks on it.**

## Consequences

- The v0.1 draft's `subject =` field reads as `authority_context =` in the
  promoted vocabulary; the draft is retained verbatim in `research/` and the
  rename is recorded in its §12 change list.
- A [disambiguation page](disambiguation.md) is a permanent part of the canon's
  orientation surface, not a transitional aid.
- The [mapping](../infospace/mappings/mode-of-authority-to-infotechcanon.md)
  carries the cross-layer relationships, including the deliberate blanks where
  one layer has no equivalent.