tegwick
2f22ddf7d3
The placement record named ITC-ACCESS the owner of Scope and imports.json pinned it there. The corpus says otherwise: ITC-IDENT section 2.10 defines Scope as the general boundary, and ITC-ACCESS section 11.8 ResourceScope already declares itself a refinement of it rather than a competing definition. The second use R-1 was actually reaching for is CARING section 21, resolved upstream in InfoTechCanon by ADHOC-2026-09-20-T01. Scope now imports from InfoTechCanonIdentityModel. No hash changes: both files were already pinned at the same source commit. 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
117 lines
8.2 KiB
Markdown
117 lines
8.2 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 | 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. |
|
|
| 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 — 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`.** 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.
|