security-canon/decisions/decisions.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

41 lines
1.3 KiB
Markdown

# Decision records
## SECURITY-DEC-2026-001 — SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer vocabulary
```yaml
id: SECURITY-DEC-2026-001
kind: decision
title: 'SecurityCanon boundary: CARING stays in InfoTechCanon; Auth Mode is architecture-layer
vocabulary'
status: accepted
created: '2026-09-20T19:30:50.120170Z'
updated: '2026-09-20T19:30:50.120170Z'
state_hub_decision_id: "f6496e7d-4622-4cc6-b5b1-b62172dd148e"
```
## SECURITY-DEC-2026-002 — Terminology separation: Auth Mode renames Subject to AuthorityContext; no upstream redefinition
```yaml
id: SECURITY-DEC-2026-002
kind: decision
title: 'Terminology separation: Auth Mode renames Subject to AuthorityContext; no
upstream redefinition'
status: accepted
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"
```