security-canon/infospace/interfaces/concept-placement.md

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

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