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

workplans/INFO-WP-0027-concept-declaration-coverage.md

@@ -4,7 +4,7 @@ type: workplan
 title: "Close the concept-declaration gap so ownership conflicts are detectable"
 domain: infotech
 repo: info-tech-canon
-status: active
+status: finished
 owner: claude
 topic_slug: canon-federation
 created: "2026-09-20"
@@ -243,7 +243,7 @@ without a boundary review would repeat the mistake this workplan exists to fix.
 
 ```task
 id: INFO-WP-0027-T07
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "f2f23e8e-542b-5b37-82fd-95cd694af493"
 ```
@@ -282,7 +282,7 @@ restored trust in the earlier reviews.
 
 ```task
 id: INFO-WP-0027-T05
-status: todo
+status: done
 priority: low
 state_hub_task_id: "eb02c948-6401-5ef7-a341-4563ee73e00c"
 ```
@@ -347,3 +347,66 @@ The method limit is the finding worth carrying: hash verification and name
 resolution are two different checks, and federation reviews were running only the
 first. Worth making the second a standing check rather than a one-off, which is
 not in this workplan's scope.
+
+### Result — 2026-09-20 (T05)
+
+Residual R-3 resolved by disambiguation, as recommended, with no rename. CARING
+section 10.7 now states that its `Authority` exposure mode names a demanding
+party rather than a right, links to ITC-ORG section 10.17, and says that an
+Authority in that section holds no organizational authority over the system it
+compels — it compels from outside. ITC-ORG section 10.17 carries the reciprocal
+sentence and adds that SecurityCanon's `AuthMode` qualifies the exercise of this
+right rather than redefining it.
+
+The test the residual asked for — that a reader arriving from
+`sec-authority:AuthMode` can tell which sense a section means — is met by both
+sections naming the other.
+
+### Result — 2026-09-20 (T07)
+
+All seventeen concepts that no artifact declared are now declared, and the
+`concept_defined_without_owner` warning is at zero. The Organization Model takes
+eleven (`Assignment`, `Availability`, `Capacity`, `CollectiveActor`,
+`Competence`, `Group`, `OrganizationEntity`, `OrganizationalCapability`, `Post`,
+`ReportingLine`, `Skill`), CARING four and the Capability Model two.
+
+The question the task flagged is answered: `Capacity` in the Organization Model
+and `Capacity behaviour` in the Capability Model are two concepts. One is how
+much work an actor or group can absorb; the other is whether a capability's
+supply is elastic or fixed as demand grows. Neither moves.
+
+Two of CARING's four were not new concepts. `Capability Profile` and
+`Derived Capability` are the prose spellings of the declared
+`CaringCapabilityProfile` and `CaringDerivedCapability`; both spellings are now
+declared to the same owner so the name a reader meets in the text resolves, with
+no conflict. `Effective Access` and `Declared Access` are genuinely central and
+were genuinely undeclared.
+
+Three boundary reviews are added — organization, caring and capability — which
+brings the count to fourteen.
+
+## Closure — 2026-09-20
+
+All seven tasks are done. Final state: the ownership index holds 718 declared
+concepts against 690 the extractor can see, zero ownership conflicts, zero
+declaration errors and zero unowned-concept warnings. `kernel/itc-kernel-map` is
+the only artifact declaring nothing, by design and by exemption in the code.
+
+What the workplan set out to do, it did: the gap that let `itc-org:Authority`
+pass a federation conflict check unseen is closed, measured, reported and
+enforced, and both accepted extension boundaries were re-verified against the
+enlarged index.
+
+What it found on the way is worth more than what it fixed. Hash verification and
+name resolution are two different checks, and every federation review so far had
+run only the first — which is why nine import declarations across two boundaries
+named concepts their pinned artifact does not define. Making name resolution a
+standing check is not in this workplan's scope and deserves its own.
+
+Residual R-2, the proposal to generalise CARING section 32, remains open and
+untouched, as this workplan said it would.
+
+Limits. Extraction reads three definition forms; seed-concept lists and YAML
+payload concepts are declared but not extracted, which is why the ratio exceeds
+one. A declaration records that an artifact claims a concept, not that the
+concept is well defined. Everything here is agent review, not human sign-off.