coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

21
infospace/interfaces/interface-canon-boundary.md
View file

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