#Architecture Candidate Synthesis

C.32 · Cluster C.IV - Composite & Macro-Scale · Stable · Architectural 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: Architectural pattern Status: Draft Normativity: Normative unless explicitly marked informative

Use this pattern when a practitioner has a grounded ArchitectureOf@Context question and needs to synthesize several candidate architecture configurations across selected structures before comparison, archive or front-policy work, publication of a selected set, or decision.

#Keywords

• architecture candidate synthesis
• CandidateArchitecturePalette@Project
• selected structures
• architecture characteristics
• synthesis structure map
• candidate configurations
• trade-off front
• retained alternatives.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner has a grounded ArchitectureOf@Context question and needs to synthesize several candidate architecture configurations across selected structures before comparison, archive or front-policy work, publication of a selected set, or decision.

Primary working reader: an architect or architecture-responsible practitioner preparing alternatives for one described holon before comparison, selection, publication of a selected set, local choice, or project decision.

Typical entry phrases:

"The functional structure is clear, but module allocation and placement change the trade-off."
"One platform proposal improves reuse and worsens evidence or control burden."
"A search or workshop produced options; which selected structures and architecture characteristics do they change?"
"We need a candidate palette with structurally different architecture configurations before choosing one."
"The architecture of the team or tool that changes the target holon no longer fits the target architecture."

First-minute use slice. A regulated product-family team has a grounded ArchitectureOf@Context for a field device family. The work question is synthesis: how should required functions, constructive modules, field placement, control responsibility, and certification evidence be coordinated so maintainability, substitutability, latency, and evidence reuse stay acceptable? Using C.32, the practitioner first builds a synthesis structure map, then records three candidate configurations: one shared module grammar with tighter evidence scope, one product-family split with lower interface burden, and one bounded exception that keeps the existing module split but changes evidence responsibility and reopen trigger. The team now has candidate architecture configurations under declared characteristics, not one attractive platform proposal.

The primary EntityOfConcern is the local candidate architecture palette for one synthesis question over ArchitectureOf@Context. The described holon can be a system, product family, organization, method family, discipline, cultural practice, evidence-bearing practice, AI-agent setup, built asset, or another admitted holon kind when the governing FPF pattern admits that use. C.32 is not software-system architecture by default; software-system sources are one source family and one domain example.

What goes wrong if C.32 is missed: the team optimizes one visible structure, such as modules, placement, team responsibility, control relation, or evidence package, and then treats that local improvement as architecture synthesis. The competing structures, architecture characteristics, losses, and alternatives disappear before they can be compared.

What C.32 buys in practice: a practitioner can build a small set of candidate architecture configurations, each grounded in selected structure changes, architecture characteristics, known losses, and receiving patterns.

Ordinary working move: name the selected structures that really change, name the few architecture characteristics that make the trade-off real, then write two to five candidate configurations with gain, loss, preserved structure, hidden loss, and next receiving use.

Adoption test: after using C.32, another practitioner can see at least two structurally different candidate configurations, the selected-structure changes, the architecture characteristics under pressure, each gain and loss, the source-return condition, and the next receiving use.

Use C.32 only for candidate palette construction. Do not use it to ground the architecture claim, recover one structure, build characteristic criteria rows, design eval programs, handle transformer correspondence, run archive or front-policy work, publish a selected set, choose locally, or decide the project architecture.

Common exits by claim kind:

• [C.30](/generated/patterns/C.30) grounds the architecture claim; [C.30.ASV](/generated/patterns/C.30.ASV), [A.6.F](/generated/patterns/A.6.F), and [A.6.M](/generated/patterns/A.6.M) recover structural views, function wording, and module-interface relations.
• [C.32.HCS](/generated/patterns/C.32.HCS), [C.32.ACS](/generated/patterns/C.32.ACS), [C.32.ACE](/generated/patterns/C.32.ACE), [C.25](/generated/patterns/C.25), [C.31](/generated/patterns/C.31), [C.31.ASAP](/generated/patterns/C.31.ASAP), and [C.16](/generated/patterns/C.16) govern starter heads, project criteria rows, eval programs, Q-Bundles, modularity or scale-preference claims, and measurement.
• [C.32.MLAO](/generated/patterns/C.32.MLAO), [C.32.CONWAY](/generated/patterns/C.32.CONWAY), [C.32.FAIL](/generated/patterns/C.32.FAIL), and [C.29](/generated/patterns/C.29) govern residual-reducing frames, transformer-transformed correspondence, candidate repair, and mathematical-lens use.
• [A.19.CPM](/generated/patterns/A.19.CPM), [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism), [C.18](/generated/patterns/C.18), [C.19](/generated/patterns/C.19), [G.5](/generated/patterns/G.5), [C.11](/generated/patterns/C.11), and [C.32.PAD](/generated/patterns/C.32.PAD) govern comparison, selection, archive, front, publication of a selected set, local choice, and decision work.
• [C.30.AD](/generated/patterns/C.30.AD), [E.17](/generated/patterns/E.17), [E.24.PUB](/generated/patterns/E.24.PUB), [A.10](/generated/patterns/A.10), and [B.3](/generated/patterns/B.3) govern architecture-description, publication-face, evidence, and assurance claims.

The first useful output is CandidateArchitecturePalette@Project. It is the project working record for candidate-palette construction. The name does not introduce a new U.* kind, and the record does not carry selection, publication, evidence, assurance, or decision authority.

For a first pass, fill only the described holon, bounded context, synthesis question, synthesis structure map, live architecture-characteristic rows, candidate configurations, and palette stop condition. Add optional refs only when they change the next use of the palette:

CandidateArchitecturePalette@Project:
  describedHolonRef:
  boundedContextRef:
  synthesisQuestion:
  architectureSynthesisFrameRef?:
  synthesisStructureMap:
    - structureKindRef:
      selectedStructureRef?:
      contributionToSynthesis:
      constraintOrAffordance:
      governingPatternRef:
      sourceReturnCondition?:
  architectureCharacteristicCriteriaSetRef?:
  architectureCharacteristicCriteriaRowRefs:
  qBundleRefs?:
  characteristicImprovementCycleRef?:
  architectureIdealityPressureRef?:
  scaleAmenabilityPolicyRef?:
  functionBearerFeasibilityRef?:
  candidateArchitectureConfigurations:
    - candidateId:
      candidateName:
      selectedStructureChanges:
        - structureKindRef:
          selectedStructureRef?:
          changeMade:
          governingPatternRef:
      affectedArchitectureCharacteristicRefs:
      affectedCriteriaRowRefs?:
      architectureCharacteristicEvalResultRefs?:
      qBundleRefs?:
      expectedArchitectureGain:
      knownArchitectureLoss:
      constraintFit:
      preservedStructure:
      lostOrHiddenStructure:
      sourceCueRefs?:
      sourceSideReferent?:
      sourceReturnCondition:
      nextUse:
  tradeoffFrontOrArchiveRef?:
  evolutionWindowRef:
  transformerTransformedCorrespondenceRef?:
  paletteStopCondition:

#Problem

Architecture synthesis is the constructive middle of architecture work. A practitioner may already know the described holon, bounded context, some selected structures, and some concerns, but still need to configure those structures together before later comparison or decision can be honest.

The typical synthesis problem is multi-structure. Required functions or effects must be borne by candidate modules, roles, work methods, control relations, transformation-flow structures, placement structures, information structures, or evidence structures. A control relation can improve supervision while increasing timing or accountability burden; an information structure can improve maintenance access when exposed through a digital-twin view while still hiding source-return loss; a team structure can improve flow while failing to match module or deployment structure.

A functional architecture is not enough by itself. A function graph, use case decomposition, workflow, neural cell graph, method step, or cultural practice function can enter architecture synthesis only after a possible bearer is named. If no admitted module, role, method, resource, placement, control relation, or evidence structure can carry the required function under current constraints, the candidate must be repaired before it enters comparison, selection, local choice, or decision work.

The typical synthesis problem is also multi-characteristic. Architecture characteristics such as cohesion, coupling, substitutability, evidence reuse, work repeatability, latency, locality, control separation, source-return cost, and composite quality families often compete. Functional demands describe what the holon is to do; architecture characteristics describe whether the selected structures make those demands maintainable, controllable, evolvable, replaceable, inspectable, and otherwise acceptable in the current context.

One recurring candidate-generation heuristic is idealization: ask whether an existing selected structure or resource can carry an additional required function, whether a support bearer can disappear, or whether a more general scale-amenable bearer can replace several special bearers. Admit that heuristic only as a candidate. The candidate must name the functions transferred to a bearer, the bearer removed or generalized, the architecture characteristics improved and worsened, and any BLP scale window or waiver when scale advantage is claimed.

C.32 makes the constructive translation explicit. It creates a small palette whose candidates answer: which selected structures are configured together, which architecture characteristics improve or worsen, which constraints remain admissible, what source detail must remain recoverable, and which receiving pattern governs the next use.

#Forces

#Solution

Create an ArchitectureSynthesisFrame@Project when the selected structures and characteristics are not yet visible enough. The frame is a temporary visibility aid for C.32 use; the palette remains the first useful output. Then create a CandidateArchitecturePalette@Project. Treat the palette as a small constructive object over selected structures of a described holon, not as a checklist, not as a decision, and not as a published selected set under G.5.

Work in seven steps:

1. Anchor the palette to one described holon or holon family, bounded context, and synthesis question.
2. Build the smallest useful synthesis structure map. Start with the declared functional demand, constructive module or manufacture structure, and placement or deployment structure when they shape the question; add control, transformation-flow, work, role, information, evidence, scale, or other selected structures only when they change the synthesis question. For each required function, name at least one admissible bearer under the declared constraints.
3. Reference the architecture-characteristic criteria rows and any Q-Bundle slots that make the trade-off real. Separate functional demand, architecture characteristics, criteria rows, eval results, and decisions.
4. Generate candidate architecture configurations. Each candidate may change decomposition, allocation, function bearing, bearer count, placement, interface grammar, control relation, transformation-flow relation, work method, role responsibility, evidence scope, information structure, or bounded exception.
5. For each candidate, state selected structure changes, expected architecture gain, known architecture loss, constraint fit, preserved structure, lost or hidden structure, and source-return condition.
6. When a front, archive, search result, or pool-treatment policy is being used, cite C.18, C.19, or NQD and OEE support as generation or retention support only. Keep the C.32 candidate content separate from archive work, front membership, pool treatment, publication of a selected set, and local choice.
7. Stop when the palette contains the fields required by the receiving pattern for comparison, C.18 or C.19 front-policy use, publication of a selected set, local choice, decision, or repair.

The synthesis structure map is not an audit checklist. It is the small set of structures that actually changes the candidate configuration.

Architecture-characteristic improvement loop. C.32 is one turn in a continuing improvement cycle over architecture characteristics, not a one-shot search for final form. The practitioner starts with characteristic pressure or criteria rows from C.32.ACS, C.31, C.25, C.16, C.16.P, C.31.ASAP, or a local Q-Bundle; synthesizes candidate selected-structure changes; and records which criteria rows are expected to improve and which protected rows may worsen.

ArchitectureCharacteristicImprovementLoop@Project is a local feedback record for reopening C.32 synthesis when characteristic pressure changes. It is not an E.23 method, an ACE eval program, a comparison rule, a selection result, or a decision.

Keep each receiving claim with its own pattern. Criteria rows stay with C.32.ACS; Q-Bundles with C.25; scale preference with C.31.ASAP; measurement with C.16; eval programs and eval results with C.32.ACE. Improvement-question framing and repeated-improvement method stay with E.22 or E.23. Comparison, set-returning selection, selected-set publication, local choice, and project architecture decision stay with A.19.CPM, A.19.SelectorMechanism, G.5, C.11, and C.32.PAD. C.32 only consumes the changed characteristic pressure and produces the next candidate palette. Open the next synthesis question from the resulting eval result, front relation, retained alternative, rejected candidate, or source-return trigger.

An eval result that cohesion improved, evidence reuse decayed, coupling changed, latency worsened, or exception growth changed does not choose an architecture. C.32 can use it as feedback only after the bearer, criteria row, scale or qualitative reading frame, selected structures, parity frame, and receiving pattern use are recoverable.

ArchitectureCharacteristicImprovementLoop@Project:
  describedHolonRef:
  currentArchitectureCharacteristicPressureRefs:
  architectureCharacteristicCriteriaSetRef?:
  architectureCharacteristicCriteriaRowRefs?:
  synthesisQuestion:
  candidatePaletteRef:
  architectureCharacteristicEvalResultRefs?:
  changedSelectedStructureRefs:
  improvementClaimGoverningPatternRef: C.32.ACS | C.32.ACE | C.31 | C.25 | C.16 | C.16.P | C.31.ASAP | other receiving pattern
  nextSynthesisQuestion?:
  sourceReturnCondition:

Candidate architecture changes are local C.32 entries for candidate configurations. They are not FPF work occurrences, method steps, or receiving-pattern claims. A change is admissible only when the selected structure being changed is named.

Didactic mini-slices. Use these as examples of the kind of work C.32 expects, not as domain-specific templates.

When the architecture being synthesized belongs to a holon that changes another holon, use [C.32.CONWAY](/generated/patterns/C.32.CONWAY) before using Conway, mirroring, or inverse-Conway language in candidate synthesis. The practitioner names the changing relation, the transformer holon, the transformed holon, selected structures on both sides, architecture characteristics under pressure, candidate changes, expected gains, known losses, and source-return conditions.

The C.32 side keeps the candidate palette. [C.32.CONWAY](/generated/patterns/C.32.CONWAY) carries the correspondence frame. Transformation, work, transformation-flow, and module-interface claims belong to [A.3.4](/generated/patterns/A.3.4), [E.18](/generated/patterns/E.18), [A.15](/generated/patterns/A.15), C.30.TFS-REL, or [A.6.M](/generated/patterns/A.6.M) when current. Structural-similarity or preservation claims belong to [C.29](/generated/patterns/C.29) when they are current.

A richer dossier is optional. Open it only when one candidate must carry source views, relation notes, measurements, C.29 lens outputs, evidence notes, or failure repairs that affect the next architecture use. Ordinary C.32 use should remain one row per candidate configuration.

Downstream use. C.32 prepares architecture-specific candidate content. Publishing a selected set belongs to [G.5](/generated/patterns/G.5). A fixed local choice belongs to [C.11](/generated/patterns/C.11). A project architecture decision belongs to [C.32.PAD](/generated/patterns/C.32.PAD). Archive, front, pool-treatment, or generation policy belongs to [C.18](/generated/patterns/C.18) or [C.19](/generated/patterns/C.19) when that claim is being made. Architecture-description or publication-face work belongs to [C.30.AD](/generated/patterns/C.30.AD), [E.17](/generated/patterns/E.17), or [E.24.PUB](/generated/patterns/E.24.PUB).

Stop condition. Stop C.32 when the palette can support the next use without hiding the selected structures, architecture-change kind, architecture gain, architecture loss, constraint fit, source-return condition, or receiving pattern.

Lowering condition. Lower the record out of C.32 use when the needed architecture claim is not grounded, the item is only a source artifact, only one configuration is visible, the candidate lacks selected-structure change, the functional demand has no feasible bearer, the architecture gain or loss is unnamed, or the next use is already comparison, selection, publication of a selected set, local choice, decision, evidence, or assurance. Return to [C.30](/generated/patterns/C.30) for grounding, to the source or description pattern for source artifacts, to [C.32.FAIL](/generated/patterns/C.32.FAIL) for candidate repair, and to the named receiving pattern when the downstream claim is current. Reopen C.32 when a criteria row, eval result, retained alternative, front relation, source-return trigger, or source-currentness change alters the selected structures under pressure or the acceptable loss profile.

#Worked Architecture Cases

#Architecture Trade-Off Failure Modes

#Conformance Checklist

#Common Repair Cues

#Consequences

#Rationale

Architecture practice needs a pattern between a grounded architecture question and an architecture decision. C.30 can ground the architecture question over selected structures of a described holon. C.30.ASV, A.6.F, A.6.M, C.30.LCA, C.30.TFS-REL, C.25, and C.31 can recover the particular structures and characteristics. Front patterns, G.5 publication of a selected set, C.11 local choice, and decision patterns can later govern downstream set treatment and project decisions.

C.32 governs the constructive middle: building a small set of candidate architecture configurations whose selected structures, allocations, characteristic trade-offs, known losses, source-return conditions, and receiving patterns are explicit.

The same middle repeats during improvement. A later criteria-row change, scale-row change, C.16 reading, C.25 or C.31 pressure change, C.31.ASAP scale-preference change, or C.18 or C.19 front, archive, or retained-alternative relation can reopen C.32 when it changes the architecture-characteristic pressure, the selected structures under stress, or the acceptable loss profile. C.32 then synthesizes another candidate palette; it does not turn the trigger into a decision.

The nontrivial work is not to warn against every possible confusion. The work is to make synthesis real enough that architecture content is available for a later front, comparison, publication of a selected set, or decision.

#SoTA-Echoing

These rows document transfers from source practice into C.32. Each row states which C.32 field, repair row, boundary, or worked case the draft sets or revises from the source, and where a reader can inspect that source line. Software-system sources are used as lineage and domain examples only; they do not narrow C.32 to IT architecture.

Source-currentness boundary. Use each source row only for the C.32 candidate-generation move that the row transfers. If a named standard, guide, book edition, survey, or research line changes that move, recheck the row before using it again. If a receiving FPF pattern named in the row changes how it handles the source family, recheck the row before using it again. If the project needs comparison, selection, publication of a selected set, local choice, decision, evidence, or assurance, leave C.32 and open the receiving pattern. Rows named as lineage, such as TRIZ ideality, information hiding, or mature DSM lineage, stay lineage until a current source relation is recovered.

#Relations

• Builds on: C.30, C.30.P, C.30.ASV, A.22, A.6.F, A.6.M, C.32.HCS, C.32.ACS, C.32.ACE, C.25, C.31, C.31.ASAP, C.16, C.16.P, E.22, E.23, C.19.1, C.30.LCA, C.30.TFS-REL, E.18, A.3.4, A.15, and local patterns for recovering source-side architecture referents.
• Uses: C.30.ILC when a residual starts the candidate work; C.32.MLAO when residual-reducing multilevel framing is being used; C.32.CONWAY when transformer and transformed architectures must be co-synthesized; C.32.FAIL when a candidate needs repair before explicit comparison, selection, local choice, or decision; C.32.ACE when candidate eval results are needed before later comparison or selection; C.33 when a source, description, view, decision record, eval report, handoff, or realized observation captures only part of selected structure; C.34 when candidate or source structures need preservation adequacy or correspondence adequacy; C.35 when generated or discovered carriers need admission support before candidate palette use; C.29 when mathematical-lens use is being claimed.
• Receiving patterns: A.19.CPM for explicit comparison claims, A.19.SelectorMechanism for set-returning selection claims, G.5 for claims about publishing a selected set, C.18 and C.19 for archive, front, or pool-treatment policy, C.11 for fixed local choice, C.30.AD, E.17, and E.24.PUB for architecture-description or publication-face work, and C.32.PAD for project architecture decisions.
• P2S docking: C.32.P2S uses C.32 for the candidate-synthesis stages after problem pressure, selected structures, architecture characteristics, and structural uncertainty have been recovered; C.32 remains the candidate-palette owner.
• Boundary: C.32 governs candidate architecture palette construction for one grounded architecture question over selected structures of a described holon. C.35 may feed C.32 with generated or discovered carrier adequacy, but C.35 does not select candidates, publish sets, or decide the project architecture. Evidence, assurance, gate, release, work authorization, method governance, ethical mediation, and causal claims use their own patterns when those claims are being made.

#Footer marker

C.32 governs first useful architecture candidate-configuration synthesis for one grounded architecture question. Later C.18 or C.19 front-policy, publication of a selected set, local choice, architecture-description, publication-face, decision, gate, release, and authority-relation claims use their own patterns.

#C.32:End

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