tegwick
60b8e4d40f
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 |
||
|---|---|---|
| .. | ||
| agent | ||
| artifacts | ||
| assimilation | ||
| concepts | ||
| evaluations | ||
| examples | ||
| indexes | ||
| interfaces | ||
| kernel | ||
| mappings | ||
| models | ||
| patterns | ||
| profiles | ||
| reports | ||
| schemas | ||
| standards | ||
| validation | ||
| views | ||
| infospace.yaml | ||
| README.md | ||
InfoTechCanon Infospace
This directory is the single concrete infospace implemented by this repository. The repository root remains the service, governance, and workplan shell.
The current placement pass copies the seed documents into canonical
kernel/, models/, and standards/ paths while keeping seeds/ as
provenance until the scaffold migration is reviewed.