---
id: ADHOC-2026-09-20
slug: adhoc-2026-09-20
title: Ad hoc tasks, 2026-09-20
status: finished
flavor: maintenance
state_hub_workstream_id: "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

```task
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.