tegwick
c7482c6823
Fifty-two InfoTechCanon files mention authority; twenty are live canon and thirty-two are preserved assimilation source. The survey separates three senses of the word already in use — the right itself (itc-org:Authority, ITC-ORG 10.17), an external body compelling disclosure (CARING 10.7 exposure mode), and the relationship in which authority is exercised (sec-authority:AuthMode) — and records, per artifact, how SecurityCanon must reference rather than restate them. Two corrections follow, applied through the amendment procedure SECURITY-DEC-2026-003 requires. itc-org:Authority is a live concept that no owned_concepts declaration lists, so the boundary review's conflict check could not see it; it becomes a declared import on the existing organization-model entry, whose pinned hash is unchanged. Environment was listed as SecurityCanon-owned but CARING 21.5 already defines it, which the decision forbids; InfoTechCanon owns it, SecurityCanon imports it with a newly pinned CARING hash, and the RECOVERY value is carried as an upstream value proposal. The declared import list goes from ten concepts to twelve. Two findings need no change here. CARING's Authority exposure mode against itc-org:Authority becomes residual R-3, InfoTechCanon-internal. itc-ident:Realm against AuthorityRealm owes the disambiguation page a line but no rename. AuthorityContext, AuthorityProvenance, Activation, EvidenceBoundary and AccessSituation collide with nothing in the live corpus. No InfoTechCanon file is changed by this survey. 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 |