C.31 - Modularity and Reusable Structure Characteristics

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

C.31:1 - 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:
  architectureQuestion:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  architectureClaimRef?:
  selectedStructureRefs:
  structureKindRefs:
  threeLiveCharacteristicsAtMost:
  observedProblem:
  repairDirection:
  relatedClaimPatternLocatorsIfClaimed:
  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 subject 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 architecture use, which false use is blocked, which repair is plausible, and which exact subject assertion and defining or constraining ClaimGraph are needed for 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 admissibility, quality-family claim, architecture scale-preference claim, mathematical-lens use, candidate architecture synthesis, or selection. Use C.30.STRAT, A.6.M, C.31.RSA, C.16, C.25, C.31.ASAP, C.29, C.32, G.5, or C.11 as appropriate: C.32 governs candidate architecture synthesis, G.5 selected-set result declaration, and C.11 local choice.

C.31:2 - 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.

C.31:3 - Forces

C.31:4 - Solution

C.31 defines and constrains modularity and reusable-structure characteristic assertions 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.

C.31:4.1 - 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:
  architectureQuestion:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  architectureClaimRef?:
  selectedStructureRefs:
  structureKindRefs:
  threeLiveCharacteristicsAtMost:
    - characteristicRef:
      characteristicScaleRef?:
      evidenceRefs?:
      comparisonBasisRef?:
      currentCue:
      repairDirection:
      claimUseClass:
      forbiddenOverread:
  observedProblem:
  relatedClaimPatternLocatorsIfClaimed:
  stopCondition:

The vector is complete enough when it states what can be done next and what cannot be inferred. relatedClaimPatternLocatorsIfClaimed is a non-semantic locator field: if a characteristic is used beyond local repair, the exact subject assertion and its defining or constraining ClaimGraph remain separately required. Architecture scale-preference claims use the predicate defined in C.31.ASAP.

C.31:4.1a - Filled ModularityVectorLite

ModularityVectorLite:
  describedHolonRef: ProductPlatform@FieldPumpFamily
  architectureQuestion: which structural repair would reduce field-replacement and certification burden?
  intendedArchitectureUse: choose the next modularity repair for field service and procurement
  claimScopeRef?: field-service and procurement architecture claims
  qualificationWindowRef?: 2026Q2
  architectureClaimRef?: ArchitectureOf@PumpControllerPlatform
  selectedStructureRefs: PumpControllerModuleInterfaceStructure, PumpControllerEvidencePackageStructure
  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.
  relatedClaimPatternLocatorsIfClaimed: 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 an exact evidence-use or assurance-use assertion is being made.
  stopCondition: stop at local repair until measurement basis, comparability basis, and any selection or assurance use are declared under their subject 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.

C.31:4.2 - 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.

C.31:4.3 - 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:
  evidenceRelationRefs?:
  evidenceProvenanceRelationRefs?:
  sourceRelationRefs?:
  evidenceClaimAbsentBecause?:
  commonFalseUse:
  nonAdmissibleUse:
  repairAction:
  relationFunctionClaimRef?:     # only when this use depends on exact rule identity
  authoritySourceRef?:           # only when a non-pattern source carries relevant authority

Use an ordinary PatternID to locate the rule. Under E.10 L-EPI-PUB, relationFunctionClaimRef identifies the defining or constraining ClaimGraph only when interpretation, comparison, migration, publication or reuse depends on that exact rule identity. It is not a demand to establish a separate relation-function individual. When an external standard, policy or other non-pattern source carries the relevant authority, use authoritySourceRef for that source instead.

For example, an ordinary InterfaceStandardizationShare account states its subject, the counted interface population, conformance specification, ratio Scale, source/test basis and limitations. It needs no extra rule-identity claim merely to describe that share. If a comparison combines two editions that count partial conformance differently, cite the exact defining predicates through relationFunctionClaimRef before treating their shares as comparable. The comparison still needs its actual measurement and evidence basis; citing the predicate supplies neither test results nor assurance.

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 relation, evidence-provenance relation, or source relation. If no evidence claim is being made, evidenceClaimAbsentBecause states why the head remains local, report-only, or repair-only.

C.31:4.4 - 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:
  evidenceRelationRefs?:
  evidenceProvenanceRelationRefs?:
  sourceRelationRefs?:
  evidenceClaimAbsentBecause?:
  proxyRisk:
  auditQuestion:
  nonAdmissibleUse:
  repairAction:
  relatedClaimPatternLocators:
  relationFunctionClaimRef?:     # same rule-identity condition as MeasurementHeadMapping
  authoritySourceRef?:           # relevant non-pattern authority, when used

Each card states its own C.16 well-formedness fields: characteristic, scale, unit or unitless interpretation, declared measurement basis, comparability basis, evidence relation, evidence-provenance relation, source relation, or evidence-claim-absent reason, non-admissible use, and repair action. 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.

C.31:4.5 - Seed characteristic heads and repair actions

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

C.31:4.6 - Claim-scoped residual heads

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

C.31:4.7 - 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.

C.31:4.8 - 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.

C.31:4.9 - 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 relation, evidence-provenance relation, source relation, evidence-claim-absent reason, or source-return condition changes;
• described holon, architecture question or intended use, ClaimScope or qualification window, 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 relatedClaimPatternLocatorsIfClaimed, lower a score to a local proxy, or stop C.31 use for the beyond-local-repair claim and constitute the exact subject assertion under its predicate.

C.31:5 - 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: C.31 characterizes selected module-interface and other architecture-relevant structures of described holons for named architecture questions and uses; the described holon may be an admitted system, organization-as-system, episteme, work occurrence, discipline, or another admitted holon kind. Publication-family material uses the episteme and publication patterns. A MethodDescription is an episteme; a Method uses A.3.1, and any relation asserted for it uses the pattern that defines that relation. 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.

C.31:6 - Bias-Annotation

C.31:7 - Conformance Checklist

C.31:8 - Common Anti-Patterns and How to Avoid Them

C.31:9 - 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 subject-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 need an exact characteristic, a lens-backed interpretation, or a residual cue.

C.31:10 - 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 action 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 subject-pattern discipline.

C.31:11 - 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 and the exact subject assertion 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-use relation, update the affected characteristic head, proxy-risk field, audit question, related claim locator and assertion, 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 subject pattern for that use.

C.31:12 - Relations

C.31:End