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