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 |
||
|---|---|---|
| .repo-manager | ||
| decisions | ||
| docs | ||
| history | ||
| infospace | ||
| research | ||
| workplans | ||
| .custodian-brief.md | ||
| .repo-classification.yaml | ||
| AGENTS.md | ||
| INTENT.md | ||
| README.md | ||
| SCOPE.md | ||
| WORK-RECORDS.md | ||
security-canon
Orthogonal vocabulary and canonical model for security-related concepts.
SecurityCanon extends InfoTechCanon with a focused security domain model, in the same architectural role that CommerceCanon holds for commercial terminology and InterfaceCanon for interface terminology.
Its subject is architecture, not implementation: the relationships in which
authority is exercised, described before and independently of the mechanisms
that enforce them. Its first contribution is the Mode of Authority vocabulary
— seven auth modes (USE, OBSERVE, OPERATE, ADMINISTER, GOVERN,
CONSTRUCT, SOVEREIGN) read relative to a scope. CARING and the access-control
and identity models stay in InfoTechCanon, at the implementation layer and as
shared roots; see SEC-ADR-001.
| Flavor | project |
| Domain | infotech |
| Workplan prefix | SECURITY-WP- |
| Upstream canon | InfoTechCanon |
| Service surface | none — reuses InfoTechCanon's |
Start with INTENT.md and SCOPE.md. Agent instructions are in AGENTS.md; active work is in workplans/.
| Document | What it holds |
|---|---|
| SEC-ADR-001 | the boundary decision — what stays upstream, and why |
| SEC-ADR-002 | the terminology separation — why AuthorityContext, not Subject |
| Mode of Authority assessment | review of the v0.1 draft and the proposed canon structure |
| Actor/Subject implications | the one open terminology question, analysed |
Status
Draft. The Mode of Authority vocabulary is published as a canon artifact with
machine-readable modes and dimensions; the v0.1 research draft is retained in
research/ as provenance. Stable promotion needs reviewed mappings and concrete
consumer evidence. See
SECURITY-WP-0001.
Orientation
| Start here | For |
|---|---|
| Vocabulary card | the seven modes and the notation, on one page |
| Mode of Authority | the canon artifact |
| Disambiguation | operator or OPERATE? role, plane, or mode? |
| Mapping to InfoTechCanon | how it relates to the access-control model and CARING |