tegwick
a4ec38feb2
Publishes sec-authority:ModeOfAuthority v0.2.0 with machine-readable auth-modes.yaml and dimensions.yaml, and moves the v0.1 draft verbatim to research/ as provenance — it had been sitting in spec/, which the Repository Layout Standard reserves for implementation guidance. Terminology separation decided as SECURITY-DEC-2026-002 / SEC-ADR-002. The v0.1 Subject dimension becomes AuthorityContext, because InfoTechCanon's access-control model already owns Actor and Subject and binds them as "Subject is the access-control view of an actor"; reusing the pair for two distinct parties would have made one word mean two things across the canons. Operator versus OPERATE, Build Plane versus CONSTRUCT, Policy Plane versus GOVERN, Audit Plane versus EvidenceBoundary and Condition versus Activation are separated rather than merged, and Scope, AccessOperations, Purpose and PrincipalType are declared imports. Namespace sec-authority: reserved; itc-caring: and itc-access: stay upstream and are not aliased. Two of the draft's open questions are closed. CONSTRUCT stays distinct from GOVERN, the test being the object of authority — the artifact versus the constraint it must satisfy — which keeps "who may edit the policy" separable from "who decides what it must say". Substrate authority becomes a DOMINATES relation between Authority Realms carrying dominance_kind, observable and evidence_boundary, which makes the relative-sovereignty principle checkable instead of merely asserted. Orientation surfaces published: the one-page vocabulary card, the ten-question design heuristic promoted from the draft's appendix to section 3 of the artifact, the role/plane/mode disambiguation page, and the cross-layer mapping to InfoTechCanon with its deliberate blanks where one layer has no equivalent. Generalising CARING section 32 beyond non-human subjects is deliberately not bundled in; it is InfoTechCanon's to accept as a demand signal. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj Assistant: claude-code Assistant-Model: opus Assistant-Process: 36656@bnt-lap001 Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
4.4 KiB
| id | type | title | repo | status | created | relates_to |
|---|---|---|---|---|---|---|
| SEC-DISAMBIG-001 | reference | Disambiguation: role, plane, and auth mode | security-canon | draft | 2026-09-20 | 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.
Operatoris a CARING canonical role — one of Creator, Builder, Verifier, Maintainer, Integrator, Operator, Manager, Coach, Doer. It describes a lifecycle posture toward a product.OPERATEis 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).
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 |