diff --git a/.repo-manager/index.json b/.repo-manager/index.json index c85dcb6..4281bc8 100644 --- a/.repo-manager/index.json +++ b/.repo-manager/index.json @@ -2,9 +2,9 @@ "schema": "repo_manager.index.v1", "slug": "security-canon", "repo_root": "/home/worsch/security-canon", - "head_sha": "55b57382ffc60db70eecddb283a880f9a4ac7bbb", - "observed_at": "2026-09-20T19:36:23.067664Z", - "source_fingerprint": "a1728e9ad28986c53662b1955b58d84f038af9b211c82dba8a8bd23b9c1e9335", + "head_sha": "be6b0631ce639d743a822f80c0f8d7f4a6d3347d", + "observed_at": "2026-09-20T19:42:55.115596Z", + "source_fingerprint": "f13b65255a16d0a8daec0cd40d04c406493b7ff394252a0afeb22faa1117227d", "source_files": [ ".repo-classification.yaml", "INTENT.md", @@ -75,7 +75,7 @@ { "kind": "task", "id": "SECURITY-WP-0001-T06", - "status": "todo", + "status": "done", "title": "Promote Mode of Authority into a canon artifact", "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", "uuid": "de5fc42c-2e18-5f03-b86c-a5ad45a9bb0a", @@ -85,7 +85,7 @@ { "kind": "task", "id": "SECURITY-WP-0001-T07", - "status": "todo", + "status": "done", "title": "Decide the terminology separation", "source_path": "workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md", "uuid": "4a0d3df9-d8a2-51c4-a4bc-72488d866068", @@ -98,7 +98,7 @@ "status": "accepted", "title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary", "source_path": "decisions/decisions.md", - "uuid": null, + "uuid": "f6496e7d-4622-4cc6-b5b1-b62172dd148e", "parent_id": null, "extra": { "record": { @@ -107,7 +107,27 @@ "title": "SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary", "status": "accepted", "created": "2026-09-20T19:30:50.120170Z", - "updated": "2026-09-20T19:30:50.120170Z" + "updated": "2026-09-20T19:30:50.120170Z", + "state_hub_decision_id": "f6496e7d-4622-4cc6-b5b1-b62172dd148e" + } + } + }, + { + "kind": "decision", + "id": "SECURITY-DEC-2026-002", + "status": "accepted", + "title": "Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition", + "source_path": "decisions/decisions.md", + "uuid": null, + "parent_id": null, + "extra": { + "record": { + "id": "SECURITY-DEC-2026-002", + "kind": "decision", + "title": "Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition", + "status": "accepted", + "created": "2026-09-20T19:42:12.263921Z", + "updated": "2026-09-20T19:42:12.263921Z" } } } @@ -118,7 +138,7 @@ "workplan_count": 1, "task_count": 7, "source": "repo-manager", - "emitted_at": "2026-09-20T19:36:23.067751Z" + "emitted_at": "2026-09-20T19:42:55.115676Z" } ] } diff --git a/README.md b/README.md index 277f6e4..d38ad48 100644 --- a/README.md +++ b/README.md @@ -30,11 +30,23 @@ Agent instructions are in [AGENTS.md](AGENTS.md); active work is in | Document | What it holds | | --- | --- | | [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md) | the boundary decision — what stays upstream, and why | +| [SEC-ADR-002](docs/adr-002-terminology-separation.md) | the terminology separation — why `AuthorityContext`, not `Subject` | | [Mode of Authority assessment](history/260920-mode-of-authority-and-canon-structure.md) | review of the v0.1 draft and the proposed canon structure | | [Actor/Subject implications](docs/260920-actor-subject-implications.md) | the one open terminology question, analysed | ## Status -Bootstrap. The repository is registered and governed. Its only content is the -Mode of Authority v0.1 research draft, not yet promoted into a canon artifact. -See [SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md). +Draft. The Mode of Authority vocabulary is published as a canon artifact with +machine-readable modes and dimensions; the v0.1 research draft is retained in +`research/` as provenance. Stable promotion needs reviewed mappings and concrete +consumer evidence. See +[SECURITY-WP-0001](workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md). + +## Orientation + +| Start here | For | +| --- | --- | +| [Vocabulary card](docs/vocabulary-card.md) | the seven modes and the notation, on one page | +| [Mode of Authority](infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md) | the canon artifact | +| [Disambiguation](docs/disambiguation.md) | *operator* or `OPERATE`? role, plane, or mode? | +| [Mapping to InfoTechCanon](infospace/mappings/mode-of-authority-to-infotechcanon.md) | how it relates to the access-control model and CARING | diff --git a/decisions/decisions.md b/decisions/decisions.md index fecc81f..21104bb 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -12,3 +12,15 @@ created: '2026-09-20T19:30:50.120170Z' updated: '2026-09-20T19:30:50.120170Z' state_hub_decision_id: "f6496e7d-4622-4cc6-b5b1-b62172dd148e" ``` + +## SECURITY-DEC-2026-002 — Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition + +```yaml +id: SECURITY-DEC-2026-002 +kind: decision +title: 'Terminology separation: Auth Mode renames Subject to AuthorityContext; no + upstream redefinition' +status: accepted +created: '2026-09-20T19:42:12.263921Z' +updated: '2026-09-20T19:42:12.263921Z' +``` diff --git a/docs/adr-002-terminology-separation.md b/docs/adr-002-terminology-separation.md new file mode 100644 index 0000000..fd33a56 --- /dev/null +++ b/docs/adr-002-terminology-separation.md @@ -0,0 +1,73 @@ +--- +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. diff --git a/docs/disambiguation.md b/docs/disambiguation.md new file mode 100644 index 0000000..b254f66 --- /dev/null +++ b/docs/disambiguation.md @@ -0,0 +1,107 @@ +--- +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 | diff --git a/docs/vocabulary-card.md b/docs/vocabulary-card.md new file mode 100644 index 0000000..37f9bc8 --- /dev/null +++ b/docs/vocabulary-card.md @@ -0,0 +1,80 @@ +--- +id: SEC-CARD-001 +type: reference +title: "Auth Mode vocabulary card" +repo: security-canon +status: draft +created: "2026-09-20" +source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md +--- + +# Auth Mode — vocabulary card + +One page. Full definitions in +[SecurityCanonModeOfAuthority](../infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md). + +## Notation + +```text +MODE @ SCOPE + +alice: + ADMINISTER @ tenant/acme + activation = JUST_IN_TIME + duration = 2h + +support-agent: + USE @ tenant/acme + authority_context = customer-42 + relation = IMPERSONATED + +recovery-principal: + SOVEREIGN @ identity-realm + activation = BREAK_GLASS + evidence = EXTERNAL +``` + +## The seven modes + +| Mode | Question | One-line test | +| --- | --- | --- | +| `USE` | How do I get the value the system exists to provide? | domain purpose | +| `OBSERVE` | What is this system doing? | knowledge about, not value from | +| `OPERATE` | How do I keep it functioning? | changes running state, not definition | +| `ADMINISTER` | How do I configure it within the rules? | inside rules set elsewhere | +| `GOVERN` | What rules constrain authority? | decides what admins may decide | +| `CONSTRUCT` | What can future versions be? | changes definitions, not instances | +| `SOVEREIGN` | How is the regime established or recovered? | at or beyond the authority boundary | + +**Not a ladder.** These classify the kind of authority, not the amount. + +## Dimensions + +| Dimension | Values | +| --- | --- | +| `activation` | `STANDING` `JUST_IN_TIME` `SCHEDULED` `APPROVED` `INCIDENT` `BREAK_GLASS` `RECOVERY` | +| `provenance` | `LOCAL` `PARENT_SCOPE` `SUBSTRATE` `DELEGATED` `FEDERATED` `ASSUMED` `IMPERSONATED` | +| `environment` | `DEVELOPMENT` `TEST` `STAGING` `PRODUCTION` `RECOVERY` | +| `evidence` | `target-audited` `external-audited` `substrate-audited` `multi-party-audited` `outside-audit-boundary` | +| `principal_type` | `HUMAN` `WORKLOAD` `SERVICE` `AGENT` `CONTROLLER` `DEVICE` *(imported)* | +| `relation` | `DELEGATED` `IMPERSONATED` | + +## The ten questions + +```text +1. Who is the actor? 6. Where does the authority originate? +2. On whose authority? 7. Under what conditions is it activated? +3. What Auth Mode? 8. What realm enforces it? +4. Over what scope? 9. Who preserves the evidence? +5. What operations? 10. Who can override enforcement? +``` + +## Common translations + +```text +auditor → OBSERVE @ evidence +developer → CONSTRUCT @ product +backup operator → OPERATE @ backup-system +break-glass → , activation=BREAK_GLASS +"has root" → SOVEREIGN @ host (say the scope) +``` diff --git a/infospace/mappings/mode-of-authority-to-infotechcanon.md b/infospace/mappings/mode-of-authority-to-infotechcanon.md new file mode 100644 index 0000000..ce20d3c --- /dev/null +++ b/infospace/mappings/mode-of-authority-to-infotechcanon.md @@ -0,0 +1,120 @@ +--- +id: sec-authority:MoAToInfoTechCanonMapping +title: Mode of Authority to InfoTechCanon mapping +type: mapping +namespace: sec-authority +version: 0.1.0 +status: draft +source_artifact: sec-authority:ModeOfAuthority +target_repository: info-tech-canon +target_artifacts: + - itc-access:AccessControlModel + - itc-caring:CaringAccessGovernanceStandard +decisions: + - SECURITY-DEC-2026-001 + - SECURITY-DEC-2026-002 +--- + +# Mode of Authority → InfoTechCanon mapping + +Relates the architecture-layer vocabulary to the two InfoTechCanon artifacts +that speak about the same subject at the implementation layer. Per +[SEC-ADR-001](../../docs/adr-001-securitycanon-boundary.md) this is a mapping, +not a merge: neither side is rewritten to match the other. + +## 1. Entity vocabulary + +| Mode of Authority | ITC access control | CARING | Relationship | +| --- | --- | --- | --- | +| `Actor` | `Subject`, `Principal` | `Principal`, effective actor | imported — ITC owns actor semantics via the Organization Model | +| `AuthorityContext` | — | `Delegator` | refines; CARING scopes it to non-human subjects | +| `relation = DELEGATED` | `delegation` | Delegated Access §33.2 | same concept, three granularities | +| `relation = IMPERSONATED` | — | customer impersonation; `ImpersonationBlocked` §29 | CARING adds the restriction | +| `PrincipalType` | — | Subject dimension §9 | imported from the ITC identity model | +| — | — | audit identity, capability ceiling | **no architecture-layer equivalent** | +| — | — | Mediated §33.3, Induced §33.4 access | **no architecture-layer equivalent** | + +The blank cells are informative rather than defects. Capability ceilings and +induced access paths are implementation findings; the architecture layer has no +business asserting them. + +## 2. Dimension vocabulary + +| Mode of Authority | CARING | Relationship | +| --- | --- | --- | +| `AuthMode` | Canonical Role §11, Plane §22 | **orthogonal** — three different questions, see [disambiguation](../../docs/disambiguation.md) | +| `Scope` | Scope §21 | imported from ITC access control; one definition | +| `AccessOperations` | Capability §23 | imported; CARING's is the richer implementation form | +| `Activation` | Condition §26 | same idea; `Activation` is the architecture term | +| `Environment` | — | architecture-layer only | +| `EvidenceBoundary` | Audit Plane §22.10 | **different** — surface versus trust question | +| `AuthorityProvenance` | — | architecture-layer only | +| `AuthorityRealm`, `DOMINATES` | — | architecture-layer only; models substrate authority | +| — | Exposure Mode §25, Exposure Event §29 | implementation-layer only | +| — | Lifecycle State §27, Restriction §28 | implementation-layer only | +| — | Organization Relation §10 | implementation-layer only | + +## 3. Mode-to-plane affinity + +Affinity, not equivalence. A mode may touch any plane; these are the common +pairings, useful for orientation and not normative. + +| Auth Mode | Planes most often touched | +| --- | --- | +| `USE` | Data, Execution, Commercial, Community | +| `OBSERVE` | Audit, Runtime, Data | +| `OPERATE` | Runtime, Execution | +| `ADMINISTER` | Configuration, Identity, Policy, Secret | +| `GOVERN` | Policy, Intent | +| `CONSTRUCT` | Build, Intent, Configuration | +| `SOVEREIGN` | Identity, Secret, Policy | + +## 4. Mode-to-canonical-role affinity + +Also affinity only. CARING roles describe lifecycle posture; a role does not +grant a mode. + +| CARING role | Modes commonly exercised | +| --- | --- | +| Creator | `GOVERN`, `CONSTRUCT` | +| Builder | `CONSTRUCT` | +| Verifier | `OBSERVE` | +| Maintainer | `CONSTRUCT`, `OPERATE` | +| Integrator | `CONSTRUCT`, `ADMINISTER` | +| Operator | `OPERATE`, `OBSERVE` | +| Manager | `ADMINISTER`, `GOVERN` | +| Coach | `OBSERVE`, `USE` with `authority_context` | +| Doer | `USE` | + +Note the Operator row: the role and the `OPERATE` mode are not the same thing, +and the row says only that they frequently co-occur. + +## 5. Direction of import + +```text +InfoTechCanon ──owns──> Actor, Subject, Principal, Scope, + AccessOperations, PrincipalType, Purpose + │ + │ imported by + ▼ +SecurityCanon ──owns──> AuthMode, AuthorityContext, AuthorityRealm, + AuthorityProvenance, Activation, EvidenceBoundary + │ + │ referenceable by + ▼ +CARING ──owns──> Canonical Role, Plane, Capability, Exposure, + Lifecycle State, Restriction, Organization Relation +``` + +Nothing flows upward as a redefinition. CARING may reference the vocabulary; +the vocabulary imports from the shared roots; the shared roots know nothing of +either. + +## 6. Open + +- Whether CARING generalises its §32 role set beyond non-human subjects. Additive + and non-breaking if adopted, but it is InfoTechCanon's to accept — raise as a + demand signal there, not as a change here. Analysis in the + [implications note](../../docs/260920-actor-subject-implications.md) §4. +- Whether `AuthMode` becomes a machine-readable authorization attribute + consumable by CARING descriptors (v0.1 draft Q7). diff --git a/infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md b/infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md new file mode 100644 index 0000000..e4d8a68 --- /dev/null +++ b/infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md @@ -0,0 +1,376 @@ +--- +id: sec-authority:ModeOfAuthority +title: SecurityCanon Mode of Authority +short_name: AUTH-MODE +type: model +standard_family: SecurityCanon +repository_context: security-canon +recommended_path: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md +status: draft +version: 0.2.0 +source_version: "0.1" +source_file: research/260920-mode-of-authority-v0.1.md +canonical_owner: SecurityCanonModeOfAuthority +namespace: sec-authority +classification: vocabulary +abstraction_layer: architecture +primary_cluster: authority +imports: + - InfoTechCanonCore + - InfoTechCanonAccessControlModel + - InfoTechCanonIdentityModel + - InfoTechCanonOrganizationModel + - InfoTechCanonPurposesExtension +related: + - InfoTechCanonCaringAccessGovernanceStandard + - InfoTechCanonSecurityModel +owned_concepts: + - AuthMode + - AuthorityContext + - AuthorityRealm + - AuthorityProvenance + - Activation + - EvidenceBoundary + - AccessSituation +decisions: + - SECURITY-DEC-2026-001 + - SECURITY-DEC-2026-002 +--- + +# SecurityCanon Mode of Authority + +**Short name:** `AUTH-MODE` · **Concept:** Mode of Authority · **Term:** Auth Mode + +Promoted from the [v0.1 research draft](../../../research/260920-mode-of-authority-v0.1.md), +which is retained verbatim as provenance. Changes from v0.1 are listed in §12. + +## 1. Purpose + +This vocabulary answers one question that permission and role models do not +answer directly: + +> **In what relationship to a system is an actor exercising authority?** + +That relationship is the actor's **Mode of Authority**, or **Auth Mode**. + +A Mode of Authority is: + +> A semantic classification of the intended relationship between an actor and a +> system scope, describing the nature and purpose of the authority being +> exercised. + +An Auth Mode does not itself define individual permissions. + +## 2. Layer + +This is an **architecture-layer** vocabulary. It describes authority +relationships before and independently of the mechanisms that enforce them. + +Per [SEC-ADR-001](../../../docs/adr-001-securitycanon-boundary.md), the +implementation layer is owned by InfoTechCanon's CARING standard, which analyses +how an access-control implementation is actually composed. The two layers are +complementary and neither subsumes the other. + +| | Mode of Authority | CARING | +| --- | --- | --- | +| Question | In what relationship is authority exercised? | How is this implementation composed? | +| Layer | architecture | implementation | +| Owner | SecurityCanon | InfoTechCanon | + +## 3. Orientation — start here + +Ask these ten questions, in order. They are the intended entry point to this +vocabulary, not an appendix to it. + +```text +1. Who is the actor? +2. On whose authority is it acting? +3. What Auth Mode is being exercised? +4. Over what scope? +5. What operations are permitted? +6. Where does the authority originate? +7. Under what conditions is it activated? +8. What authority realm enforces it? +9. Who observes and preserves evidence? +10. Who can override the enforcement mechanism? +``` + +This produces substantially clearer security descriptions than the labels +`user`, `admin`, `superadmin`, `root` alone. + +## 4. Distinction from access mode + +An **access operation** — read, write, execute, delete, approve — describes +*what operation may be performed on a resource*. An Auth Mode describes *in what +relationship the actor stands to the system*. The two axes are orthogonal: + +```text +read + USE → reading a customer's document +read + OBSERVE → reading telemetry about the document service +``` + +The access operation is `read` in both cases. The Auth Mode differs. Access +operations are owned by InfoTechCanon's access-control model and imported here. + +## 5. The seven Auth Modes + +| Auth Mode | Fundamental question | +| --- | --- | +| **USE** | How do I obtain the value this system exists to provide? | +| **OBSERVE** | What is this system doing? | +| **OPERATE** | How do I keep this instantiated system functioning? | +| **ADMINISTER** | How do I configure this system within existing rules? | +| **GOVERN** | What rules constrain how authority may be exercised? | +| **CONSTRUCT** | How do I change what future incarnations of this system can be? | +| **SOVEREIGN** | How is the authority regime itself established, recovered or replaced? | + +Machine-readable definitions, including intent, typical actions and boundary +cases, are in [`auth-modes.yaml`](auth-modes.yaml). + +## 6. Principles + +### A1 — Authority is scope-relative + +There is no meaningful authority without a scope. Authority at one scope does +not automatically imply authority at another. + +### A2 — Mode and privilege magnitude are different concepts + +Auth Modes are not a privilege ladder. `USE < ADMINISTER < SOVEREIGN` must not +be treated as the semantic model. An auditor may OBSERVE what administrators +cannot see; a developer may CONSTRUCT production behaviour with no production +access; a governor may constrain administrators without being able to perform +their operational tasks. + +### A3 — Auditability is independent of Auth Mode + +Auditability depends on the **Evidence Boundary**, not the mode. The central +question is whether the actor being observed can alter, suppress, bypass or +invalidate the evidence used to observe it. Sovereign authority does not +necessarily mean unaudited authority. + +### A4 — Federation does not imply authorization + +Federation establishes trusted assertions between independent authority realms. +The receiving realm decides independently what the asserted identity may do. + +### A5 — Sovereignty is relative, not absolute + +There need not be a universal root. `SOVEREIGN @ database` does not imply +`SOVEREIGN @ host`; `SOVEREIGN @ tenant` does not imply `SOVEREIGN @ platform`. + +### A6 — Naming does not collide with the implementation layer *(new in 0.2.0)* + +Where InfoTechCanon owns a term, this vocabulary imports it rather than +redefining it, and where this vocabulary needs a distinct concept it takes a +distinct name. See [SECURITY-DEC-2026-002](../../../decisions/decisions.md) and +§9. + +## 7. Dimensions + +An **Access Situation** is the complete context in which authority is exercised: + +```text +AccessSituation = + Actor + × AuthorityContext + × AuthMode + × Scope + × AccessOperations + × AuthorityProvenance + × Activation + × Environment + × EvidenceBoundary + × Time + × Purpose +``` + +Not every implementation materialises every dimension; the model exists to +support precise reasoning. + +| Dimension | Owner | Note | +| --- | --- | --- | +| Actor | InfoTechCanon Organization Model | imported | +| **AuthorityContext** | SecurityCanon | renamed from v0.1 `Subject`, see §9 | +| **AuthMode** | SecurityCanon | the seven modes | +| Scope | InfoTechCanon access-control model | imported | +| AccessOperations | InfoTechCanon access-control model | imported | +| **AuthorityProvenance** | SecurityCanon | `LOCAL`, `PARENT_SCOPE`, `SUBSTRATE`, `DELEGATED`, `FEDERATED`, `ASSUMED`, `IMPERSONATED` | +| **Activation** | SecurityCanon | `STANDING`, `JUST_IN_TIME`, `SCHEDULED`, `APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY` | +| Environment | SecurityCanon | `DEVELOPMENT`, `TEST`, `STAGING`, `PRODUCTION`, `RECOVERY` | +| **EvidenceBoundary** | SecurityCanon | who observes and preserves evidence, and who can compromise it | +| Time | — | not modelled in 0.2.0 | +| Purpose | InfoTechCanon PURPOSES extension | imported, not redefined here | +| PrincipalType | InfoTechCanon identity model | imported; `HUMAN`, `WORKLOAD`, `SERVICE`, `AGENT`, `CONTROLLER`, `DEVICE` | + +Machine-readable definitions are in [`dimensions.yaml`](dimensions.yaml). + +Auth Modes apply independently of principal type. Principal type must not be +encoded into the Auth Mode taxonomy. + +## 8. Authority Realm + +An **Authority Realm** is a scope possessing an independently meaningful +authority boundary — an operating system, a database, a Kubernetes cluster, a +cloud account or organization, an identity realm, a SaaS tenant, a trust domain. + +A realm may possess its own SOVEREIGN, GOVERN, ADMINISTER, OPERATE, OBSERVE and +USE authorities. Realms need not share a common sovereign. A federation may hold +`GOVERN @ federation` without holding `SOVEREIGN @ member-realms`, so a genuine +federation need not contain a global root. + +## 9. Actor and Authority Context + +Authority is sometimes exercised on behalf of another party. + +- **Actor** — the entity actually performing the action. +- **Authority Context** — the authority being drawn on, when it is not the + actor's own. + +Normally the actor acts on its own authority and the dimension is absent. When +it does not: + +```text +support-agent: + USE @ tenant/acme + authority_context = customer-42 + relation = IMPERSONATED +``` + +**Delegation** means the actor retains its identity while exercising delegated +authority. **Impersonation** means the actor acts within another party's +authority context. Neither is an Auth Mode; both describe *how* authority is +exercised, and the underlying mode may still be USE, OPERATE, ADMINISTER or any +other. + +> **Renamed in 0.2.0.** The v0.1 draft called this dimension `Subject`. +> InfoTechCanon's access-control model already owns both `Actor` and `Subject` +> and binds them differently — "Subject is the access-control view of an actor" — +> so reusing the pair for two distinct parties would have made the same word mean +> two things across the canons. `AuthorityContext` names what the field holds, +> which stays accurate when the target is a role or mandate rather than a person. +> See [SECURITY-DEC-2026-002](../../../decisions/decisions.md) and the +> [implications note](../../../docs/260920-actor-subject-implications.md). + +CARING §32 carries a richer form of this distinction — Principal, effective +actor, Delegator, audit identity, capability ceiling — scoped to non-human +subjects. The relationship is recorded as a +[mapping](../../mappings/mode-of-authority-to-infotechcanon.md), not a +redefinition. + +## 10. Positions on the v0.1 open questions + +### 10.1 CONSTRUCT and GOVERN are distinct — the artifact does not decide it + +v0.1 asked whether policy-as-code blurs CONSTRUCT and GOVERN. **Position: they +remain distinct, and the distinguishing test is the object of authority, not the +medium.** + +```text +CONSTRUCT authority over definitions from which behaviour is produced +GOVERN authority over the rules constraining how authority is exercised +``` + +Policy-as-code is an artifact *and* a rule, so an actor may hold both modes over +it — and that is the point, not a defect: + +```text +platform-engineer: + CONSTRUCT @ policy-repo/authz # may change the policy source + # but NOT GOVERN @ organization # may not decide what the policy must say + +security-governor: + GOVERN @ organization # decides what the policy must require + # but NOT CONSTRUCT @ policy-repo # does not write or merge it +``` + +The separation is the security property worth having: whoever can edit the +policy file should generally not be the one who decides what it must contain. +Collapsing the two modes would make that separation inexpressible. The test is +therefore: + +> Does the actor change the *artifact* (CONSTRUCT) or decide the *constraint* +> the artifact must satisfy (GOVERN)? An actor holding both over the same scope +> is a finding, not a modelling error. + +### 10.2 Substrate authority is a relation between realms + +v0.1 named substrate authority — hypervisor over VM, host root over container, +cloud provider over tenant — but recorded it only as +`AuthorityProvenance = SUBSTRATE`, which names the fact without modelling which +realm dominates which. + +**Position: substrate authority is a relation between Authority Realms, not a +mode and not a provenance value alone.** It is written: + +```text +realm:host/node-7 DOMINATES realm:container/app-3 +realm:cloud/aws-account-1 DOMINATES realm:tenant/acme +``` + +with three properties, which are what actually matter in analysis: + +| Property | Question | +| --- | --- | +| `dominance_kind` | execution substrate, storage substrate, identity substrate, network substrate? | +| `observable` | can the dominated realm detect the dominating realm's exercise of authority? | +| `evidence_boundary` | does the dominated realm's evidence survive the dominating realm? | + +This makes A5 checkable. `SOVEREIGN @ container` is true within its realm and +simultaneously dominated by `SOVEREIGN @ host` — with no contradiction, and with +the security consequence stated explicitly rather than implied. + +`AuthorityProvenance = SUBSTRATE` is retained: it marks authority that *arrives* +through a dominance relation, while the relation itself records the structure. + +### 10.3 Still open + +Q1 (are seven modes sufficient), Q4 (decomposing sovereignty), Q5 (mutually +constraining sovereigns), Q6 (autonomous agents modifying their own future +authority) and Q7 (Auth Mode as a machine-readable ABAC attribute) remain open +and are carried in the [v0.1 draft](../../../research/260920-mode-of-authority-v0.1.md) §31. + +## 11. What is deliberately not an Auth Mode + +`AUDIT`, `SECURITY`, `SUPPORT`, `BACKUP`, `DEVELOPER`, `OWNER`, `BILLING`, +`AUTOMATION`, `AGENT`, `FEDERATION`, `BREAK_GLASS`, `SUPERADMIN`, `ROOT`. + +Each is representable as a composition: + +```text +auditor → OBSERVE @ evidence +backup operator → OPERATE @ backup-system +developer → CONSTRUCT @ product +security administrator → ADMINISTER @ security-controls +security policy owner → GOVERN @ security-controls +break-glass admin → ADMINISTER, activation=BREAK_GLASS +``` + +`root` is an implementation-specific manifestation of sovereign or broad +authority, not a mode. Prefer `SOVEREIGN @ host` or `ADMINISTER @ cluster` over +"has root". + +A new Auth Mode is introduced only when a recurring authority relationship +cannot be expressed as an existing mode plus scope, operation, provenance, +activation and purpose. + +## 12. Changes from v0.1 + +| Change | Reason | +| --- | --- | +| `Subject` dimension renamed to `AuthorityContext` | collision with InfoTechCanon-owned `Actor`/`Subject` binding (§9) | +| Scope, AccessOperations, Purpose, PrincipalType declared as imports | InfoTechCanon owns them; SEC-ADR-001 D2 | +| Principle A6 added | naming separation made explicit | +| Position taken on CONSTRUCT vs GOVERN | §10.1; was open question Q2 | +| Substrate authority modelled as realm dominance | §10.2; was open question Q3 | +| Design heuristic moved to §3 | it is the entry point, not an appendix | +| Machine-readable modes and dimensions added | `auth-modes.yaml`, `dimensions.yaml` | +| Artifact frontmatter, id, namespace, owned concepts added | makes it a canon artifact rather than a paper | + +## 13. Status + +**Draft.** Stable promotion requires reviewed mappings and concrete consumer +evidence, per [INTENT.md](../../../INTENT.md). The research hypothesis — that +seven modes suffice without platform-specific additions — has not yet been +stress-tested against Unix, databases, Kubernetes, cloud IAM, identity +platforms, secrets management, CI/CD or agentic systems. diff --git a/infospace/vocabulary/mode-of-authority/auth-modes.yaml b/infospace/vocabulary/mode-of-authority/auth-modes.yaml new file mode 100644 index 0000000..a69a4e6 --- /dev/null +++ b/infospace/vocabulary/mode-of-authority/auth-modes.yaml @@ -0,0 +1,97 @@ +id: sec-authority:AuthModeCatalog +title: SecurityCanon Auth Mode Catalog +type: catalog +namespace: sec-authority +version: 0.2.0 +status: draft +source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md +notation: "MODE @ SCOPE" +non_ordered: true +non_ordered_note: >- + Auth Modes classify the kind of authority, not its magnitude. This list is not + a privilege ladder and must not be compared ordinally. + +auth_modes: + - id: USE + intent: Exercise the system for its designated domain purpose. + question: How do I obtain the value this system exists to provide? + typical_actions: [send a message, edit a document, place an order, query application data, consume an API] + boundary: >- + USE does not imply low privilege. A business user may perform highly + consequential actions entirely within USE. + contrast: + OBSERVE: reading a customer invoice is USE; reading latency metrics for the invoice service is OBSERVE + + - id: OBSERVE + intent: Establish knowledge about the system, its behavior or its state. + question: What is this system doing? + typical_actions: [read logs, view metrics, inspect traces, read audit records, examine security events] + boundary: >- + Distinct from ordinary read access. The access operation may be identical; + the relationship to the system differs. + contrast: + USE: understanding the system rather than obtaining its domain value + + - id: OPERATE + intent: >- + Maintain or change the operational state of an instantiated system while + preserving its intended definition. + question: How do I keep this instantiated system functioning? + typical_actions: [start, stop, restart, scale, fail over, restore, drain a node, terminate a stuck process] + boundary: Changes running state, not definition. + contrast: + ADMINISTER: restarting a database is OPERATE; changing its authentication configuration is ADMINISTER + + - id: ADMINISTER + intent: Configure resources and delegated authority within an established governance regime. + question: How do I configure this system within existing rules? + typical_actions: [configure resources, create users, assign roles, manage groups, provision resources, delegate bounded authority] + boundary: >- + Operates inside rules established elsewhere. Broad discretion does not + include redefining the constraints on that discretion. + contrast: + GOVERN: assigning application roles is ADMINISTER; deciding which roles administrators may assign is GOVERN + + - id: GOVERN + intent: Define the rules under which authority may be exercised. + question: What rules constrain how authority may be exercised? + typical_actions: [set policy ceilings, define delegation rules, set separation-of-duty requirements, decide allowed identity providers] + boundary: Authority over authority. + test: Can this actor decide what another administrator is allowed to decide? + contrast: + CONSTRUCT: GOVERN decides the constraint; CONSTRUCT changes the artifact that must satisfy it + + - id: CONSTRUCT + intent: Change definitions or artifacts from which system behavior is produced. + question: How do I change what future incarnations of this system can be? + typical_objects: [source code, infrastructure-as-code, build definitions, container images, schemas, policy-as-code, CI/CD pipelines] + boundary: >- + Authority over the possible future system, not necessarily over the + running instance. Substantial CONSTRUCT authority may coexist with no + production runtime authority. + contrast: + ADMINISTER: ADMINISTER changes the instantiated system; CONSTRUCT changes definitions capable of producing systems + + - id: SOVEREIGN + intent: Establish, recover, replace or bypass the normal authority regime of a scope. + question: How is the authority regime itself established, recovered or replaced? + typical_situations: [initial bootstrap, establishing trust roots, root-account recovery, rebuilding the control plane, restoring authority after catastrophic failure] + boundary: >- + Sovereign relative to a defined scope and authority boundary, never + all-powerful everywhere. SOVEREIGN @ database does not imply SOVEREIGN @ host. + see_also: Evidence Boundary — sovereign authority is not necessarily unaudited + +not_auth_modes: + - {term: AUDIT, expressed_as: "OBSERVE @ evidence"} + - {term: BACKUP, expressed_as: "OPERATE @ backup-system"} + - {term: DEVELOPER, expressed_as: "CONSTRUCT @ product"} + - {term: SUPPORT, expressed_as: "USE or ADMINISTER with authority_context and relation=IMPERSONATED"} + - {term: BREAK_GLASS, expressed_as: "any mode with activation=BREAK_GLASS"} + - {term: FEDERATION, expressed_as: "any mode with provenance=FEDERATED"} + - {term: AGENT, expressed_as: "any mode with principal_type=AGENT"} + - {term: SUPERADMIN, expressed_as: "ADMINISTER or SOVEREIGN at a named scope"} + - {term: ROOT, expressed_as: "SOVEREIGN @ host, or ADMINISTER @ scope — implementation-specific"} + - {term: OWNER, expressed_as: "GOVERN or ADMINISTER at a named scope"} + - {term: BILLING, expressed_as: "USE @ billing, or ADMINISTER @ billing"} + - {term: AUTOMATION, expressed_as: "any mode with principal_type=WORKLOAD or CONTROLLER"} + - {term: SECURITY, expressed_as: "ADMINISTER @ security-controls, or GOVERN @ security-controls"} diff --git a/infospace/vocabulary/mode-of-authority/dimensions.yaml b/infospace/vocabulary/mode-of-authority/dimensions.yaml new file mode 100644 index 0000000..19e78c7 --- /dev/null +++ b/infospace/vocabulary/mode-of-authority/dimensions.yaml @@ -0,0 +1,100 @@ +id: sec-authority:AuthorityDimensions +title: SecurityCanon Authority Dimensions +type: catalog +namespace: sec-authority +version: 0.2.0 +status: draft +source: infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md + +access_situation: + note: >- + The complete context in which authority is exercised. Not every + implementation materializes every dimension; the model supports reasoning. + dimensions: [Actor, AuthorityContext, AuthMode, Scope, AccessOperations, + AuthorityProvenance, Activation, Environment, EvidenceBoundary, + Time, Purpose] + +owned: + - id: AuthorityContext + definition: The authority being drawn on, when it is not the actor's own. + absent_when: The actor acts on its own authority. + companion_field: + name: relation + values: [DELEGATED, IMPERSONATED] + note: >- + Delegation keeps the actor's identity while exercising delegated + authority; impersonation acts within another party's authority context. + Neither is an Auth Mode. + renamed_from: + v0_1_name: Subject + reason: >- + InfoTechCanon's access-control model 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 make one word mean two things across + the canons. + decision: SECURITY-DEC-2026-002 + + - id: AuthorityProvenance + definition: Where the exercised authority originates. + values: [LOCAL, PARENT_SCOPE, SUBSTRATE, DELEGATED, FEDERATED, ASSUMED, IMPERSONATED] + note: SUBSTRATE marks authority arriving through a realm dominance relation. + + - id: Activation + definition: When and under what conditions authority becomes exercisable. + values: [STANDING, JUST_IN_TIME, SCHEDULED, APPROVED, INCIDENT, BREAK_GLASS, RECOVERY] + orthogonal_to: AuthMode + + - id: Environment + definition: The environment in which the authority applies. + values: [DEVELOPMENT, TEST, STAGING, PRODUCTION, RECOVERY] + note: Especially significant for CONSTRUCT authority. + + - id: EvidenceBoundary + definition: >- + Which system is responsible for observing and preserving evidence of + authority use, and whether the observed actor can compromise it. + values: [target-audited, external-audited, substrate-audited, multi-party-audited, outside-audit-boundary] + tests: + - Can the actor disable logging? + - Can the actor modify historical evidence? + - Can the actor change the audit destination? + - Can the actor compromise the authority observing it? + principle: Auditability depends on this dimension, not on the Auth Mode (A3). + + - id: AuthorityRealm + definition: A scope possessing an independently meaningful authority boundary. + examples: [operating system, database, Kubernetes cluster, cloud account, cloud organization, identity realm, SaaS tenant, trust domain] + relation: + name: DOMINATES + definition: >- + A realm exercising substrate authority over another realm. Models the + hypervisor-over-VM, host-over-container and provider-over-tenant cases. + properties: + dominance_kind: [execution, storage, identity, network] + observable: Can the dominated realm detect the dominating realm's exercise of authority? + evidence_boundary: Does the dominated realm's evidence survive the dominating realm? + example: "realm:host/node-7 DOMINATES realm:container/app-3" + note: >- + Dominance does not make the dominating realm universally sovereign (A5). + SOVEREIGN @ container and SOVEREIGN @ host coexist without contradiction. + +imported: + - id: Actor + owner: InfoTechCanonOrganizationModel + note: Actor semantics are owned upstream; this vocabulary references them. + - id: Scope + owner: InfoTechCanonAccessControlModel + - id: AccessOperations + owner: InfoTechCanonAccessControlModel + note: read, write, execute, delete, approve — orthogonal to AuthMode. + - id: Purpose + owner: InfoTechCanonPurposesExtension + note: Named in the Access Situation tuple; defined upstream, not here. + - id: PrincipalType + owner: InfoTechCanonIdentityModel + values: [HUMAN, WORKLOAD, SERVICE, AGENT, CONTROLLER, DEVICE] + constraint: Principal type must not be encoded into the Auth Mode taxonomy. + +not_modelled: + - id: Time + note: Named in the Access Situation tuple; not modelled in 0.2.0. diff --git a/spec/ModeOfAuthorityCanon-v0.1.md b/research/260920-mode-of-authority-v0.1.md similarity index 100% rename from spec/ModeOfAuthorityCanon-v0.1.md rename to research/260920-mode-of-authority-v0.1.md diff --git a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md index 8a4bdbd..d79dba4 100644 --- a/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md +++ b/workplans/SECURITY-WP-0001-bootstrap-and-vocabulary.md @@ -133,7 +133,7 @@ a bounded change handled under a new task, not a migration programme. ```task id: SECURITY-WP-0001-T06 -status: todo +status: done priority: high state_hub_task_id: "de5fc42c-2e18-5f03-b86c-a5ad45a9bb0a" ``` @@ -165,7 +165,7 @@ extension rather than defining it here. ```task id: SECURITY-WP-0001-T07 -status: todo +status: done priority: high state_hub_task_id: "4a0d3df9-d8a2-51c4-a4bc-72488d866068" ``` @@ -194,3 +194,39 @@ with InfoTechCanon. No canon content is authored or moved under this workplan. No service surface, CLI, HTTP API, or validation tooling is built for SecurityCanon; whether it reuses InfoTechCanon's Python service is deferred until content exists. + +## Result — 2026-09-20 (T06, T07) + +Mode of Authority promoted to +[`sec-authority:ModeOfAuthority`](../infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md) +v0.2.0, with machine-readable [`auth-modes.yaml`](../infospace/vocabulary/mode-of-authority/auth-modes.yaml) +and [`dimensions.yaml`](../infospace/vocabulary/mode-of-authority/dimensions.yaml). +The v0.1 draft moved verbatim to +[`research/260920-mode-of-authority-v0.1.md`](../research/260920-mode-of-authority-v0.1.md) +as provenance; it had been sitting in `spec/`, which the Repository Layout +Standard reserves for implementation guidance. + +Orientation surfaces published: the [vocabulary card](../docs/vocabulary-card.md), +the ten-question design heuristic promoted to §3 of the artifact, and the +[role/plane/mode disambiguation page](../docs/disambiguation.md). The cross-layer +[mapping](../infospace/mappings/mode-of-authority-to-infotechcanon.md) records +entity and dimension correspondences, mode-to-plane and mode-to-role affinities, +and the import direction. + +Terminology separation decided as +[SECURITY-DEC-2026-002 / SEC-ADR-002](../docs/adr-002-terminology-separation.md): +`Subject` becomes `AuthorityContext`; `Operator`/`OPERATE`, Build Plane/`CONSTRUCT`, +Policy Plane/`GOVERN`, Audit Plane/`EvidenceBoundary` and Condition/`Activation` +are separated rather than merged; Scope, AccessOperations, Purpose and +PrincipalType are declared imports; namespace `sec-authority:` reserved. + +Two v0.1 open questions closed in the artifact §10. CONSTRUCT stays distinct from +GOVERN, with the test being the object of authority — the artifact versus the +constraint it must satisfy — so that "who may edit the policy" and "who decides +what it must say" remain separable. Substrate authority is modelled as a +`DOMINATES` relation between Authority Realms carrying `dominance_kind`, +`observable` and `evidence_boundary`, which makes A5 checkable. Q1 and Q4–Q7 +remain open. + +Generalising CARING §32 beyond non-human subjects was deliberately **not** bundled +in; it is InfoTechCanon's to accept as a demand signal.