#Reusable Structure Accounting

C.31.RSA · 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 a practitioner needs to locate where reusable structure lives, where bespoke residue grows, which accounting basis is being used, what can be refactored, and what remains a bounded exception or source-return condition. A report-only share stays report-only unless the relevant outside-RSA use is governed by its governing pattern.

#Keywords

• reusable-structure accounting
• reusable share
• bespoke residue
• accounting basis
• report-only share
• source return
• refactoring opportunity.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner needs to locate where reusable structure lives, where bespoke residue grows, which accounting basis is being used, what can be refactored, and what remains a bounded exception or source-return condition. A report-only share stays report-only unless the relevant outside-RSA use is governed by its governing pattern.

Claim-use boundary: comparison, publication, evidence validity, assurance or safety-case reliance, gate use, architecture scale preference, causal-use, selected-set publication, candidate-synthesis, and local decision are outside-RSA uses. C.31.RSA may state the reusable locus, bespoke residue, accounting basis, report-only share, repair direction, and source-return condition. Add those other claims only under their governing patterns when those claims are being made.

The first useful move is ReusableStructureTriage:

ReusableStructureTriage:
  describedHolonRef:
  boundedContextRef:
  architectureClaimRef?:
  structureRefs or structuralAspectRefs:
  whereReusableStructureCurrentlyLives:
  whereBespokeResidueCurrentlyGrows:
  residueRefactoredInto:
    template | interfaceSpecification | methodDescription |
    workStructure | evidencePackage | assuranceArgumentStructure | otherDeclared
  residueAcceptedAsBoundedException:
  sourceReturnCondition?:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

Use the fuller accounting description only when an accounting basis and structure references are declared. Ordinary use stops when the practitioner knows where reusable structure lives, where bespoke residue grows, what can be refactored, and what remains a bounded exception.

What goes wrong if C.31.RSA is missed: a reusable share is treated as a proof of modularity; one-off work is hidden under a reuse label; evidence reuse is counted without validity context; hidden residual uncertainty is averaged with reusable templates; and "more reusable structure" is treated as always better.

What C.31.RSA buys in practice: the practitioner can state where structure is reusable, where it is bespoke, what source-side distinctions must remain reachable, and when the result is only report-only accounting.

Not this pattern when the question under repair is source-label recovery, module-interface relation repair, modularity-characteristic selection, measurement or comparability legality, architecture scale preference, mathematical-lens use, or any outside-RSA use named above. Use [C.30.STRAT](/generated/patterns/C.30.STRAT), [A.6.M](/generated/patterns/A.6.M), [C.31](/generated/patterns/C.31), [C.16](/generated/patterns/C.16), [A.10](/generated/patterns/A.10), [B.3](/generated/patterns/B.3), [G.6](/generated/patterns/G.6), [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.RSA as the synthesis or selector pattern.

#Problem

Architecture teams often say that structure is reusable, repeated, templated, common, standardized, or bespoke. Those phrases are useful, but they do not say what is being counted, described, or compared. Structure can be selected from functions, flows, control relations, module interfaces, work methods, evidence packages, regulatory arguments, data schemas, deployment constraints, or exception networks.

Functional, flow, control, module-interface, work, evidence, and assurance structures may be included only when their declared accountingBasisRef and evidence relation named by value, assurance relation, source relation, or source-return condition are declared when those relations are being claimed.

The practical question is: which reusable loci matter, which bespoke residue remains, what source distinctions are lost by accounting, and what repair or source return follows?

#Forces

#Solution

C.31.RSA governs reusable-structure accounting as a typed description over declared structures and structural aspects. It starts with ReusableStructureTriage; it uses ReusableStructureAccountingDescription@Context only when the accounting basis is declared.

#Typed accounting description

ReusableStructureAccountingDescription@Context:
  accountingBasisRef:
  structureRefs: FinSet(U.StructureRef)
  structuralAspectRefs: FinSet(StructuralAspectDescriptionRef)
  reusableStructureSlots:
  bespokeResidueSlots:
  hiddenOrResidualUncertaintySlots:
  slotBasisRefs?:
  admissibleAggregationRuleRef?:
  reportOnlyShares?:
  sourceReturnCondition?:
  admissibleUse:
  nonAdmissibleUse:

accountingBasisRef states the accounting rule being used: description length, dependency edges, work items, evidence package count, cost share, template instances, interface variants, regulatory case sections, or another declared accounting rule. The accounting rule is not implied by the word "reuse".

Well-formedness: every slot is over declared structureRefs, declared structuralAspectRefs, and one declared accounting basis. Slot labels are explanatory; they are not root kinds and are not automatically commensurable.

#Explanatory slot labels

A local accounting description may use explanatory slot labels such as:

S_function
S_flow
S_control
S_type
S_interface
S_scale
S_work
S_evidence
S_changePolicy
S_unique
S_crossScopeUnique
H_residual

These labels are local slots, not FPF ontology. H_residual is residual uncertainty or unmodelled variance under the accounting basis. It is not obviously the same unit as interface grammar, work template, evidence package, or regulatory argument.

#Report-only shares

ReusableStructureShare:
  report-only share over declared structureRefs and structuralAspectRefs
  under accountingBasisRef; not an architecture amount

BespokeResidueShare:
  report-only share under accountingBasisRef

HiddenOrResidualShare:
  report-only uncertainty or residue interpretation under accountingBasisRef

Numeric shares require a declared accountingBasisRef, declared scale or unitless-value rule, unit when relevant, polarity when relevant, admissible comparability relation, and comparator admission named by value such as CG-Spec, ComparatorSetRef, or a comparator-governing reference named by value before they can guide outside-RSA use such as comparison, ranking, selection, gate use, or decision use. Without that, the share remains local report-only guidance.

#Pseudo-sum boundary

An explanatory decomposition may be useful:

total-described-structure under accountingBasisRef:
  reusable slots
  bespoke residue slots
  hidden or residual uncertainty slots

This is not ReusableStructureEquation, not an architecture amount, and not a hidden StructureAmount kind. It is a readable decomposition of one declared accounting description. If the slots do not share a declared accounting basis and comparability rule, they cannot be summed or ranked.

#Structure-relocation moves

RSA is useful because it points to relocation and repair moves:

High reusable structure is not always good. The architecture question is where structure lives and what action follows: reusable templates, interfaces, flows, control relations, work methods, evidence packages, or unique exception networks and hidden coupling.

After a relocation or reuse move, ask what got worse:

The result is not "more reuse is better." A conforming RSA move states the reusable locus, the bespoke or residual locus, the accounting basis, the first repair direction, and the first cost, loss, or source-return condition that can make the move inadmissible.

#Triage and accounting use boundary

Use only ReusableStructureTriage when:

• there is one local case;
• no outside-RSA use is being made;
• the practitioner only needs a repair direction;
• no numeric share is being relied on.

Use ReusableStructureAccountingDescription@Context when:

• the accounting basis is declared;
• a report-only share is useful;
• structure refs or structural aspects need to be compared inside one declared accountingBasisRef;
• source-return conditions matter;
• reusable structure or bespoke residue is used for outside-RSA use such as cross-case report, publication, assurance, architecture scale preference, or decision.

#Reopen and lowering conditions

An RSA result remains valid only inside its declared accounting basis, structure edition, source-return condition, and comparator admission. Reopen the triage or lower the admissible use when any of the following changes:

• a hidden source distinction becomes action-relevant;
• the accounting basis changes or proves heterogeneous;
• the selected structure, structural aspect, interface grammar, evidence package, work method, or assurance argument changes edition;
• a comparator set, CG-Spec, or outside-RSA use is added after a report-only share was recorded;
• downstream reliance uses the RSA result for outside-RSA evidence, assurance, gate, causal-use, scale-preference, or decision work that the RSA note did not admit;
• evidence validity, assurance window, or source-return condition decays;
• a local bounded exception becomes repeated enough to require refactoring;
• a reuse move improves one locus while worsening interface cost, variation loss, evidence decay, assurance work, source-return cost, or hidden bespoke residue.

Lower the result to report-only when outside-RSA comparison, ranking, selection, gate use, or decision use lacks comparator admission named by value. Lower it to quote-only or source cue when the accounting basis cannot be recovered. Mark it blocked when the reusable locus and bespoke-residue locus cannot be separated.

#Archetypal Grounding

Tell. Reusable structure is not a substance. It is structure located in declared places under a declared accounting basis.

Show. In one architecture, reusable structure may be located in a template and interface grammar. In another, it may be located in a test package, regulatory argument, work method, or flow pattern. In a third, the reusable part may be small, but the bounded exception is exactly what preserves safety or local fit.

Show. A share can be useful as a local report. It becomes misleading when it hides which structure was counted, which structure was not counted, and when the reader must return to source records.

Holon and episteme: the structures being accounted over are selected architecture-relevant structures in context. The RSA description, slots, report-only shares, and source-return condition are accounting descriptions, slot-bearing records, report-only records, and source-return records about those structures.

#Worked case: reusable evidence package, bespoke delivery work

Situation:

A regulated product line has reusable component templates and a reusable test package.
Each customer delivery still repeats approval work and bespoke integration exceptions.

ReusableStructureTriage:

describedHolonRef: product-line delivery system
boundedContextRef: regulated customer deployments, current qualification window
architectureClaimRef: ArchitectureOf@Context(product-line delivery)
structureRefs or structuralAspectRefs:
  component template structure
  interface grammar structure
  evidence package structure
  delivery work structure
whereReusableStructureCurrentlyLives:
  component template structure
  reusable test package
  interface grammar for standard variants
whereBespokeResidueCurrentlyGrows:
  customer-specific approval work
  integration exceptions outside interface grammar
  local evidence witnesses not covered by reusable package
residueRefactoredInto:
  workStructure + evidencePackage + interfaceSpecification
residueAcceptedAsBoundedException:
  customer-specific regulatory clause with declared non-admissible reuse
sourceReturnCondition:
  return to deployment evidence and regulatory exception record before assurance or gate use
relatedClaimGovernanceIfClaimed:
  `A.10` and `G.6` for evidence validity; `B.3` for assurance reliance; `A.6.M` for interface grammar; `C.16` if comparison is being made
stopCondition:
  report-only accounting unless comparator admission, evidence validity, and assurance validity are declared

Admissible move: publish the local report-only RSA note and repair the recurring delivery approval work into reusable work structure and reusable evidence structure. Non-admissible move: claim that the reusable evidence package proves every deployment or that a high reusable share makes the architecture better.

#Anti-case: high share hides a bad architecture move

Situation:

A team reports that 85 percent of its architecture is reusable because most screens use one shared template.
The template makes many local exceptions necessary for product teams and side-channel integrations.

This is not a successful RSA result. The accounting basis counts template instances but hides interface relation cost, lost variation, hidden bespoke work, and evidence decay. The repair is to mark the share as report-only, add the missing bespoke-residue slots, and apply A.6.M, C.31, or an characteristic pattern governing the claim to the interface relation cost before any comparison or decision use.

Lowering replay: the team tries to use the 85 percent share to rank this template architecture above another product-line variant and approve the template program. The use is lowered to local report-only accounting because the comparator set, accounting-basis alignment, interface-cost measure, source-return condition, and decision record are absent. Before comparison or decision use, A.6.M must repair the interface grammar, C.16 or A.19 must govern comparability and characteristic space, and C.11 must govern the local decision claim.

Stop condition: do not use the 85 percent share for outside-RSA ranking, gate, assurance, or decision. Reopen the RSA note when the interface grammar, exception register, or comparator set changes.

#Transfer case: neural-network block replacement

Situation:

A model architecture replaces a repeated attention block with a hybrid SSM-attention block.
The benchmark improves, but cache placement, memory access, and ablation evidence change.

RSA can transfer from product-line architecture to neural-network architecture only after [C.30.STRAT](/generated/patterns/C.30.STRAT) has treated block, cache, and related terms as source labels unless the reusable locus is already recovered. Then RSA names the declared structures and accounting basis:

• reusable structure may be located in recovered repeated-block topology, dataflow pattern, cache-placement rule, or evaluation harness;
• bespoke residue may be located in model-specific tuning, data distribution dependence, memory-layout exception, or ablation gap;
• benchmark gain is not reusable-structure accounting by itself;
• evidence claims apply [A.10](/generated/patterns/A.10) and [G.6](/generated/patterns/G.6); causal claims apply [C.28](/generated/patterns/C.28); mathematical-lens or compression claims apply [C.29](/generated/patterns/C.29).

Admissible move: record which recovered structural locus was reused, what changed, what source distinctions must remain reachable, and which governing pattern governs benchmark, evidence, causal-use, or mathematical-lens claims. Non-admissible move: treat "block replacement improved the architecture" as RSA proof.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits:

• Reusable structure and bespoke residue become visible without a false architecture amount.
• Practitioners get a cheap triage before accounting.
• Report-only shares can guide repair without becoming proof.
• Evidence reuse, work repeatability, interface grammar, and bounded exceptions can be separated instead of averaged.

Costs:

• Some attractive reuse reports remain report-only.
• Numeric shares require declared accountingBasisRef, declared scale or unitless-value rule, relevant unit and polarity, admissible comparability relation, and comparator admission named by value before they can guide outside-RSA comparison, ranking, selection, gate, or decision use.
• The pattern raises a source-return question whenever accounting hides distinctions needed by downstream action.

#Rationale

C.31.RSA is separate from C.31 because accounting over reusable structure has a different reusable-structure accounting question from choosing modularity characteristics. C.31 asks which characteristic changes action. C.31.RSA asks where reusable structure and bespoke residue are located under a declared accounting basis.

The pattern refuses StructureAmount because architecture is selected structure in context, not a substance. A useful accounting description can still report shares, but only under declared structure refs, structural aspects, and an accounting basis.

The pattern also keeps residue ethically and practically neutral until interpreted. Bespoke residue can be a defect, a local necessity, a safety boundary, a regulatory constraint, or a deliberately accepted exception. The repair is to name which one.

#SoTA-Echoing

Source-currentness front. Use the table's Currentness or lineage use cell as the source-use boundary. Rows named current, such as ISO/IEC/IEEE 42010:2022, MOSA guidance, current product-line or variability work, GSN Community Standard v3, current safety-case reuse work, and the architecture-operation corpus material used as current practitioner language, require source refresh before outside-RSA use when the named standard, guide, practice family, or corpus role changes. Rows named lineage, such as DSM or product-architecture lineage, Eppinger and Browning lineage, Goodhart and Campbell proxy-pressure lineage, system-evolution and information-hiding lineage, and Pohl, Boeckle, and van der Linden lineage, stay lineage unless a current source relation is explicitly recovered.

Refresh or lower the RSA result when a source-role change alters the reusable locus, bespoke-residue locus, accounting basis, source-return condition, comparator admission, evidence-validity relation, assurance or safety-case reliance, architecture scale-preference relation, or any outside-RSA use. A source row may explain why an accounting distinction matters, but it does not make an RSA share current for comparison, decision, assurance, gate, or publication without the governing pattern for that outside-RSA use.

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 an RSA share admissible for outside-RSA use without the governing pattern for that use.

#Relations

#C.31.RSA:End

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