security-canon/infospace/mappings/mode-of-authority-to-infotechcanon.md

---
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.~~
  **Closed 2026-09-20.** InfoTechCanon accepted option B as INFO-DEC-2026-001:
  the role set now applies wherever access is exercised through another party,
  CARING is at canon version 0.4.0-RC2-itc2, and the change is additive. The
  mapping below is unaffected. 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).