2026-09-20 18:13:56 +00:00
# security-canon
2026-09-20 20:32:05 +02:00
Orthogonal vocabulary and canonical model for security-related concepts.
SecurityCanon extends InfoTechCanon with a focused security domain model, in the
same architectural role that [CommerceCanon ](../commerce-canon ) holds for
commercial terminology and [InterfaceCanon ](../interface-canon ) for interface
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
terminology.
Its subject is **architecture, not implementation** : the relationships in which
authority is exercised, described before and independently of the mechanisms
that enforce them. Its first contribution is the **Mode of Authority** vocabulary
— seven auth modes (`USE` , `OBSERVE` , `OPERATE` , `ADMINISTER` , `GOVERN` ,
`CONSTRUCT` , `SOVEREIGN` ) read relative to a scope. CARING and the access-control
and identity models stay in InfoTechCanon, at the implementation layer and as
shared roots; see [SEC-ADR-001 ](docs/adr-001-securitycanon-boundary.md ).
2026-09-20 20:32:05 +02:00
| | |
| --- | --- |
| **Flavor** | project |
| **Domain** | infotech |
| **Workplan prefix** | `SECURITY-WP-` |
| **Upstream canon** | [InfoTechCanon ](../info-tech-canon ) |
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
| **Service surface** | none — reuses InfoTechCanon's |
2026-09-20 20:32:05 +02:00
2026-09-20 20:33:56 +02:00
Start with [INTENT.md ](INTENT.md ) and [SCOPE.md ](SCOPE.md ).
2026-09-20 20:32:05 +02:00
Agent instructions are in [AGENTS.md ](AGENTS.md ); active work is in
[workplans/ ](workplans/ ).
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
| Document | What it holds |
| --- | --- |
| [SEC-ADR-001 ](docs/adr-001-securitycanon-boundary.md ) | the boundary decision — what stays upstream, and why |
Promote Mode of Authority to a canon artifact (T06, T07)
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
2026-09-20 21:43:11 +02:00
| [SEC-ADR-002 ](docs/adr-002-terminology-separation.md ) | the terminology separation — why `AuthorityContext` , not `Subject` |
Re-scope SecurityCanon to architecture-layer vocabulary (SEC-ADR-001)
Owner decision of 2026-09-20 answering four of the five open questions from the
Mode of Authority assessment, recorded as SEC-DEC-0001 with the reasoning in
docs/adr-001-securitycanon-boundary.md.
CARING stays in InfoTechCanon: it is implementation-layer and imports eleven
InfoTechCanon models, and SecurityCanon should help rather than hinder keeping
InfoTechCanon practical. Identity stays a shared root, since pulling it in would
collapse too much into security and it reaches into personhood; a dedicated
identity or personhood canon is deferred, not rejected. Mode of Authority is
architecture where CARING is implementation — different layers of abstraction,
neither subsuming the other, but they must not use the same word for different
things. No service surface is duplicated: integration is uniform across
commerce-canon, interface-canon and security-canon through the canon-federation
interface card, and InfoTechCanon's service stays the only one.
Content migration is therefore no longer a goal. T02 narrows from a disposition
review to concept placement, T03 becomes a non-collision survey, and T05, the
migration workplan handoff, is cancelled. T06 gains the three-way mapping table
and T07 becomes the terminology separation decision.
The remaining open question is analysed in docs/260920-actor-subject-implications.md.
InfoTechCanon's access-control model already owns Actor and Subject and binds
them as "Subject is the access-control view of an actor", while Mode of Authority
uses the same two words for two distinct parties; and CARING already carries the
split for non-human subjects. The note recommends renaming Mode of Authority's
second party to Authority Context rather than changing a release-candidate
standard.
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
2026-09-20 21:34:45 +02:00
| [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 |
2026-09-20 20:32:05 +02:00
## Status
Promote Mode of Authority to a canon artifact (T06, T07)
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
2026-09-20 21:43:11 +02:00
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 |
