#Transformer and Transformed Architecture Correspondence

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

Use this pattern when a practitioner is synthesizing an architecture for a holon that changes another holon, and the architecture of the changing holon constrains, enables, or degrades the architecture of the holon being changed.

#Keywords

• Conway correspondence
• inverse Conway maneuver
• transformer holon
• transformed holon
• changing relation
• selected-structure correspondence
• coordination cost.

#Relations

#Content

#Problem frame

Use this pattern when a practitioner is synthesizing an architecture for a holon that changes another holon, and the architecture of the changing holon constrains, enables, or degrades the architecture of the holon being changed.

Primary working reader: an architect or architecture-responsible practitioner who must co-synthesize selected structures of the changing holon and the changed holon under one changing relation.

Typical entry phrases:

"The product architecture we want cannot be built by the existing manufacturing line."
"The service boundaries we chose still require every team to coordinate every release."
"The method family changes documents, but its review roles do not match the evidence structure it must create."
"The AI-agent toolchain changes project work products, but its control and evidence boundaries do not match the transformed work-product architecture."
"We need an inverse Conway candidate alternative, not another diagram of the desired transformed-holon architecture."

First-minute use slice. A product-family team wants independently replaceable field modules. The existing manufacturing and certification organization is built around one batch line and one shared evidence responsibility. Using C.32.CONWAY, the practitioner names the two holons in the changing relation: the manufacturing and certification holon as transformer, and the product family as transformed holon. The C.32 candidate palette now includes three architecture configurations: change the manufacturing cell and evidence roles to match module variation, change the product-family module split to fit the fixed line, or keep a bounded mismatch with a clear exception cost and reopen trigger.

The primary EntityOfConcern is a local correspondence frame inside architecture candidate synthesis. The frame relates selected structures of the changing holon and selected structures of the changed holon under one changing relation. Organization-design decisions, organization-design authority relations, module-interface repair, structural-equivalence claims, and architecture decisions belong to their governing patterns when those claims are being made; C.32.CONWAY may use them only as constraints, costs, or candidate-change inputs.

What goes wrong if C.32.CONWAY is missed: the team either treats the existing organization, toolchain, manufacturing line, method family, or communication structure as if it already settled the transformed-holon architecture, or it draws a desired transformed-holon architecture that the changing holon cannot actually produce, test, maintain, evolve, or certify.

What C.32.CONWAY buys in practice: the practitioner can turn Conway pressure and inverse Conway maneuvers into candidate alternatives inside the C.32 palette. An alternative may change the transformer side, the transformed side, both sides, or a bounded mismatch; each variant names gains, losses, affected architecture characteristics, and the receiving pattern.

Ordinary working move: name the changing holon, the changed holon, the changing relation, and the selected structures on both sides; then prepare alternatives that change the transformer side, the transformed side, both sides, or keep a bounded mismatch.

Adoption test: after using C.32.CONWAY, the recorded candidate palette states whether each alternative changes the transformer side, the transformed side, both sides, or a bounded mismatch, and what gain, loss, affected characteristic, and stop condition follow.

Not this pattern when the current work is only module-interface repair, bounded-transformation identification, work or role assignment without architecture synthesis, mathematical structural similarity, local choice, or project architecture decision.

Common exits by claim kind:

• [A.6.M](/generated/patterns/A.6.M) for module-interface repair.
• [A.3.4](/generated/patterns/A.3.4) or [A.3.4.P](/generated/patterns/A.3.4.P) for bounded transformation.
• The A.15 family, [A.2](/generated/patterns/A.2), or the direct role pattern for work and responsibility.
• [C.29](/generated/patterns/C.29) and the project-selected structural-equivalence pattern for structural similarity.
• [A.19.CPM](/generated/patterns/A.19.CPM) for explicit comparison and [A.19.SelectorMechanism](/generated/patterns/A.19.SelectorMechanism) for set-returning selection.
• [G.5](/generated/patterns/G.5) for selected-set publication; [C.18](/generated/patterns/C.18) and [C.19](/generated/patterns/C.19) for archive, front, or pool-treatment policy.
• [C.11](/generated/patterns/C.11) for fixed local choice and [C.32.PAD](/generated/patterns/C.32.PAD) for project decision.

The first useful output is TransformerTransformedArchitectureCorrespondenceFrame@Project. The frame is the project working record for the correspondence question. It records candidate co-synthesis pressure; it does not make a C.29 structural-equivalence claim, organization-design decision, or new correspondence ontology:

For a first pass, fill only the bounded context, synthesis question, changing relation, transformer holon, transformed holon, the selected-structure pair that changes the candidate frame, affected architecture characteristics, candidate configurations, and next governing pattern. Add full correspondence claims, C.29 refs, detailed source-return fields, and extra structure pairs only when a receiving comparison, structural-similarity, publication, choice, or decision claim needs them.

TransformerTransformedArchitectureCorrespondenceFrame@Project:
  boundedContextRef:
  synthesisQuestion:
  changingRelationRef:
  transformerHolonRef:
  transformedHolonRef:
  transformerArchitectureRef?:
  transformedArchitectureRef?:
  transformerSelectedStructureMap:
    - structureKindRef:
      selectedStructureRef?:
      contributionToChangingRelation:
      architectureCharacteristicPressure:
      governingPatternRef:
      sourceReturnCondition?:
  transformedSelectedStructureMap:
    - structureKindRef:
      selectedStructureRef?:
      requiredArchitectureRole:
      architectureCharacteristicPressure:
      governingPatternRef:
      sourceReturnCondition?:
  correspondenceClaims:
    - correspondenceId:
      transformerStructureRef:
      transformedStructureRef:
      correspondenceUse:
      pressureDirection:
      affectedArchitectureCharacteristicRefs:
      expectedArchitectureGain:
      knownArchitectureLoss:
      preservedStructure:
      lostOrHiddenStructure:
      receivingPatternRef:
      sourceReturnCondition:
  candidateArchitectureConfigurations:
    - candidateRef:
      transformerSideChange:
      transformedSideChange:
      coordinationChange:
      expectedArchitectureGain:
      knownArchitectureLoss:
      stopOrEscalationCondition:
  c29LensOrStructuralEquivalenceRef?:
  nextGoverningPatternRef:

#Problem

Architecture synthesis often crosses a changing relation. A manufacturing system changes a product. A design organization changes a system design. A method family changes documents and work products. An AI-agent toolchain changes project work. A school changes student capabilities. A hospital triage organization changes patient-flow states. In each case, the architecture of the changing holon can make some transformed-holon architectures cheap, slow, brittle, feasible, infeasible, evolvable, or hard to certify.

Conway's law and the mirroring hypothesis make this pressure visible, but they do not replace architecture synthesis. The recurring engineering failure is that a desired transformed-holon architecture is synthesized without recovering whether the changing holon's work, communication, toolchain, manufacturing, certification, operational, or evidence structures can produce and evolve it. The result is predictable: the candidate looks architecturally clean, then independent change, deployability, testability, certification, or maintenance collapses into cross-team and cross-structure coordination work.

The inverse Conway maneuver is also an architecture candidate change, not a slogan. It means deliberately changing selected structures of the changing holon so that the desired changed-holon architecture becomes feasible and maintainable. Sometimes the stronger candidate changes the transformed-holon architecture instead. Often the honest candidate changes both and records the new burden.

C.32.CONWAY makes the correspondence explicit enough to prepare comparison inputs without collapsing the two sides.

#Forces

#Solution

Build a correspondence frame before treating Conway or inverse Conway as guidance.

Work in eight steps:

1. Name the changing relation. Use A.3.4 when one bounded transformation is being claimed, E.18 when a transformation-flow structure is being claimed, or the direct work and method patterns when the claim is work or method use.
2. Name the transformer holon and the transformed holon. Keep their architectures distinct even when they belong to one larger holon.
3. Map only the selected structures that carry the constraint or option shaping the candidate frame. On the transformer side, name the actual structure that makes one transformed-holon architecture feasible or infeasible. On the transformed side, name the actual structure that must carry the desired function or architecture characteristic. Stop at the smallest pair that can change the candidate frame or the later comparison input.
4. State only the architecture characteristics that can change the comparison. Use the local q-bundle when possible; otherwise name the few characteristics under pressure, such as independent change, substitutability, evidence reuse, latency, coupling, cohesion, coordination load, or source-return cost.
5. State the correspondence claim. Say which transformer-side selected structure constrains or enables which transformed-side selected structure, what is preserved, what is hidden or lost, and which receiving pattern governs the next claim.
6. Generate candidate architecture configurations:
   • change the transformer-side structure so the desired transformed architecture becomes feasible;
   • change the transformed-side architecture to fit a transformer constraint that is not worth changing now;
   • change both sides as one co-synthesis candidate;
   • keep a bounded mismatch with exception cost, source-return condition, and reopen trigger.
7. Use C.29 only when the correspondence is claimed as structural similarity, homomorphism-like mapping, equivalence, or formal preservation. Otherwise keep it as architecture synthesis material.
8. Stop when the C.32 candidate palette contains the fields required by A.19.CPM explicit comparison, C.32.MLAO residual reduction, C.32.FAIL repair, publication of a selected set under G.5, C.11 choice, or C.32.PAD.

Correspondence repair rows are local C.32.CONWAY entries. They do not create new FPF kinds.

Didactic mini-slices.

Stop condition. Stop when the frame names both holons, the changing relation, selected structures on both sides, architecture characteristics under pressure, candidate changes, known losses, receiving patterns, and source-return conditions.

Lowering condition. Keep a correspondence claim as C.32.CONWAY synthesis material only while the changing relation, both holons, both selected structures, affected architecture characteristics, preserved structure, lost or hidden structure, evolution window, and receiving pattern remain current. Lower the claim to diagnostic pressure when one of those values is unknown, stale, or outside the current synthesis question. Retire a candidate configuration when its transformer-side change, transformed-side change, bounded mismatch, or known loss no longer belongs to the declared evolution window. Return to A.3.4 or E.18 when the changing relation is not recovered, to work or organization-governance patterns when no transformed-holon architecture characteristic is under pressure, and to C.29 when the current claim is structural similarity, preservation, mapping, or equivalence.

#Worked Correspondence Cases

#Correspondence Failure Modes

#Conformance Checklist

#Common Repair Cues

#Consequences

#Rationale

Conway and inverse Conway are important because architecture work is not done by an abstract architect outside the world. The holon that changes another holon has its own architecture. That architecture can shape feasible candidate architectures for the changed holon.

The nontrivial work is to make both sides visible as selected structures in a candidate synthesis frame. Then the practitioner can prepare four alternatives that the next comparison, selection, choice, or decision step can actually use: change the transformer, change the transformed architecture, change both, or keep a bounded mismatch. This is architecture synthesis; similarity-based adequacy, organization-design decisions, organization-design authority relations, and publication discipline belong to their governing patterns when those claims are being made.

#SoTA-Echoing

These rows document transfers from source practice into C.32.CONWAY. Each row states which field, repair row, or boundary the draft sets or revises from the source. The source family is used as architecture practice support, not as an ontology import.

Source-currentness boundary. Use each source row only for the C.32.CONWAY field, repair row, or boundary named in that row. Recheck the row when the project's transformer structures, transformed structures, evolution window, source practice, or named receiving FPF pattern changes. If the source row no longer supports the local selected-structure correspondence, lower it to background lineage and keep the candidate frame only when the local architecture-characteristic pressure remains recoverable.

#Relations

• Builds on: C.32 for candidate architecture synthesis, A.3.4 and A.3.4.P for bounded change recovery, E.18 for transformation-flow structure, A.15 and role patterns for work and responsibility, A.6.M for module-interface relation repair, and C.30 for grounded architecture over selected structures.
• Uses: C.32.MLAO when the correspondence problem is a cross-scope or interlevel residual; C.32.FAIL when a Conway or inverse-Conway cue first appears as a repair failure; C.29 when structural similarity, preservation, homomorphism-like mapping, or equivalence 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.32.PAD for project architecture decisions, A.10 for evidence sufficiency, B.3 for assurance, A.20 or A.21 for gate or release claims when those claims are being made, and method, work, or organization-governance patterns when those claims are being made.
• P2S docking: C.32.P2S uses C.32.CONWAY when a problem-to-structure flow must co-synthesize selected structures of the transformer holon and the transformed holon under one changing relation.
• Boundary: C.32.CONWAY governs correspondence framing inside architecture candidate synthesis. It does not govern organization-redesign decisions, organization-redesign authority relations, work authorization, evidence sufficiency, assurance, gate passage, release, structural-equivalence theory, or final architecture decision.

#Footer marker

C.32.CONWAY governs architecture candidate synthesis where selected structures of a changing holon and selected structures of the changed holon must be co-synthesized under Conway, mirroring, or inverse-Conway pressure.

#C.32.CONWAY:End

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