Accept the SecurityCanon extension boundary

SecurityCanon publishes an architecture-layer vocabulary for authority
relationships, the Mode of Authority, and references shared InfoTechCanon
concepts. This records the InfoTechCanon-side acceptance of that boundary and
adds reciprocal navigation from the federation interface README.

The accepted dispositions keep the layers apart. Mode of Authority describes the
relationship in which authority is exercised; CARING analyses how an
access-control implementation is composed. Auth Mode is orthogonal to access
operation and to CARING's Canonical Role and Plane, so the Operator role and the
OPERATE mode stay distinct concepts and neither is renamed. SecurityCanon does
not reuse Actor or Subject, which ITC-ACCESS owns and binds as "Subject is the
access-control view of an actor"; it renamed its on-behalf-of dimension to
AuthorityContext instead, so no change is required here.

Verified at security-canon b1fa25eb: all five pinned manifest hashes match Git
blobs at this commit and the sources are unchanged in the review checkout, and
none of the seven concepts SecurityCanon declares appears in any InfoTechCanon
owned_concepts declaration, so the boundary introduces no ownership conflict.

No concept is transferred and nothing is removed, so the corpus is unchanged.
Generated indexes and the repository tree are refreshed for the added file;
make check passes with 46 tests, clean validation and a passing small-saas
profile. This is an agent review, not human sign-off, and it records no consumer
adoption or conformance claim.

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

infospace/indexes/artifact-tree.yaml

@@ -1,5 +1,5 @@
 root: infospace
-file_count: 279
+file_count: 280
 files:
 - path: README.md
   directory: .
@@ -580,6 +580,9 @@ files:
 - path: interfaces/interface-canon-boundary.md
   directory: interfaces
   name: interface-canon-boundary.md
+- path: interfaces/security-canon-boundary.md
+  directory: interfaces
+  name: security-canon-boundary.md
 - path: kernel/InfoTechCanonCore.md
   directory: kernel
   name: InfoTechCanonCore.md

infospace/interfaces/README.md

@@ -7,6 +7,9 @@ under [accepted ADR-006](../../../the-custodian/canon/architecture/adr-006-canon
 - [the-custodian interface](../../../the-custodian/canon/interfaces/federation.yaml)
 - [InterfaceCanon boundary review](interface-canon-boundary.md) — scoped acceptance
   of the draft 0.1.1 extension boundary, with pinned sources and review evidence.
+- [SecurityCanon interface](../../../security-canon/infospace/interfaces/federation.yaml)
+- [SecurityCanon boundary review](security-canon-boundary.md) — scoped acceptance
+  of the draft 0.2.0 architecture-layer authority vocabulary, with pinned sources.
 
 Each export names its source document and current maturity. Imports identify
 actual dependencies; reciprocal navigation does not imply reciprocal semantic

infospace/interfaces/security-canon-boundary.md

@@ -0,0 +1,72 @@
+# SecurityCanon extension boundary
+
+Status: accepted for the semantic boundary documented below, reviewed by Claude
+in the InfoTechCanon repository on 2026-09-20. This is an agent review, not a
+claim of separate human sign-off or a published peer merge.
+
+Review target: security-canon draft 0.2.0 at
+`b1fa25ebe3204b5da0febf70190533711c19fbce`.
+InfoTechCanon review base and import source:
+`e1f98da015f32545254747c8e9f59b780c423d5b`.
+
+SecurityCanon supplies an architecture-layer vocabulary for authority
+relationships — the Mode of Authority — and references shared InfoTechCanon
+concepts. InfoTechCanon retains the shared roots, the access-control model, the
+identity model, and the CARING access governance standard.
+
+## Accepted dispositions
+
+- **Layer separation.** Mode of Authority describes the relationship in which
+  authority is exercised; CARING analyses how an access-control implementation is
+  composed. Both may describe the same system without either subsuming the
+  other. Recorded on the SecurityCanon side as SEC-ADR-001.
+- **Auth Mode is orthogonal to access operation.** `read + USE` and
+  `read + OBSERVE` share an operation and differ in authority relationship.
+  AccessOperations remains owned by ITC-ACCESS and is imported, not redefined.
+- **Auth Mode is orthogonal to CARING Canonical Role and Plane.** The three
+  answer different questions. The CARING `Operator` role and the `OPERATE` auth
+  mode are not the same concept and neither is renamed; a disambiguation page in
+  SecurityCanon is the required companion.
+- **Actor/Subject is not reused.** ITC-ACCESS owns `Subject` and binds it as
+  "Subject is the access-control view of an actor", with actor semantics owned by
+  the Organization Model. SecurityCanon renamed its on-behalf-of dimension to
+  `AuthorityContext` rather than overloading either word. No change is required
+  in InfoTechCanon.
+- **Scope, AccessOperations, PrincipalType and Purpose are imports.** They retain
+  their InfoTechCanon owners. Purpose resolves to the Purpose and Demand
+  extension rather than being defined in SecurityCanon.
+- **EvidenceBoundary is a new concept, not an alias of the CARING Audit Plane.**
+  The Audit Plane names a surface; EvidenceBoundary asks whether the observed
+  actor can alter, suppress or bypass the evidence used to observe it.
+- **No InfoTechCanon concept is transferred.** This boundary creates no removal,
+  relocation or deprecation in InfoTechCanon, so the InfoTechCanon corpus is
+  unchanged by it.
+
+## Evidence and limits
+
+Reviewed `infospace/vocabulary/mode-of-authority/SecurityCanonModeOfAuthority.md`,
+`auth-modes.yaml`, `dimensions.yaml`, `imports.json`,
+`infospace/mappings/mode-of-authority-to-infotechcanon.md` and
+`infospace/interfaces/federation.yaml` at the SecurityCanon revision above.
+
+All five manifest SHA-256 values match Git blobs at the declared InfoTechCanon
+source revision, and those files are unchanged in the review checkout:
+InfoTechCanonCore, InfoTechCanonAccessControlModel, InfoTechCanonIdentityModel,
+InfoTechCanonOrganizationModel, and InfoTechCanonPurposeDemandExtension.
+
+None of the seven concepts SecurityCanon declares — AuthMode, AuthorityContext,
+AuthorityRealm, AuthorityProvenance, Activation, EvidenceBoundary,
+AccessSituation — appears in any InfoTechCanon `owned_concepts` declaration, so
+this boundary introduces no ownership conflict.
+
+Limits of this acceptance:
+
+- Scoped to SecurityCanon draft 0.2.0. No stable promotion is asserted.
+- Acceptance covers the semantic boundary and import declarations. It records no
+  consumer adoption, no runtime claim, and no conformance statement.
+- A proposal to generalise CARING section 32 beyond non-human subjects is
+  referenced by SecurityCanon but is **not** accepted here. It would be an
+  InfoTechCanon change requiring its own review.
+- The G7 validator in `prj-canon-federation` pins card paths for
+  info-tech-canon, commerce-canon and the-custodian. Registering the
+  security-canon card is that project's change; this review does not make it.

infospace/views/repository-tree.md

@@ -2,7 +2,7 @@
 
 # Repository Tree
 
-File count: **279**
+File count: **280**
 
 - `README.md`
 - `agent/README.md`
@@ -197,6 +197,7 @@ File count: **279**
 - `interfaces/README.md`
 - `interfaces/federation.yaml`
 - `interfaces/interface-canon-boundary.md`
+- `interfaces/security-canon-boundary.md`
 - `kernel/InfoTechCanonCore.md`
 - `kernel/InfoTechCanonKernelMap.md`
 - `mappings/README.md`