info-tech-canon/infospace/interfaces/interface-canon-boundary.md
tegwick 1527b33999
All checks were successful
CI Smoke / host-smoke (push) Successful in 1s
CI Smoke / container-smoke (push) Successful in 5s
Close the last open import pins and the workplan (T04)
interface-canon corrected its Interface and Endpoint pins at 20d7bfc2. Both were
pinned twice, to ITC-LAND and ITC-NET, because ITC-LAND section 13.2 lists them
in a seed-concept block while the Network Model defines them. Landscape section
13.2 now says in this repository that Interface, Endpoint and API are pointers
there and that the Network Model owns the first two, so the next reader does not
repeat it.

That is the fourth time in one day a list of concept names was read as a
definition, after CARING's Scope ladder, CARING's Environment values, and the
Landscape seeds that hid SoftwareSystem and SoftwareComponent. The closure
section names the pattern.

Both boundaries now resolve completely, security-canon 11 of 11 and
interface-canon 23 of 23, the registered copy is refreshed to the corrected
revision, and validation carries no drift warnings. The CLI test is rebuilt from
a deliberately broken copy so that a partner fixing its own pins can no longer
break this repository's suite.

make check passes with 59 tests, clean validation and no 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
2026-09-20 23:50:52 +02:00

99 lines
5.6 KiB
Markdown

# 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](../../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.
## 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 23 declared imports resolve**, all seven pinned hashes
match, no drift.
The `Interface` and `Endpoint` pins were corrected in interface-canon at
`20d7bfc2` on 2026-09-20. Both names had been pinned twice, to ITC-LAND and to
ITC-NET; the ITC-LAND pins are dropped, since section 13.2 lists them as pointers
while the Network Model defines and owns them. Landscape section 13.2 now says so
in InfoTechCanon, so the next reader does not repeat it. The accepted
dispositions are unchanged: this was a citation fix, and the mapping tables that
cite ITC-LAND section 13.2 as a related seed stand as they are.