#Module Relation Repair

A.6.M · Stable · Architectural pattern · Normative unless explicitly marked informative · Part A - Kernel Architecture Cluster

#About this pattern

This is a generated FPF pattern page projected from the published FPF source. It is canonical FPF content for this ID; it is not a FPF Reference product feature page.

#How to use this pattern

Read the ID, status, type, and normativity first. Use the content for exact wording, the relations for adjacent concepts, and citations to keep active work grounded without pasting the whole specification.

Type: Architectural pattern Status: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when an architecture or engineering text says "module", "component", "interface", "port", "platform", or "open architecture", and the phrase is doing more than ordinary orientation. If a stratification or architecture-operation source label covered by C.30.STRAT is doing the work, apply C.30.STRAT first; use A.6.M only when that repair recovers module-interface claim content. Use A.6.M when the question under repair is whether one holon is being claimed as a replaceable, reusable, or separately changed structural unit of a larger holon under the exact VP.ModuleInterface viewpoint episteme. The note or claim does not make a direct module relation obtain.

#Keywords

• module relation
• component
• interface
• port
• platform
• layer
• stack
• open architecture
• substitutability
• interface specification.

#Relations

#Content

#Problem frame

Use this pattern when an architecture or engineering text says "module", "component", "interface", "port", "platform", or "open architecture", and the phrase is doing more than ordinary orientation. If a stratification or architecture-operation source label covered by C.30.STRAT is doing the work, apply C.30.STRAT first; use A.6.M only when that repair recovers module-interface claim content. Use A.6.M when the question under repair is whether one holon is being claimed as a replaceable, reusable, or separately changed structural unit of a larger holon under the exact VP.ModuleInterface viewpoint episteme. The note or claim does not make a direct module relation obtain.

The first useful output is ModuleRelationRepairNote, a claim-repair note rather than a relation occurrence:

ModuleRelationRepairNote:
  wholeHolonRef:
  candidateModuleHolonRef:
  effectiveReferenceScheme: U.ReferenceScheme, byValue
  claimScope?: U.ClaimScope, byValue
  modelUseStructureRef?: only when one selected model-use structure changes module meaning
  moduleInterfaceViewpointRef?: VP.ModuleInterface
  selectedDependencyStructureRef?: U.StructureRef
  boundaryRef:
  interfaceSpecificationRef or interfaceSpecificationGap:
  admissibilityConditions:
  substitutabilityPolicyRef?:
  changePolicyRef?:
  directModuleRelationDisposition:
    claimOnly | admittedDirectOwnerAndOccurrenceRef | directOwnerStillNeeded
  claimBoundary:
  notAModuleBecause:
  governedNonModuleClaimPatternRefs:
  stopCondition:

Ordinary use stops when the whole, candidate module, boundary, interface specification, admissibility conditions, substitutability policy, change policy, blocked false interpretation, relation disposition, and neighboring work, procedural, role, or enactor governing-pattern choice are clear enough to choose the next architecture move. Use the fuller moduleIn(...) claim record only when substitutability, conformance, publication, evidence, assurance, change policy, repeated reuse, or cross-team coordination requires durable claim content.

What goes wrong if A.6.M is missed: a functional link becomes a module interface; a signature becomes an implemented interface; a port label becomes proof of integration; "open" becomes a decoration; a platform label hides the actual extension rules; a stratification or architecture-operation source label bypasses [C.30.STRAT](/generated/patterns/C.30.STRAT) and mints a false local kind; autonomy-like wording is confused with separate module change policy; and a module diagram starts being used for claims governed elsewhere.

What A.6.M buys in practice: the practitioner can repair one module or interface phrase into usable claim content, distinguish it from an independently admitted direct relation occurrence, see which FPF pattern governs any remaining non-module claim, and stop before full measurement, evidence, or mechanism-suite records are needed.

Not this pattern when the question under repair is the general architecture claim, selected architecture structure kind, structural view, stratification wording or source-label recovery, function wording, procedural or work-package wording, role or enactor wording, autonomous operation, independent acting, unsupervised decision or action, measurement, modularity characterization, or reusable-structure residue. Use [C.30](/generated/patterns/C.30), [C.30.ASV](/generated/patterns/C.30.ASV), [C.30.STRAT](/generated/patterns/C.30.STRAT), [A.6.F](/generated/patterns/A.6.F), [A.15](/generated/patterns/A.15), [A.2](/generated/patterns/A.2), [E.16](/generated/patterns/E.16), [C.31](/generated/patterns/C.31), [C.16](/generated/patterns/C.16), or [C.31.RSA](/generated/patterns/C.31.RSA) as appropriate. For any other claim being made, apply the governing FPF pattern and keep A.6.M only for the module-relation and interface-specification portion.

E.10.ARCH relation. A.6.M is the precision-restoration pattern for module-interface relation wording, interface-specification wording, platform-grammar wording, substitutability wording, change-policy wording, and open-architecture module-interface claims. [E.10](/generated/patterns/E.10), [E.10.ARCH](/generated/patterns/E.10.ARCH), or [C.30.STRAT](/generated/patterns/C.30.STRAT) applies A.6.M only after the recovered result is a module-interface relation, interface specification, platform grammar, substitutability policy, change policy, or open-architecture module-interface claim. If the source wording is still a stratification or architecture-operation source label covered by [C.30.STRAT](/generated/patterns/C.30.STRAT), apply [C.30.STRAT](/generated/patterns/C.30.STRAT) first. If the claim being made is non-module work, role, evidence, assurance, gate, decision, characteristic, flow, autonomy, component, mechanism, or mathematical-lens use, apply the governing pattern named in [A.6.M:12](/generated/patterns/A.6.M#relations) and keep A.6.M only for the module-interface slice when that module-interface relation remains the claim being made.

#Problem

Engineering teams use module language for several different things:

• a component in a part-whole decomposition;
• a replaceable unit under a declared interface;
• a functional element;
• a software package, neural-network block, hardware board, chiplet, subsystem, service, team boundary, or delivery unit;
• a published API, protocol, signature, port, connector, or endpoint;
• a platform extension point;
• a control relation, deployment scope, or stratification or architecture-operation source label that still needs C.30.STRAT recovery;
• an open-architecture claim.

These are useful ordinary words, but they do not establish the same FPF claim. A module claim is not created by a label. A conforming module-interface claim names the candidate U.Holon, larger U.Holon, exact VP.ModuleInterface viewpoint episteme when needed, boundary, interface specification, admissibility conditions, substitutability policy when replacement is claimed, change policy when separate change is claimed, and any exact evidence, conformance, or admissible-use claim being made. It remains claim content unless a separate direct relation owner has admitted a module relation and its obtaining predicate is satisfied.

The practical question is: does this phrase name a module relation, a component relation, a functional allocation, a procedural or work-package relation, a role-assignment or responsibility relation, a deployment or placement structure, an interface specification, a signature declaration, a port or endpoint slot, a transformation-flow crossing, a mechanism realization, a platform grammar, a control relation, an autonomy-like operation claim, a source label governed first by C.30.STRAT, or only plain source wording?

#Forces

#Solution

A.6.M specializes A.6.P for module, component, interface, platform, and open-architecture wording when the recovered result is module-interface claim content, an interface specification, platform grammar, substitutability claim, or open-architecture module-interface claim. Stratification or architecture-operation source labels covered by C.30.STRAT are governed by C.30.STRAT until that repair recovers this module-interface content. A.6.M neither mints root kinds from those labels nor admits a direct module relation from record syntax.

A candidate module is an exact U.Holon used in a claim that treats it as a replaceable, reusable, or separately changed structural unit of a larger U.Holon, ordinarily under the exact VP.ModuleInterface viewpoint episteme. The claim names its boundary, interface specification, admissibility conditions, substitutability policy when replaceability is claimed, and change policy when separate change is claimed. Effective U.ReferenceScheme and U.ClaimScope qualify the claim; an optional selected model-use structure appears only when its organization changes module meaning. None replaces the two holons or makes a module relation obtain. A FunctionalElementClaim is different: it is view-local claim content inside a functional structural-view episteme, not a root kind and not a module relation. It binds required behaviour or effect to bearer or candidate bearer, capability, functional ports, and allocation claims when those claims are current; required or desired content is not an actual U.Transformation. The relation between functional and module claims is separately governed allocation or correspondence, not identity. One module candidate can correspond to many functional elements; many module candidates can correspond to one functional element; a functional element can remain unallocated; and a module candidate can be present in a module-interface view with no current functional behaviour in the functional view.

Functional ports and module interfaces may both use U.Signature discipline, but they govern different claims. A functional port constrains input condition, output condition, accepted-state, and produced-state slots for a functional behavior or transformation. A module interface constrains boundary, substitutability, compatibility, protocol references, schema references, version policy, change policy, and conformance expectations for a module relation. Do not move a functional-port claim into module-interface structure unless a module-interface or substitution claim is actually being made.

For modular synthesis, A.6.M supplies only the module-interface claim slice. A synthesis action may align required functional claims under VP.Functional, transformation-flow topology under E.18 and C.30.TFS-REL, control structure under C.30.LCA, procedures and work packages under VP.Procedural, allocation and responsibility claims under VP.AllocationResponsibility, and module/interface claims under VP.ModuleInterface; A.6.M repairs the latter claim content, while non-module candidate generation, evidence, assurance, decision, work, and characteristic claims remain with their direct patterns.

#moduleIn(...) claim record

Use moduleIn(...) only when the light repair note is not enough and a durable claim about module use is needed:

moduleIn(
  claimEpistemeRef: U.EpistemeRef,
  entityOfConcernRef:
    moduleHolonRef | selectedDependencyStructureRef |
    admittedDirectModuleRelationOccurrenceRef,
  effectiveReferenceScheme: U.ReferenceScheme, byValue,
  claimScope?: U.ClaimScope, byValue,
  modelUseStructureRef?: U.StructureRef,
  moduleHolonRef: U.HolonRef,
  wholeHolonRef: U.HolonRef,
  viewpointRef?: U.ViewpointRef = VP.ModuleInterface,
  selectedDependencyStructureRef?: U.StructureRef,
  boundaryRef: BoundaryRef,
  interfaceSpecRef: InterfaceSpecificationRef,
  functionalCorrespondenceRelationRefs?: FinSet(U.RelationRef),
  transformationFlowStructureRefs?: FinSet(U.StructureRef),
  transformationFlowRelationOccurrenceRefs?: FinSet(U.RelationRef),
  mechanismRefs?: FinSet(U.EntityRef constrained by the selected mechanism pattern),
  dependencyRelationOccurrenceRefs?: FinSet(U.RelationRef),
  substitutabilityPolicyRef?: U.EpistemeRef,
  changePolicyRef?: U.EpistemeRef,
  variabilitySlotRefs?: FinSet(SlotSpecRef),
  evidenceOrSourceRelianceRelationRefs?: FinSet(U.RelationRef),
  admissibleUse,
  nonAdmissibleUse
)

This form is claim content in one C.2.1 episteme. Its identity uses that content, the one exact entityOfConcernRef, and the effective U.ReferenceScheme. claimScope qualifies the claim when its coverage matters. modelUseStructureRef is present only when one independently selected model-use structure changes the meaning of module for this claim; it is not a module participant, whole, boundary, or source of relation obtaining. VP.ModuleInterface is a reference to the exact viewpoint episteme when viewpoint use matters; citing it does not make this claim a U.View.

moduleIn(...) syntax, a package path, file boundary, graph edge, list position, common name, or publication does not make a world-side module relation obtain. Current A.6.M admits no general direct moduleIn relation kind. If repeated engineering use genuinely needs one direct module relation occurrence, first use the subject pattern and [A.6.RCD](/generated/patterns/A.6.RCD) to recover the exact module and whole participant meanings, obtaining predicate, applicability, recurrence rule, and occurrence-identity rule. Use [A.6.REL](/generated/patterns/A.6.REL) only after the resulting direct owner has admitted that relation and a later use must distinguish one obtaining occurrence from another. A separately constituted RelationSignature may then declare reusable SlotSpecs; neither the signature nor this claim creates the occurrence.

Well-formedness: the claim names both holons, one exact EntityOfConcern, an effective reference scheme, one boundary, and an interface specification or explicit interface-specification gap. Optional structure, relation, evidence, mechanism, policy, conformance, source, and reliance references are used only when those exact objects and claims are current under their direct governors.

#Interface specification is not a label

InterfaceSpecificationRef is the local specification reference for an interface specification. It may include:

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

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.

#Repair applications for overloaded words

#First repair sequence

1. Name the phrase and the practical situation.
2. Select the whole holon and candidate module holon.
3. State whether the source phrase is module relation, component relation, function allocation, procedural or work-package relation, role-assignment or responsibility relation, deployment or placement structure, interface specification, signature, port or endpoint, transformation-flow crossing, mechanism realization, platform grammar, control relation, autonomy-like operation claim, C.30.STRAT source-label case, or open-architecture claim.
4. State the boundary and the declared interface specification or explicit interface-specification gap.
5. State the admissibility conditions, substitutability policy, and change policy, or mark any of those fields not established by the repair.
6. State the governing pattern for any non-module claim being made: C.30, C.30.ASV, A.6.F, A.15, A.2, E.18, C.30.TFS-REL, C.31, C.31.RSA, C.16, A.10, B.3, A.20, A.21, C.28, E.20, G.5, or C.11.
7. Stop when the claim, direct-relation disposition, and next use are explicit. Do not open A.6.RCD or A.6.REL unless a named receiving use genuinely needs a reusable direct relation or distinguishable obtaining occurrence.

#Worked slices

Ports line up.

Phrase:
  "The ports line up, so the modules are compatible."

ModuleRelationRepairNote:
  wholeHolonRef: VehicleControlSystem
  candidateModuleHolonRef: BrakeControllerPackage
  effectiveReferenceScheme: VehicleControlInterfaceScheme-2026Q2
  claimScope: BrakeControllerReleaseUse-2026Q2
  directModuleRelationDisposition: claimOnly; no admitted direct owner or obtaining occurrence asserted
  boundaryRef: BrakeControlBoundary
  interfaceSpecificationRef or gap: endpoint names present; protocol and semantic conditions missing
  admissibilityConditions: not yet declared
  substitutabilityPolicyRef: missing
  changePolicyRef: missing
  claimBoundary: interface-spec repair; no evidence or gate claim yet
  notAModuleBecause: port labels alone do not establish implemented interface compatibility
  governedNonModuleClaimPatternRefs: A.6.5 for endpoint slots; A.6.B only if L, A, D, or E boundary-package statement classification is current; A.6.M only if a module-interface or substitution claim remains
  stopCondition: endpoint slots and missing interface-spec fields are visible

Open platform claim.

Phrase:
  "This is an open platform."

OpenArchitectureClaim:
  architectureClaimRef:
  platformGrammarRef:
  interfaceSpecificationRefs:
  variabilitySlotRefs:
  substitutabilityPolicyRef:
  changePolicyRef:
  conformanceExpectationRefs:
  evidenceOrSourceRelianceRefs?:
  nonAdmissibleUse:
    "open" does not by itself prove substitutability, interoperability,
    assurance, procurement suitability, or architecture quality

The first slice repairs the claim without requiring measurement. The second slice applies MOSA-like conformance expectations and substitution policy only for the conformance or substitution claim being made.

Supplier-diversity, procurement suitability, use-context compatibility, business constraint, policy authorization, and provider-selection claims are not module-interface fields. If those claims are being made, A.6.M names only the module-interface slice; non-module selection, procurement, work, role, evidence, assurance, gate, release, and mechanism claims are governed by the patterns named in [A.6.M:12](/generated/patterns/A.6.M#relations).

Team boundary claim.

Phrase:
  "The team communication boundary matches the module boundary."

ModuleRelationRepairNote:
  wholeHolonRef: PaymentsPlatform
  candidateModuleHolonRef: SettlementService
  effectiveReferenceScheme: PaymentsPlatformInterfaceScheme-2026Q2
  claimScope: SettlementServiceProductLineUse-2026Q2
  directModuleRelationDisposition: claimOnly; team/module correspondence remains diagnostic
  boundaryRef: SettlementServiceBoundary
  interfaceSpecificationRef or gap: service API exists; semantic versioning, data schema, and semantic-constraint conditions incomplete
  admissibilityConditions: team delivery responsibility and on-call responsibility declared; substitutability not established
  substitutabilityPolicyRef: missing
  changePolicyRef: missing
  claimBoundary: role-assignment, responsibility, work, and procedural correspondence first; module-interface relation only after boundary and interface specification are declared
  notAModuleBecause: team communication boundary and delivery responsibility do not by themselves establish module interface, substitutability, or compatibility
  governedNonModuleClaimPatternRefs: A.15 and A.2 for team and work claims; C.29 if the team-to-module correspondence is claimed as homomorphism-like or almost-same structure; A.6.M only for the declared module-interface relation
  stopCondition: the correspondence is usable as an architecture diagnostic, not as proof

The third slice uses Conway-like mirroring as a diagnostic prompt. It does not make organization structure, communication relations, or delivery responsibility into module-interface structure by identity.

Proxy-cost replay: if a repair proposes more modules, more open interfaces, or more parallel transformation-flow paths, name what may get worse before claiming improvement. Synchronization work, communication overhead, conformance work, shared-resource pressure, hidden exception cost, or cross-boundary change cost can become the claim being made. A.6.M repairs only the module-interface relation; speedup, bottleneck, modularity, measurement, work, and quality tradeoffs are governed by [C.29](/generated/patterns/C.29), [E.18](/generated/patterns/E.18), [C.31](/generated/patterns/C.31), [C.16](/generated/patterns/C.16), [A.15](/generated/patterns/A.15), or the related governing pattern named by value when that related claim is being made.

#Lowering and Reopen Conditions

Lower an A.6.M repair to reduced-use cue, quote-only wording, blocked use, or incomplete rewrite when the module-interface relation, interface specification, admissibility conditions, substitutability policy, or change policy cannot be stated by value.

Reopen the repair when any of these change: the whole holon, candidate module holon, boundary, interface specification, explicit interface gap, substitutability policy, change policy, platform grammar, conformance expectation, relied-on evidence relation, relied-on source relation, source-label recovery from C.30.STRAT, team-boundary correspondence, work correspondence, or the governing pattern for a related claim being made.

If the reopened material is no longer a module-interface relation, A.6.M keeps only the previous repair as source context and the claim being made is governed by the pattern named in A.6.M:12.

#Archetypal Grounding

Tell. A module is not a little box. It is a holon related to a larger holon under a declared boundary, interface specification, admissibility conditions, substitutability policy, and change policy.

Show. A software package, neural-network block, chiplet, power converter, document template, or organizational unit can be treated as module-like only when the claim says what whole is at issue, what boundary it offers, what interface specification governs use, what substitutability policy makes replacement admissible, and what change policy governs separate change. That claim still does not make a direct module relation obtain.

Show. A port label, API endpoint label, source-local route label, flow edge, or function name may be a useful clue. It can substantiate a module-interface claim only after the relevant signature, slot, protocol, semantic condition, correspondence, mechanism, evidence relation, conformance expectation, source relation, or reliance relation named by value is declared.

Holon, relation, and episteme: the candidate module and whole retain their admitted holon kinds. A moduleIn(...) record is a C.2.1 claim episteme whose content may concern the module holon, one selected dependency structure, or an independently admitted direct module relation occurrence; it is not that relation. Framework and module-description epistemes, authoring Work, publication occurrence, publication form, carrier, effective reference scheme, ClaimScope, and optional model-use structure retain separate identities and direct relations. Method descriptions enter as epistemes; method values enter through their method owner. Stratification and architecture-operation labels named by C.30.STRAT remain source labels unless C.30.STRAT recovers module-interface claim content that A.6.M can repair.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits:

• Module and interface talk becomes usable without minting false root kinds.
• Practitioners get a cheap relation repair before measurement or evidence work.
• MOSA and open-system claims become precise enough to make real substitution and change reasoning admissible.
• Functional, flow, control, mechanism, work, evidence, assurance, gate, decision, and causal claims stay with their governing patterns.

Costs:

• Ordinary architecture prose loses the convenience of treating boxes, ports, interfaces, and modules as one kind.
• Interface claims sometimes require additional records before substitutability can be relied on.
• "Open architecture" becomes harder to claim because interface publication alone is not enough.

#Rationale

The central decision is to treat module as relation-sensitive claim language over exact admitted holons, not as a root kind and not as a relation admitted by notation. The same system, organization-as-system, episteme, Work occurrence, discipline, or other admitted holon may be claimed as a component under one direct relation, as a module candidate under one interface-and-change claim, or as a bearer/candidate bearer in functional claim content. effectiveReferenceScheme and ClaimScope make the claim interpretable and bounded. An independently selected model-use structure may qualify model-local meaning, but it neither becomes a holon nor supplies module membership. Method descriptions and publication-family material enter through their episteme and publication owners; authoring, description edition, publication occurrence, form, and carrier remain distinct.

A.6.M follows A.6.P: overloaded relation language is repaired by recovering the actual subjects, claim content, direct-relation disposition, qualifiers, admissible use, and sources. A.6.M owns the module/interface claim repair. A direct module relation, if later needed, is admitted only by its subject pattern with A.6.RCD's participant, obtaining, applicability, and identity discipline; A.6.REL then handles distinguishable obtaining occurrences.

The pattern deliberately keeps measurement out of the first move. A module relation can be repaired before anyone knows whether external coupling density, interface standardization share, evidence reuse, or reusable-structure accounting will be needed. When those claims are being made, A.6.M applies C.31, C.31.RSA, and C.16.

#SoTA-Echoing

Older or local sources may serve as lineage or worked examples only when the row says so. They do not stand in for current competitive source, and they do not make a module, interface, platform, or open-architecture claim admissible for comparison, assurance, gate, selection, or decision use without the governing pattern for that use.

#Relations

#A.6.M:End

Last Updated: 2026-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)