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/agent/briefs/model-capability.md

@@ -42,7 +42,9 @@ Imports and anchors:
 - `CapabilityQualityDimension`
 - `CapabilityRequirement`
 - `CapabilityResourceClass`
+- `Capacity behaviour`
 - `InfoTechCanon Capability Model`
+- `Supply`
 
 ## Related Distinctions
 

infospace/agent/briefs/model-organization.md

@@ -28,18 +28,29 @@ Imports and anchors:
 - `Accountability`
 - `Actor`
 - `Agent`
+- `Assignment`
 - `Authority`
+- `Availability`
+- `Capacity`
+- `CollectiveActor`
 - `Community`
+- `Competence`
+- `Group`
 - `Household`
 - `InfoTechCanon Organization Model`
 - `Membership`
 - `Organization`
+- `OrganizationEntity`
+- `OrganizationalCapability`
 - `OrganizationalUnit`
 - `Ownership`
 - `Person`
 - `Position`
+- `Post`
+- `ReportingLine`
 - `Responsibility`
 - `Role`
+- `Skill`
 - `Stewardship`
 - `Team`
 

infospace/agent/briefs/standard-caring.md

@@ -49,6 +49,10 @@ Imports and anchors:
 - `CARINGPlane`
 - `CARINGRedesignProcedure`
 - `CARINGRestrictionPrecedence`
+- `Capability Profile`
+- `Declared Access`
+- `Derived Capability`
+- `Effective Access`
 - `InfoTechCanon CARING Access Governance Standard`
 
 ## Related Distinctions

infospace/agent/retrieval-index.json

@@ -1433,7 +1433,9 @@
         "CapabilityQualityDimension",
         "CapabilityRequirement",
         "CapabilityResourceClass",
-        "InfoTechCanon Capability Model"
+        "Capacity behaviour",
+        "InfoTechCanon Capability Model",
+        "Supply"
       ],
       "relationships": [
         {
@@ -2162,18 +2164,29 @@
         "Accountability",
         "Actor",
         "Agent",
+        "Assignment",
         "Authority",
+        "Availability",
+        "Capacity",
+        "CollectiveActor",
         "Community",
+        "Competence",
+        "Group",
         "Household",
         "InfoTechCanon Organization Model",
         "Membership",
         "Organization",
+        "OrganizationEntity",
+        "OrganizationalCapability",
         "OrganizationalUnit",
         "Ownership",
         "Person",
         "Position",
+        "Post",
+        "ReportingLine",
         "Responsibility",
         "Role",
+        "Skill",
         "Stewardship",
         "Team"
       ],
@@ -3418,6 +3431,10 @@
         "CARINGPlane",
         "CARINGRedesignProcedure",
         "CARINGRestrictionPrecedence",
+        "Capability Profile",
+        "Declared Access",
+        "Derived Capability",
+        "Effective Access",
         "InfoTechCanon CARING Access Governance Standard"
       ],
       "relationships": [

infospace/agent/retrieval-index.md

@@ -395,7 +395,7 @@ Items: **81**
 - Source path: `infospace/assimilation/it-capability-canon/source/ITCapabilityCanonV0.1.md`
 - Summary: Domain model used by canon profiles and standards: InfoTechCanon Capability Model.
 - Imports and anchors: `catalog/evidence-basis`, `kernel/itc-core`, `model/evidence`, `model/governance`, `model/landscape`, `model/observability`, `model/purpose-demand-extension`
-- Owned concepts: `Capability`, `CapabilityConsumption`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `InfoTechCanon Capability Model`
+- Owned concepts: `Capability`, `CapabilityConsumption`, `CapabilityContract`, `CapabilityDomain`, `CapabilityEvidenceHook`, `CapabilityInclusionRule`, `CapabilityMaturityLevel`, `CapabilityProfile`, `CapabilityProvider`, `CapabilityProvision`, `CapabilityQualityDimension`, `CapabilityRequirement`, `CapabilityResourceClass`, `Capacity behaviour`, `InfoTechCanon Capability Model`, `Supply`
 
 ### InfoTechCanon Data Model
 
@@ -495,7 +495,7 @@ Items: **81**
 - Source path: `seeds/InfoTechCanonOrganizationModel_RC1_seed.md`
 - Summary: Domain model used by canon profiles and standards: InfoTechCanon Organization Model.
 - Imports and anchors: `kernel/itc-core`, `model/evidence`, `model/identity`
-- Owned concepts: `Accountability`, `Actor`, `Agent`, `Authority`, `Community`, `Household`, `InfoTechCanon Organization Model`, `Membership`, `Organization`, `OrganizationalUnit`, `Ownership`, `Person`, `Position`, `Responsibility`, `Role`, `Stewardship`, `Team`
+- Owned concepts: `Accountability`, `Actor`, `Agent`, `Assignment`, `Authority`, `Availability`, `Capacity`, `CollectiveActor`, `Community`, `Competence`, `Group`, `Household`, `InfoTechCanon Organization Model`, `Membership`, `Organization`, `OrganizationEntity`, `OrganizationalCapability`, `OrganizationalUnit`, `Ownership`, `Person`, `Position`, `Post`, `ReportingLine`, `Responsibility`, `Role`, `Skill`, `Stewardship`, `Team`
 
 ### InfoTechCanon Purpose And Demand Model Extension
 
@@ -795,7 +795,7 @@ Items: **81**
 - Source path: `seeds/InfoTechCanonCaringAccessGovernanceStandard.md`
 - Summary: Cross-cutting canon standard: InfoTechCanon CARING Access Governance Standard.
 - Imports and anchors: `kernel/itc-core`, `model/access-control`, `model/data`, `model/devsecops`, `model/evidence`, `model/governance`, `model/network`, `model/observability`, `model/organization`, `model/security`, `model/task`, `standard/tagging`
-- Owned concepts: `CARINGAccessDescriptor`, `CARINGAnalysisFitnessTest`, `CARINGAnalysisProcedure`, `CARINGCanonicalRole`, `CARINGCapabilityProfile`, `CARINGDeclaredAccessMap`, `CARINGDerivedCapability`, `CARINGEffectiveAccessMap`, `CARINGExposureEvent`, `CARINGExposureMode`, `CARINGInducedAccess`, `CARINGOrganizationRelation`, `CARINGPlane`, `CARINGRedesignProcedure`, `CARINGRestrictionPrecedence`, `InfoTechCanon CARING Access Governance Standard`
+- Owned concepts: `CARINGAccessDescriptor`, `CARINGAnalysisFitnessTest`, `CARINGAnalysisProcedure`, `CARINGCanonicalRole`, `CARINGCapabilityProfile`, `CARINGDeclaredAccessMap`, `CARINGDerivedCapability`, `CARINGEffectiveAccessMap`, `CARINGExposureEvent`, `CARINGExposureMode`, `CARINGInducedAccess`, `CARINGOrganizationRelation`, `CARINGPlane`, `CARINGRedesignProcedure`, `CARINGRestrictionPrecedence`, `Capability Profile`, `Declared Access`, `Derived Capability`, `Effective Access`, `InfoTechCanon CARING Access Governance Standard`
 
 ### InfoTechCanon Emission Cadence Standard
 

infospace/agent/retrieval-index.yaml

@@ -917,7 +917,9 @@ items:
   - CapabilityQualityDimension
   - CapabilityRequirement
   - CapabilityResourceClass
+  - Capacity behaviour
   - InfoTechCanon Capability Model
+  - Supply
   imports:
   - catalog/evidence-basis
   - kernel/itc-core
@@ -1538,18 +1540,29 @@ items:
   - Accountability
   - Actor
   - Agent
+  - Assignment
   - Authority
+  - Availability
+  - Capacity
+  - CollectiveActor
   - Community
+  - Competence
+  - Group
   - Household
   - InfoTechCanon Organization Model
   - Membership
   - Organization
+  - OrganizationEntity
+  - OrganizationalCapability
   - OrganizationalUnit
   - Ownership
   - Person
   - Position
+  - Post
+  - ReportingLine
   - Responsibility
   - Role
+  - Skill
   - Stewardship
   - Team
   imports:
@@ -2378,6 +2391,10 @@ items:
   - CARINGPlane
   - CARINGRedesignProcedure
   - CARINGRestrictionPrecedence
+  - Capability Profile
+  - Declared Access
+  - Derived Capability
+  - Effective Access
   - InfoTechCanon CARING Access Governance Standard
   imports:
   - kernel/itc-core

infospace/indexes/artifact-tree.yaml

@@ -1,5 +1,5 @@
 root: infospace
-file_count: 291
+file_count: 294
 files:
 - path: README.md
   directory: .
@@ -610,6 +610,9 @@ files:
 - path: models/capability/InfoTechCanonCapabilityModel.md
   directory: models/capability
   name: InfoTechCanonCapabilityModel.md
+- path: models/capability/boundary-review.md
+  directory: models/capability
+  name: boundary-review.md
 - path: models/capability/capabilities.yaml
   directory: models/capability
   name: capabilities.yaml
@@ -676,6 +679,9 @@ files:
 - path: models/organization/InfoTechCanonOrganizationModel.md
   directory: models/organization
   name: InfoTechCanonOrganizationModel.md
+- path: models/organization/boundary-review.md
+  directory: models/organization
+  name: boundary-review.md
 - path: models/security/InfoTechCanonSecurityModel.md
   directory: models/security
   name: InfoTechCanonSecurityModel.md
@@ -826,6 +832,9 @@ files:
 - path: standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml
   directory: standards/caring/benchmarks/kubernetes-rbac
   name: native-concepts.yaml
+- path: standards/caring/boundary-review.md
+  directory: standards/caring
+  name: boundary-review.md
 - path: standards/emission-cadence/InfoTechCanonEmissionCadenceStandard.md
   directory: standards/emission-cadence
   name: InfoTechCanonEmissionCadenceStandard.md

infospace/indexes/concept-ownership.yaml

@@ -1,4 +1,4 @@
-concept_count: 752
+concept_count: 769
 concepts:
 - concept: Canon federation research provenance
   owner: assimilation/canon-federation
@@ -472,6 +472,14 @@ concepts:
   owner: model/capability
   path: models/capability/InfoTechCanonCapabilityModel.md
   source: artifact_title
+- concept: Capacity behaviour
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
+- concept: Supply
+  owner: model/capability
+  path: models/capability/InfoTechCanonCapabilityModel.md
+  source: frontmatter.owned_concepts
 - concept: Capability
   owner: model/capability
   path: models/capability/InfoTechCanonCapabilityModel.md
@@ -2144,6 +2152,50 @@ concepts:
   owner: model/organization
   path: models/organization/InfoTechCanonOrganizationModel.md
   source: artifact_title
+- concept: Assignment
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: Availability
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: Capacity
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: CollectiveActor
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: Competence
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: Group
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: OrganizationEntity
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: OrganizationalCapability
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: Post
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: ReportingLine
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
+- concept: Skill
+  owner: model/organization
+  path: models/organization/InfoTechCanonOrganizationModel.md
+  source: frontmatter.owned_concepts
 - concept: Accountability
   owner: model/organization
   path: models/organization/InfoTechCanonOrganizationModel.md
@@ -2806,6 +2858,22 @@ concepts:
   owner: standard/caring
   path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
   source: artifact_title
+- concept: Declared Access
+  owner: standard/caring
+  path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+  source: frontmatter.owned_concepts
+- concept: Effective Access
+  owner: standard/caring
+  path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+  source: frontmatter.owned_concepts
+- concept: Capability Profile
+  owner: standard/caring
+  path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+  source: frontmatter.owned_concepts
+- concept: Derived Capability
+  owner: standard/caring
+  path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+  source: frontmatter.owned_concepts
 - concept: CARINGAccessDescriptor
   owner: standard/caring
   path: standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md

infospace/models/capability/InfoTechCanonCapabilityModel.md

@@ -35,6 +35,8 @@ related:
   - InfoTechCanonTaskModel
   - InfoTechCanonCaringAccessGovernanceStandard
 owned_concepts:
+  - Capacity behaviour
+  - Supply
   - Capability
   - CapabilityDomain
   - CapabilityProfile

infospace/models/capability/boundary-review.md

@@ -0,0 +1,14 @@
+# InfoTechCanon Capability Model concept boundary review — 2026-09-20
+
+Authority: INFO-WP-0027-T07, which declared the two concepts this model defined
+without declaring. No concept is renamed, moved or removed.
+
+| Concept | Owner | Resolution | Decided by |
+| --- | --- | --- | --- |
+| `Capacity behaviour` | model/capability | Whether a capability's supply is elastic or fixed as demand grows. The Organization Model's `Capacity` is how much work an actor or group can absorb. Different questions; no transfer. | this review |
+| `Supply` | model/capability | Internal, drawn from own capacity, or external, purchased. No other artifact defines the name. | this review |
+| `Capability` | model/capability | The canonical capability concept. The Organization Model's `OrganizationalCapability` is the organizational reading and imports; the Purpose and Demand extension's `ProducerCapability` and CARING's `CaringCapabilityProfile` are qualified specializations. | this review |
+
+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.

infospace/models/organization/InfoTechCanonOrganizationModel.md

@@ -7,6 +7,17 @@ version: RC1-seed
 # Incremental machine-readable ownership for the social extension; existing
 # organization concepts retain their definitions and ownership declarations below.
 owned_concepts:
+  - Assignment
+  - Availability
+  - Capacity
+  - CollectiveActor
+  - Competence
+  - Group
+  - OrganizationEntity
+  - OrganizationalCapability
+  - Post
+  - ReportingLine
+  - Skill
   - Accountability
   - Actor
   - Agent
@@ -852,6 +863,12 @@ Profiles MAY require exactly one accountable actor per scope, but the core model
 
 **Authority** is the recognized right to make decisions, allocate resources, approve changes, enforce rules, or direct action within a scope.
 
+This is the concept SecurityCanon's Auth Mode qualifies: an auth mode describes
+the relationship in which this right is exercised, not the right itself. It is
+distinct from the CARING section 10.7 Authority exposure mode, which names an
+external body compelling disclosure rather than a right held within the
+organization.
+
 Subtypes:
 
 ```text

infospace/models/organization/boundary-review.md

@@ -0,0 +1,19 @@
+# InfoTechCanon Organization Model concept boundary review — 2026-09-20
+
+Authority: INFO-WP-0027-T02 and T07, which declared the concepts this model
+defines, and T05, which resolved residual R-3 from the SecurityCanon boundary
+review. No concept is renamed, moved or removed.
+
+| Concept | Owner | Resolution | Decided by |
+| --- | --- | --- | --- |
+| `Authority` | model/organization | The recognized right to make decisions, allocate resources, approve changes, enforce rules or direct action within a scope. The CARING section 10.7 `Authority` exposure mode names an external body compelling disclosure, not a right; both sections now say so. SecurityCanon's `AuthMode` qualifies the exercise of this right and does not redefine it. | this review (R-3) |
+| `Actor` | model/organization | Declared here under T02. ITC-ACCESS binds `Subject` as the access-control view of an actor; the identity model imports Actor; SecurityCanon imports it against a pinned hash. | kernel map |
+| `Ownership` | model/organization | The kernel map assigns Ownership and Stewardship here. SecurityCanon's manifest pinned it to Core until the T04 name-resolution audit corrected it. | kernel map |
+| `Capacity` | model/organization | The amount of work or responsibility an actor or group can realistically absorb in a period. The Capability Model's `Capacity behaviour` describes how a capability's supply responds to demand. Different questions, different names; no transfer. | this review |
+| `OrganizationalCapability` | model/organization | The capacity of an organization to reliably perform a class of work. The Capability Model owns `Capability` as the canonical capability concept; this is the organizational reading of it and imports rather than competes. | this review |
+| `CollectiveActor` | model/organization | A group-like actor that can hold responsibility or authority. Distinct from `Group`, which is structural, and from identity's collective concepts. | this review |
+| `Person`, `Agent`, `Role`, `Membership`, `Responsibility`, `Accountability`, `Position`, `Team` | model/organization | Assigned here by the kernel map concept-owner table and declared under T02. | kernel map |
+
+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.

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.

infospace/views/by-concept.md

@@ -2,7 +2,7 @@
 
 # By Concept
 
-Concept count: **752**
+Concept count: **769**
 
 | Concept | Owner | Source |
 | --- | --- | --- |
@@ -124,6 +124,8 @@ Concept count: **752**
 | TemporaryAccess | `model/access-control` | `frontmatter.owned_concepts` |
 | TokenReference | `model/access-control` | `frontmatter.owned_concepts` |
 | InfoTechCanon Capability Model | `model/capability` | `artifact_title` |
+| Capacity behaviour | `model/capability` | `frontmatter.owned_concepts` |
+| Supply | `model/capability` | `frontmatter.owned_concepts` |
 | Capability | `model/capability` | `frontmatter.owned_concepts` |
 | CapabilityDomain | `model/capability` | `frontmatter.owned_concepts` |
 | CapabilityProfile | `model/capability` | `frontmatter.owned_concepts` |
@@ -542,6 +544,17 @@ Concept count: **752**
 | TraceContext | `model/observability` | `frontmatter.owned_concepts` |
 | TraceSample | `model/observability` | `frontmatter.owned_concepts` |
 | InfoTechCanon Organization Model | `model/organization` | `artifact_title` |
+| Assignment | `model/organization` | `frontmatter.owned_concepts` |
+| Availability | `model/organization` | `frontmatter.owned_concepts` |
+| Capacity | `model/organization` | `frontmatter.owned_concepts` |
+| CollectiveActor | `model/organization` | `frontmatter.owned_concepts` |
+| Competence | `model/organization` | `frontmatter.owned_concepts` |
+| Group | `model/organization` | `frontmatter.owned_concepts` |
+| OrganizationEntity | `model/organization` | `frontmatter.owned_concepts` |
+| OrganizationalCapability | `model/organization` | `frontmatter.owned_concepts` |
+| Post | `model/organization` | `frontmatter.owned_concepts` |
+| ReportingLine | `model/organization` | `frontmatter.owned_concepts` |
+| Skill | `model/organization` | `frontmatter.owned_concepts` |
 | Accountability | `model/organization` | `frontmatter.owned_concepts` |
 | Actor | `model/organization` | `frontmatter.owned_concepts` |
 | Agent | `model/organization` | `frontmatter.owned_concepts` |
@@ -707,6 +720,10 @@ Concept count: **752**
 | Globex Tenant | `small-saas/tenant/globex` | `artifact_title` |
 | Ada Admin | `small-saas/user/ada-admin` | `artifact_title` |
 | InfoTechCanon CARING Access Governance Standard | `standard/caring` | `artifact_title` |
+| Declared Access | `standard/caring` | `frontmatter.owned_concepts` |
+| Effective Access | `standard/caring` | `frontmatter.owned_concepts` |
+| Capability Profile | `standard/caring` | `frontmatter.owned_concepts` |
+| Derived Capability | `standard/caring` | `frontmatter.owned_concepts` |
 | CARINGAccessDescriptor | `standard/caring` | `frontmatter.owned_concepts` |
 | CARINGCanonicalRole | `standard/caring` | `frontmatter.owned_concepts` |
 | CARINGOrganizationRelation | `standard/caring` | `frontmatter.owned_concepts` |

infospace/views/repository-tree.md

@@ -2,7 +2,7 @@
 
 # Repository Tree
 
-File count: **291**
+File count: **294**
 
 - `README.md`
 - `agent/README.md`
@@ -207,6 +207,7 @@ File count: **291**
 - `models/access-control/InfoTechCanonAccessControlModel.md`
 - `models/access-control/boundary-review.md`
 - `models/capability/InfoTechCanonCapabilityModel.md`
+- `models/capability/boundary-review.md`
 - `models/capability/capabilities.yaml`
 - `models/data/InfoTechCanonDataModel.md`
 - `models/data/attribute-value-types-alignment.md`
@@ -229,6 +230,7 @@ File count: **291**
 - `models/observability/InfoTechCanonObservabilityModel.md`
 - `models/observability/boundary-review.md`
 - `models/organization/InfoTechCanonOrganizationModel.md`
+- `models/organization/boundary-review.md`
 - `models/security/InfoTechCanonSecurityModel.md`
 - `models/security/boundary-review.md`
 - `models/task/InfoTechCanonTaskModel.md`
@@ -279,6 +281,7 @@ File count: **291**
 - `standards/caring/benchmarks/kubernetes-rbac/caring-mapping.yaml`
 - `standards/caring/benchmarks/kubernetes-rbac/findings-and-canon-pressure.yaml`
 - `standards/caring/benchmarks/kubernetes-rbac/native-concepts.yaml`
+- `standards/caring/boundary-review.md`
 - `standards/emission-cadence/InfoTechCanonEmissionCadenceStandard.md`
 - `standards/emission-cadence/examples/qonto-assistant.yaml`
 - `standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md`

tests/test_maintenance.py

@@ -160,15 +160,26 @@ def test_concept_coverage_cli_reports_one_artifact(capsys):
     assert [item["artifact"] for item in payload["artifacts"]] == ["model/identity"]
 
 
-def test_declaration_checks_warn_on_unowned_and_error_on_silence(tmp_path):
+def test_every_defined_concept_has_an_owner():
     context = load_context()
-    ownership = concept_ownership(context)
-    result = concept_declaration_checks(context, ownership)
+    result = concept_declaration_checks(context, concept_ownership(context))
 
     assert not result["errors"]
-    warned = {item["artifact_id"] for item in result["warnings"]}
-    assert "model/organization" in warned
-    assert all(item["code"] == "concept_defined_without_owner" for item in result["warnings"])
+    assert not result["warnings"]
+
+
+def test_declaration_warning_fires_for_a_concept_nobody_owns(corpus):
+    target = corpus / "standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md"
+    text = target.read_text(encoding="utf-8")
+    target.write_text(text.replace("  - Effective Access\n", "", 1), encoding="utf-8")
+
+    context = load_context(corpus)
+    result = concept_declaration_checks(context, concept_ownership(context))
+
+    warned = {item["artifact_id"]: item for item in result["warnings"]}
+    assert "standard/caring" in warned
+    assert "Effective Access" in warned["standard/caring"]["concepts"]
+    assert warned["standard/caring"]["code"] == "concept_defined_without_owner"
 
 
 def test_declaration_error_fires_when_an_artifact_declares_nothing(corpus):

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.