#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:
  describedHolonRef:
  claimScopeRef:
  selectedContextSliceRefs:
  modelUseStructureRef?:
  scaleVariableRef:
  scaleWindowRef:
  claimedPreferenceUnderScale:
  slopeEvidenceRef, scaleProbeEvidenceRef, or noProbeReason:
  expectedStableOrImprovingStructure:
  exceptionGrowthRisk:
  sourceReturnCondition:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

Ordinary use starts by naming the alternatives and described holon, the exact U.ClaimScope and relevant A.2.6 U.ContextSlice membership, the scale variable and 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. Name modelUseStructureRef only when one independently selected BoundedModelUseStructure changes this receiving interpretation; it never replaces the claim scope. 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, law-domain, 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), [C.32](/generated/patterns/C.32), [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, described holon, exact U.ClaimScope, and relevant A.2.6 U.ContextSlice membership;
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:
  claimScopeRef:
  selectedContextSliceRefs:
  modelUseStructureRef?:
  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.

claimScopeRef designates one exact U.ClaimScope; selectedContextSliceRefs records the A.2.6 membership relevant to this use. A scale window is the range of the scale variable for which the preference is claimed, not a substitute for either scope object. modelUseStructureRef is optional and is filled only when an independently selected A.1.1 BoundedModelUseStructure changes the interpretation of this exact preference use. A generic bounded-context label creates none of those values or relations.

#Architecture scale-preference rule

When architecture alternatives satisfy the same safety boundary, law-domain 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.

A scale-preference claim may inform C.32 candidate generation or supply one input to an A.19.CPM comparison by naming the scale variable, scale window, expected stable or improving structure, exception-growth risk, and source-return condition for candidate alternatives. It does not itself compare, select, publish, authorize, or prove an architecture. C.32 carries the candidate architecture palette; A.19.CPM governs explicit comparison, G.5 governs selected-set publication, C.11 governs final local choice, C.32.PAD governs project architecture decision, and evidence, assurance, gate, and release patterns govern those claims when current.

When the same scale-sensitive pressure must also become a project criterion, C.32.ACS creates a separate row for the exact characteristic or Q-Bundle slot, bearer, scale form, and use class. That row may supply declared input to an ASAP preference, but it does not assert that one alternative is preferable under the scale window; conversely, an ASAP preference record is not an ACS row and does not classify the row as an optimization indicator, guardrail, or context-only row.

#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:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureScaleAuditProjectUseRelationRef?: U.RelationRef governed by the exact audit-use or work-use pattern
  architectureAlternativeSetRef:
  claimScopeRef:
  selectedContextSliceRefs:
  modelUseStructureRef?:
  scaleVariableRefs:
  scaleWindowRef:
  ArchitectureSlopeVector:
  IsoScaleParityNote?:
  ASAPWaiverReason?:
  ArchitectureHeuristicDebt?:
  BespokeResidueRegisterRef?:
  SourceReturnCondition:
  admissibleUse:
  nonAdmissibleUse:
  relatedClaimGovernanceIfClaimed:
  stopCondition:

For ArchitectureScaleAuditRecord@Project and BespokeResidueRegister@Project, @Project is a compatibility and retrieval cue only; it establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. An audit local to one actual project names both the exact composite U.Work in projectWorkOccurrenceRef and the obtaining direct audit-use relation in architectureScaleAuditProjectUseRelationRef; either field alone is insufficient. BespokeResidueRegister@Project remains retrieval-only in this edition: BespokeResidueRegisterRef may cite the register episteme, but neither that reference nor the audit-use relation asserts the register's own project locality. Assert such locality only after a direct register-to-work relation is governed and cite that exact occurrence; do not borrow the audit relation. Otherwise no audit or residue-register project locality is asserted.

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 law-domain boundary
  scale-probe overturn
  assurance infeasibility
  context-specific bounded exception

Not every non-scale-amenable choice is debt. A deontic constraint, safety boundary, law-domain 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 use. 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
  describedHolonRef: the regulated deployment platform and its site-specific variants
  claimScopeRef: preference claim for 5 to 40 named regulated deployment sites inside the current qualification boundary
  selectedContextSliceRefs: the named site, jurisdiction, and qualification-window slices admitted by that claim scope
  modelUseStructureRef?: absent; no independently selected bounded-model-use structure changes this use
  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, law-domain, 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 and How to Avoid Them

#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, law-domain, 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.2.6, A.17, A.18, A.19, C.18.1, C.19.1, and C.29; uses A.1.1 only when a selected BoundedModelUseStructure changes the receiving interpretation.
• 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; C.33, C.34, and C.35 when scale-amenability material needs captured-structure adequacy, lost-structure adequacy, preservation adequacy, correspondence adequacy, or generated-carrier adequacy before candidate use; C.32.P2S when scale-amenability pressure must continue through problem-to-structure architecturing; C.32.ACS when the pressure is represented as a distinct project criteria row; C.32 when scale preference informs candidate architecture generation; A.19.CPM when it supplies one input to explicit comparison; 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.32.ACS governs criteria-set and criteria-row construction; A.19.CPM governs explicit comparison. 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-08-05 — upstream FPF commit 3dbce514 (github.com/ailev/FPF)