A.6.M:4.2 - Interface specification is not a label

A.6.M calls the independently identified specification episteme an InterfaceSpecification. It is one U.Episteme under C.2.1 whose EntityOfConcern is the exact boundary named by the module claim. Its identity is <exact ClaimGraph, that one EntityOfConcern, effective U.ReferenceScheme>. Its claim content may include:

InterfaceSpecification claim content:
  signatureRefs?: FinSet(SignatureRef)
  slotSpecSetRefs?: FinSet(SlotSpecSetRef)
  portEndpointSpecRefs?: FinSet(PortEndpointSpecRef)
  protocolRefs?: FinSet(EpistemeRef)
  schemaRefs?: FinSet(EpistemeRef)
  admissibilityConditions
  semanticConditions
  versionPolicyRef?
  changePolicyRef?
  conformanceExpectationRefs?
  evidenceOrSourceRelianceRefs?
  nonAdmissibleUse

interfaceSpecificationRef is one U.EpistemeRef constrained to that specification form. Under the effective reference scheme it resolves one already identified InterfaceSpecification; it carries none of the specification content itself. Two spellings or serialized references may resolve the same unchanged specification. Retargeting the reference selects another already identified specification without changing the previous one. Changing identity-bearing specification content, its EntityOfConcern, or its effective reference scheme yields another episteme. When no complete specification is established, keep an explicit interfaceSpecificationGap rather than a partly filled reference.

A signature declares vocabulary, laws, and applicability. A slot or endpoint record names positions and field structure. A protocol or schema constrains interaction. A mechanism reference can substantiate a realization relation. Evidence relations, source relations, reliance relations, and conformance expectations substantiate reliance only when the corresponding evidence, source-use, assurance, or conformance claim is being made. None of these, alone, is the module interface.