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.