Publish the SecurityCanon federation interface card (T04)
Declares one export surface, sec-authority, carrying the Mode of Authority
vocabulary and its machine-readable catalogs, with InfoTechCanon,
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.
The card validates against InfoTechCanon's interface-card schema.
Imports are pinned against InfoTechCanon e1f98da0 in imports.json, recording
path and SHA-256 for each of the five sources; all five were verified to match
Git blobs at that commit with the sources unchanged in the review checkout.
Reciprocal navigation runs both ways: this repository's interfaces README links
the peer cards, and InfoTechCanon carries the SecurityCanon boundary review with
its own README link, following the InterfaceCanon precedent.
The prj-canon-federation G7 validator passes, and InfoTechCanon make check
passes with 46 tests and clean validation. The validator pins card paths for
three repositories only, so this card meets the same contract without yet being
registered there; that is prj-canon-federation's change to make and the card
says so.
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:50:07 +02:00
|
|
|
# Canon federation interface
|
|
|
|
|
|
|
|
|
|
The [interface card](federation.yaml) publishes this canon's federation boundary
|
|
|
|
|
under [accepted ADR-006](../../../the-custodian/canon/architecture/adr-006-canon-federation-concept-ownership.md).
|
|
|
|
|
|
|
|
|
|
- [info-tech-canon interface](../../../info-tech-canon/infospace/interfaces/federation.yaml)
|
|
|
|
|
— shared-concept upstream
|
|
|
|
|
- [SecurityCanon boundary review](../../../info-tech-canon/infospace/interfaces/security-canon-boundary.md)
|
|
|
|
|
— InfoTechCanon-side acceptance of this extension boundary
|
|
|
|
|
- [interface-canon interface](../../../interface-canon/infospace/interfaces/federation.yaml)
|
|
|
|
|
- [commerce-canon interface](../../../commerce-canon/infospace/interfaces/federation.yaml)
|
|
|
|
|
- [the-custodian interface](../../../the-custodian/canon/interfaces/federation.yaml)
|
|
|
|
|
|
2026-10-11 23:41:30 +02:00
|
|
|
SecurityCanon exports two surfaces. `sec-authority` is the architecture-layer
|
Publish the SecurityCanon federation interface card (T04)
Declares one export surface, sec-authority, carrying the Mode of Authority
vocabulary and its machine-readable catalogs, with InfoTechCanon,
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.
The card validates against InfoTechCanon's interface-card schema.
Imports are pinned against InfoTechCanon e1f98da0 in imports.json, recording
path and SHA-256 for each of the five sources; all five were verified to match
Git blobs at that commit with the sources unchanged in the review checkout.
Reciprocal navigation runs both ways: this repository's interfaces README links
the peer cards, and InfoTechCanon carries the SecurityCanon boundary review with
its own README link, following the InterfaceCanon precedent.
The prj-canon-federation G7 validator passes, and InfoTechCanon make check
passes with 46 tests and clean validation. The validator pins card paths for
three repositories only, so this card meets the same contract without yet being
registered there; that is prj-canon-federation's change to make and the card
says so.
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:50:07 +02:00
|
|
|
[Mode of Authority](../vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
|
2026-10-11 23:41:30 +02:00
|
|
|
vocabulary. `sec-dsm` is the
|
|
|
|
|
[DevOps Secrets Management Standard](../standards/devops-secrets-management/SecurityCanonDevOpsSecretsManagementStandard.md).
|
|
|
|
|
It imports shared roots from InfoTechCanon and redefines none of
|
Publish the SecurityCanon federation interface card (T04)
Declares one export surface, sec-authority, carrying the Mode of Authority
vocabulary and its machine-readable catalogs, with InfoTechCanon,
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.
The card validates against InfoTechCanon's interface-card schema.
Imports are pinned against InfoTechCanon e1f98da0 in imports.json, recording
path and SHA-256 for each of the five sources; all five were verified to match
Git blobs at that commit with the sources unchanged in the review checkout.
Reciprocal navigation runs both ways: this repository's interfaces README links
the peer cards, and InfoTechCanon carries the SecurityCanon boundary review with
its own README link, following the InterfaceCanon precedent.
The prj-canon-federation G7 validator passes, and InfoTechCanon make check
passes with 46 tests and clean validation. The validator pins card paths for
three repositories only, so this card meets the same contract without yet being
registered there; that is prj-canon-federation's change to make and the card
says so.
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:50:07 +02:00
|
|
|
them; the [pinned manifest](../vocabulary/mode-of-authority/imports.json) records
|
2026-10-11 23:41:30 +02:00
|
|
|
each vocabulary source path and content hash at the declared commit.
|
Publish the SecurityCanon federation interface card (T04)
Declares one export surface, sec-authority, carrying the Mode of Authority
vocabulary and its machine-readable catalogs, with InfoTechCanon,
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.
The card validates against InfoTechCanon's interface-card schema.
Imports are pinned against InfoTechCanon e1f98da0 in imports.json, recording
path and SHA-256 for each of the five sources; all five were verified to match
Git blobs at that commit with the sources unchanged in the review checkout.
Reciprocal navigation runs both ways: this repository's interfaces README links
the peer cards, and InfoTechCanon carries the SecurityCanon boundary review with
its own README link, following the InterfaceCanon precedent.
The prj-canon-federation G7 validator passes, and InfoTechCanon make check
passes with 46 tests and clean validation. The validator pins card paths for
three repositories only, so this card meets the same contract without yet being
registered there; that is prj-canon-federation's change to make and the card
says so.
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:50:07 +02:00
|
|
|
|
|
|
|
|
Reciprocal navigation does not imply reciprocal semantic imports. InfoTechCanon
|
|
|
|
|
retains the shared roots, CARING, the access-control model and the identity
|
|
|
|
|
model; see [SEC-ADR-001](../../docs/adr-001-securitycanon-boundary.md).
|
|
|
|
|
|
|
|
|
|
The G7 validator in `prj-canon-federation` currently pins card paths for
|
|
|
|
|
info-tech-canon, commerce-canon and the-custodian. Adding `security-canon` to
|
|
|
|
|
`CARD_PATHS` is that project's change to make; this card is written to satisfy
|
|
|
|
|
the same contract in the meantime.
|
Decide concept placement across the canon boundary (T02)
Records one owning canon and one import direction per concept that appears in
both layers, as SECURITY-DEC-2026-003. Ten InfoTechCanon concepts are declared
imports and the list is closed at what imports.json pins: anything further must
be added there with a blob hash before use. Nine concepts are SecurityCanon's
own. CARING's Canonical Role, Plane, Condition, Capability and Audit Plane stay
upstream with no SecurityCanon counterpart.
Both remaining migration candidates stay in InfoTechCanon. The security model is
a posture model of the shared spine with eleven upstream imports and nothing to
gain from the move; the DevSecOps model is delivery vocabulary that is only
incidentally security-flavoured and belongs beside the repository-layout standard
and the evidence model. No artifact migrates, consistent with the cancelled T05.
The open boundary questions are answered rather than assumed: the identity model
is a shared root and SecurityCanon imports PrincipalType only; the small-saas
policy, control, evidence and incident artifacts stay whole, with any
SecurityCanon example referencing them by id across the federation interface.
Two residuals stay open and are InfoTechCanon-internal: CARING Scope against
ITC-ACCESS Scope, where ITC-ACCESS is named owner, and the unaccepted CARING
section 32 generalisation. This is an agent decision, not human sign-off, and it
records no consumer adoption or conformance claim.
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:33:46 +02:00
|
|
|
|
|
|
|
|
Concept placement across the two canons — one owning canon and one import
|
|
|
|
|
direction per shared concept — is recorded in
|
|
|
|
|
[concept-placement.md](concept-placement.md) (SECURITY-DEC-2026-003).
|