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

Amendment — 2026-10-11, SEC-DSM insertion (SECURITY-DEC-2026-004)

sec-dsm:DevOpsSecretsManagementStandard is a SecurityCanon-owned standard. It owns the secrets-practice requirements, the preference hierarchy, and the decision procedure. It does not add Principal, Authority, Capability, or Scope to SecurityCanon's owned concepts. The body's section 4 uses those words as practice language; the standard's preface records the reading. Secret and Credential remain practice terms until an upstream artifact owns them. No row in the placement table changes.