tegwick
a3dcdd4845
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
97 lines
6.5 KiB
Markdown
97 lines
6.5 KiB
Markdown
# 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.
|