info-tech-canon/workplans/ADHOC-2026-09-20.md

id	slug	title	status	flavor	state_hub_workstream_id
ADHOC-2026-09-20	adhoc-2026-09-20	Ad hoc tasks, 2026-09-20	finished	maintenance	2bc6d66c-50da-58cb-af2d-be9587bed07d

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

id: ADHOC-2026-09-20-T01
status: done
priority: medium
state_hub_task_id: "66b8221c-3599-5335-affa-e1fcd021efbc"

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.