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 |
||
|---|---|---|
| .. | ||
| concept-placement.md | ||
| federation.yaml | ||
| README.md | ||
Canon federation interface
The interface card publishes this canon's federation boundary under accepted ADR-006.
- info-tech-canon interface — shared-concept upstream
- SecurityCanon boundary review — InfoTechCanon-side acceptance of this extension boundary
- interface-canon interface
- commerce-canon interface
- the-custodian interface
SecurityCanon exports one surface, sec-authority: the architecture-layer
Mode of Authority
vocabulary. It imports shared roots from InfoTechCanon and redefines none of
them; the pinned manifest records
each source path and content hash at the declared commit.
Reciprocal navigation does not imply reciprocal semantic imports. InfoTechCanon retains the shared roots, CARING, the access-control model and the identity model; see SEC-ADR-001.
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 (SECURITY-DEC-2026-003).