#Modularity and Reusable Structure Characteristics

C.31 · Cluster C.IV - Composite & Macro-Scale · Stable · Characterization pattern · Normative unless explicitly marked informative · Part C - Kernel Extension Specifications

#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: Characterization pattern Status: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when modularity or reusable-structure language is doing work in an architecture discussion and the practitioner needs to know which few characteristics matter, what repair follows, and whether any measurement or comparison is admissible.

#Keywords

• modularity characteristics
• reusable-structure characteristics
• coupling
• cohesion
• substitutability
• interface variation
• evidence reuse
• bespoke residue
• ModularityVectorLite.

#Relations

#Content

#Problem frame

Use this pattern when modularity or reusable-structure language is doing work in an architecture discussion and the practitioner needs to know which few characteristics matter, what repair follows, and whether any measurement or comparison is admissible.

The first useful move is deliberately small:

ModularityVectorLite:
  describedHolonRef:
  boundedContextRef:
  architectureClaimRef?:
  structureKindRefs:
  threeLiveCharacteristicsAtMost:
  observedProblem:
  repairDirection:
  relatedClaimGovernanceIfClaimed:
  nonAdmissibleOverread:
  stopCondition:

Start with recognition, at most three characteristics under evaluation, the observed problem, and a repair direction. A report-only proxy is an admissible stop when no beyond-local-repair use is being made.

Claim-use boundary: comparison, publication, evidence, assurance, gate, decision, benchmark, causal-use, cross-case reuse, selection, procurement, and architecture scale-preference are beyond-local-repair uses in C.31. Add their fields only when that use is being made and recoverable by value and the governing pattern can be named.

What goes wrong if C.31 is missed: "modular" becomes a binary label; a single modularity score hides incompatible characteristics; interface publication is confused with substitutability; internal cohesion is improved while evidence reuse gets worse; bespoke residue moves from templates into work or assurance; and complexity language becomes a commensurable score without a declared characteristic, scale, measurement basis, comparison basis, or admissible-use boundary.

What C.31 buys in practice: the practitioner can see which modularity characteristic changes the next move, which false use is blocked, which repair is plausible, and which governing pattern governs measurement, evidence, causal, scale, selection, or accounting claims.

Not this pattern when the question under repair is only source-label recovery, module-interface relation repair, reusable-structure accounting, general measurement legality, quality-family claim, architecture scale-preference claim, mathematical-lens use, candidate architecture synthesis, or selection. Use [C.30.STRAT](/generated/patterns/C.30.STRAT), [A.6.M](/generated/patterns/A.6.M), [C.31.RSA](/generated/patterns/C.31.RSA), [C.16](/generated/patterns/C.16), [C.25](/generated/patterns/C.25), [C.31.ASAP](/generated/patterns/C.31.ASAP), [C.29](/generated/patterns/C.29), [G.5](/generated/patterns/G.5), or [C.11](/generated/patterns/C.11) as appropriate; do not treat C.31 as the synthesis or selector pattern.

#Problem

Architecture work often asks for more modularity, better reuse, lower coupling, more explicit interfaces, cleaner allocation, or less bespoke residue. These phrases point to real engineering work, but they do not name one scalar property.

Modularity can improve along one characteristic while worsening another. A design can reduce external coupling and increase interface alphabet size. A platform can standardize interfaces and create unhelpful rigidity. Evidence reuse can improve while functional-to-module allocation remains tangled. A report can show a high reuse share while hiding source-return work or residual uncertainty.

C.31 turns modularity talk into a small characteristic vector plus repair direction. It does not promise that every characteristic is measurable now, comparable across cases, causal, admissible for decision use, or evidence-backed.

#Forces

#Solution

C.31 governs modularity and reusable-structure characteristics as C.16-compatible characteristic heads, composite descriptions, lens-backed characteristic interpretations, temporal or scale-sensitive characteristic interpretations, causal-use-sensitive characteristic interpretations, or report-only proxies. It starts from action guidance and adds fields for beyond-local-repair use only when a use being made requires them.

#Ordinary output: ModularityVectorLite

ModularityVectorLite is the ordinary output. It names at most three characteristics under evaluation because the first task is to find the next repair, not to audit all possible modularity interpretations.

ModularityVectorLite:
  describedHolonRef:
  boundedContextRef:
  architectureClaimRef?:
  structureKindRefs:
  threeLiveCharacteristicsAtMost:
    - characteristicRef:
      currentCue:
      repairDirection:
      claimUseClass:
      forbiddenOverread:
  observedProblem:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

The vector is complete enough when it states what can be done next and what cannot be inferred. If a characteristic is used beyond local repair, use the appropriate card and governing pattern; architecture scale-preference claims are governed by [C.31.ASAP](/generated/patterns/C.31.ASAP).

#Filled ModularityVectorLite

ModularityVectorLite:
  describedHolonRef: ProductPlatform@FieldPumpFamily
  boundedContextRef: FieldServiceAndProcurement@2026Q2
  architectureClaimRef?: ArchitectureOf@PumpControllerPlatform
  structureKindRefs: ModuleInterfaceStructure, EvidencePackageStructure
  threeLiveCharacteristicsAtMost:
    - characteristicRef: InterfaceStandardizationShare
      currentCue: controller ports are named by the same API family, but three field variants still require adapter-specific wiring.
      repairDirection: narrow the interface grammar and name the allowed variation before counting the interface as standardized.
      claimUseClass: local repair cue
      forbiddenOverread: the public API label is not substitutability or procurement suitability.
    - characteristicRef: SubstitutabilityWidth
      currentCue: two alternate controller boards pass the bench test, but only one has the required thermal envelope and connector constraints.
      repairDirection: state the substitution conditions and the exception before using the alternative count.
      claimUseClass: report-only proxy until C.16 or selection use is being made
      forbiddenOverread: the alternate-board count is not a selection result.
    - characteristicRef: EvidenceReuseShare
      currentCue: electrical-safety evidence is reused, while environmental evidence is recreated per enclosure variant.
      repairDirection: split reusable evidence package from variant-specific evidence and add source-return condition.
      claimUseClass: local repair cue with possible evidence-package use
      forbiddenOverread: reused evidence is not assurance sufficiency.
  observedProblem: the team says the platform is modular because interfaces are public and evidence is reusable, but field replacement and certification still create variant-specific work.
  relatedClaimGovernanceIfClaimed: A.6.M for the module-interface relation; C.31.RSA if report-only share becomes reusable-structure accounting; A.10 or B.3 only if evidence or assurance use is being made.
  stopCondition: stop at local repair until measurement basis, comparability basis, and any selection or assurance use are declared by their governing patterns.

Near miss: a high interface-standardization count alone is not a C.31 improvement. If field-service work, source-return events, or variant-specific evidence increase, the vector records that proxy divergence and returns to repair rather than treating the count as architecture quality.

#Characteristic classes

Every C.31 head is classified before use:

In C.31, declared basis and comparability basis name C.16-compatible measurement or comparison fields. They are not generic reason words and are not substitutes for evidence, assurance, cause, source, decision, or architecture-description relations.

#Measurement-head mapping

When a head becomes decision-facing or publication-facing, create MeasurementHeadMapping before relying on it:

MeasurementHeadMapping:
  sourceHead:
  knownMeasureFamilyOrPractice:
  fpfCharacteristicKind:
  scaleType:
  unitPolicy:
  declaredBasisNeeded:
  requiredEvidence:
  evidencePathRefs?:
  sourceRelationRefs?:
  evidenceClaimAbsentBecause?:
  commonFalseUse:
  nonAdmissibleUse:
  repairMove:
  governingPatternRef:

This mapping is not a measurement template by itself. It prepares a C.16-compatible characteristic card or a report-only boundary. When the head is decision-facing or publication-facing, the mapping names required evidence plus at least one evidence path or source relation. If no evidence claim is being made, evidenceClaimAbsentBecause states why the head remains local, report-only, or repair-only.

#C.31 characteristic card

Use the full card only when the use goes beyond local repair:

ModularityCharacteristicCard:
  characteristicRef:
  subjectRef or relationSubjectTuple:
  characteristicClass:
  scaleRef:
  unitInterpretation:
  declaredBasisRef:
  comparabilityBasisRef:
  requiredEvidence:
  evidencePathRefs?:
  sourceRelationRefs?:
  evidenceClaimAbsentBecause?:
  proxyRisk:
  auditQuestion:
  nonAdmissibleUse:
  repairMove:
  relatedClaimGovernanceRefs:

Each card states its own C.16 well-formedness fields: characteristic, scale, unit or unitless interpretation, declared measurement basis, comparability basis, evidence path or evidence-claim-absent reason, non-admissible use, and repair move. When source material is used as evidence, the source relation is named. A source checklist, source-discharge slice, dashboard label, or inherited score is not enough.

#Seed characteristic heads and repair moves

These heads are seeds, not an exhaustive taxonomy. Use only the heads that change the next move.

#Claim-scoped residual heads

C.31 uses residual heads only as qualitative repair cues. These heads do not create one complexity characteristic.

#Proxy-risk discipline

Every decision-facing C.31 card includes ProxyRisk and AuditQuestion. If the proxy diverges from the value it was meant to represent, the card stops at report-only use or returns to repair.

#Rejected shortcut

The expression ModularityScore = average(all measures) is not admissible as a C.31 result. A local score is admissible only when the scoring method, codomain, polarity, characteristic basis, comparability basis, and use boundary are disclosed through the governing scoring or comparator pattern. Without that, keep the result as report-only or return to ModularityVectorLite.

#Lowering and currentness conditions

Lower or reopen a ModularityVectorLite, ModularityCharacteristicCard, or report-only proxy when any of these conditions changes the characteristic use:

• proxy audit worsens, such as more integration failures, workarounds, source-return events, stale evidence reuse, or bounded exceptions;
• measurement basis, comparability basis, scoring method, codomain, polarity, unit policy, or declared characteristic basis changes;
• evidence path, source relation, evidence-claim-absent reason, or source-return condition changes;
• described holon, bounded context, architecture claim, structure kind, characteristic head, or repair direction changes;
• a report-only proxy is used for comparison, selection, publication, assurance, benchmark, causal-use, cross-case reuse, decision, procurement, or architecture scale-preference;
• C.31.RSA, C.31.ASAP, C.16, C.25, C.29, C.30.STRAT, A.6.M, C.30, C.30.ASV, A.10, B.3, A.20, A.21, G.5, or C.11 changes the boundary for the neighboring claim being made.

Admissible repair results are: keep the result report-only, split or rename the characteristic head, update basis or evidence fields, revise the repair direction, change relatedClaimGovernanceIfClaimed, lower a score to a local proxy, or stop C.31 use for the beyond-local-repair claim and use the governing pattern.

#Archetypal Grounding

Tell. Modularity is a vector of action-guiding characteristics, not a magic scalar. A good C.31 interpretation says what to repair next.

Show. A product architecture can have high interface standardization and still poor substitutability. A software-system architecture can reduce external coupling while increasing hidden data custody. A safety-case architecture can reuse evidence while increasing regulatory bespoke residue. Each case needs a different characteristic and a different repair.

Show. A DSM or dependency graph can substantiate a modularity interpretation, but the graph does not by itself say which dependency kind matters, what scale applies, whether the interpretation is comparable, or what action follows.

Holon and episteme: architecture and modules are selected structures of described holons; the described holon may be a system, episteme, method, organization, publication family, or another structured holon. C.31 heads, cards, vectors, and report-only proxies are characteristic records, declared-measurement-basis records, comparability-basis records, or report-only records about those structures.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits:

• Modularity becomes action-guiding without becoming one fake score.
• Cheap repair remains possible before measurement.
• Characteristic, declared-measurement-basis, comparability-basis, proxy-risk, and governing-pattern boundaries are visible.
• DSM, MOSA, platform, product-line, and architecture-operation sources can inform practice without importing their ontology wholesale.

Costs:

• Familiar score language often has to be downgraded to report-only use.
• Cross-case comparison requires additional C.16, C.25, G.2, comparator, evidence, or decision claim.
• Some attractive "complexity" statements are assigned to characteristic named by value, lens, or residual cue rather than becoming a general complexity pattern here.

#Rationale

C.31 is a characterization pattern because modularity and reusable-structure talk changes engineering action through characteristics: coupling, cohesion, interface variation, substitutability, reuse, evidence reuse, hidden coupling, source-return cost, and residual growth. Those heads are useful only when their subject, scale, declared measurement or comparison basis, false use, and repair move are visible.

The pattern puts ModularityVectorLite first to preserve affordability. Many practitioners need to see one relation to repair, one interface grammar to tighten, or one residue to account for. Requiring the full measurement apparatus too early would turn C.31 into a control form and would violate the architecture source invariant: repair succeeds only when one useful admissible action remains.

The pattern rejects a single complexity or modularity score because selected heads are not automatically commensurable. When a local score is genuinely useful, it belongs under disclosed scoring, comparator, characteristic, declared-measurement-basis, and governing-pattern discipline.

#SoTA-Echoing

Source-currentness front. Use the table's Currentness or lineage use cell as the source-use boundary. A lineage row can explain why a characteristic family matters, but it cannot establish current comparison, procurement, assurance, benchmark, decision, publication, or other beyond-local-repair use without a current source relation under G.2 or the governing pattern for that use. Refresh the source use when MOSA or acquisition guidance changes, platform or product-line practice changes, DSM or modularity-index practice changes, queueing or coordination-overhead assumptions change, proxy-pressure law is used for a new claimed value relation, or architecture-operation language is used as current practice rather than as source-side recognition language. When refresh changes the source role, update the affected characteristic head, proxy-risk field, audit question, related claim governance, or report-only boundary rather than treating the older source as current by default.

Rows named current, such as MOSA guidance, current platform practice, current scalable-workload extensions, or current architecture-operation corpus material, require source refresh before beyond-local-repair use when the named practice changes. Rows named lineage stay lineage unless a current source relation is explicitly recovered.

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 modularity value admissible for beyond-local-repair use without the governing pattern for that use.

#Relations

#C.31:End

Last Updated: 2026-06-03 — this section last modified in upstream FPF commit a0c90e3b (github.com/ailev/FPF)