#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 a module-interface relation. Use A.6.M when the question under repair is whether one holon is being treated as a replaceable, reusable, or separately changed structural unit of a larger holon under a declared module-interface viewpoint.

#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 a module-interface relation. Use A.6.M when the question under repair is whether one holon is being treated as a replaceable, reusable, or separately changed structural unit of a larger holon under a declared module-interface viewpoint.

The first useful move is ModuleRelationRepairNote:

ModuleRelationRepairNote:
  wholeHolonRef:
  candidateModuleHolonRef:
  boundedContextRef:
  moduleInterfaceViewpointRef: VP.ModuleInterface
  boundaryRef:
  interfaceSpecificationRef or interfaceSpecificationGap:
  admissibilityConditions:
  substitutionOrChangePolicyRef:
  claimBoundary:
  notAModuleBecause:
  governedNonModuleClaimPatternRefs:
  stopCondition:

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

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 a module-relation record, 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, 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, substitution or 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 states how a candidate U.Holon relates to a larger U.Holon under VP.ModuleInterface: boundary, interface specification, admissibility conditions, substitution or change policy, and any evidence, conformance, or admissible-use expectation being claimed.

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 or enactor relation, a deployment or placement structure, an interface specification, a signature declaration, a port or endpoint slot, a TGA 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 a module-interface relation, interface specification, platform grammar, substitutability relation, 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 a module-interface relation; A.6.M applies only to that recovered module-interface result. A.6.M does not mint root kinds from those source labels.

A module is a U.Holon viewed in a declared bounded context as a replaceable, reusable, or separately changed structural unit of a larger U.Holon under VP.ModuleInterface, with explicit boundary, interface specification, admissibility conditions, and admissible substitution or change policy.

For modular synthesis, A.6.M supplies only the module-interface slice. A synthesis move may align required functions or functional-service claims under VP.Functional, flow or transduction topology under E.TGA, control structure under C.30.LCA, procedures and work packages under VP.Procedural, role enactors under VP.RoleEnactor, and modules or interfaces under VP.ModuleInterface; A.6.M repairs the module-interface relation, while non-module candidate generation, evidence, assurance, decision, work, and characteristic claims are governed by the patterns named in A.6.M:12 when those claims are being made.

#moduleIn(...) relation record

Use moduleIn(...) only when the light repair note is not enough:

moduleIn(
  moduleHolonRef: U.HolonRef,
  wholeHolonRef: U.HolonRef,
  boundedContextRef: U.BoundedContextRef,
  viewpointRef: U.ViewpointRef = VP.ModuleInterface,
  boundaryRef: BoundaryRef,
  interfaceSpecRef: InterfaceSpecificationRef,
  functionalCorrespondenceRefs?: FinSet(CorrespondenceRef | KindBridgeRef),
  tgaFlowRefs?: FinSet(PathSliceId | TransferRef | CrossingRef),
  mechanismRefs?: FinSet(MechanismRef),
  dependencyRefs?: FinSet(QualifiedRelationRecordRef),
  substitutabilityPolicyRef?: EpistemeRef,
  variabilitySlotRefs?: FinSet(SlotRef),
  evidencePathRefs?: FinSet(EvidencePathRef),
  admissibleUse,
  nonAdmissibleUse
)

Well-formedness: the relation names both holons, one bounded context, one module-interface viewpoint, one boundary, and an interface specification or explicit interface-specification gap. Optional evidence, mechanism, and policy fields are used only when the corresponding evidence, mechanism, policy, conformance, or reliance claim is being made.

#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)
  protocolOrSchemaRefs?: FinSet(EpistemeRef)
  admissibilityConditions:
  semanticConditions:
  versionOrChangePolicyRef?:
  conformanceExpectationRefs?:
  evidencePathRefs?:
  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 paths and conformance expectations can substantiate reliance only when an evidence path named by value or an assurance 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 or enactor relation, deployment or placement structure, interface specification, signature, port or endpoint, TGA 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 and substitution or change policy, or mark them 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.TGA-FLOW-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 relation and next move are explicit.

#Worked slices

Ports line up.

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

ModuleRelationRepairNote:
  wholeHolonRef: VehicleControlSystem
  candidateModuleHolonRef: BrakeControllerPackage
  boundedContextRef: Release-2026Q2
  boundaryRef: BrakeControlBoundary
  interfaceSpecificationRef or gap: endpoint names present; protocol and semantic conditions missing
  admissibilityConditions: not yet declared
  substitutionOrChangePolicyRef: 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, A.6.B, then A.6.M only if a substitution claim remains
  stopCondition: endpoint slots and missing interface-spec fields are visible

Open platform claim.

Phrase:
  "This is an open platform."

OpenArchitectureClaim@Context:
  architectureClaimRef:
  platformGrammarRef:
  interfaceSpecificationRefs:
  variabilitySlotRefs:
  substitutionOrChangePolicyRef:
  conformanceExpectationRefs:
  evidencePathRefs?:
  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
  boundedContextRef: ProductLine-2026Q2
  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
  substitutionOrChangePolicyRef: missing
  claimBoundary: role, enactor, 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/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 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, or substitution or change policy cannot be stated by value.

Reopen the repair when any of these change: the whole holon or candidate module holon, the boundary, the interface specification or explicit gap, the substitution or change policy, the platform grammar, the conformance expectation, the evidence path relied on, the source-label recovery from C.30.STRAT, the team-boundary or 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, and substitution or change policy.

Show. A software package, neural-network block, chiplet, power converter, document template, or organizational unit can become module-like in a project only when the relation record says what whole it belongs to, what boundary it offers, what interface specification governs use, and what substitution or change policy makes replacement admissible.

Show. A port label, API endpoint or 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, and evidence, conformance, source relation, or reliance relation named by value are declared.

Holon and episteme: the candidate module and whole are described holons under a module relation; they may be systems, epistemes, methods, organizations, publication families, or other structured holons. The module relation, interface specification, platform grammar, and open-architecture claim are Description epistemes, specification-use descriptions, or relation records about those holons. Stratification and architecture-operation labels named by C.30.STRAT remain source labels unless C.30.STRAT recovers a module-interface relation that A.6.M can use.

#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 a context-sensitive and viewpoint-sensitive relation role of U.Holon, not as a new root kind. This keeps FPF compatible with many engineering contexts where the same system, episteme, method, organization, publication family, or other structured holon can be a component under one declared relation, a module under another, a functional element under another, and an evidence, assurance, source, or publication artifact under another.

A.6.M follows A.6.P: overloaded relation language is repaired by reconstructing kind, slots, qualifiers, admissible use, and witnesses. It also follows the architecture relation discipline: boundary notes catch the first confusion, while A.6.M supplies the full repair body for module relation, interface specification, substitutability, change policy, and open-architecture conformance and admissible-use claims.

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-06-03 — this section last modified in upstream FPF commit a0c90e3b (github.com/ailev/FPF)