# 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 | | --- | --- | --- | --- | --- | | CanonArtifact | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Shared root. Corrected from `Artifact` by T04: Core defines `CanonArtifact`, and bare `Artifact` resolves to the DevSecOps build artifact. | | Ownership | InfoTechCanon | Organization Model | ITC → SC (import) | Owner corrected by T04; the kernel map assigns Ownership and Stewardship to Organization. | | RelationshipDefinition | InfoTechCanon | InfoTechCanonCore | ITC → SC (import) | Corrected from `Relationship` by T04, which the identity model owns as its actor-linking taxonomy. | | 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 | SecurityCanon | sec-authority:ModeOfAuthority | SC-owned | Corrected by T04: the identity model does not define this name. It is SecurityCanon's classification of the imported `Principal`. | | Scope | InfoTechCanon | Identity Model (ITC-IDENT 2.10) | ITC → SC (import) | The general boundary. ITC-ACCESS `ResourceScope` (11.8) refines it; CARING 21 ranges over it. Owner corrected by R-1. | | Operation | InfoTechCanon | ITC-ACCESS | ITC → SC (import) | The upstream name; `AccessOperations` was a SecurityCanon compaction. 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 | Landscape Model | ITC → SC (import) | Owner corrected again 2026-09-20: the kernel map concept-owner table names Landscape, and CARING 21.5 enumerates values for it. 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. - **2026-09-20, second correction.** `Environment` was attributed to CARING 21.5 on the strength of its value ladder. The InfoTechCanon kernel map's concept-owner table names the Landscape Model as its owner, and InfoTechCanon declared it there under INFO-WP-0027-T02. The import is re-pointed to the Landscape Model at the same pinned source commit. This is the second time a value enumeration was mistaken for a definition, after `Scope`; a re-verification against the enlarged InfoTechCanon ownership index is owed, and InfoTechCanon tracks it as INFO-WP-0027-T04. ### Amendment — 2026-09-20, name-resolution audit (T04) InfoTechCanon re-verified this boundary against its enlarged ownership index under INFO-WP-0027-T04 and found that five of the twelve declared imports named concepts their pinned artifact does not define. The original review verified the manifest by file hash, which every entry passed, and never checked that the named concept exists in the named file. `Artifact` became `CanonArtifact`, `Relationship` became `RelationshipDefinition`, `Ownership` moved to the Organization Model, `AccessOperations` became `Operation`, and `PrincipalType` moved from an import to a SecurityCanon-owned dimension. Eleven imports remain. No concept is contested and no semantic disposition changes. ## Residuals - **R-1 — resolved 2026-09-20 in InfoTechCanon (ADHOC-2026-09-20-T01).** The owner named here was wrong in both halves. `Scope` is owned by ITC-IDENT 2.10; ITC-ACCESS owns `ResourceScope` 11.8, which the model already declares as a refinement rather than a competing definition. The real second use was CARING 21, which now states that its dimension ranges over ITC-IDENT Scope instances and that its ladder is a value set, not a definition. The table row and `imports.json` are corrected to import `Scope` from the identity model. - **R-3 — CARING `Authority` exposure mode against `itc-org:Authority`.** Now sharper: InfoTechCanon declared `Authority` to the Organization Model on 2026-09-20 (INFO-WP-0027-T02), so the two senses are no longer both undeclared. 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 — resolved 2026-09-20 in InfoTechCanon (INFO-DEC-2026-001).** The section 32 role set now applies wherever a subject's access is exercised through another party, not to non-human subjects only. Option B from the implications note was accepted narrowly: section 32.1 stays agent-stated, no role is renamed, and CARING moves to canon version 0.4.0-RC2-itc2. Additive and non-breaking; no SecurityCanon declaration changes. The blank cell in the mapping table stands — InfoTechCanon's access-control model still has no on-behalf-of relation.