#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 action selected for the current question. 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 use the pattern for that missing claim.

#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 action selected for the current question. 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 use the pattern for that missing claim.

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 distinct and the practitioner uses the pattern for each current claim.

For the first pass, fill only the fields that prevent the next wrong move: exact problem claim or pressure, described holon, architecture question and intended use, ClaimScope or qualification window when material, first pattern to use, one unknown or selected structure slot, selected transformation-flow structure when one is actually relied on, and pattern for the next claim. Add decision, work, eval, publication, and feedback refs only when the corresponding question becomes current.

ProblemToStructureArchitecturingFlowCard@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to an individual admitted under U.Work
  architecturingFlowCardProjectUseRelationRef?: U.RelationRef whose predicate is stated in the cited architecturing-use or work-use pattern
  flowId:
  describedHolonRef:
  architectureQuestion:
  intendedArchitectureUse:
  claimScopeRef?: U.ClaimScope
  qualificationWindowRef?:
  transformationFlowStructureRef?: exact independently selected E.18 structure used by this flow
  architectingSystemRef?: U.EntityRef constrained to U.System
  architectingAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
  architectingSystemRoleAssignmentRef?: U.RelationRef constrained to U.SystemRoleAssignment, naming the obtaining occurrence when an assignment claim is current

  firstPatternLocator:
  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?: refs to independently identified U.Work occurrences when performance is current
    performedWorkAttributionRefs?: refs to obtaining F.6 performedUnderAssignment relations only when the flow or receiving use expressly represents attribution

    actualTransformationRefs?:
    workToChangeRelationRefs?: Work-to-change relations that actually obtain
    workToChangeRuleRefs?: refs to applicable rules in the cited patterns, or to local claims selected under A.6.RCD disposition 2
    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 to a relation that actually obtains and has a declared predicate
      influencePatternLocator:
    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?:
    returnOrRepairForNextQuestion:
      c32NextSynthesisExit?
      c32PadOrAdaDecisionRepairOrSupersessionExit?
      e23ImprovementCycleRef?
      g11CurrentnessRefreshRef?
      e18TransformationFlowRefreshRef?
      c18C19ArchiveFrontPoolUpdateRef?
      c30DescriptionOrViewLossRepairRef?
  patternForNextClaim:

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 point to independently established objects; they are 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. An assignment claim uses architectingAssignmentSpeciesRef and architectingSystemRoleAssignmentRef for its separately declared species and obtaining occurrence; it supplies neither classification nor performance. When performance is current, each exact performer first has its A.13 core and each performedWorkRef names Work independently admitted through A.15.1. performedWorkAttributionRefs are optional and appear only when the flow or receiving use expressly represents precise assignment-bound attribution through the same obtaining A.13 assignment; missing or failed F.6 leaves the Work refs intact. Authority, responsibility, capability, Work, assignment, attribution, and result remain separate.

actualTransformationRefs name independently identified actual changes under [A.3.4](/generated/patterns/A.3.4). The Work-to-change fields pair each relation that actually obtains with the cited pattern or local claim used to check it. 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 direct facts that actually obtain; they introduce neither an ActualStructure kind nor an actualization relation. Use C.30 to keep the 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 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.

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. When the applicable rule in another pattern fully answers the current question, use that pattern and stop there. 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 is the pattern for actual-system recognition; A.15.6 is the pattern for 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. A P2W use carries an accepted problem-side record or exact accepted C.22.2 ProblemCard episteme plus the carried distinction into the next FPF use. A C.32.P2S use carries architecture-relevant pressure and structural uncertainty into candidate structures, selected structures, project architecture decision, realization work, and actual-structure feedback. The practitioner then uses the pattern for the next question. The analogy ends when that question is method, work, telemetry, publication, or improvement-loop use; use its 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 pattern to use. If the pressure is still only a cue, use C.22.2 and cite the resulting 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, recover it under the applicable recognition or problem pattern before continuing with P2S.
2. Recover the described holon after the outside-use and boundary hypotheses are visible. State the architecture question and intended use, plus ClaimScope or qualification window when either changes the answer. 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 pattern for the receiving claim are recoverable.
5. Synthesize candidate architecture configurations and candidate sets through C.32. Keep function-bearing feasibility, ordinary work organization or actual Work, and candidate-relevant selected structures visible when they change the candidate. Such structures include constructive-module, placement, control, transformation-flow, information, evidence, and scale structures. Route every unresolved claim-bearing role cue through E.10.ROLE; carry the recovered local system-role kind, separate System-classification judgment, assignment, direct-relation position, function claim, organization or representation position, or ordinary wording rather than a generic role structure.
6. Compare, retain, declare a selected-set result, publish it, or return alternatives only under the exact predicate that defines or constrains that 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 selected-set result declaration, and C.11 for a fixed local choice. For publication, use E.17 for a source-backed face and source return and E.24.PUB for the publication occurrence and audience availability.
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 claims about 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. Name the intended architecting or realizing Systems first, then make the needed Method descriptions, constraints, readiness expectations, work expectations, and structure-use return conditions available to them under their own access or use relations. Do not call a System a holder unless a separately obtaining assignment is present; assignment does not establish classification. Keep availability or access, local kind, separate classification, assignment, readiness, permission, authority, responsibility, and plan or commitment independent. When performance is claimed, recover each exact actual performer through A.13 and let A.15.1 independently admit the U.Work. Add performedWorkAttributionRefs only when the flow or receiving use expressly represents precise assignment-bound attribution. Add a Work-to-change relation only when that direct predicate obtains. Return the exact missing governor for an unsupported direct claim.
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 dated work occurrence and A.3.4 for each independently identified actual bounded change. If work is said to cause or realize a change, name the Work-to-change relation and use the cited pattern to check the applicable rule. If no reusable relation is available, cite a local claim selected under A.6.RCD disposition 2. 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 to the independently established Work occurrences, transformations, Work-to-change relations, and local production 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 relation occurrences, applied constraints, invariants, or other facts that actually obtain. Include 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. Use the pattern for the next question to select the return or repair action from actual-structure divergence, eval results, functional implications, freshness loss, description or view loss, and new constraints.

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 patterns for decision, description, work, and feedback claims, add this local block. P2SUnfoldingStructureBlock is an architecture-facing local A.22.CGUS U.Structure specialization block defined 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: U.StructureRef resolving to the selected CGUS or local architecture-facing structure block
  problemPressureRef: U.EpistemeRef resolving to a C.22.2 ProblemCard or another architecture-pressure episteme whose claim has been checked with the cited pattern
  selectedOrUnknownStructureRefs[]:
  architectureContentLoci[]:
  structuralUncertaintyLoci[]:
  candidateSynthesisLoci[]:
  decisionLinkageRef?:
  realizationWorkLinkageRef?:
  actualTransformationRefs[]?:
  workToChangeRelationRefs[]?: Work-to-change relations that actually obtain
  workToChangeRuleRefs[]?: refs to applicable rules in the cited patterns, or to local claims selected under A.6.RCD disposition 2
  productionWorkClaimRefs[]?:
  entityIdentityInceptionClaimRefs[]?:
  productionCompletionClaimRefs[]?:
  actualStructureFeedbackRef?:
  e18TransformationFlowUnfoldingRefs[]?:
  descriptionRefs[]?:
  nextReceivingAction: next action supported by the problem-to-structure result; apply a decision, description, Work, transformation, production, or feedback pattern when its claim is current
  stopOrReturnCondition: reopen when the problem, constraints, candidate structure, or actual feedback changes
  blockedOverread?: include only when F.19's plausible-reader test justifies this exact blocked reading

The block is useful when the architecture work has to show how problem pressure constrains candidate, selected, expected, or actual structures without hiding the rule for the next claim or the pattern that contains it. unfoldingStructureRef names the selected CGUS or local architecture-facing U.Structure block. When a narrower-specialization relation is needed, name and test it under the pattern that defines its predicate; use A.6.RCD if that predicate is missing. decisionLinkageRef names the project architecture decision relation defined in [C.32.PAD](/generated/patterns/C.32.PAD) only when that decision is current. For the claims associated with descriptionRefs[], use [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 patterns only when a description, view, ADR projection, narrative rendering, or publication claim is current. realizationWorkLinkageRef points to the A.15-family work relation; use [A.3.4](/generated/patterns/A.3.4) for actual transformations. The Work-to-change fields keep the obtaining relation separate from the cited pattern or local claim used to check it. The three production-ref groups point only to separate local [A.15.PROD](/generated/patterns/A.15.PROD) claims. Establish any Work-authorization, performed-Work, or selected/expected-to-actual claim through its direct pattern. Otherwise stop with the problem-to-structure result, next receiving action, and stop or return condition.

groundedArtifactConfusion? is an alias for the same optional blockedOverread? value.

Use e18TransformationFlowUnfoldingRefs[] only for slices whose substrate is transformation-flow structure. P2S itself is broader: it can carry, for example, module, functional, placement, control, method, evidence, scale, and information structures through architecture synthesis and feedback. Any role-like source wording first resolves to the independently relevant local kind, classification judgment, assignment occurrence, direct-relation or representation position, function claim, organization position, responsibility or authority relation, or ordinary label; P2S has no generic role-structure carrier.

#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 dependent architecture-use relation record is defined here; use it with the relevant C.30 or C.32 pattern. Record any architecture decision, description, ADR projection, or realization Work through its direct pattern when that claim is current.

ArchitectureUnfoldingStructureUse@Project:
  kind: dependent architecture-use relation record under C.32.P2S, C.30, and adjacent architecture 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 use relation. 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. For decisions, descriptions, ADR-like projections, measurements, evals, evidence, gates, publication, and performed work, use the exact subject predicates and treat their patterns only as locators.

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 [A.3.1](/generated/patterns/A.3.1) for Method identity or [A.3.2](/generated/patterns/A.3.2) for MethodDescription membership, or at the A.15 family when the current question is method-work alignment, 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;
• reconsider P2S only when a later subject assertion establishes architecture pressure that changes candidate structures, expected structures, actual structures, selected structures, or the stronger-structure inspection condition.

#Archetypal Grounding

Tell. 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 throughput-after-layout-change architecture question, operating-shift qualification window, pressure kind actualStructureDivergesFromExpectedStructure, first pattern to use C.30, unknown structure material-flow bottleneck bearer, selected structure candidate buffer placement, and 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 when their questions 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 clinic service system as described holon, the turnaround-and-contamination architecture question, intended operating use, applicable scope and window, 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 develops these alternatives: a centralized autoclave bay, distributed sterilization modules, and a reusable tray-interface change. Use C.32.PAD for the decision selecting one configuration, C.30.AD and C.32.ADR for its descriptions and publication, and A.15-family patterns for construction and operating work. During operation, measure actual turnaround, contamination events, maintenance burden, and actual-structure feedback triggers.

Show B - organization and Method structures. Inspection work catches ontological errors late. The source may call the object a review practice and speak of checker roles, but P2S first restores the claim: the described holon is the review organization-as-system; if review Work is the subject instead, recover each exact performer through A.13 and identify the U.Work occurrence independently through A.15.1. Use E.10.ROLE to separate any local checker kind, classification, current assignment, direct review-relation position, function claim, organization position, and ordinary audience label. Candidate synthesis develops modal alternatives. Establish any claimed actual subject relations independently. For later actual inspection Work, add F.6 only when the flow or receiving use expressly represents precise assignment-bound attribution. Telemetry separately shows whether errors are caught earlier.

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. The team uses C.32.CONWAY within the P2S flow: 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; use C.32.PAD for the project architecture decision. 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. Where the assembly or commissioning work is asserted to cause a change, cite the work-to-change relation and its declared predicate. 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 applicability basis, work-to-change and change-to-identity facts, and inceptionBoundary; it need not assert a composite transformation. Later commissioning can remain production work until 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; use C.32.ACE to evaluate 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 assertion is next, with the relevant pattern as a locator, 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 one narrower pattern already answers the question, use it directly and do not open P2S.

The pattern improves cross-holon and adjacent-structure reuse. Practitioners may apply the same P2S method and Plain action sequence to different project-local flows in system, built-asset, product-family, organization-as-system, episteme, AI-agent-setup, discipline, and C.36-recovered cultural-evolution cases, after identifying the described holon in each case. Sharing that guidance does not give the flows one cross-holon identity or turn the examples into performed-work order. When architecture pressure concerns source wording such as roles, methods, practices, cultures, traditions, or styles, name the described holon and locality separately. Keep each recovered local kind, classification judgment, assignment, direct-relation or representation position, Method, Method relation structure, MethodDescription, Work claim, canon or memory episteme, recognition or selection regime, and mediation-system claim with the pattern for that claim.

The pattern does not guarantee adequacy. It makes the architecturing flow inspectable. For candidate quality, decision adequacy, evidence, assurance, gate passage, release, measurement validity, and G.11 currentness refresh, use the relevant 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. During realization, identify and test every actual bounded change under 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 supply candidate construction or downstream-work instructions. 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 supply 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. Descriptions and records 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 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, applicable FPF 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 and C.34 for structural-information capture and preservation, C.35 to recover the kind of a generated or discovered result and assess its adequacy for the next architecture use 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, E.17 for a source-backed publication face and source return, and E.24.PUB for the publication occurrence and audience availability.
• 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.
• Patterns for the next questions: A.19.CPM, A.19.SelectorMechanism, C.18, C.19, G.5, and C.11 for comparison, selection, archive, front, pool policy, selected-set result declaration, 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 for architecture descriptions; A.6.3.NAR for architecture-mediated narrative renderings; E.17 for source-backed publication faces and source return; E.24.PUB for publication occurrences and audience availability; A.3.1 for Method identity and A.3.2 for MethodDescription membership; A.15, A.15.1, A.15.2, and A.15.5 for method-work alignment, performed work, work plan, and readiness; A.3.4 for each actual bounded change; the pattern for the predicate, or A.6.RCD, for Work-to-change claims 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, currentness refresh, and transformation-flow slice-local refresh.
• Boundary: Use C.32.P2S for the connected project-local architecturing transformation flow from architecture-relevant pressure to subject-side actual structures recovered under A.22 from obtaining facts, and then to feedback. C.33, C.34, and C.35 deepen the structural-information slot group already present in P2S; they do not move the whole connected flow out of P2S. C.32.P2S does not define or test architecture claims, architecture descriptions, structural views, candidate palettes, comparison, selected-set result declarations, decisions, ADR-like publications, publication forms, publication-use claims, methods, Work, measurement, eval, evidence, assurance, gate, release, improvement, currentness refresh, or formal structural-information theory.

#Footer marker

Use C.32.P2S for one reader-facing problem-to-structure architecturing flow: pressure and structural uncertainty are carried into candidate, selected, and expected structures, then through domain work to independently grounded actual changes and subject-side actual structures, with descriptions, evaluations, and return or repair exits selected for the next question.

#C.32.P2S:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)