#Architecture Scale-Amenability Preference

C.31.ASAP · 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 compares architecture alternatives under a declared scale variable or scale window and needs to avoid treating a modularity label, platform label, product-line label, reusable-structure share, or coarse-graining metaphor as an automatic scale-preference claim.

#Keywords

• architecture scale preference
• scale amenability
• ScaleClaimTriage
• scale variable
• scale window
• architecture alternatives
• source-return condition
• coarse-graining
• RG
• platform scale claim
• waiver reason.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner compares architecture alternatives under a declared scale variable or scale window and needs to avoid treating a modularity label, platform label, product-line label, reusable-structure share, or coarse-graining metaphor as an automatic scale-preference claim.

The first useful move is ScaleClaimTriage:

ScaleClaimTriage:
  architectureAlternativeSetRef:
  scaleVariableRef:
  scaleWindowRef:
  claimedPreferenceUnderScale:
  slopeEvidenceRef, scaleProbeEvidenceRef, or noProbeReason:
  expectedStableOrImprovingStructure:
  exceptionGrowthRisk:
  sourceReturnCondition:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

Ordinary use starts by naming the alternatives, the scale variable, the scale window, the claimed preference under scale, the available slope or scale-probe evidence or no-probe reason, the expected stable or improving structure, and the exception growth risk. Use ArchitectureScaleAuditRecord@Project only when the scale preference is being used to affect a comparison, selected set, publication, assurance input, or architecture decision.

What goes wrong if C.31.ASAP is missed: "modular", "platform", "product line", "reusable", "general", "open", "coarse-grained", or "RG-like" becomes a shortcut for a scale-preference claim; a locally hand-engineered solution is called debt even when safety, legality, or mission constraints justify it; exception growth is hidden until the architecture is already expensive to change; and coarse descriptions keep losing lower-scope safety or semantic distinctions without a source-return condition.

What C.31.ASAP buys in practice: the practitioner can say what is being scaled, where the scale claim holds, what structure is expected to remain stable or improve, what exceptions are allowed, what evidence or no-probe reason exists, which scale-preference claim stays in C.31.ASAP, and which governing pattern governs any lens-use, evidence, assurance, selection, or decision claim being made.

Not this pattern when the question under repair is only module-interface relation repair, modularity-characteristic selection, reusable-structure accounting, mathematical-lens use, scale-law adequacy, method preference under general BLP, candidate architecture generation, selected-set return, or final local choice. Use [A.6.M](/generated/patterns/A.6.M), [C.31](/generated/patterns/C.31), [C.31.RSA](/generated/patterns/C.31.RSA), [C.29](/generated/patterns/C.29), [C.18.1](/generated/patterns/C.18.1), [C.19.1](/generated/patterns/C.19.1), [G.5](/generated/patterns/G.5), [G.9](/generated/patterns/G.9), or [C.11](/generated/patterns/C.11) as appropriate. C.31.ASAP governs architecture scale-preference claims; it does not select the architecture, prove the scale law, or certify the project.

#Problem

Architecture work often asks whether one structure will scale better than another: a product-line architecture rather than bespoke variants, an open interface rather than a closed integration, a stable flow topology rather than repeated project exceptions, or a reusable evidence package rather than repeated assurance work.

These claims are useful only after the scale relation is declared. "Scales better" can mean fewer interface grammar variants, lower exception growth, better learning transfer, more reusable templates, more stable control relations, less source-return cost, fewer regulatory exceptions, or more freedom of action. Those are not the same claim.

C.31.ASAP turns architecture scale-preference talk into a declared scale variable or window, a preference claim, evidence or no-probe reason, expected stable or improving structure, exception-growth risk, and source-return condition. It does not turn scale preference into proof, selection, assurance, causal use, or a universal law.

#Forces

#Solution

C.31.ASAP specializes scale-amenability preference for architecture alternatives. It applies when an architecture alternative set, scale variable or scale window, and claimed preference under scale are named.

#Applicability fields

C.31.ASAP applies only when all of the following are present:

1. a declared architecture alternative set;
2. a declared scale variable or scale window;
3. a claimed preference under scale;
4. slope evidence, scale-probe evidence, or a no-probe reason;
5. an expected stable or improving structure, exception-growth risk, or source-return condition that changes the next architecture move.

If those fields are absent, keep the claim in C.31 as a temporal or scale-sensitive characteristic cue, in C.31.RSA as report-only accounting, in C.29 as a bounded lens-use output, or in ordinary architecture prose.

#ScaleClaimTriage

Use ScaleClaimTriage before any heavier scale audit:

ScaleClaimTriage:
  architectureAlternativeSetRef:
  describedHolonRef:
  boundedContextRef:
  architectureClaimRef?:
  scaleVariableRef:
  scaleWindowRef:
  claimedPreferenceUnderScale:
  slopeEvidenceRef?:
  scaleProbeEvidenceRef?:
  noProbeReason?:
  expectedStableOrImprovingStructure:
  exceptionGrowthRisk:
  sourceReturnCondition:
  admissibleUse:
  nonAdmissibleUse:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

The triage is complete enough when it states the next admissible architecture move and the nearest blocked overread. It may stop at local guidance when no comparison, publication, assurance, selected-set, or decision use is being made.

#Architecture scale-preference rule

When architecture alternatives satisfy the same safety boundary, legal boundary, and assurance boundary, prefer the alternative whose reusable functional-structure, flow-structure, control-structure, module-interface, work-template, and evidence-package structure and learning-transfer slopes remain stable or improve over the declared scale window, unless an ArchitectureScaleAuditRecord@Project records a bounded exception.

This is not a selector result. If an alternative set, shortlist, selected set, local choice, gate, or decision is being claimed, use G.5, G.9, C.11, A.21, or the governing pattern. C.31.ASAP governs only the scale-preference claim and its boundary.

#Scale variables

Typical architecture scale variables include:

The scale variable is not enough by name. The claim being made also needs a scale window, expected stable or improving structure, exception-growth risk, and source-return condition.

#Scale audit outputs

Use the heavier audit only when the scale preference changes comparison, publication, selected-set, assurance-input, or decision use:

ArchitectureScaleAuditRecord@Project:
  architectureAlternativeSetRef:
  scaleVariableRefs:
  scaleWindowRef:
  ArchitectureSlopeVector:
  IsoScaleParityNote?:
  ASAPWaiverReason?:
  ArchitectureHeuristicDebt?:
  BespokeResidueRegisterRef?:
  SourceReturnCondition:
  admissibleUse:
  nonAdmissibleUse:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

ArchitectureScaleAuditRecord@Project is a project-side triage record governed by this pattern. It is not an assurance proof, gate record, selected-set publication, local decision, or work plan.

#Waiver discipline

ASAPWaiverReason:
  deontic constraint
  safety or legal boundary
  scale-probe overturn
  assurance infeasibility
  context-specific bounded exception

Not every non-scale-amenable choice is debt. A deontic constraint, safety boundary, legal boundary, mission constraint, assurance infeasibility, or scale-probe overturn can justify a bounded exception without creating ArchitectureHeuristicDebt.

ArchitectureHeuristicDebt remains report-only unless tied to a decision, risk, work, evidence, assurance, or selected-set record through its governing pattern.

#Scale-refactoring moves

Before scale-preference guidance becomes action-guiding, name at least one possible repair or stop:

#C.29 lens relation

C.31.ASAP does not prove a scale law and does not perform mathematical-lens recovery. Use C.29 when the scale preference depends on an RG, coarse-graining, epiplexity, graph, multilevel-learning, or frustration lens.

For architecture use, the C.29 output should name MLU.Description@RGArchitecture, MLU.Description@MultilevelLearningFrustration, or another local MathLensUse output only when the lens changes the next admissible move. The C.31.ASAP side records the scale variable, scale window, slope or scale-probe evidence, exception-growth risk, and source-return condition. C.29 records candidate mathematical object, mapping mode, preserved structure, lost structure, visible payoff, admissible use, non-admissible use, and stop condition.

#Archetypal grounding

#Filled triage slice

ScaleClaimTriage:
  architectureAlternativeSetRef: product-line platform alternative vs bespoke customer-specific variants
  scaleVariableRef: N_sites
  scaleWindowRef: 5 to 40 regulated deployment sites inside the current qualification window
  claimedPreferenceUnderScale: platform alternative is preferred if interface variants and approval exceptions grow slower than bespoke variants
  slopeEvidenceRef, scaleProbeEvidenceRef, or noProbeReason: scale-probe evidence from six deployments; no universal scale law claimed
  expectedStableOrImprovingStructure: interface grammar, reusable test package, deployment work template
  exceptionGrowthRisk: jurisdiction-specific clauses and side-channel integrations may grow faster than sites
  sourceReturnCondition: return to exception register, interface variant log, and deployment evidence before publication, selected-set, assurance, or decision use
  relatedClaimGovernanceIfClaimed: C.31 for the characteristic; C.31.RSA for reusable-structure share; C.16 or A.19 for comparison; G.5 or G.9 for selected-set use; C.11 for local decision; A.10, B.3, or G.6 for evidence or assurance
  stopCondition: stop at local scale-preference guidance unless comparator admission, evidence validity, and decision or selected-set governance are present

Admissible move: prefer the platform alternative as a local scale-preference guide and start interface-grammar repair before deployment spread increases. Non-admissible move: treat the platform label, reusable-share number, or six-site probe as architecture selection, evidence sufficiency, assurance, gate passage, or final decision.

#Near-miss lowering slice

Near-miss: a team says the platform architecture should win because it has an 82 percent reusable-structure share, an RG-like coarse description, and "less bespoke debt" than the local variant.

Lowering replay:

• The platform label is a source cue, not scale-preference evidence; recover variability slots, extension rules, exception curve, and source-return condition first.
• The 82 percent reusable-structure share stays report-only under C.31.RSA until the scale variable, scale window, accounting basis, comparator admission, and admissible comparison relation are declared.
• The RG-like phrase stays with C.29 unless the mathematical-lens fields, preserved structure, lost structure, payoff, admissible use, and stop condition are recoverable.
• The "bespoke debt" label is lowered to waiver review when safety, legal, mission, assurance, or scale-probe overturn reasons may justify the local variant.

Stop C.31.ASAP use when the scale window, probe evidence or no-probe reason, comparator admission, or source-return condition is absent. Reopen it only after those fields are recoverable and the platform-label, share, lens, and waiver claims have their governing patterns.

#Bias annotation

#Conformance Checklist

#Common anti-patterns

#Consequences

#Rationale

C.31.ASAP is added because C.31 and C.31.RSA can expose scale-sensitive characteristics and reusable-structure residue, but they should not themselves decide which architecture alternative is preferable under scale. C.31.ASAP governs this architecture scale-preference claim family; it is narrower than general BLP and broader than one measurement card.

The pattern adapts BLP-style scale-amenability to architecture: prefer the alternative that preserves or improves reusable structure over a declared scale window when safety, legality, and assurance boundaries are comparable. It also blocks the common shortcut that treats modularity, reuse, platform practice, or mathematical coarse-graining as scale-preference evidence by itself.

#SoTA-Echoing

#Relations

• Builds on: C.31, C.31.RSA, C.16, A.17, A.18, A.19, C.18.1, C.19.1, and C.29.
• Coordinates with: A.6.M for module-interface relation repair; C.30, C.30.ASV, C.30.LCA, and C.30.ILC for architecture and selected-structure questions; A.10, B.3, and G.6 for evidence and assurance reliance; G.5, G.9, and C.11 for selected-set, parity, and choice claims.
• Boundary: C.31.ASAP governs architecture scale-preference claims. C.31, C.31.RSA, C.29, C.18.1, C.19.1, G.5, G.9, and C.11 govern modularity-characteristic, reusable-structure accounting, mathematical-lens, scale-law, general method preference, selected-set, parity, and local-choice claims when those claims are being made.
• Precision-restoration relation: source wording recovered by E.10, E.10.ARCH, or C.30.STRAT is governed by C.31.ASAP only when the recovered claim being made is architecture scale preference over a declared alternative set, scale variable, and scale window.

#C.31.ASAP:End

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