FPF Reference

    ARCHITECTURE - Shape architecture from problem pressure

    Preface node heading:architecture-shape-architecture-from-problem-pressure:479

    What this page is

    This is generated FPF reference text from the specification preface or supporting sections. It helps interpret FPF; it is not FPF Reference product documentation.

    Methodology

    Use it to understand how the specification wants to be read, then return to a route, pattern, or work packet for active work. Cite generated IDs only when the wording changes the task decision.

    Content

    • Situation and question. The exact system or other architecture EntityOfConcern and the required outside effect or use are explicit. Architecture-relevant problem pressure and competing characteristics are present, but the project still needs to decide which internal structure could realize that effect and carry the decision toward candidate, selected, expected, or actual structures. Ask: which connected architecturing-flow, ordinary architecture-question, or description-use result is needed first?
    • Optional obstacle. Candidate structures, architecture characteristics, or the relation between problem pressure and structure are not yet reviewable.
    • Template A. C.32.P2S Solution -> ProblemToStructureArchitecturingFlowCard@Project. Select when the connected problem-to-structure flow is current. Local basis adds architecture-relevant pressure refs and current architecture-characteristic refs when available.
    • Template B. C.30 Solution -> ArchitectureQuestionCard@Project. Select when the described holon, architecture concern, and required outside effect or use are explicit and one small card can name the next architecture move without making a full architecture-description use current.
    • Template C. C.30.AD Solution -> ArchitectureDescriptionUseCard@Project. Select when an existing architecture description or view is already the object being used and its admissible-use boundary is current.
    • Boundaries. If the EntityOfConcern or required outside effect or use is still unclear, stop at that exact blocker and return to its recognition or problem owner before choosing internal structure. Otherwise stop when the selected first card makes the receiving architecture work reviewable. Return when problem pressure, EntityOfConcern, outside use, characteristics, description edition, or actual-structure feedback changes. Wrong-turn recovery sends a diagram-as-architecture claim to C.30 and C.33. Stronger neighbors are C.32 synthesis, C.32.PAD decision, A.15 work, E.23 improvement, or G.11 currentness according to the next claim.
    • Result test. Template A can promise only a ProblemToStructureArchitecturingFlowCard@Project; Template B only an ArchitectureQuestionCard@Project; Template C only an ArchitectureDescriptionUseCard@Project. Identify that card under its named Solution, then name the exact architecture U.WorkPlan, structure evaluation or decision, first architecture move, or architecture-description use it would answer and the relation, application binding, or supported local claim that makes it this use's result. Name later architecture work or review only when it is current; otherwise stop with the missing pressure, concern, selected structure, description edition, governor, or case fact.
    • Public coarsening. "Architecture working card" restores to one of the three exact project cards; it does not denote architecture itself.

    Last Updated: 2026-07-30 — upstream FPF commit 308edacf (github.com/ailev/FPF)