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
This commit is contained in:
parent
c9d4e1ad5d
commit
a3dcdd4845
4 changed files with 154 additions and 1 deletions
|
|
@ -25,3 +25,17 @@ created: '2026-09-20T19:42:12.263921Z'
|
|||
updated: '2026-09-20T19:42:12.263921Z'
|
||||
state_hub_decision_id: "7717592b-70cf-43fc-986e-d208d1641f49"
|
||||
```
|
||||
|
||||
## SECURITY-DEC-2026-003 — Concept placement: ten declared imports, no migration, identity model is a shared root
|
||||
|
||||
```yaml
|
||||
id: SECURITY-DEC-2026-003
|
||||
kind: decision
|
||||
title: 'Concept placement: ten declared imports, no migration, identity model is a
|
||||
shared root'
|
||||
status: accepted
|
||||
created: '2026-09-20T20:20:00.000000Z'
|
||||
updated: '2026-09-20T20:20:00.000000Z'
|
||||
state_hub_decision_id: "054e60cc-c8df-4335-83d4-28fd438bb0a8"
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -25,3 +25,7 @@ The G7 validator in `prj-canon-federation` currently pins card paths for
|
|||
info-tech-canon, commerce-canon and the-custodian. Adding `security-canon` to
|
||||
`CARD_PATHS` is that project's change to make; this card is written to satisfy
|
||||
the same contract in the meantime.
|
||||
|
||||
Concept placement across the two canons — one owning canon and one import
|
||||
direction per shared concept — is recorded in
|
||||
[concept-placement.md](concept-placement.md) (SECURITY-DEC-2026-003).
|
||||
|
|
|
|||
97
infospace/interfaces/concept-placement.md
Normal file
97
infospace/interfaces/concept-placement.md
Normal file
|
|
@ -0,0 +1,97 @@
|
|||
# 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.
|
||||
|
|
@ -60,7 +60,7 @@ running `statehub fix-consistency` — never by hand.
|
|||
|
||||
```task
|
||||
id: SECURITY-WP-0001-T02
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "8b9e4cd0-9905-5ae8-9a23-8957110d72e4"
|
||||
```
|
||||
|
|
@ -264,3 +264,41 @@ the-custodian only, so this card is written to the same contract but is not yet
|
|||
registered there; adding it is prj-canon-federation's change to make, and the
|
||||
card records that. The boundary acceptance is an agent review, not human
|
||||
sign-off, and records no consumer adoption or conformance claim.
|
||||
|
||||
## Result — 2026-09-20 (T02)
|
||||
|
||||
Concept placement decided and recorded as SECURITY-DEC-2026-003 in
|
||||
`decisions/decisions.md`, with the full record at
|
||||
`infospace/interfaces/concept-placement.md`.
|
||||
|
||||
The placement table carries 25 rows: 10 InfoTechCanon concepts declared as
|
||||
imports (Artifact, Ownership, Relationship, Actor, Subject, Principal,
|
||||
PrincipalType, Scope, AccessOperations, Purpose), 5 InfoTechCanon CARING and
|
||||
capability concepts that stay upstream with no SecurityCanon counterpart
|
||||
(Canonical Role, Plane, Condition, Capability, Audit Plane), and 9 SecurityCanon
|
||||
concepts (AuthMode, AuthorityContext, AuthorityRealm, AuthorityProvenance,
|
||||
Activation, EvidenceBoundary, AccessSituation, Environment, Time). The declared
|
||||
import list is closed at what `imports.json` pins; further needs must be added
|
||||
there with a blob hash before use.
|
||||
|
||||
Both remaining migration candidates stay upstream. The security model is a
|
||||
posture model of the shared spine with eleven upstream imports and no semantic
|
||||
gain from moving; the DevSecOps model is delivery vocabulary that is only
|
||||
incidentally security-flavoured and sits beside the repository-layout standard
|
||||
and the evidence model. No artifact migrates, consistent with T05 having been
|
||||
cancelled.
|
||||
|
||||
The open boundary questions are answered rather than assumed: the identity model
|
||||
is a shared root (SecurityCanon imports PrincipalType only); the small-saas
|
||||
policy, control, evidence and incident artifacts do not split and stay whole,
|
||||
with any SecurityCanon example referencing them by id across the federation
|
||||
interface; declared imports replace moves in both directions.
|
||||
|
||||
Two residuals are recorded, both InfoTechCanon-internal and neither made here:
|
||||
R-1, CARING `Scope` and ITC-ACCESS `Scope` are two definitions of one concept
|
||||
and ITC-ACCESS is named the owner; R-2, the CARING section 32 generalisation
|
||||
remains an unaccepted InfoTechCanon proposal.
|
||||
|
||||
Limits. This is an agent decision recorded on the SecurityCanon side and
|
||||
reflected in InfoTechCanon's accepted boundary; it is not separate human
|
||||
sign-off, and it records no consumer adoption or conformance claim.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue