#Structural Synthesis and Discovery Adequacy

C.35 · 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: Stable Normativity: Normative unless explicitly marked informative

Use this pattern when a generated, searched, clustered, queried, learned, transformed, simulated, or discovered structure-bearing output may seed or inform architecturing, and the practitioner must decide whether it can enter architecture work before or around C.32 candidate admission.

#Keywords

• structural synthesis
• structural discovery
• generated carrier
• produced carrier
• described structure
• candidate admission
• source return
• DSM
• NAS
• LLM.

#Relations

#Content

#Problem frame

Use this pattern when a generated, searched, clustered, queried, learned, transformed, simulated, or discovered structure-bearing output may seed or inform architecturing, and the practitioner must decide whether it can enter architecture work before or around C.32 candidate admission.

Primary working reader: an architect, architecture researcher, AI-assisted architecture worker, model-based engineer, or reviewer receiving a structure-bearing output from DSM and MDM modularization, MBSE query and view generation, graph grammar, model transformation, NAS, DSE, QD, OEE, and NQD search, LLM-assisted architecture design, code-agent mapping, simulation, benchmark trace, or source discovery.

Typical entry phrases:

"The LLM generated an architecture diagram; can it seed synthesis?"
"The DSM clustering suggests modules; is this a candidate architecture yet?"
"The MBSE query produced a view; what selected structure does it describe?"
"NAS found a Pareto point; what architecture claim can use it?"
"A graph grammar transformed the model; what preservation and bearer boundary must be checked?"

The first useful output is StructuralSynthesisDiscoveryAdequacyNote@Project:

StructuralSynthesisDiscoveryAdequacyNote@Project:
  groundedArchitectureQuestionRef:
  sourceStructureRefs:
  generationOrDiscoveryMethodRef:
  searchOrQuerySpaceRef?:
  constraintRefs:
  producedCarrierOrDescriptionRefs:
  describedStructureRefs?:
  synthesisStructureMapOrTransformationTrace?:
  preservedStructure:
  lostStructure:
  sourceLabelRecoveryRef?:
  observationAndUncertaintyRefs?:
  validationOrComparisonRefs?:
  selectedCandidateStructureRefs?:
  candidateAdmissionCondition:
  bearerOrRealizationBoundary:
  realizedHolonStructureRefs?:
  measurementOrEvalReturnRefs?:
  bearerFeasibilityQuestionRef?:
  receivingOwnerOrPatternRef:
  receivingClaimKind:
  admissibleUse:
  nonAdmissibleUse:
  sourceReturnCondition:

Adoption test: after using C.35, another practitioner can tell what was produced, which structure it describes, what it preserves and loses, what must happen before C.32 admission or realization claims, and which owner receives the next claim.

What C.35 buys in practice: the practitioner can accept useful generated or discovered material without handing it authority. The pattern lets a search output, cluster, query result, model transformation, or LLM proposal become source material for architecturing only after carrier, described structure, admission condition, and receiving owner are named.

Ordinary working move: name the produced carrier first, then the described structure, then the admission condition. If those three cannot be separated, do not let the output enter C.32 or a decision.

Not this pattern when the current question is how to search, choose, measure, decide, authorize, publish, govern a reusable generator, or run the work itself. Use the owner of that question first. Return to C.35 only when a produced carrier must be admitted or rejected before another architecture owner relies on it.

#Problem

Modern architecture work receives structure-bearing outputs from many sources: DSM clusters, MDM slices, MBSE queries, generated views, graph grammars, model transformations, LLM architecture proposals, AI-assisted ADD, code-agent relation graphs, NAS graphs, DSE traces, Pareto fronts, QD archives, benchmark traces, simulations, and source corpus mining.

These outputs can be extremely useful. They can expose candidate decompositions, relation gaps, hidden invariants, feasible search regions, trade-off points, source labels, or overlooked structure. But they are not automatically architecture, selected candidate structures, realized holon structures, eval results, evidence sufficiency, or decision authority.

C.35 handles the gap between produced carrier and architecture use. It asks what source structures and method produced the output, which described structure is recoverable, what is preserved and lost, what validation or comparison is available, what bearer or realization boundary is open, and what condition must be met before the output can feed C.32 or another owner.

#Forces

#Solution

Create one StructuralSynthesisDiscoveryAdequacyNote@Project before admitting the output into candidate synthesis, evaluation, publication, decision, or realization claims.

Read the note as an admission check between generation and architecture work. The generated output can be useful only after the record says what it carries, what it drops, and which owner can use it next.

Work in this order:

1. Name the grounded architecture question and source structure refs. If no grounded architecture question exists, return to C.30, C.32.P2S, or C.32.
2. Name the generation or discovery method and search or query space: DSM, MDM, MBSE query, graph grammar, model transformation, LLM proposal, NAS, DSE, QD archive, code-agent probe, simulation, benchmark, or source-mining method.
3. Separate produced carrier or description from described structure. The carrier may be a diagram, table, graph, query result, cluster, model file, prompt output, or benchmark trace.
4. State preserved structure, lost structure, constraints, source-label recovery, observation and uncertainty refs, validation or comparison refs, and transformation trace when present.
5. State candidate-admission condition. Route to C.32 only when the described structure can be used as a candidate configuration or candidate-generation input under selected structures, architecture characteristics, constraints, gains, losses, and source return.
6. State bearer or realization boundary. Use bearerFeasibilityQuestionRef? only when the direct owner has opened a separate software, physical, organizational, method, role, or epistemic bearer-feasibility question.
7. Route selected-set publication, archive, front, and pool policy to G.5, C.18, or C.19.
8. Route eval programs and eval results to C.32.ACE; route measurement to C.16; route mathematical-lens use to C.29; route descriptions and views to C.30.AD or C.30.ASV; route decisions and ADR projections to C.32.PAD or C.32.ADR.
9. Route reusable generator or mechanism-suite governance to E.20, G.1, G.10, G.11, or another selected owner only after that reusable-generator object has been selected as the current governed object.
10. Stop when admissible use, non-admissible use, source-return condition, receiving owner, and receiving claim kind are named.

#Archetypal Grounding

Tell: C.35 is the pattern for admitting or rejecting a produced structure-bearing carrier before another architecture owner relies on it. The carrier may be generated, searched, clustered, queried, learned, transformed, simulated, or discovered. C.35 does not search, select, decide, or realize architecture. It asks what was produced, what selected structure it describes, what is preserved and lost, what bearer boundary remains open, and what must be true before C.32 or another owner can use it.

Show - generated artifact not yet structure. An LLM produces a plausible architecture diagram for a medical device. C.35 records the prompt output as produced carrier, recovers described module, control, evidence, and placement structures where possible, records missing constraints and unknown bearers, and sets candidate admission condition "C.32 palette entry only after selected structures, characteristics, gains, losses, and source return are named." The output is not a project decision or realized architecture.

Show - DSM and MDM clustering. A DSM modularization clusters components by co-change and interface hints. C.35 records the relation matrix, clustering method, preserved dependency structure, lost functional bearer semantics, semantic-alignment risk, and source return to C.31 and C.32. The cluster can seed candidate synthesis and modularity review, but it is not architecture adequacy by itself.

Show - NAS result. A multi-objective NAS run returns a neural architecture graph and Pareto point. C.35 records search space, constraints, performance and resource criteria refs, generated carrier, described functional architecture structure, preserved dataflow, lost deployment and evidence structure, bearer boundary, and eval return. C.32 owns candidate-palette admission; C.32.ACE owns eval results.

Show - graph grammar or model transformation. A graph grammar transforms a product-line model into a candidate structure. C.35 records transformation rules, source structures, target structures, preserved interfaces, lost manufacturing constraints, and transformation trace. C.34 may check preservation; C.32 admits only after selected-structure and characteristic effects are recoverable.

#Bias-Annotation

#Conformance checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Positive consequences:

• Generated and discovered material can enter architecture work without becoming authority. The architect gets a useful admission note instead of rejecting all generated material or accepting it too early.
• C.32 remains the candidate-palette owner. C.35 supplies the carrier admission and source-return information that C.32 may need.
• Search, query, transformation, and AI-assisted outputs become auditable: source structures, search space, constraints, preserved structure, lost structure, validation refs, and bearer boundaries are visible.
• Reusable generator governance stays outside C.35 until explicitly opened, which prevents one-case output review from becoming a hidden method or mechanism-suite pattern.

Costs and trade-offs:

• C.35 adds an admission step before fast use of generated outputs. That is a real cost when teams want quick candidate expansion.
• Some outputs will be useful but not yet admissible. The repair is not to discard them; it is to name the missing selected structure, bearer boundary, validation trace, or receiving owner.
• The pattern is intentionally narrow. It does not choose among alternatives, manage archives, define eval programs, or authorize work.

#Rationale

Architecture synthesis increasingly receives outputs from search, model transformation, LLM proposal, code-agent mapping, DSM modularization, NAS, simulation, benchmark, and source discovery. Refusing those outputs would waste useful structure. Accepting them as architecture would create false authority. C.35 occupies the middle position: admission of a produced carrier for a declared architecture use.

The separation of produced carrier, described structure, selected candidate structure, bearer boundary, eval return, and decision authority is the core ontology of the pattern. Without that separation, C.35 would duplicate C.32, PAD, ADR, ACE, C.16, C.18, C.19, G.5, evidence, assurance, gate, release, method, or work owners.

The source families explain the chain. MBSE query practice and generated views show why produced descriptions can reveal and omit structure. Graph grammars and model transformations show why transformation trace and preserved structure matter. DSM and MDM work shows semantic-alignment risk between structural optimization and functional priors. Multi-objective NAS shows why Pareto fronts and generated architecture graphs need search-space, criteria, and bearer recovery. Sapunov, ToCS, and GonzoML show why agent maps and neural architecture labels need observation, uncertainty, and source-label recovery before candidate admission.

#SoTA-Echoing

C.35 rejects the popular shortcut that a generated output, Pareto point, or cluster is a candidate architecture because it looks useful. The better practice is to admit the carrier only after the described structure, losses, bearer boundary, validation trace, and receiving owner are clear.

#Relations

• Builds on: C.30, C.30.AD, C.30.ASV, A.22, C.32.P2S, and C.32.
• Uses: C.34 when generated or transformed output must preserve source structure; C.33 when capture and loss in the output are the current issue; C.29 when a formal search, graph, entropy, category, or learned representation is being used as a mathematical lens.
• Coordinates with: C.30.STRAT, C.30.TFS-REL, A.6.M, C.31, C.31.ASAP, C.32.ACS, C.32.ACE, C.16, C.25, G.5, C.18, C.19, E.18, C.32.PAD, and C.32.ADR.
• Boundary: C.35 governs generated or discovered carrier adequacy before or around C.32 candidate admission. It does not build the candidate palette, select from alternatives, govern reusable generators, define eval programs, measure values, decide projects, supply evidence or assurance, authorize work, or prove realization.

#C.35:End

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