2026-09-20 20:32:05 +02:00
|
|
|
# SCOPE
|
|
|
|
|
|
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
|
|
|
Reviewed: 2026-09-20 (Europe/Berlin), after [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md).
|
2026-09-20 20:32:05 +02:00
|
|
|
|
|
|
|
|
## Current repository scope
|
|
|
|
|
|
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 carries governance files — INTENT, SCOPE, AGENTS,
|
|
|
|
|
repo classification — the [SEC-ADR-001](docs/adr-001-securitycanon-boundary.md)
|
|
|
|
|
boundary decision, the Mode of Authority review in `history/`, and one active
|
|
|
|
|
workplan. The only content is the Mode of Authority v0.1 research draft, not yet
|
|
|
|
|
promoted into a canon artifact. There is no service code, and by decision there
|
|
|
|
|
will be none.
|
2026-09-20 20:32:05 +02:00
|
|
|
|
|
|
|
|
## Ownership and boundaries
|
|
|
|
|
|
|
|
|
|
Following [INTENT.md](INTENT.md), SecurityCanon occupies the Taxonomy layer and
|
|
|
|
|
owns security concept definitions and their cross-canon mappings. It imports
|
|
|
|
|
shared roots from InfoTechCanon and does not redefine them.
|
|
|
|
|
|
|
|
|
|
Out of scope, with the owner named:
|
|
|
|
|
|
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
|
|
|
- the CARING access governance standard and its Kubernetes RBAC benchmark,
|
|
|
|
|
the access-control model, and the identity model — **InfoTechCanon**, by
|
|
|
|
|
SEC-ADR-001 D1 and D3
|
|
|
|
|
- any CLI, HTTP API, or validation service — **InfoTechCanon's service surface**,
|
|
|
|
|
by SEC-ADR-001 D4; integration is via the canon-federation interface card
|
2026-09-20 20:32:05 +02:00
|
|
|
- security architecture and standards of record for the estate — NetKingdom
|
|
|
|
|
- authorization decisions — flex-auth
|
|
|
|
|
- login, OIDC, MFA — key-cape / Keycloak
|
|
|
|
|
- secret custody and credential issuance — OpenBao, ops-warden
|
|
|
|
|
- adversarial evidence and findings practice — whitehat-security
|
|
|
|
|
- shared artifact/ownership/mapping/profile mechanisms — InfoTechCanon
|
|
|
|
|
- consumer runtime state, enforcement, observation, and adoption evidence — the consumers
|
|
|
|
|
|
|
|
|
|
## Planned scope
|
|
|
|
|
|
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
|
|
|
The near-term deliverable is the architecture-layer vocabulary, not a migration.
|
2026-09-20 20:32:05 +02:00
|
|
|
|
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
|
|
|
| Deliverable | Task |
|
2026-09-20 20:32:05 +02:00
|
|
|
| --- | --- |
|
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 promoted to a checkable Tier-1 artifact | `SECURITY-WP-0001-T06` |
|
|
|
|
|
| Terminology separation from CARING and the access-control model | `SECURITY-WP-0001-T07` |
|
|
|
|
|
| Federation interface card declaring Auth Mode as an export | `SECURITY-WP-0001-T04` |
|
|
|
|
|
| Orientation surfaces: vocabulary card, design heuristic, disambiguation page | `SECURITY-WP-0001-T06` |
|
2026-09-20 20:32:05 +02:00
|
|
|
|
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
|
|
|
InfoTechCanon artifacts this canon **references rather than absorbs**:
|
2026-09-20 20:32:05 +02:00
|
|
|
|
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
|
|
|
| Path in info-tech-canon | Relationship |
|
|
|
|
|
| --- | --- |
|
|
|
|
|
| `infospace/standards/caring/` | implementation layer; imports the vocabulary |
|
|
|
|
|
| `infospace/models/access-control/` | owns Subject, Principal, IdentityReference |
|
|
|
|
|
| `infospace/models/identity/` | shared root; stays upstream |
|
|
|
|
|
| `infospace/models/security/` | boundary under review in `SECURITY-WP-0001-T02` |
|
|
|
|
|
| `infospace/models/devsecops/` | boundary under review in `SECURITY-WP-0001-T02` |
|
|
|
|
|
|
Close the bootstrap and vocabulary workplan
All tasks resolved: T01, T02, T03, T04, T06 and T07 done, T05 cancelled. The
workplan delivered the governed repository, the Mode of Authority vocabulary at
v0.2.0, the federation interface card, three decisions, the concept-placement
record and the reference-impact survey.
It also concluded that the migration it was preparing should not happen. The
material this canon was meant to receive is load-bearing where it sits, and
SecurityCanon's real contribution is an architecture-layer vocabulary that
InfoTechCanon does not have, so it is an extension canon rather than a
destination for extracted material. Nothing moves; the boundary holds by
declared imports, twelve InfoTechCanon concepts pinned and nine owned here.
SCOPE.md carries the three open questions to their answers rather than leaving
them carried, and points at the placement record and the survey.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
2026-09-20 22:48:23 +02:00
|
|
|
Open questions, answered under SECURITY-WP-0001 and no longer carried:
|
|
|
|
|
|
|
|
|
|
- the security and DevSecOps models stay in InfoTechCanon. Both were the only
|
|
|
|
|
remaining migration candidates and neither cleared the bar of demonstrably
|
|
|
|
|
helping both canons (SECURITY-DEC-2026-003);
|
|
|
|
|
- the small-saas profile's security artifacts stay whole in InfoTechCanon. A
|
|
|
|
|
SecurityCanon example references them by id across the federation interface
|
|
|
|
|
rather than relocating them;
|
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
|
|
|
- the Actor/Subject naming question, analysed in
|
|
|
|
|
[the implications note](docs/260920-actor-subject-implications.md) and decided
|
Close the bootstrap and vocabulary workplan
All tasks resolved: T01, T02, T03, T04, T06 and T07 done, T05 cancelled. The
workplan delivered the governed repository, the Mode of Authority vocabulary at
v0.2.0, the federation interface card, three decisions, the concept-placement
record and the reference-impact survey.
It also concluded that the migration it was preparing should not happen. The
material this canon was meant to receive is load-bearing where it sits, and
SecurityCanon's real contribution is an architecture-layer vocabulary that
InfoTechCanon does not have, so it is an extension canon rather than a
destination for extracted material. Nothing moves; the boundary holds by
declared imports, twelve InfoTechCanon concepts pinned and nine owned here.
SCOPE.md carries the three open questions to their answers rather than leaving
them carried, and points at the placement record and the survey.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
2026-09-20 22:48:23 +02:00
|
|
|
under `SECURITY-WP-0001-T07`: the on-behalf-of dimension is `AuthorityContext`
|
|
|
|
|
and no upstream concept is redefined.
|
|
|
|
|
|
|
|
|
|
Concept placement across the boundary — one owning canon and one import
|
|
|
|
|
direction per shared concept — is recorded in
|
|
|
|
|
[concept-placement.md](infospace/interfaces/concept-placement.md), with the
|
|
|
|
|
supporting survey of InfoTechCanon's existing authority vocabulary in
|
|
|
|
|
[infotechcanon-authority-survey.md](infospace/mappings/infotechcanon-authority-survey.md).
|
2026-09-20 20:32:05 +02:00
|
|
|
|
|
|
|
|
## Exclusions and evolution
|
|
|
|
|
|
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
|
|
|
No service surface is in scope, now or later: SEC-ADR-001 D4 settles that
|
|
|
|
|
SecurityCanon reuses InfoTechCanon's service rather than shipping its own. A
|
|
|
|
|
check that does not exist is a change request against InfoTechCanon.
|
|
|
|
|
|
|
|
|
|
A dedicated identity or personhood canon may eventually be right. It is deferred
|
|
|
|
|
and belongs to no current workplan.
|