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

36
infospace/interfaces/security-canon-boundary.md
View file

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