Re-verify both extension boundaries against the enlarged index (T04)

Neither boundary has an ownership conflict now that declarations cover the
corpus, so the central claim of both acceptances holds. Name resolution is a
different matter, and it had never been checked: both original reviews verified
their import manifests by file hash, every hash matched, and that was recorded
as evidence. A hash proves the reviewed file is the pinned file; it says nothing
about whether the concept named in the manifest exists in it.

SecurityCanon: five of twelve imports named concepts their pinned artifact does
not define, corrected on that side to eleven imports. InterfaceCanon: twenty-one
of twenty-five resolve exactly, and two of the four failures were this
repository's omission — SoftwareSystem and SoftwareComponent are Landscape seed
concepts that extraction cannot read and are now declared, making those pins
correct. Interface and Endpoint resolve to the Network Model, which the accepted
clarifications already treat as contextual rather than exact aliases; those pins
are InterfaceCanon's to correct.

Both boundary files carry the re-verification and its method limit.

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-landscape.md

@@ -35,6 +35,8 @@ Imports and anchors:
 - `LandscapeSource`
 - `LandscapeState`
 - `RuntimeResource`
+- `SoftwareComponent`
+- `SoftwareSystem`
 - `TechnicalService`
 - `Workload`
 

infospace/agent/retrieval-index.json

@@ -1928,6 +1928,8 @@
         "LandscapeSource",
         "LandscapeState",
         "RuntimeResource",
+        "SoftwareComponent",
+        "SoftwareSystem",
         "TechnicalService",
         "Workload"
       ],

infospace/agent/retrieval-index.md

@@ -465,7 +465,7 @@ Items: **81**
 - Source path: `seeds/InfoTechCanonLandscapeModel_RC1_seed.md`
 - Summary: Domain model used by canon profiles and standards: InfoTechCanon Landscape Model.
 - Imports and anchors: `kernel/itc-core`, `model/evidence`
-- Owned concepts: `ApplicationService`, `BusinessService`, `Environment`, `InfoTechCanon Landscape Model`, `LandscapeClaim`, `LandscapeEntity`, `LandscapeEvidence`, `LandscapeRelationship`, `LandscapeSource`, `LandscapeState`, `RuntimeResource`, `TechnicalService`, `Workload`
+- Owned concepts: `ApplicationService`, `BusinessService`, `Environment`, `InfoTechCanon Landscape Model`, `LandscapeClaim`, `LandscapeEntity`, `LandscapeEvidence`, `LandscapeRelationship`, `LandscapeSource`, `LandscapeState`, `RuntimeResource`, `SoftwareComponent`, `SoftwareSystem`, `TechnicalService`, `Workload`
 
 ### InfoTechCanon Network Model
 

infospace/agent/retrieval-index.yaml

@@ -1333,6 +1333,8 @@ items:
   - LandscapeSource
   - LandscapeState
   - RuntimeResource
+  - SoftwareComponent
+  - SoftwareSystem
   - TechnicalService
   - Workload
   imports:

infospace/indexes/concept-ownership.yaml

@@ -1,4 +1,4 @@
-concept_count: 750
+concept_count: 752
 concepts:
 - concept: Canon federation research provenance
   owner: assimilation/canon-federation
@@ -1520,6 +1520,14 @@ concepts:
   owner: model/landscape
   path: models/landscape/InfoTechCanonLandscapeModel.md
   source: artifact_title
+- concept: SoftwareSystem
+  owner: model/landscape
+  path: models/landscape/InfoTechCanonLandscapeModel.md
+  source: frontmatter.owned_concepts
+- concept: SoftwareComponent
+  owner: model/landscape
+  path: models/landscape/InfoTechCanonLandscapeModel.md
+  source: frontmatter.owned_concepts
 - concept: BusinessService
   owner: model/landscape
   path: models/landscape/InfoTechCanonLandscapeModel.md

infospace/interfaces/interface-canon-boundary.md

@@ -54,3 +54,24 @@ The file's eventual containing commit identifies the applied review revision;
 the review base above must not be represented as a merge commit. Work and
 verification are tracked in
 [INFO-WP-0026](../../workplans/INFO-WP-0026-interface-canon-boundary-review.md).
+
+## Re-verification — 2026-09-20 (INFO-WP-0027-T04)
+
+Re-run against the enlarged InfoTechCanon ownership index (750 entries, up from
+164) after INFO-WP-0027-T02. Twenty-one of InterfaceCanon's twenty-five declared
+imports resolve by name to the artifact they are pinned to. No ownership
+conflict is introduced by the enlarged index.
+
+Four do not resolve, and two of the four were InfoTechCanon's omission rather
+than InterfaceCanon's:
+
+| Import | Pinned to | Finding |
+| --- | --- | --- |
+| `SoftwareSystem` | ITC-LAND | Defined in a Landscape seed-concept list, which declaration extraction cannot read. Now declared in the Landscape Model; the pin is correct. |
+| `SoftwareComponent` | ITC-LAND | Same. Now declared; the pin is correct. |
+| `Interface` | ITC-LAND | Declared by the Network Model, not Landscape. The clarification above already treats Landscape's Interface seed and Network's attachment-point Interface as contextual mappings rather than exact aliases, so the name resolves to Network and the Landscape pin should be qualified or re-pointed. |
+| `Endpoint` | ITC-LAND | Same as Interface. Network owns the name; the Landscape sense is contextual. |
+
+No InfoTechCanon concept is renamed, moved or removed, and the accepted
+dispositions are unchanged. The `Interface` and `Endpoint` pins are
+InterfaceCanon's to correct; the two Landscape declarations are made here.

infospace/interfaces/security-canon-boundary.md

@@ -70,3 +70,39 @@ Limits of this acceptance:
 - The G7 validator in `prj-canon-federation` pins card paths for
   info-tech-canon, commerce-canon and the-custodian. Registering the
   security-canon card is that project's change; this review does not make it.
+
+## Re-verification — 2026-09-20 (INFO-WP-0027-T04)
+
+Re-run against the enlarged InfoTechCanon ownership index (750 entries, up from
+164) after INFO-WP-0027-T02 gave every defining artifact an `owned_concepts`
+declaration. The original acceptance compared SecurityCanon's concepts against
+the declarations that existed then; this re-runs it against declarations that
+now cover the corpus.
+
+**No ownership conflict.** None of the nine SecurityCanon-owned concepts —
+AuthMode, AuthorityContext, AuthorityRealm, AuthorityProvenance, Activation,
+EvidenceBoundary, AccessSituation, Time, and the dimension slot for Environment —
+collides with an InfoTechCanon declaration. The boundary's central claim holds.
+
+**Five of the twelve declared imports do not resolve by name.** The original
+review verified the manifest by file hash, and every hash matched; it never
+checked that the named concept exists in the named artifact. The enlarged index
+makes that checkable:
+
+| Import | Pinned to | Resolves to | Finding |
+| --- | --- | --- | --- |
+| `Artifact` | InfoTechCanonCore | `model/devsecops` | Core owns `CanonArtifact`, "any identifiable unit of canon content". There is no Core `Artifact`. The name now resolves to the DevSecOps build artifact, a different concept. |
+| `Ownership` | InfoTechCanonCore | `model/organization` | The kernel map assigns Ownership and Stewardship to Organization. The pin names the wrong artifact. |
+| `Relationship` | InfoTechCanonCore | `model/identity` | Core owns `RelationshipDefinition`; the identity model owns `Relationship` as its actor-linking taxonomy. The pin names the wrong artifact and arguably the wrong concept. |
+| `AccessOperations` | InfoTechCanonAccessControlModel | unowned | ITC-ACCESS defines `Operation`, "a system-specific or API-specific action". `AccessOperations` is SecurityCanon's own compaction of it. |
+| `PrincipalType` | InfoTechCanonIdentityModel | unowned | The name appears nowhere in the identity or access-control models. |
+
+These are SecurityCanon-side manifest corrections, not InfoTechCanon changes. No
+InfoTechCanon concept is renamed, moved or removed to accommodate them, and the
+semantic boundary recorded above is unaffected: each case is a citation naming
+the wrong artifact or a name InfoTechCanon never used, not a contested concept.
+
+**Method limit, now closed.** Hash verification proves the reviewed file is the
+file that was pinned. It says nothing about whether the concept named in the
+manifest exists in it. Both checks are needed, and only the first was run in the
+original acceptance.

infospace/models/landscape/InfoTechCanonLandscapeModel.md

@@ -1,5 +1,7 @@
 ---
 owned_concepts:
+  - SoftwareSystem
+  - SoftwareComponent
   - BusinessService
   - ApplicationService
   - TechnicalService

infospace/views/by-concept.md

@@ -2,7 +2,7 @@
 
 # By Concept
 
-Concept count: **750**
+Concept count: **752**
 
 | Concept | Owner | Source |
 | --- | --- | --- |
@@ -386,6 +386,8 @@ Concept count: **750**
 | UsePath | `model/information-space` | `frontmatter.owned_concepts` |
 | VectorIndex | `model/information-space` | `frontmatter.owned_concepts` |
 | InfoTechCanon Landscape Model | `model/landscape` | `artifact_title` |
+| SoftwareSystem | `model/landscape` | `frontmatter.owned_concepts` |
+| SoftwareComponent | `model/landscape` | `frontmatter.owned_concepts` |
 | BusinessService | `model/landscape` | `frontmatter.owned_concepts` |
 | ApplicationService | `model/landscape` | `frontmatter.owned_concepts` |
 | TechnicalService | `model/landscape` | `frontmatter.owned_concepts` |

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

@@ -262,7 +262,7 @@ benchmark, and they are undeclared.
 
 ```task
 id: INFO-WP-0027-T04
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "b9313ad5-7cb0-5be6-bc28-196f84640895"
 ```
@@ -308,3 +308,41 @@ twelve silent artifacts define; coverage is reported as a number that moves with
 the corpus; the enforcement level is recorded with its rationale; and both
 accepted extension boundaries carry a conflict result re-verified against the
 enlarged index.
+
+### Result — 2026-09-20 (T04)
+
+Both accepted extension boundaries were re-run against the enlarged index, and
+the re-verification is recorded in each boundary file.
+
+**Neither boundary has an ownership conflict.** None of SecurityCanon's nine
+owned concepts and none of InterfaceCanon's collides with an InfoTechCanon
+declaration now that declarations cover the corpus. The central claim of both
+acceptances holds.
+
+**But name resolution had never been checked, and it fails in nine places.**
+Both original reviews verified their import manifests by file hash; every hash
+matched, and that was recorded as evidence. A hash proves the reviewed file is
+the pinned file. It says nothing about whether the concept named in the manifest
+exists in it. The enlarged index makes that second check possible for the first
+time.
+
+SecurityCanon: five of twelve imports named concepts their pinned artifact does
+not define. `Artifact` resolves to the DevSecOps build artifact because Core
+defines `CanonArtifact`; `Relationship` belongs to the identity model, not Core,
+which defines `RelationshipDefinition`; `Ownership` belongs to Organization;
+`AccessOperations` is a compaction of ITC-ACCESS `Operation`; `PrincipalType`
+appears nowhere upstream. All five are corrected on the SecurityCanon side, which
+now declares eleven imports. No concept is contested and no disposition changes.
+
+InterfaceCanon: twenty-one of twenty-five resolve exactly. Two of the four
+failures were InfoTechCanon's own omission — `SoftwareSystem` and
+`SoftwareComponent` are Landscape seed concepts that extraction cannot read, and
+they are now declared here, making InterfaceCanon's pins correct. The other two,
+`Interface` and `Endpoint`, resolve to the Network Model rather than Landscape,
+which the accepted clarifications already treat as contextual rather than exact
+aliases; re-pointing or qualifying those pins is InterfaceCanon's change.
+
+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.