IMPROVEMENT — Define better before repeating change
Preface node
heading:improvement-define-better-before-repeating-change:604
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: A team wants to improve something but has not agreed what better means or how the changed version will be checked.
- Question: Which evaluation question, characteristics, scales, changes, and comparison make improvement reviewable?
- First useful result or honest blocker: One evaluation question, current assessment, bounded change, before-after comparison, or exact missing use, evidence, scale, or trade-off.
- Mantra: Name the entity, current state, and use that better must serve. Frame the question before choosing metrics; select characteristics, scales, and protected trade-offs; assess the current state; compare candidate changes; make only the supported change; evaluate it on the same basis; continue, stop, or change direction from that result.
- Start with:
E.22,A.19.ECS,C.16, andE.23as their questions become current. - Stop or return: Stop at the first missing prerequisite or useful comparison. Reopen when the entity, use, evidence, or scale changes.
Last Updated: 2026-09-03 — upstream FPF commit b999972c (github.com/ailev/FPF)