The SecurityCanon boundary review recorded a residual: CARING and ITC-ACCESS
hold two definitions of Scope, with ITC-ACCESS named owner. Reading the corpus
corrects both halves. ITC-IDENT section 2.10 owns Scope as the general boundary
within which identifiers, meanings, relationships, accounts, policies or
lifecycle states are valid, and ITC-ACCESS section 11.8 ResourceScope already
declares itself a refinement of that general identity Scope rather than a
competing definition.
The second use the residual was reaching for is CARING section 21, which
presented a dimension named Scope with a ladder from Ecosystem to Field without
saying what the dimension ranges over. It now states that it ranges over
ITC-IDENT Scope instances, that the ladder is the canonical value set rather
than a second definition, and that ResourceScope refines the same concept for
resource boundaries.
No concept is renamed, moved or removed and no ladder value changes, so the
corpus is unchanged in shape; make check passes with 46 tests, clean validation
and a passing small-saas profile. The correction is carried back to the
SecurityCanon placement record and imports.json, where Scope now imports from
the identity model.
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
SecurityCanon publishes an architecture-layer vocabulary for authority
relationships, the Mode of Authority, and references shared InfoTechCanon
concepts. This records the InfoTechCanon-side acceptance of that boundary and
adds reciprocal navigation from the federation interface README.
The accepted dispositions keep the layers apart. Mode of Authority describes the
relationship in which authority is exercised; CARING analyses how an
access-control implementation is composed. Auth Mode is orthogonal to access
operation and to CARING's Canonical Role and Plane, so the Operator role and the
OPERATE mode stay distinct concepts and neither is renamed. SecurityCanon does
not reuse Actor or Subject, which ITC-ACCESS owns and binds as "Subject is the
access-control view of an actor"; it renamed its on-behalf-of dimension to
AuthorityContext instead, so no change is required here.
Verified at security-canon b1fa25eb: all five pinned manifest hashes match Git
blobs at this commit and the sources are unchanged in the review checkout, and
none of the seven concepts SecurityCanon declares appears in any InfoTechCanon
owned_concepts declaration, so the boundary introduces no ownership conflict.
No concept is transferred and nothing is removed, so the corpus is unchanged.
Generated indexes and the repository tree are refreshed for the added file;
make check passes with 46 tests, clean validation and a passing small-saas
profile. This is an agent review, not human sign-off, and it records no consumer
adoption or conformance claim.
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
Finish ITC-WP-0013 (AttributeValueType under ITC-DATA) and ITC-WP-0014
T02/T03/T05/T06/T07. Capability contract schemas, live-catalog review
CLI, landscape/kernel-map pointers. Sit on this version.
A provision can name which other provision satisfies a catalog
dependency. Relation vocabulary is depends_on / may_use only.
Quoted sits below the invoiced/measured peer pair for propagation.
§10.3 now accepts a consumer record that validates against the live
catalog; resource-control's backup restatement is that proof. ITC-GOV
gains EvidenceBasis in tiers (invoiced and measured are peers) and
ITC-CAP requires it on every consumption row (CAP-R10).
A third front door next to incoming/ and demand/: longitudinal PurposeFit
evidence, not a change request and not a canon artifact. Seeded with the
resource-control backup-cycle mapping.
Accept resource-control demand: move resource classes onto provisions,
let requirements carry targets and constraints, add human-effort class H
with native-unit consumption. Model stays proposed.
Security & Governance splits into `security` (secrets, keys, policy,
vulnerability) and `governance` (evidence, lifecycle). Every capability id
is unchanged — domains are navigation_only, so this is a table-of-contents
change, not a concept change.
- capabilities.yaml: 41 capabilities across 9 domains
- ITC-CAP §8 catalog table and promotion gate updated
- OQ-2 closed; decision record added to ASSIMILATION.md
- canon 0.2.0 -> 0.2.1 (patch) + CHANGELOG entry
- ITC-WP-0014 T01 done, workplan active
make validate: ok. make test: 22 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Define the intake and assimilation practice (incoming/ drop zone -> frozen
source snapshot -> Minimal Assimilation Profile -> disposition gate -> canon
transformation -> versioned change notes) and run it on the first inputs.
- infospace/assimilation/intake-and-assimilation-practice.md, incoming/README.md
- assimilation/it-capability-canon: frozen source, comparison matrix, 26
mappings, 8 proposed changes, 7 open questions, decision record (adapt)
- new model ITC-CAP with 41-capability machine-readable catalog, anchored to
owning canon models; CILM rejected, Profile renamed, Provision made explicit
- registered in canon.yaml / artifacts index / infospace.yaml; regenerated
briefs, indexes, views; canon version 0.1.0-scaffold -> 0.2.0 + CHANGELOG
- ITC-WP-0014 for promotion work; ITC-WP-0013 added to the workplan registry
make validate: ok (65 artifacts, 0 errors/warnings). make test: 22 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Register the InfoTechCanon Repository Layout Standard as a domain standard
(itc-repo-layout), processed from demand through the canon's Purpose/Demand
intake without collapsing existing model concepts.
- Register standard in artifacts/index.yaml, canon.yaml, infospace.yaml;
regenerate indexes, views, briefs, tree, and validation (validate green).
- T04: add reconciliation.yaml (partial/as-is dogfooding, declared core
conformance, recorded tensions); resolve the demand by moving it out of
demand/ to the evaluation pack as source-demand.md and removing demand/.
- T05: add consumer-adoption-brief.md for downstream repos.
- Update test artifact/standard counts (60->61, standards 2->3).
- Mark T03/T04/T05 done; workplan and registry status -> finished.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
