# Concept placement — SecurityCanon and InfoTechCanon Status: decided for the concepts listed below, recorded as SECURITY-DEC-2026-003. Date: 2026-09-20. Narrowed by SEC-ADR-001 (SECURITY-DEC-2026-001), which already settles that CARING, the identity model and the access-control model stay in InfoTechCanon, and by SECURITY-DEC-2026-002, which settles the terminology separation. Scope of this record: one row per concept that appears in both layers, naming the single owning canon and the import direction. It does not create, rename or remove a concept in either canon. Pinned import source: info-tech-canon at `e1f98da015f32545254747c8e9f59b780c423d5b`, as declared in `infospace/vocabulary/mode-of-authority/imports.json`. ## Placement table | Concept | Owning canon | Owning artifact | Direction | Note | | --- | --- | --- | --- | --- | | Artifact | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. | | Ownership | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. | | Relationship | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. | | Actor | InfoTechCanon | Organization Model | ITC → SC (import) | SC does not redefine it; its on-behalf-of dimension is `AuthorityContext`. | | Subject | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | Bound as "the access-control view of an actor". SC references, never redefines. | | Principal | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | | | PrincipalType | InfoTechCanon | Identity Model | ITC → SC (import) | The identity model is a shared root, not security terminology. | | Scope | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | ITC-ACCESS is the single definition. See residual R-1. | | AccessOperations | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | Orthogonal to Auth Mode: `read + USE` and `read + OBSERVE` share an operation. | | Purpose | InfoTechCanon | Purpose and Demand extension | ITC → SC (import) | Resolves to the extension, not to a SecurityCanon definition. | | Authority | InfoTechCanon | Organization Model (ITC-ORG 10.17) | ITC → SC (import) | The recognized right itself. AuthMode qualifies its exercise and never redefines it. Added by T03 (F-1). | | Environment | InfoTechCanon | CARING 21.5 | ITC → SC (import) | Corrected by T03 (F-3); the SecurityCanon `RECOVERY` value is an upstream proposal. | | Realm | InfoTechCanon | Identity Model (ITC-IDENT 2.12) | ITC-only | Adjacent to `AuthorityRealm`, not the same question; disambiguation owed, no rename. | | Canonical Role | InfoTechCanon | CARING | ITC-only | `Operator` the role and `OPERATE` the auth mode are different axes; neither is renamed. | | Plane | InfoTechCanon | CARING | ITC-only | Names a surface. `Build Plane` and `CONSTRUCT` stay distinct. | | Condition | InfoTechCanon | CARING | ITC-only | Overlaps `Activation` in intent; both stand, neither is aliased. | | Capability | InfoTechCanon | Capability Model / CARING | ITC-only | Richer than AccessOperations; no SC counterpart. | | Audit Plane | InfoTechCanon | CARING | ITC-only | A surface, not a trust question. Distinct from `EvidenceBoundary`. | | AuthMode | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned, exportable | Published for import; InfoTechCanon declares no import of it today. | | AuthorityContext | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | The on-behalf-of dimension, renamed away from Actor/Subject. | | AuthorityRealm | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | | AuthorityProvenance | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | | Activation | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | `STANDING`, `JIT`, `APPROVED`, `INCIDENT`, `BREAK_GLASS`, `RECOVERY`. | | EvidenceBoundary | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | "Can the observed actor alter, suppress or bypass its own evidence?" | | AccessSituation | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | | | Time | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | Dimension slot only; no upstream time model is claimed. | **Declared imports are closed at this list.** The twelve InfoTechCanon concepts marked `ITC → SC` are exactly those in `imports.json`. Any further InfoTechCanon concept SecurityCanon comes to need must be added there with a pinned blob hash before it is used, not referenced informally. ## Migration candidates — recommendation The default is to leave an artifact upstream unless moving it demonstrably helps both canons. Neither remaining candidate meets that bar. - **Security model (`ITC-SEC`) — stays in InfoTechCanon.** It is a domain model of the shared spine: threat, weakness, vulnerability, exposure, finding, risk, incident, control, detection and response, wired to governance, task, landscape and organization. SecurityCanon's contribution is an authority vocabulary, not a posture model, and would inherit eleven upstream imports to re-pin for no semantic gain. SecurityCanon references it; it does not host it. - **DevSecOps model (`ITC-DEVSECOPS`) — stays in InfoTechCanon.** It is delivery vocabulary that is only incidentally security-flavoured — repositories, branches, builds, attestation, release, deploy, verify. Moving it would split delivery semantics from the repository-layout standard and the evidence model that sit beside it. With both candidates resolved upstream, no artifact migrates. This is consistent with SECURITY-WP-0001-T05, the migration handoff, having been cancelled. ## Open boundary questions — answers - **Is the identity model security terminology or a shared root?** A shared root. It is imported by the access-control model and exercised by the small-saas profile's user and tenant artifacts well outside security reasoning. SecurityCanon imports `PrincipalType` from it and nothing else. - **How do the small-saas profile's policy, control, evidence and incident artifacts split?** They do not split. The profile is InfoTechCanon's end-to-end proof of its own models and stays whole. If SecurityCanon needs a worked example of Auth Mode, it publishes its own profile that references those artifacts by id across the federation interface rather than relocating them. - **Which InfoTechCanon concepts become declared imports rather than moves?** The ten listed above. No concept is transferred in either direction by this record. - **Does the Actor/Subject split replace CARING's Subject dimension?** No — settled by SECURITY-DEC-2026-002. SecurityCanon renamed its own dimension to `AuthorityContext`; CARING is not rewritten. ## Amendments - **2026-09-20, SECURITY-WP-0001-T03.** The reference-impact survey (`infospace/mappings/infotechcanon-authority-survey.md`) found two corrections. `itc-org:Authority` is a live InfoTechCanon concept that no `owned_concepts` declaration lists, so neither the boundary review nor this table saw it; it is now the eleventh declared import. `Environment` was listed as SecurityCanon-owned but is already defined in CARING section 21.5, so it moves to imported and becomes the twelfth. Both are recorded in `imports.json` through the amendment procedure this decision requires. ## Residuals - **R-1 — CARING `Scope` and ITC-ACCESS `Scope`.** The review found two definitions of one concept inside InfoTechCanon. This record names ITC-ACCESS as the owner; reconciling CARING's wording to it is an InfoTechCanon-internal change and is not made here. - **R-3 — CARING `Authority` exposure mode against `itc-org:Authority`.** One word, two live InfoTechCanon senses: a right held by an actor (ITC-ORG 10.17) and an external body compelling disclosure (CARING 10.7). Disambiguation is InfoTechCanon-internal and is not made here. - **R-2 — CARING section 32 generalisation.** Referenced by SecurityCanon, explicitly not accepted by the InfoTechCanon-side boundary review. It remains an InfoTechCanon proposal requiring its own review.