import-review takes any partner manifest and returns, per concept, whether the name resolves in the ownership index and to which artifact, and per entry whether the pinned SHA-256 matches the blob at the declared source commit. Both run in one pass so neither can be recorded without the other, which is the failure this workplan exists to prevent. It exits non-zero on a finding, reads JSON or YAML, needs no partner checkout, and carries its own limit: resolution proves a name exists and names one owner, nothing more. Accepted manifests are registered under infospace/interfaces/manifests/ as provenance-preserving copies owned by the partner, with the partner revision and retrieval date recorded. Editing a copy to make a check pass is forbidden in the file itself. Validation re-resolves them and reports drift as federation_import_drift, a warning naming the partner rather than an error, because a stale partner pin is not this repository's file to fix. The review kit gains an extension-boundary-review template requiring hash count, resolution count and conflict count as three separate lines, and an operating rule saying one is never evidence of another. Both boundary files carry the standing-check result. Verified live: security-canon resolves 11 of 11, interface-canon 23 of 25 with the two known Interface and Endpoint pins. make check passes with 58 tests, clean validation and those two warnings. 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
5.4 KiB
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.
Standing check — 2026-09-20 (INFO-WP-0028)
This partner's import manifest is registered at
infospace/interfaces/manifests/interface-canon.json as a provenance-preserving copy and is
re-resolved on every make check. Hash and name are checked together by
info_tech_canon import-review; a name that stops resolving, or resolves to a
different owner than the manifest pins, is reported as a
federation_import_drift warning naming this partner. It is a warning and not an
error because a stale partner pin is not this repository's file to fix.
Current result: 23 of 25 declared imports resolve and all seven pinned hashes match. Interface and Endpoint remain pinned to ITC-LAND while the Network Model declares them; raised with interface-canon by State Hub message 13d355f2-554b-4a3a-a0ef-3f69eeafeae9 on 2026-09-20 and unanswered as of that date. The two warnings stand until that pin is corrected or qualified in place.