From 5f652d200f3c9d3180f3885d29ceace63308238b Mon Sep 17 00:00:00 2001 From: tegwick Date: Sun, 20 Sep 2026 23:32:57 +0200 Subject: [PATCH] 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 Assistant: claude-code Assistant-Model: opus Assistant-Process: 3588@bnt-lap001 Assistant-Session: 24b80f66-e5a7-4e61-99fe-2d422e6d17da --- infospace/agent/briefs/model-capability.md | 2 + infospace/agent/briefs/model-organization.md | 11 +++ infospace/agent/briefs/standard-caring.md | 4 ++ infospace/agent/retrieval-index.json | 19 ++++- infospace/agent/retrieval-index.md | 6 +- infospace/agent/retrieval-index.yaml | 17 +++++ infospace/indexes/artifact-tree.yaml | 11 ++- infospace/indexes/concept-ownership.yaml | 70 ++++++++++++++++++- .../InfoTechCanonCapabilityModel.md | 2 + .../models/capability/boundary-review.md | 14 ++++ .../InfoTechCanonOrganizationModel.md | 17 +++++ .../models/organization/boundary-review.md | 19 +++++ ...TechCanonCaringAccessGovernanceStandard.md | 14 ++++ infospace/standards/caring/boundary-review.md | 21 ++++++ infospace/views/by-concept.md | 19 ++++- infospace/views/repository-tree.md | 5 +- tests/test_maintenance.py | 23 ++++-- ...FO-WP-0027-concept-declaration-coverage.md | 69 +++++++++++++++++- 18 files changed, 326 insertions(+), 17 deletions(-) create mode 100644 infospace/models/capability/boundary-review.md create mode 100644 infospace/models/organization/boundary-review.md create mode 100644 infospace/standards/caring/boundary-review.md 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.