diff --git a/infospace/agent/briefs/model-capability.md b/infospace/agent/briefs/model-capability.md
index 0992e86..44f4422 100644
--- a/infospace/agent/briefs/model-capability.md
+++ b/infospace/agent/briefs/model-capability.md
@@ -42,7 +42,9 @@ Imports and anchors:
 - `CapabilityQualityDimension`
 - `CapabilityRequirement`
 - `CapabilityResourceClass`
+- `Capacity behaviour`
 - `InfoTechCanon Capability Model`
+- `Supply`
 
 ## Related Distinctions
 
diff --git a/infospace/agent/briefs/model-organization.md b/infospace/agent/briefs/model-organization.md
index 91c0a00..992a2a4 100644
--- a/infospace/agent/briefs/model-organization.md
+++ b/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`
 
diff --git a/infospace/agent/briefs/standard-caring.md b/infospace/agent/briefs/standard-caring.md
index 4e28174..b71a607 100644
--- a/infospace/agent/briefs/standard-caring.md
+++ b/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
diff --git a/infospace/agent/retrieval-index.json b/infospace/agent/retrieval-index.json
index 11e4111..fbd24e8 100644
--- a/infospace/agent/retrieval-index.json
+++ b/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": [
diff --git a/infospace/agent/retrieval-index.md b/infospace/agent/retrieval-index.md
index a840571..0b7cdf4 100644
--- a/infospace/agent/retrieval-index.md
+++ b/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
 
diff --git a/infospace/agent/retrieval-index.yaml b/infospace/agent/retrieval-index.yaml
index 1f851ca..8477096 100644
--- a/infospace/agent/retrieval-index.yaml
+++ b/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
diff --git a/infospace/indexes/artifact-tree.yaml b/infospace/indexes/artifact-tree.yaml
index 7429a22..82689c0 100644
--- a/infospace/indexes/artifact-tree.yaml
+++ b/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
diff --git a/infospace/indexes/concept-ownership.yaml b/infospace/indexes/concept-ownership.yaml
index 9b9cbae..dd7f98a 100644
--- a/infospace/indexes/concept-ownership.yaml
+++ b/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
diff --git a/infospace/models/capability/InfoTechCanonCapabilityModel.md b/infospace/models/capability/InfoTechCanonCapabilityModel.md
index 9616571..05d6593 100644
--- a/infospace/models/capability/InfoTechCanonCapabilityModel.md
+++ b/infospace/models/capability/InfoTechCanonCapabilityModel.md
@@ -35,6 +35,8 @@ related:
   - InfoTechCanonTaskModel
   - InfoTechCanonCaringAccessGovernanceStandard
 owned_concepts:
+  - Capacity behaviour
+  - Supply
   - Capability
   - CapabilityDomain
   - CapabilityProfile
diff --git a/infospace/models/capability/boundary-review.md b/infospace/models/capability/boundary-review.md
new file mode 100644
index 0000000..7d815a8
--- /dev/null
+++ b/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.
diff --git a/infospace/models/organization/InfoTechCanonOrganizationModel.md b/infospace/models/organization/InfoTechCanonOrganizationModel.md
index d9a2c17..f2fcb7a 100644
--- a/infospace/models/organization/InfoTechCanonOrganizationModel.md
+++ b/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
diff --git a/infospace/models/organization/boundary-review.md b/infospace/models/organization/boundary-review.md
new file mode 100644
index 0000000..4bc723d
--- /dev/null
+++ b/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.
diff --git a/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md b/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
index db02377..01c0295 100644
--- a/infospace/standards/caring/InfoTechCanonCaringAccessGovernanceStandard.md
+++ b/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
diff --git a/infospace/standards/caring/boundary-review.md b/infospace/standards/caring/boundary-review.md
new file mode 100644
index 0000000..c4a6121
--- /dev/null
+++ b/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.
diff --git a/infospace/views/by-concept.md b/infospace/views/by-concept.md
index ea79c08..30b17ba 100644
--- a/infospace/views/by-concept.md
+++ b/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` |
diff --git a/infospace/views/repository-tree.md b/infospace/views/repository-tree.md
index 8692457..fbc0d94 100644
--- a/infospace/views/repository-tree.md
+++ b/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`
diff --git a/tests/test_maintenance.py b/tests/test_maintenance.py
index 6dd2f0e..dc8a94f 100644
--- a/tests/test_maintenance.py
+++ b/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):
diff --git a/workplans/INFO-WP-0027-concept-declaration-coverage.md b/workplans/INFO-WP-0027-concept-declaration-coverage.md
index 5e1867d..2f91a8c 100644
--- a/workplans/INFO-WP-0027-concept-declaration-coverage.md
+++ b/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.