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
Declares one export surface, sec-authority, carrying the Mode of Authority
vocabulary and its machine-readable catalogs, with InfoTechCanon,
InterfaceCanon, CommerceCanon and the Custodian as peers under CUST-ADR-006.
The card validates against InfoTechCanon's interface-card schema.
Imports are pinned against InfoTechCanon e1f98da0 in imports.json, recording
path and SHA-256 for each of the five sources; all five were verified to match
Git blobs at that commit with the sources unchanged in the review checkout.
Reciprocal navigation runs both ways: this repository's interfaces README links
the peer cards, and InfoTechCanon carries the SecurityCanon boundary review with
its own README link, following the InterfaceCanon precedent.
The prj-canon-federation G7 validator passes, and InfoTechCanon make check
passes with 46 tests and clean validation. The validator pins card paths for
three repositories only, so this card meets the same contract without yet being
registered there; that is prj-canon-federation's change to make and the card
says so.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
Publishes sec-authority:ModeOfAuthority v0.2.0 with machine-readable
auth-modes.yaml and dimensions.yaml, and moves the v0.1 draft verbatim to
research/ as provenance — it had been sitting in spec/, which the Repository
Layout Standard reserves for implementation guidance.
Terminology separation decided as SECURITY-DEC-2026-002 / SEC-ADR-002. The
v0.1 Subject dimension becomes AuthorityContext, because InfoTechCanon's
access-control model already owns Actor and Subject and binds them as "Subject
is the access-control view of an actor"; reusing the pair for two distinct
parties would have made one word mean two things across the canons. Operator
versus OPERATE, Build Plane versus CONSTRUCT, Policy Plane versus GOVERN, Audit
Plane versus EvidenceBoundary and Condition versus Activation are separated
rather than merged, and Scope, AccessOperations, Purpose and PrincipalType are
declared imports. Namespace sec-authority: reserved; itc-caring: and itc-access:
stay upstream and are not aliased.
Two of the draft's open questions are closed. CONSTRUCT stays distinct from
GOVERN, the test being the object of authority — the artifact versus the
constraint it must satisfy — which keeps "who may edit the policy" separable
from "who decides what it must say". Substrate authority becomes a DOMINATES
relation between Authority Realms carrying dominance_kind, observable and
evidence_boundary, which makes the relative-sovereignty principle checkable
instead of merely asserted.
Orientation surfaces published: the one-page vocabulary card, the ten-question
design heuristic promoted from the draft's appendix to section 3 of the
artifact, the role/plane/mode disambiguation page, and the cross-layer mapping
to InfoTechCanon with its deliberate blanks where one layer has no equivalent.
Generalising CARING section 32 beyond non-human subjects is deliberately not
bundled in; it is InfoTechCanon's to accept as a demand signal.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUkN13CAqtXWPXuEiEtmJj
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 36656@bnt-lap001
Assistant-Session: 66d6eece-d245-43ca-85e8-68a1b5970a67
