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