Re-verify both extension boundaries against the enlarged index (T04)
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

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
This commit is contained in:
tegwick 2026-09-20 23:27:47 +02:00
parent a28526e540
commit 60b8e4d40f
10 changed files with 117 additions and 4 deletions

View file

@ -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.