coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Bind the CARING Scope dimension to one definition (R-1)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 3s
Details

Browse source 
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
This commit is contained in:
tegwick 2026-09-20 22:42:28 +02:00
parent d61ec8adf6
commit 209bb5a9c4
2 changed files with 53 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

45
workplans/ADHOC-2026-09-20.md Normal file
View file

@ -0,0 +1,45 @@
---
id: ADHOC-2026-09-20
slug: adhoc-2026-09-20
title: Ad hoc tasks, 2026-09-20
status: finished
flavor: maintenance
---
# Ad hoc tasks — 2026-09-20
Opportunistic work found during the SecurityCanon boundary review
(SECURITY-WP-0001 T02/T03), recorded there as residual R-1.
## R-1 — one definition of Scope
```task
id: ADHOC-2026-09-20-T01
status: done
priority: medium
```
The boundary review reported CARING and ITC-ACCESS as holding two definitions of
`Scope` and named ITC-ACCESS the owner. Reading the corpus corrects both halves
of that:
- `Scope` is owned by **ITC-IDENT section 2.10** — "a boundary within which
identifiers, meanings, relationships, accounts, policies, or lifecycle states
are valid".
- ITC-ACCESS owns **ResourceScope** (section 11.8), which the model already
declares as refining "the general identity Scope". That is a declared
refinement, not a competing definition, so there was never a conflict there.
- CARING section 21 is the actual second use: it presents "Dimension: Scope"
with a canonical ladder from Ecosystem to Field without saying which concept
the dimension ranges over.
Resolution: CARING section 21 now states that the dimension ranges over
`ITC-IDENT Scope` instances, that its 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 value in
the ladder changes.
Consequences outside this repo: the SecurityCanon placement record named
ITC-ACCESS the owner of `Scope` and `imports.json` pinned it to the
access-control model. Both are corrected on the SecurityCanon side to import
`Scope` from the identity model.