diff --git a/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md b/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
index a1791f8..db02377 100644
--- a/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+++ b/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
@@ -1755,6 +1755,14 @@ Scope defines where the role applies.
 
 Scope prevents canonical roles from exploding into countless local variants.
 
+This dimension does not define Scope. It ranges over instances of
+[ITC-IDENT Scope](../../models/identity/InfoTechCanonIdentityModel.md) section 2.10,
+the general boundary within which identifiers, meanings, relationships, accounts,
+policies or lifecycle states are valid. The ladder below is the canonical value
+set CARING uses for that dimension, not a second definition of the concept. Where
+access applies to a resource boundary specifically, ITC-ACCESS section 11.8
+ResourceScope refines the same concept.
+
 Canonical scope ladder:
 
 ```text
diff --git a/workplans/ADHOC-2026-09-20.md b/workplans/ADHOC-2026-09-20.md
new file mode 100644
index 0000000..89a46af
--- /dev/null
+++ b/workplans/ADHOC-2026-09-20.md
@@ -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.