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 | ITC-ACCESS | ITC → SC (import) | ITC-ACCESS is the single definition. See residual 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 — CARING `Scope` and ITC-ACCESS `Scope`.** The review found two
  definitions of one concept inside InfoTechCanon. This record names ITC-ACCESS
  as the owner; reconciling CARING's wording to it is an InfoTechCanon-internal
  change and is not made here.
- **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.