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 |
| [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
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
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 ).
