Jump to text
On this page
Copy and source
Published source confirmed at last check

Source changed 2026-10-14 19:58:00 UTC · snapshot created 2026-10-14 19:58:38 UTC · last check 2026-10-15 00:55:16 UTC

FPF.Reference:16.7 - Develop and use methods with distinct claims and results

These connected questions help a reader improve a way of working without treating its description, support or observed performance as the same result. The full Methods retain their individual entries; the explanation below shows why their answers can differ and when they need to be used together.

FPF.Reference:16.7.1 - Method, MethodDescription, WorkPlan, and Work remain distinct

A Method is a reusable way of doing. A MethodDescription is an episteme about one admitted Method. A candidate Method account can be improved, compared, and tested while its candidate status remains explicit. A WorkPlan is about intended Work. Admit an occurrence as Work only after establishing when it happened, who performed it, which admitted Methods they enacted, which Systems and relations it relied on, and its conditions and results.

These distinctions prevent a familiar failure: a team writes a complete playbook, schedules a trial, publishes it in a repository, and then reports that the Method exists and was enacted. Each claim needs its own basis. Tools, prompts, repositories, providers, capability, permission, authority, descriptions, support structures, and results likewise keep their own identities.

FPF.Reference:16.7.2 - Several structures and several views can coexist

A Method decision may depend on a Method composition structure, a Method unfolding, simultaneous Work, an allocation structure, a subject-and-support arrangement, a description structure, or cultural relations. These structures need not be isomorphic. Name the structure and relation that changes the decision. Do not call every connected arrangement a graph: a mathematical graph is one possible lens only after its nodes, edges, semantics, and use are selected.

Project, process, and case views can expose different claims about the same Work. A project viewpoint may expose dates, allocations, authorities, and decision slots. A process viewpoint may expose recurring input/result and coordination correspondences. A case viewpoint may expose the changing evidence, exception, and next decision. The views do not create three Work occurrences, identify three Methods, or make a WorkPlan into performed Work.

FPF.Reference:16.7.3 - Reader route and result dependencies do not prescribe Work order

A reading route through this family begins with focus and recovery because later decisions need a truthful subject. It then moves through individual qualification and architecture, description and support, and trial and change. This order helps a reader find prerequisites. It is not a lifecycle. Repertoire recovery, description, support repair, trial planning, and source refresh can overlap; a known support or evidence defect can be repaired without traversing every earlier pattern.

Use the smallest entry whose result can change the decision. Follow a dependency only when the receiving result actually consumes it. Stop early when an individual qualification, non-Method return, exact gap, or bounded repair already resolves the working difficulty.

Constituent actions in ongoing work. During a trial of a proposed review Method, asking a participant to explain a unit conversion can constitute part of testing that Method, while the trial constitutes part of developing the team’s way of reviewing. If the trial asks about unaided recognition, supplying the conversion during the attempt changes what the trial can establish. The facilitator needs both the subject knowledge and the ability to elicit performance without supplying the answer. C.32.MWA.PP’s worked case develops this connection; FPF B.1.5.EW recovers it and B.1.5.RS helps compare a substitute constituent. Preparing the trial remains earlier work, not an activity presumed to continue throughout it.

Learning to recover and change a way of working. If you know the work and want to learn how to explain and change its method, use the Reference’s practice with records, first attempts and explained answers (Engineering.Reference:16). You can save an attempt, compare it with the discussion and correct it yourself. Individual feedback requires a qualified helper and agreed time; the text supplies material for self-checking.

FPF.Reference:16.7.4 - Status, evidence, and assurance decisions are preserved

Identification, qualification, selection, trial, and effectiveness are different claims. A candidate account does not become a Method because it is coherent, selected for trial, represented well, supported by a tool, or used in Work. A successful occurrence establishes only the observations and results supported by that occurrence.

A.3.1.CC checks coherence among the claims on which a use relies. A.3.1.FT checks bounded fit or transfer. C.11.MV judges practical worth against current alternatives. The results can disagree. A Method can be coherent yet poorly fit, fit one situation yet fail transfer, or produce a useful result whose burden makes another alternative preferable.

FPF.Reference:16.7.5 - What this Method-development family foregrounds and leaves outside

This family foregrounds choosing and recovering the Method-development subject; qualifying candidates and comparing architectures; authoring and comparing descriptions and configuring enactment support; obtaining actual trial evidence and making separate judgments; maintaining variants, introducing Methods into practice and changing cultural continuation; and producing and using connected pattern-language knowledge. The last family uses source-grounded pattern-language knowledge; it does not restrict other Method-development uses to that form.

These general Methods do not contain domain Methods, operating procedures, curricula, legal or safety decisions, software tools, repository designs, statistical identification procedures, or complete organizational-change programmes. Use their direct Methods and authorities. Open a neighbouring DPF only when its specialist result is needed; the general Method-development family does not assume that a sibling edition is available merely because its discipline is named.

FPF.Reference:16.7.6 - Why these Method-development questions stay separate

A practitioner often receives a proposed Method as a package: a procedure, a diagram, a tool, a training course and a success story. The costly failure is to change the whole package without knowing which contribution is missing. This family separates the questions because their useful results and grounds differ. A truthful description may still describe an unsuitable Method; a suitable Method may have poor support; a well-supported trial may still leave practical worth unresolved.

The gain is not a complete framework traversal. It is an appropriately bounded answer that the owning practice can use: a qualified candidate, an architecture alternative, usable description content, a support correction, trial evidence or a separate change decision. The EC-417 application illustrates how these questions connect without creating a Method from a project label. Direct domain work remains outside until a Method-related question actually blocks it.

This separation is also a protection against familiar biases. Source prestige does not admit a Method, a familiar package does not define its parts, and a successful demonstration does not settle fit, causal contribution or worth. Check the subject, receiving use, relied-on conditions and first useful result before accepting a more ambitious account. If a known direct answer already settles the difficulty, stop there.

The cost is maintaining several answers and their dependencies instead of one undifferentiated success claim. Keep them separate only where a difference changes selection, action or reconsideration. C.39.MF supplies the smallest subject; A.3.1.QM, C.32.MWA.PP and B.1.5.CM supply qualification and architecture; A.3.2.DE, C.37.MP and A.15.8.MS supply description and support; A.3.1.WT, A.3.1.CC, A.3.1.FT, C.11.MV, A.3.1.MV, A.3.1.MI and C.36.MC separate evidence, judgments and maintenance. RMP.11 can explain why a professional architecture differentiated without treating that history as a justification of its present worth.

Mathematical modeling can contribute both to comparison and to construction. MMP.21 asks which consequences follow from proposed arrangements: does regrouping preserve the answer, can shared resources meet a deadline, or can an intervening operation invalidate a result? MMP.22 uses a mathematical transformation to construct a changed way of working, then returns its preserved properties and changed demands to the practical comparison. A different notation for the same way of working remains a description change.

The mathematical operations are developed in Mathematical Thinking (MATH), especially MATH.17 and MATH.18. Computational Thinking (CMP), including CMP.14, supplies constructions for interactions among computations. FPF C.29 connects a derived consequence to the work it describes. These contributions let practitioners reuse mathematical behavior while preserving the question about the actual method, its performers and conditions.