coulomb/security-canon
5
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
security-canon/infospace/interfaces/concept-placement.md
tegwick a3dcdd4845 Decide concept placement across the canon boundary (T02) 
Records one owning canon and one import direction per concept that appears in
both layers, as SECURITY-DEC-2026-003. Ten InfoTechCanon concepts are declared
imports and the list is closed at what imports.json pins: anything further must
be added there with a blob hash before use. Nine concepts are SecurityCanon's
own. CARING's Canonical Role, Plane, Condition, Capability and Audit Plane stay
upstream with no SecurityCanon counterpart.

Both remaining migration candidates stay in InfoTechCanon. The security model is
a posture model of the shared spine with eleven upstream imports and nothing to
gain from the move; the DevSecOps model is delivery vocabulary that is only
incidentally security-flavoured and belongs beside the repository-layout standard
and the evidence model. No artifact migrates, consistent with the cancelled T05.

The open boundary questions are answered rather than assumed: the identity model
is a shared root and SecurityCanon imports PrincipalType only; the small-saas
policy, control, evidence and incident artifacts stay whole, with any
SecurityCanon example referencing them by id across the federation interface.

Two residuals stay open and are InfoTechCanon-internal: CARING Scope against
ITC-ACCESS Scope, where ITC-ACCESS is named owner, and the unaccepted CARING
section 32 generalisation. This is an agent decision, not human sign-off, and it
records no consumer adoption or conformance claim.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 3588@bnt-lap001
Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da
2026-09-20 22:33:46 +02:00

6.5 KiB
Raw Blame History

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

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