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