InfoTechCanon reviewed the demand signal separately and accepted option B as
INFO-DEC-2026-001: the CARING section 32 role set now applies wherever a
subject's access is exercised through another party, rather than to non-human
subjects only. CARING moves to canon version 0.4.0-RC2-itc2.
The change is additive and no SecurityCanon declaration moves. The blank cell in
the mapping table stands: InfoTechCanon's access-control model still has no
on-behalf-of relation.
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
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
The kernel map concept-owner table names Landscape as the owner of Environment;
CARING section 21.5 enumerates values for it. InfoTechCanon declared it to the
Landscape Model under INFO-WP-0027-T02. The import moves to that artifact at the
same pinned source commit.
This is the second time a value enumeration was read as a definition, after
Scope. A re-verification of both boundaries against InfoTechCanon's enlarged
ownership index is owed and is tracked there as INFO-WP-0027-T04.
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
The placement record named ITC-ACCESS the owner of Scope and imports.json pinned
it there. The corpus says otherwise: ITC-IDENT section 2.10 defines Scope as the
general boundary, and ITC-ACCESS section 11.8 ResourceScope already declares
itself a refinement of it rather than a competing definition. The second use R-1
was actually reaching for is CARING section 21, resolved upstream in
InfoTechCanon by ADHOC-2026-09-20-T01.
Scope now imports from InfoTechCanonIdentityModel. No hash changes: both files
were already pinned at the same source commit.
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
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
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
