FPF Reference

    ARCHITECTURE - Shape architecture from problem pressure

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

    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. Architecture-relevant problem pressure and competing characteristics are present, but the project needs to carry them toward candidate, selected, expected, or actual structures. Ask: which architecturing flow 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.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. Stop when the selected first card makes the receiving architecture work reviewable. Return when problem pressure, EntityOfConcern, 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 ArchitectureDescriptionUseCard@Project. Identify that card under its named Solution, then name the exact architecture U.WorkPlan, structure evaluation or decision, 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, characteristic, description edition, governor, or case fact.
    • Public coarsening. "Architecture working card" restores to one of the two exact project cards; it does not denote architecture itself.

    Last Updated: 2026-07-29 — upstream FPF commit 2ada4136 (github.com/ailev/FPF)