tegwick
e159fe7a1b
InfoTechCanon re-verified this boundary against its enlarged ownership index under INFO-WP-0027-T04. The original manifest was verified by file hash, which every entry passed; nothing checked that the named concept exists in the named file. Five of twelve did not. Artifact becomes CanonArtifact, which is what Core defines; bare Artifact now resolves to the DevSecOps build artifact, a different concept. Relationship becomes RelationshipDefinition, since the identity model owns Relationship as its actor-linking taxonomy. Ownership moves to the Organization Model, which the kernel map names as its owner. AccessOperations becomes Operation, the upstream name. PrincipalType stops being an import: the identity model does not define it, and it is SecurityCanon's own classification of the imported Principal. Eleven imports remain, no concept is contested, and no semantic disposition changes. 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 |