#Problem-to-Structure Architecturing Unfolding

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

Use this pattern when an architect or architecture-responsible practitioner has a stated external-use hypothesis for one project system-of-interest and must carry the resulting architecture pressure through selected structures, candidate synthesis, project architecture decision, realization Work, actual-structure feedback, and the next governed action. If the expected change outside the system, beneficiary or relying use, project designation, boundary hypothesis, or required functioning is not yet intelligible, stop before internal architecture and recover that missing basis through its direct owner.

#Relations

#Content

#Problem frame

Use this pattern when an architect or architecture-responsible practitioner has a stated external-use hypothesis for one project system-of-interest and must carry the resulting architecture pressure through selected structures, candidate synthesis, project architecture decision, realization Work, actual-structure feedback, and the next governed action. If the expected change outside the system, beneficiary or relying use, project designation, boundary hypothesis, or required functioning is not yet intelligible, stop before internal architecture and recover that missing basis through its direct owner.

The common first moment is practical: a required function has no recoverable bearer; an architecture characteristic is failing; a cross-scope residual survives local repair; a modularity, reuse, interface, scale, or description-loss problem blocks action; one typed Work, communication, tool, method, deployment, evidence, selected-structure, or architecture-side source cannot yet sustain the transformed-side architecture content needed for the changed referent; or operation shows that expected structures and actual structures diverge.

The first useful output is ProblemToStructureArchitecturingFlowCard@Project. The card is a working U.Episteme about one project-local P2S architecturing transformation flow, not the flow itself, the P2S method, a U.MethodDescription, or any planned or performed U.Work. It is not a new U kind, not an architecture claim, not an architecture decision, not a work plan, not an eval result, and not a publication format. It keeps the connected flow reviewable while each local object remains governed by the pattern that governs the current claim.

For the first pass, fill only the fields that prevent the next wrong move: described holon, bounded context, problem pressure, first governing pattern, one unknown or selected structure slot, and governing pattern for the next claim. Add decision, work, eval, publication, and feedback refs only when the flow reaches the pattern that governs them.

ProblemToStructureArchitecturingFlowCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to an individual admitted under U.Work
  architecturingFlowCardProjectUseRelationRef?: U.RelationRef governed by the exact architecturing-use or work-use pattern
  flowId:
  describedHolonRef:
  boundedContextRef:
  architectingSystemRef?: U.EntityRef constrained to U.System
  architectingRoleAssignmentRef?: U.EntityRef constrained to U.RoleAssignment, required when an architecting-role claim is current

  firstGoverningPatternRef:
  problemPressure:
    acceptedProblemCardRef?: U.EpistemeRef resolving to one exact C.22.2 ProblemCard
    actualProblematicForRelationRef?: U.RelationRef resolving to one exact C.22.PFR occurrence, only when an actual Problem is independently current

    pressureKind:
    problemPressureSignalRefs?:
    sourceUseRecordRefs?:
    architectureConcernRefs?:
    currentStopOrReturnReason?:
  architectureContent:
    architectureQuestionCardRef?: U.EpistemeRef resolving to one exact C.30 ArchitectureQuestionCard@Project
    architectureClaimRefs[]?: exact C.30 ArchitectureClaimRefs
    currentArchitectureRelationRefs[]?: exact obtaining C.30 ArchitectureRelation refs

    candidateStructureKindRefs:
    selectedStructureRefs?:
    expectedStructureRefs?:
    actualStructureRefs?:
    architectureCharacteristicRefs:
    architectureCharacteristicCriteriaSetRef?:
    qBundleRefs?:
    candidateSynthesisRef?:
  structuralInformation:
    unknownStructure:
    selectedStructure:
    expectedStructure:
    actualStructure:
    capturedInDescriptionsOrDecisions:
    handedToMethodsOrWork:
    latentOrHiddenStructure:
    lostStructure:
    strongerStructureInspectionReturnCondition:
  decisionAndWorkDocking:
    candidateSetOrPaletteRef?:
    selectedSetRef?:
    architectureDecisionRef?:
    adrProjectionRef?:
    methodDescriptionRefs?:
    workPlanRefs?:
    readinessRefs?:
    performedWorkRefs?:
    performedUnderAssignmentRelationRefs?: exact F.6 relation refs when performance attribution is current

    actualTransformationRefs?:
    directWorkToChangeGovernorRefs?:
    productionWorkClaimRefs?:
    entityIdentityInceptionClaimRefs?:
    productionCompletionClaimRefs?:
  architectureInfluenceCorrespondence?:
    changedReferentRef:
    actualTransformationRef?: U.EntityRef constrained to U.Transformation, only when independently grounded under A.3.4
    influenceSourceRows[]?: asserted influence facts only
      influenceSourceRef:
      influenceSourceKindRef:
      exactInfluenceRelationRef: U.RelationRef under its direct governor
      influenceGoverningPatternRef:
    influenceSourceArchitectureMaps[]?:
      influenceSourceHolonRef:
      influenceSourceArchitectureRelationRef?: exact obtaining C.30 ArchitectureRelation ref
      influenceSourceArchitectureClaimRef?: exact C.30 ArchitectureClaimRef for modal content
      influenceSourceSelectedStructureRefs:
    transformedHolonRef:
    transformedArchitectureRelationRef?: exact obtaining C.30 ArchitectureRelation ref
    transformedArchitectureClaimRef?: exact C.30 ArchitectureClaimRef for modal content
    transformedSelectedStructureRefs:
    correspondenceFrameOrPairRowRef: C.32.CONWAY synthesis-local frame or exact pair-row ref
  feedback:
    evalProgramRefs?:
    evalResultRefs?:
    actualStructureDescriptionRefs?:
    measurementRefs?:
    operationOrUseObservationRefs?:
    functionalCharacteristicImplications?:
    freshnessOrDecaySignalRefs?:
    governingPatternSpecificReturnOrRepair:
      c32NextSynthesisExit?
      c32PadOrAdaDecisionRepairOrSupersessionExit?
      e23ImprovementCycleRef?
      g11CurrentnessRefreshRef?
      e18TransformationFlowRefreshRef?
      c18C19ArchiveFrontPoolUpdateRef?
      c30DescriptionOrViewLossRepairRef?
  governingPatternForNextClaim:

For ProblemToStructureArchitecturingFlowCard@Project, flowId designates the exact project-local P2S architecturing transformation flow that is the card's C.2.1 EntityOfConcern. The claims carried by the filled card and the effective U.ReferenceScheme for its designations remain recoverable; changed claim content, changed flow EntityOfConcern, or changed effective reference scheme identifies another card episteme. @Project is a compatibility and retrieval cue only. It establishes no project entity, composite-work identity, context, authority, viewpoint, or parthood. When the card is genuinely used in one actual project, projectWorkOccurrenceRef identifies the exact composite Work occurrence admitted under U.Work and architecturingFlowCardProjectUseRelationRef identifies the direct relation by which architecturing work uses the card. The card, the architecturing work it helps coordinate, and the larger project work remain distinct.

The problem, architecting-side, realization, and architecture refs are pointers to independently governed objects, not P2S relation kinds. acceptedProblemCardRef resolves to one C.22.2 C.2.1 episteme; the nested signal and pressure fields neither constitute that card nor make an actual Problem obtain. actualProblematicForRelationRef is present only for an independently obtaining C.22.PFR occurrence. architectingSystemRef and any A.2.1 architectingRoleAssignmentRef remain distinct; when performance is current, performedWorkRefs and exact F.6 performedUnderAssignment refs retain the actual performer projection and assignment coverage. actualTransformationRefs resolve only to actual bounded changes independently grounded and identified under [A.3.4](/generated/patterns/A.3.4); directWorkToChangeGovernorRefs resolve to exact direct subject relations or local claims selected under [A.6.RCD](/generated/patterns/A.6.RCD) disposition 2. The three production refs resolve to separate local [A.15.PROD](/generated/patterns/A.15.PROD) claims and remain absent when their particular question is not current. actualStructureRefs name subject-side U.Structure values whose declared substrate and selected relation organization are recovered under [A.22](/generated/patterns/A.22) from directly governed facts that actually obtain; they introduce neither an ActualStructure kind nor an actualization relation. C.30 keeps the exact described holon, obtaining ArchitectureRelation occurrences, selected structures, and any affirmative, negative, unresolved, candidate, required, desired, or expected ArchitectureClaim content separate. actualStructureDescriptionRefs name later descriptions of those structures and do not make them actual.

Not this pattern when the current work is only a problem card, only a grounded architecture claim, only a structural view, only a candidate palette, only a project architecture decision, only an ADR-like publication, only work planning, only performed work, only measurement, only a mathematical lens, or only [G.11](/generated/patterns/G.11) currentness, freshness, telemetry, edition, or decay orchestration. Use the pattern named in Relations for that narrower claim.

#Problem

FPF has direct governing patterns for problem records, grounded architecture, structural views, candidate palettes, architecture characteristics, eval programs, decisions, ADR-like projections, methods, Work occurrences, separate method descriptions and work-record epistemes, measurements, mathematical lenses, improvement loops, and currentness or decay orchestration. A practitioner still needs one readable pattern for the architecture work that connects them.

Without C.32.P2S, architecture work can fail in two opposite ways.

First, the flow collapses into a description or decision artifact: a diagram, view set, ADR, memo, dashboard, score, or publication record is treated as if it carried the architecture, the decision, and the realized structure. The project then loses the distinction between selected structure, description, decision, method expectation, performed work, and actual structure.

Second, the flow starts inside the boundary or disappears into relation rows. An architect selects modules, interfaces, or an attractive configuration before stating the external change, relying use, project system-of-interest, and functioning hypothesis that would justify them; or every local pattern is correct but no readable flow carries the pressure through Work and feedback. In either branch, the user can name patterns but cannot explain why this internal structure serves the outside use.

#Forces

#Solution

Create or update one ProblemToStructureArchitecturingFlowCard@Project and apply the P2S method through only the smallest useful part of the Plain action sequence below. The numbered presentation guides attention; it is not by itself a claim about the order, identity, or occurrence of project Work or actual transformations. Stop at the first pattern that fully governs the claim; continue the P2S card only while the connected project-local P2S architecturing transformation flow remains the object being reviewed.

Before selecting internal structure, state four things in ordinary language: the expected change outside the system, the beneficiary or relying use, the actual or intended project system-of-interest and its boundary, and the functioning hypothesis by which that system could support the use. A merely intended system stays in plan or description content. A.1/A.1.SCR owns actual-system recognition; A.15.6 owns project designation; A.1.STM can locate the first unsupported long-map answer. If one of the four statements is missing or contested, return there and do not justify architecture from the inside alone.

Use the analogy with E.18.1 P2W narrowly. P2W carries an accepted problem-side record or exact accepted C.22.2 ProblemCard episteme plus the carried distinction into a next governed FPF use. C.32.P2S carries architecture-relevant pressure and structural uncertainty into candidate structures, selected structures, project architecture decision, realization work, actual-structure feedback, and governing-pattern-specific next actions. The analogy ends when the current claim is method, work, telemetry, publication, or improvement-loop governance; then use the receiving governing pattern rather than stretching P2S into generic process management.

1. Recover the problem pressure or architecture concern together with its outside-use basis. Name the expected environmental or relying-use change, beneficiary or user, project system-of-interest designation and boundary hypothesis, required functioning, pressure signals, source-use records, affected holon, and first governing pattern. If the pressure is still only a cue, use C.22.2 and cite the resulting exact ProblemCard episteme when it becomes the accepted input. If an actual Problem is claimed, cite an independently obtaining C.22.PFR ProblematicForRelation; the card and its fields create no such occurrence. If the outside-use or system basis is absent, return to its owner before P2S continues.
2. Recover the described holon and bounded context only after the outside-use and boundary hypotheses are visible. Then recover candidate or selected structure kinds, selected structures when available, and architecture characteristics. Use C.30 for the grounded architecture claim, C.32.HCS for starter characteristic heads, C.32.ACS for project criteria rows, and C.25 when a composite quality family is current.
3. Represent future-structure uncertainty. State unknown structure kinds, unknown internal composition, candidate bearers, interfaces, allocations, variation points, constraints, expected structures, and the condition that returns the work to stronger inspection of the selected or expected structure. Record what is captured, handed off, latent, hidden, or lost.
4. Generate architecture ideas, principles, constraints, and candidate structure changes. Use an admitted problem-side record, source-pack cue, architecture pressure note, or candidate-generation input only after the affected selected structure, architecture characteristic, expected gain, accepted loss, and receiving governing pattern are recoverable.
5. Synthesize candidate architecture configurations and candidate sets through C.32. Keep function-bearing feasibility, constructive modules, placement, control, transformation-flow, work, role, information, evidence, scale, and other selected structures visible when they change the candidate.
6. Compare, retain, publish, or return alternatives through the pattern that governs the set relation. Use A.19.CPM for explicit comparison, A.19.SelectorMechanism for set-returning selection, C.18 and C.19 for archive, front, and pool policy, G.5 for publication of a selected set, and C.11 for a fixed local choice.
7. Make a project architecture decision through C.32.PAD when implementation commitment is current. The decision relation names the selected architecture option, affected structures, trade-off, accepted losses, method and work consequences, accepted lost-structure return, and decision repair or supersession condition.
8. Publish descriptions, views, ADR-like records, narrative renderings, or other records only as descriptions, structure-to-narrative renderings, or publication forms of structures, decision relations, method expectations, description or view loss repair, and reader use. Use C.30.AD, C.30.ASV, C.32.ADR, A.6.3.NAR, E.17, and E.24.PUB as applicable.
9. Hand the exact architecting or realizing U.System holders the method descriptions, constraints, readiness expectations, work expectations, and structure-use return conditions needed to realize selected structures. Name an exact A.2.1 U.RoleAssignment when a role claim is current; when performance is claimed, name exact dated U.Work, the F.6 attribution, and its actual performer separately. Use A.15, A.15.2, and A.15.5 for method, work-plan, and readiness claims.
10. Realize selected structures in the transformed holon through domain work without treating the selected or expected structure, decision, method, MethodDescription, WorkPlan, model, description, evaluation result, publication, or transfer as the actual structure or as an actual transformation. Use A.15.1 for each exact dated work occurrence. Use A.3.4 for each independently identified actual bounded change, and cite the exact direct work-to-change governor or a local claim selected under A.6.RCD disposition 2 whenever exact work is asserted to cause or realize that change. Use separate local A.15.PROD claims only when production-work participation, entity-identity inception, or historically indexed production completion is current. The P2S card records refs; it performs none of the work and derives none of those claims.
11. Observe, inspect, measure, and evaluate subject-side U.Structure values whose declared substrate and selected relation organization are recovered under A.22 from directly governed facts that actually obtain, together with architecture-characteristic results and functional-characteristic or capability implications in operation or use. Ask whether those actual structures enable or block the functions and effects they were meant to bear, and ask what selected structure, accepted loss, counter-characteristic, or functional implication got worse when a visible metric improved. A description, measurement, evaluation result, publication, or resemblance to the selected structure does not itself make a structure actual or establish conformance. Use C.30 to name an obtaining ArchitectureRelation only when its exact holon, selected-structure participant, and predicate are satisfied; keep candidate, required, desired, expected, negative, or unresolved architecture content in an exact ArchitectureClaim. Use C.30.AD or C.30.ASV for actual-structure descriptions or views, C.32.ACE for eval programs and eval results, C.16 for measurement, and C.25 for Q-bundles. Use E.23 when repeated improvement method is current, G.11 when currentness, telemetry, edition, freshness, or decay orchestration is current, E.18 for transformation-flow slice-local refresh, C.18 or C.19 for archive, front, and pool updates, C.32.PAD or C.32.ADA for decision repair or supersession, C.32 for new synthesis, and C.30.AD or C.30.ASV for architecture-description or structural-view loss repair. Feed actual-structure divergence, eval results, functional implications, freshness loss, description or view loss, and new constraints into the return or repair action governed by the receiving pattern.

At the realization boundary, keep selected structure, expected structure, actual subject-side structure, exact dated work, independently identified actual transformations, local production claims, actual-structure description, and evaluation result as different objects. Shared assembly work, temporal adjacency, common affected referents, one flow, or one selected configuration establishes neither one composite transformation nor absence of finer transformation parts. If a receiving claim requires transformation composition, return the exact missing-governor blocker; do not use that blocker to stop independent work, inception, completion, actual-structure, description, evaluation, or return claims.

When architecture-influence correspondence constrains the candidate set, add the C.32.CONWAY branch before synthesis becomes narrow. Name the changed referent and any independently grounded A.3.4 transformation separately. Name every influence source by exact kind. Put only asserted influence facts with an exact obtaining direct relation in influenceSourceRows[]; otherwise keep the pressure synthesis-local in the C.32.CONWAY frame with its missing-governor, unresolved-grounding, or false-predicate disposition. For each actual architecture side, name the exact C.30 holon, obtaining ArchitectureRelation, and selected U.Structure; keep modal content in an exact ArchitectureClaim. Then frame candidate families that change the influence-source side, the transformed side, both, or declare a bounded mismatch with the named correspondence or decision-repair return condition.

#P2S Unfolding Structure Block

When the P2S card must remain reusable across decision, description, work, and feedback governing patterns, add this local block. P2SUnfoldingStructureBlock is an architecture-facing local A.22.CGUS U.Structure specialization block governed here for problem-to-structure architecturing use. That U.Structure, the project-local P2S architecturing transformation flow, the P2S method, and the flow-card episteme remain distinct. A pre-admission ProvisionalUnfoldingDemonstrationDescription or post-admission DemonstrativeUnfoldingSlice is a separate episteme whose displayed order is not the CGUS, flow, method, or Work. The block is not a root U-kind, not an architecture decision, not an ADR, not an architecture description, and not a work plan by itself.

P2SUnfoldingStructureBlock:
  unfoldingStructureRef: current architecture-facing ConstraintGovernedUnfoldingStructure record
  problemPressureRef: U.EpistemeRef resolving to an exact C.22.2 ProblemCard or another directly governed architecture-pressure episteme
  selectedOrUnknownStructureRefs[]:
  architectureContentLoci[]:
  structuralUncertaintyLoci[]:
  candidateSynthesisLoci[]:
  decisionLinkageRef?:
  realizationWorkLinkageRef?:
  actualTransformationRefs[]?:
  directWorkToChangeGovernorRefs[]?:
  productionWorkClaimRefs[]?:
  entityIdentityInceptionClaimRefs[]?:
  productionCompletionClaimRefs[]?:
  actualStructureFeedbackRef?:
  e18TransformationFlowUnfoldingRefs[]?:
  descriptionRefs[]?:
  blockedOverread: not architecture decision, not ADR, not work plan by itself

The block is useful when the architecture work has to show how problem pressure constrains candidate, selected, expected, or actual structures without hiding which pattern governs the next claim. unfoldingStructureRef names the current CGUS record or local architecture-facing structure block; an A.22-level narrower-specialization relation, when needed, remains specializedStructureRef? on the A.22.CGUS record. decisionLinkageRef points to [C.32.PAD](/generated/patterns/C.32.PAD) only when a project architecture decision is current. descriptionRefs[] point to [C.30.AD](/generated/patterns/C.30.AD), [C.30.ASV](/generated/patterns/C.30.ASV), [C.32.ADR](/generated/patterns/C.32.ADR), [A.6.3.NAR](/generated/patterns/A.6.3.NAR), or publication governing patterns only when a description, view, ADR projection, narrative rendering, or publication claim is current. realizationWorkLinkageRef points to the exact A.15-family work relation; actual transformations and direct work-to-change governors retain their [A.3.4](/generated/patterns/A.3.4), direct-subject, or [A.6.RCD](/generated/patterns/A.6.RCD) owners. The three production-ref groups point only to separate local [A.15.PROD](/generated/patterns/A.15.PROD) claims. The P2S block neither authorizes nor records performed work and does not make selected or expected structure actual.

Use e18TransformationFlowUnfoldingRefs[] only for slices whose substrate is transformation-flow structure. P2S itself is broader: it can carry module, functional, placement, control, role, method, evidence, scale, information, and other architecture-relevant structures through architecture synthesis and feedback.

#Architecture Unfolding Structure Use

Use ArchitectureUnfoldingStructureUse@Project when a named constraint-governed unfolding structure is being used as architecture-relevant structure inside problem-to-structure architecturing. This is a dependent architecture-use relation record owned here and by the relevant C.30 or C.32 architecture pattern. It is not a root U-kind, not an architecture decision, not an architecture description, not an ADR projection, and not realization work.

ArchitectureUnfoldingStructureUse@Project:
  kind: dependent architecture-use relation record under C.32.P2S, C.30, and adjacent architecture governing patterns
  projectWorkOccurrenceRef: U.EntityRef constrained to the exact composite U.Work that is an explicit participant in this use relation
  architectureQuestionCardRef?: U.EpistemeRef resolving to one exact C.30 ArchitectureQuestionCard@Project
  architectureBearingHolonRef: U.EntityRef resolving to the exact described holon
  architectureRelationRefs[]?: exact obtaining C.30 ArchitectureRelation refs
  architectureClaimRefs[]?: exact C.30 ArchitectureClaimRefs for affirmative, negative, unresolved, candidate, required, desired, or expected content
  unfoldingStructureRef:
  architectureStructureUseKind:
    transformationFlow |
    methodWork |
    control |
    narrativePublication |
    evidenceAssurance |
    referenceCurrentnessRefresh |
    otherDeclared
  architectureViewpointRef?:
  affectedSelectedStructures[]:
  architectureCharacteristicRefs[]:
  acceptedLosses[]:
  methodOrWorkLinkageRefs[]?:
  architectureDecisionRef?:
  architectureDescriptionRefs[]?:
  architectureUseReturnCondition:
  repairOrSupersessionCondition:

For ArchitectureUnfoldingStructureUse@Project, the suffix remains a compatibility and retrieval cue until an exact use is asserted. Every asserted occurrence includes projectWorkOccurrenceRef as the exact composite U.Work participant; without that Work, keep only the retrieval cue and do not assert the relation record. architectureQuestionCardRef may cite the exact C.30 triage episteme, while architectureBearingHolonRef names its independently identified subject. architectureRelationRefs[] contain only independently obtaining C.30 occurrences; modal architecture content stays in architectureClaimRefs[]. unfoldingStructureRef names the admitted CGUS or local block being used. affectedSelectedStructures[], architectureCharacteristicRefs[], and acceptedLosses[] state why the unfolding structure matters for architecture rather than for a generic route. Method and work refs point to the A.15 family only as realization or feedback linkage. Decisions, descriptions, ADR-like projections, measurements, evals, evidence, gates, publication, and performed work still exit to their direct governing patterns.

Stop conditions:

• stop at [C.22.2](/generated/patterns/C.22.2) when the signal is not yet a reviewable problem-side record;
• stop at [C.30](/generated/patterns/C.30) or [C.30.ASV](/generated/patterns/C.30.ASV) when the current need is only architecture claim or structural-view adequacy;
• stop at [C.32](/generated/patterns/C.32) when the next useful artifact is a candidate palette rather than a whole P2S carry-through record;
• stop at [C.32.PAD](/generated/patterns/C.32.PAD) when the project architecture decision is current;
• stop at the A.15 family when the current question is method, work planning, readiness, or performed work;
• stop at [C.16](/generated/patterns/C.16), [C.25](/generated/patterns/C.25), [C.29](/generated/patterns/C.29), [C.32.ACE](/generated/patterns/C.32.ACE), [E.23](/generated/patterns/E.23), or [G.11](/generated/patterns/G.11) when the current claim is measurement, quality-bundle, mathematical-lens, eval, improvement, or [G.11](/generated/patterns/G.11) currentness refresh;
• return to P2S only when a later governing pattern returns architecture pressure that changes candidate structures, expected structures, actual structures, selected structures, or the stronger-structure inspection return condition.

#Archetypal Grounding

Tell. A capable architect does not merely "document the architecture." The architect carries pressure into structure: first by finding which selected structures are missing or inadequate, then by constructing alternatives, deciding what will be pursued, enabling exact domain work, and watching which subject-side structures actually obtain under operation. An actual transformation is introduced only when its own A.3.4 basis is grounded.

First-minute use slice. A plant architect sees that expected throughput and actual throughput diverge after a layout change. The first P2S card pass names the production cell as described holon, the operating shift as bounded context, pressure kind actualStructureDivergesFromExpectedStructure, first governing pattern C.30, unknown structure material-flow bottleneck bearer, selected structure candidate buffer placement, and governing pattern for the next claim C.32. The card does not yet add a PAD decision, work plan, or eval result; those refs appear only after their governing patterns become current.

Lens-use slice. If the plant team builds a DSM or epiplexity-style lens over stations, buffers, and routing events, P2S records only the architecture use: which dependency or learnable structural content was preserved, which flow distinction was compressed away, which selected structures the lens can inform, and which lens-use return condition sends the claim back to C.29. The lens result is not architecture adequacy, an eval result, or a decision.

Show A - built asset and technical system. A clinic has rising instrument-turnaround delays and infection-control pressure. The first P2S move does not ask for a better diagram. It names the described holon, bounded context, candidate structure kinds, architecture characteristics, and uncertainty: room layout, sterile and contaminated flows, equipment modules, tray interface, maintenance work, throughput, contamination isolation, maintainability, and surge adaptability. Candidate synthesis compares a centralized autoclave bay, distributed sterilization modules, and a reusable tray-interface change. C.32.PAD decides a selected configuration, C.30.AD and C.32.ADR publish the decision and views, A.15-family records guide construction and operating work, and operation measures actual turnaround, contamination events, maintenance burden, and actual-structure feedback triggers.

Show B - organization and role/method structures. Inspection work catches ontological errors late. The source may call the object a review practice, but P2S first restores the claim: the described holon is the review organization-as-system or bounded review-work context; the adjacent governed structures include role relation structure, method relation structure, method descriptions, evidence handoffs, decision records, and live attention cues. Architecture characteristics include error containment, learnability, throughput, evidence reuse, and repair locality. Candidate synthesis compares a single checker role assignment, a split intake and ontology-checking role relation structure, and a live-beat microstep method relation structure. The project architecture decision binds those selected structures to method descriptions and readiness checks. Later inspection work and telemetry show whether errors are caught earlier or whether the selected method-side or role-side structures need repair.

Show C - architecture-influence and transformed-side co-synthesis. A team wants a modular product architecture but its toolchain, team communication, release method, and evidence workflow only support one tightly coupled build. P2S uses C.32.CONWAY: those typed influence sources and their direct relations remain separate from both exact C.30 architecture sides, the changed referent, any actual transformation, acting Systems, assignments, and Work. Candidate families include changing the product modules only, changing the influence-source structures only, changing both, or accepting a bounded mismatch while retaining a named correspondence-frame return condition. The decision states which side changes now, what architecture characteristics are protected, what Work and exact work-to-change relations realize the change, and what operation or delivery feedback can return to the C.32.CONWAY correspondence frame or to decision repair.

Show D - PumpSkid 7 realization and return. Architecture pressure calls for a modular pump-skid with selected module and placement structures; C.32.PAD governs the project architecture decision. Exact assembly work W-PS7-ASSEMBLY and later commissioning work W-PS7-COMMISSION are separate Work occurrences admitted under U.Work by A.15.1. Mounting change T-PS7-MOUNT, wiring change T-PS7-WIRE, fluid-connection change T-PS7-CONNECT, and commissioning-related change T-PS7-COMMISSION are each independently identified under A.3.4, with exact work-to-change governors where the assembly or commissioning work is asserted to cause them. Shared work, temporal adjacency, and one selected pump-skid configuration do not establish one composite transformation. The local A.15.PROD entity-identity-inception claim uses the applicable PumpSkid 7 identity-specification edition, its direct applicability basis, exact work-to-change and change-to-identity facts, and inceptionBoundary; it need not assert a composite transformation. Later commissioning can remain production work until exact subject-state facts at completionBoundary satisfy the applicable production-completion-criterion edition; only then can a separate historically indexed completion claim be written. A later C.30.AD or C.30.ASV record describes the actual structure; C.32.ACE evaluates service-access coupling. When coupling is worse than the selected expectation, the eval result returns to decision repair or new synthesis. Neither the description, evaluation, identity-inception claim, completion claim, nor shared assembly work proves conformance to the selected architecture or transformation composition.

#Bias-Annotation

Use these rows as repair cues for problem pressure, source-practice transfer, or observed signals, not as a catalogue of mistakes.

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

The project gains one replayable architecturing flow from pressure to actual-structure feedback. Practitioners can see where the work currently stands and which governing pattern governs the next claim, without treating descriptions, decisions, eval results, Work occurrences, or separate records about them as interchangeable.

The cost is disciplined record work: the card preserves structural uncertainty, candidate plurality, accepted losses, handoffs, and stronger-structure inspection return. If that cost is not justified because the question is already governed by one narrower pattern, use that pattern directly and do not open P2S.

The pattern improves cross-holon and adjacent-governed-structure reuse. Distinct project-local P2S architecturing transformation flows may use the same P2S method and Plain action sequence for admitted holons such as systems, built assets, product families, organizations-as-systems, epistemes, AI-agent setups, disciplines, and C.36-recovered cultural-evolution cases; sharing that guidance does not give those flows one cross-holon identity or turn the displayed list into performed-work order. When architecture pressure concerns roles, methods, practices, cultures, traditions, or styles, the described holon and bounded context are named separately, while role values, role relation structures, method values, method relation structures, method descriptions, work claims, canon or memory epistemes, recognition and selection regimes, and mediation-system claims stay with their direct governing patterns.

The pattern does not guarantee adequacy. It makes the architecturing flow inspectable. Candidate quality, decision adequacy, evidence, assurance, gate passage, release, measurement validity, and G.11 currentness refresh still require their governing patterns.

#Rationale

C.32.P2S belongs under C.32 because its central architecturing concern is architecture synthesis: recovering problem pressure and structural uncertainty, generating candidate selected-structure changes, preserving alternatives, making decision-ready content, and returning actual-structure feedback to the next synthesis question. This architecturing concern is not itself a U.Transformation; any actual bounded change during realization remains independently governed by A.3.4.

It cannot be only a C.22 pattern because a problem card does not carry architecture synthesis, decision, realization, and feedback. It cannot be only a C.30 pattern because grounded architecture and structural-view adequacy do not themselves construct candidate palettes or govern downstream work. It cannot be only a C.32 pattern because the palette is only one stage of the larger architecturing flow. It cannot be only C.32.PAD or C.32.ADR because decisions and records do not create the candidate space and do not realize structures. It cannot be only A.15 or E.18.1 because method and work carry-through and P2W do not govern architecture candidate synthesis or selected-structure decision content.

The P2S structural-information slots are necessary because otherwise P2S cannot explain what changes. Architecturing refines uncertainty about future structures into candidate, selected, expected, and actual structures, while descriptions, decisions, methods, Work occurrences, separate records about them, and eval reports capture only part of that content. The practitioner records which structural content is captured by descriptions, decisions, method handoffs, references to Work occurrences, separate work-record epistemes, evals, and measurements; which structure remains latent, hidden, or lost; and which stronger-structure inspection return condition returns the work to stronger structure inspection, description or view loss repair, decision repair, or a C.29 lens use such as epiplexity, DSM, graph, coarse-graining, equivalence, or morphism.

#SoTA-Echoing

These rows document transfers from source practice into C.32.P2S. Software-system sources are used as source families and examples only; they do not narrow P2S to IT architecture.

SoTA-anchor currentness boundary. Use each SoTA source-anchor row only for the exact P2S card field, P2S method or architecturing-transformation-flow step, boundary, or repair named in the row. Recheck the row when the source-practice anchor, FPF governing pattern, described holon, structure kinds, architecture characteristics, architecture-influence relation, eval mode, or project use changes.

#Relations

• Builds on: A.1 and A.1.SCR for an existing system boundary, A.15.6 for project system-of-interest designation and intended-system separation, A.1.STM when the missing outside-to-inside dependency must be located, C.22.2 for problem-side recovery, C.30, C.30.AD, and C.30.ASV for grounded architecture, architecture-description adequacy, and structural-view adequacy, C.33, C.34, and C.35 for structural-information capture, preservation, and generated or discovered carrier adequacy inside the flow, C.32 for candidate architecture synthesis, C.32.HCS, C.32.ACS, and C.32.ACE for characteristic starter heads, project criteria rows, and eval programs, C.25 for Q-bundles, C.31 family patterns for modularity, reusable structure, and scale preference, C.29 for mathematical-lens use when claimed, and E.17 and E.24.PUB for publication-face and publication-use claims.
• Uses: A.22.CGUS for the P2S unfolding-structure block when problem pressure, structure uncertainty, candidate synthesis, decision linkage, work linkage, and actual-structure feedback must remain inspectable as one constraint-governed unfolding structure; E.18.3, C.30.TFS-REL, E.18, and A.3.4 when architecture pressure concerns transformation-flow or bounded change; C.30.ILC, C.32.MLAO, and B.2 family patterns when cross-scope, interlevel, interlayer, meta-holon, emergence, or reidentification pressure changes the candidate frame; C.32.CONWAY when co-synthesis of exact influence-source and transformed-side architecture content is current; C.32.FAIL when a recognizable architecture-synthesis failure becomes a repair action.
• Receiving patterns: A.19.CPM, A.19.SelectorMechanism, C.18, C.19, G.5, and C.11 for comparison, selection, archive, front, pool policy, publication of a selected set, and local choice; C.32.PAD, C.32.ADR, and C.32.ADA for project architecture decision, ADR-like projection, and decision adequacy; C.30.AD, A.6.3.NAR, E.17, and E.24.PUB for architecture descriptions, architecture-mediated narrative renderings, publication faces, and publication-use claims; A.15, A.15.1, A.15.2, and A.15.5 for method, performed work, work plan, and readiness; A.3.4 for each actual bounded change; direct subject patterns or A.6.RCD for exact work-to-change governors and blockers; A.15.PROD for separate local production-work, entity-identity-inception, and production-completion claims; C.16, C.25, C.29, C.32.ACE, E.23, G.11, and E.18 for measurement, Q-bundle, mathematical lens, eval, improvement, G.11 currentness refresh, and E.18 transformation-flow slice-local refresh.
• Boundary: C.32.P2S governs the connected project-local P2S architecturing transformation flow from architecture-relevant pressure to subject-side actual structures recovered under A.22 from directly governed obtaining facts and to feedback. C.33, C.34, and C.35 deepen the structural-information slot group already present in P2S; they do not move that whole connected flow out of P2S. C.32.P2S does not replace any governing pattern for architecture claim, architecture description, structural view, candidate palette, comparison, selected-set publication, decision, ADR-like publication, publication form, publication-use claim, method, work, measurement, eval, evidence, assurance, gate, release, improvement, G.11 currentness refresh, or formal structural-information theory.

#Footer marker

C.32.P2S governs one reader-facing problem-to-structure architecturing flow: pressure and structural uncertainty are carried into candidate, selected, and expected structures, then through exact domain work to independently grounded actual changes and subject-side actual structures, with descriptions, evaluations, and governing-pattern-specific return or repair exits named by value.

#C.32.P2S:End

Last Updated: 2026-08-04 — upstream FPF commit 7ba40a95 (github.com/ailev/FPF)