coulomb/info-tech-canon
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
info-tech-canon/infospace/interfaces/interface-canon-boundary.md
tegwick 60b8e4d40f
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
Details
CI Smoke / container-smoke (push) Successful in 1s
Details
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
2026-09-20 23:27:47 +02:00

4.5 KiB
Raw Blame History

InterfaceCanon extension boundary

Status: accepted for the semantic boundary documented below, reviewed by Codex in the InfoTechCanon repository on 2026-09-09. This is an agent review, not a claim of separate human sign-off or a published peer merge.

Review target: interface-canon draft 0.1.1 at 1fc82ec6655ed286cea3be284e33d08e7b27edc3. Proposed patch: interface-canon reviews/INTERFACE-WP-0004/info-tech-canon.patch in review package 6b33ac2388190207c4373e6f288922ce5c0b0413. InfoTechCanon review base and import source: 8eb1c83f2e119de57e7ad448b901381f8e92fb57.

InterfaceCanon derives interface-domain terminology from FIAM in facetted-interfaces and references shared InfoTechCanon concepts. It supplies a focused interface model while InfoTechCanon retains the shared roots.

Accepted dispositions

  • FIAM Port is contract participation, distinct from ITC-NET network Port. Network profiles also distinguish physical/device ports from transport ports; the distinction is broader than the TCP example alone.
  • InterfaceContract describes semantic interface behavior. Landscape's Interface seed and Network's attachment-point Interface are contextual mappings, not universal exact aliases.
  • FIAM Endpoint locates or selects a Binding. Network Endpoint is related where realization is network-based; local bindings need not have a network endpoint.
  • InformationResource/InformationShape map contextually to Data concepts. Dataset, DataObject, Record, DataType, and Constraint retain their shared owners; these mappings establish neither universal subtyping nor exact equivalence.
  • FIAM Representation concerns participation encoding; Data Representation also describes value-level forms. Consumers must qualify these scopes.
  • Describing artifacts may be KnowledgeArtifact and Evidence Source. An Evidence Source is an addressable container with a relevant version or capture where mutable; Evidence is a separate assertion drawn for an explicit interest. An artifact implementing a contract is not automatically a KnowledgeArtifact.

Evidence and limits

Reviewed infospace/models/interface/InterfaceCanonInterfaceModel.md, infospace/mappings/review-2026-09-09.md, and infospace/models/interface/imports.json at the InterfaceCanon revision above. All seven manifest SHA-256 values match Git blobs at the declared InfoTechCanon source revision, and those files are unchanged in the review checkout: ITC-LAND, ITC-IDENT, ITC-EVID, ITC-GOV, ITC-DATA, ITC-INFOSPACE, and ITC-NET.

The proposed boundary is accepted with the clarifications above. This reciprocal reference does not extend the completed identity/commerce ownership ledger, transfer shared ownership, or establish a reverse semantic dependency. InterfaceCanon remains draft; this review supplies no consumer implementation or deployment evidence and does not satisfy INFO-WP-0019-T06's emission-cadence gate.

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.

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.