Resolve the two senses of Authority and declare the unowned remainder (T05, T07)

R-3 is resolved by disambiguation without a rename. CARING section 10.7 now says
its Authority exposure mode names a demanding party rather than a right, links to
ITC-ORG section 10.17, and notes that such an Authority holds no organizational
authority over the system it compels. ITC-ORG carries the reciprocal sentence and
records that SecurityCanon's AuthMode qualifies the exercise of the right rather
than redefining it.

The seventeen concepts no artifact declared are now declared: eleven to the
Organization Model, four to CARING and two to the Capability Model. Capacity in
the Organization Model and Capacity behaviour in the Capability Model are two
concepts, not one, and neither moves. Two of CARING's four turned out not to be
new concepts at all but the prose spellings of CaringCapabilityProfile and
CaringDerivedCapability; both spellings are declared to the same owner so the
name a reader meets resolves. Effective Access and Declared Access were
genuinely undeclared.

Three boundary reviews are added for organization, caring and capability,
bringing the count to fourteen. The concept_defined_without_owner warning is at
zero, and the test that asserted it fires now proves it on a modified corpus
instead of on the live one.

make check passes with 54 tests, clean validation, no warnings, no stale assets.

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

infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md

@@ -32,6 +32,10 @@ related:
   - InfoTechCanonGovernanceModel
   - InfoTechCanonSecurityModel
 owned_concepts:
+  - Declared Access
+  - Effective Access
+  - Capability Profile
+  - Derived Capability
   - CARINGAccessDescriptor
   - CARINGCanonicalRole
   - CARINGOrganizationRelation
@@ -1059,6 +1063,16 @@ A legal, regulatory, or institutional entity with exceptional access claims.
 
 Authority access should normally be modeled as an exposure event, not as ordinary standing access.
 
+This exposure mode names a **demanding party**, not a right. It is a different
+concept from
+[ITC-ORG Authority](../../models/organization/InfoTechCanonOrganizationModel.md)
+section 10.17, "the recognized right to make decisions, allocate resources,
+approve changes, enforce rules, or direct action within a scope", which the
+Organization Model owns. An Authority in this section holds no organizational
+authority over the system it compels; it compels from outside. Where both senses
+appear together, name the ITC-ORG sense as organizational authority and this one
+as an authority demand.
+
 Examples:
 
 ```text

infospace/standards/caring/boundary-review.md

@@ -0,0 +1,21 @@
+# CARING access governance concept boundary review — 2026-09-20
+
+Authority: INFO-WP-0027-T07, which declared the concepts CARING defines, T05,
+which resolved residual R-3, and ADHOC-2026-09-20-T01, which bound the Scope
+dimension to one definition. No concept is renamed, moved or removed.
+
+| Concept | Owner | Resolution | Decided by |
+| --- | --- | --- | --- |
+| `Effective Access` | standard/caring | CARING's central distinction, with `Declared Access`. Declared here under T07; the Kubernetes RBAC benchmark depends on it. | this review |
+| `Declared Access` | standard/caring | As above. Access Control owns the authorization mechanisms; CARING owns the declared-against-effective analysis over them. | this review |
+| `Capability Profile` | standard/caring | The prose spelling of the declared `CaringCapabilityProfile`. Both spellings are declared so that the name a reader meets in the text resolves; one owner, no conflict. | this review |
+| `Derived Capability` | standard/caring | As above, for `CaringDerivedCapability`. | this review |
+| `Authority` | model/organization | CARING section 10.7 names a legal, regulatory or institutional body with exceptional access claims — a demanding party, not a right. ITC-ORG section 10.17 owns `Authority` as the right itself. Both sections now carry the disambiguation. | this review (R-3) |
+| `Scope` | model/identity | ITC-IDENT section 2.10 owns the general boundary. CARING section 21 ranges over its instances and its ladder is a value set, not a second definition. ITC-ACCESS `ResourceScope` refines the same concept. | ADHOC-2026-09-20-T01 |
+| `Environment` | model/landscape | The kernel map assigns Environment to Landscape. CARING section 21.5 enumerates values for it; SecurityCanon imports it from Landscape. | kernel map |
+| `Subject` | model/access-control | ITC-ACCESS owns Subject as the access-control view of an actor. CARING analyses subjects and imports. | this review |
+| `Canonical Role`, `Plane`, `Condition` | standard/caring | CARING's own dimensions. `Operator` the role is not `OPERATE` the SecurityCanon auth mode, and `Condition` is not `Activation`; both pairs are recorded as distinct in the SecurityCanon boundary. | SECURITY-DEC-2026-003 |
+
+Concepts this artifact declares are listed in its frontmatter. An overlap
+recorded here means another artifact defines the same name; where the owner is
+another artifact, this one imports the definition rather than restating it.