interface-canon/infospace/models/interface/InterfaceCanonInterfaceModel.md

id	title	namespace	type	status	version	imports	import_manifest	source_manifest
interface-model	InterfaceCanon Interface Model	interface-model	domain-model	draft	0.1.2	itc-land itc-ident itc-evid itc-gov itc-data itc-infospace itc-net	imports.json	../../assimilation/fiam/sources.json

InterfaceCanon Interface Model

Draft terminology derived from FIAM v0.2 Draft 6. These are domain definitions, not a new FIAM schema or a claim of transferred ownership. The exact FIAM spellings and source JSON pointers are recorded below. Upstream mappings explain shared concepts and collisions; imports.json pins InfoTechCanon.

Structural vocabulary

Each source locator below is relative to schemas/FIAM-Core-v0.2.schema.json in the pinned FIAM package.

1. Port

An owned architectural participation point through which a participant or system node offers or requires a particular interface contract.

An offer/require mode is contract participation, not message direction. This Port is distinct from ITC-NET Port. Network profiles distinguish physical/device ports from protocol-level transport ports; TCP port 8000 is one transport example.

Source: #/$defs/port. Local identifier: interface-model:port.

2. Contract Participation

The association of a Port with a specific InterfaceContract, an offers/requires mode, and contextual roles.

Roles belong to the participation; a port-global role cannot describe every contract context.

Source: #/$defs/contractParticipation. Local identifier: interface-model:contractParticipation.

3. Interface Contract

A semantic agreement organizing operations and their purposes independently of any particular transport realization.

One contract can have multiple bindings; a specification file describes the contract.

Source: #/$defs/interfaceContract. Local identifier: interface-model:interfaceContract.

4. Operation

A named unit of interface behavior within a contract, qualified by interaction style, temporal semantics, effects, and purpose.

A runtime exchange selects or realizes an operation; the operation is not a trace occurrence.

Source: #/$defs/operation. Local identifier: interface-model:operation.

5. Binding

A realization of a contract and selected operations through participating ports, communication stack, addressing, discovery, and optional channel or endpoints.

A second transport can realize the same contract without creating new semantic operations.

Source: #/$defs/binding. Local identifier: interface-model:binding.

6. Endpoint

A concrete locator or selector through which a Binding is reached.

An endpoint may be reused by multiple bindings; it is not the information resource selected through that binding.

Source: #/$defs/endpoint. Local identifier: interface-model:endpoint.

7. Channel

An exchange or mediation locus characterized by delivery, ordering, replay, or retention semantics where known.

A Kafka topic as exchange channel may be backed by a retained-log resource; those roles remain distinct.

Source: #/$defs/channel. Local identifier: interface-model:channel.

8. Interaction

An architectural participation in an exchange linking relevant operation, contract, binding, participants, and channel, with realization status where known.

An interaction can be proposed or rejected; do not equate every interaction with an executed span.

Source: #/$defs/interaction. Local identifier: interface-model:interaction.

9. Interaction Flow

An ordered composition of exchange steps referring to operations, interactions, bindings, and participants.

It expresses composition rather than inventing a new protocol or contract family.

Source: #/$defs/interactionFlow. Local identifier: interface-model:interactionFlow.

10. Information Resource

An identifiable information-bearing object, state, collection, or logical selection that can be addressed independently of a single interaction.

A collection is a resource; its admissible form is a shape, and its access location is not automatically a binding endpoint.

Source: #/$defs/informationResource. Local identifier: interface-model:informationResource.

11. Information Shape

An identifiable semantic or structural type or constraint set describing an admissible information form.

A shape is distinct from an instance, a schema artifact, and JSON or another concrete encoding. Detailed fields remain in describing artifacts. ITC-DATA DataType and Constraint supply related shared meanings; neither is an automatic shape alias.

Source: #/$defs/informationShape. Local identifier: interface-model:informationShape.

12. Resource Selector

A selector identifying an information resource within a provider, namespace, collection, or logical address space.

A database collection selector does not locate the network binding.

Source: #/$defs/resourceSelector. Local identifier: interface-model:resourceSelector.

Facets and interpretations

A Facet records an orthogonal characteristic of a structural entity or assertion. FIAM uses controlled terms for such dimensions as interaction style, temporal semantics, effect, purpose, communication stack, and security. A facet is not a new structural interface type. Source: Core #/$defs/facets and the FIAM Canon.

Representation is the concrete encoding or notation selected for information participation. It is authoritative on the most specific applicable shape-participation assertion. Operation-level and contract-level representation lists are deprecated. Source: Draft 1, “Representation stays relation-scoped”.

A Lens is a named interpretation over architectural facts and their evidence. Family labels are derived lens results, with inferred provenance if cached; HTTP, RPC, messaging, or a label such as REST must not become invented Core classes. Source: Draft 1, “Cached family labels require provenance”; Draft 6 §§1, 6–7.

Relationships and invariants

• A Port participates in a contract; a Binding realizes that contract and its operations.
• Shape participation refines Operation → Binding → Interaction. Refinement uses the same shape, identity-equivalent shape, or evidenced projection/version. Multi-operation binding refinements identify the operation with operation_ref.
• conforms-to-shape describes the whole addressed resource; element-shape describes collection members. A collection's shape and its element shape differ.
• Artifacts describe or implement architectural entities; representation encodes information.
• Missing facts remain unknown. Explicit absence, not-applicable, and unknown differ.
• Similarity supports correspondence, not automatic identity or destructive merging.
• Lens evidence scores and governance conclusions remain policy-dependent results.

Sources: Draft 1 “Stable structural spine” and hardening decisions 3–7; Core assertion; Draft 6 §§1, 6–7. These summaries preserve source semantics; FIAM remains authoritative for exact validation requirements.

Worked boundary cases

Case	Interpretation
Same MCP tools over stdio and HTTP	Shared contract/operations/shapes; distinct realization bindings.
Kafka topic with retained events	Channel for exchange, Information Resource for retained log, related by backed-by.
JSON document governed by a schema	Resource instance, Information Shape, describing Artifact, and Representation remain distinct.
Port offers a request-response contract	Offers is participation mode; requests and responses still travel in different directions.
A physical NIC port, TCP port 8000, and a service's offered Port	Device/transport network meanings and FIAM contract participation remain distinct; equal names do not identify one concept.
MCP stdio binding has no network address	A local realization need not have a Network Endpoint; FIAM does not require a network locator for every Binding.
JSON encodes a boolean field	JSON is FIAM participation Representation; the value's boolean form is a distinct Data Representation concern.
A schema document and a binary both implement or describe an interface	Reusable schema knowledge may qualify as KnowledgeArtifact; implementation alone does not establish that classification for the binary.
A mutable schema page supports a claim about an accepted field	Capture the page version and locator as Evidence Source; separately state the field assertion and the explicit interest it supports.
Two schemas have identical fields	Correspondence candidate; no automatic identity assertion.
Telemetry contains no authentication attributes	Unknown runtime authentication evidence; no inferred absence of protection.

These are explanatory cases derived from the pinned source, not executable FIAM fixtures or evidence of consumer adoption. The mapping review and Repo Manager case complete the initial review. Scoped external acceptance and adoption are recorded in completed INTERFACE-WP-0004; see the acceptance report.

These cross-canon cases apply the accepted mappings without equating distinct FIAM and InfoTechCanon concepts.