tegwick
a3dcdd4845
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
31 lines
1.8 KiB
Markdown
31 lines
1.8 KiB
Markdown
# 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)
|
|
|
|
SecurityCanon exports one surface, `sec-authority`: the architecture-layer
|
|
[Mode of Authority](../vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md)
|
|
vocabulary. It imports shared roots from InfoTechCanon and redefines none of
|
|
them; the [pinned manifest](../vocabulary/mode-of-authority/imports.json) records
|
|
each source path and content hash at the declared commit.
|
|
|
|
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.
|
|
|
|
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).
|