tegwick
209bb5a9c4
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
45 lines
1.7 KiB
Markdown
45 lines
1.7 KiB
Markdown
---
|
|
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.
|