#Pattern Change, Edition Continuity, and Impact Analysis

E.15 · Stable · Part E - The FPF Constitution and Authoring Guides

#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.

Pattern type. Method pattern.

Status. Stable.

Normativity. Normative unless a passage is marked informative.

One-sentence summary. Compare one exact predecessor pattern edition with its proposed successor, describe the actual change before naming its class, repair only the uses that depend on it, and use a wider search only when a real design choice remains.

Use this pattern when an existing FPF pattern is being corrected, clarified, reorganized, refreshed from current sources, split, merged, renamed, or changed semantically, and someone needs to know what may continue and what must be reconsidered.

#Relations

#Content

#Problem Frame

Use this pattern when an existing FPF pattern is being corrected, clarified, reorganized, refreshed from current sources, split, merged, renamed, or changed semantically, and someone needs to know what may continue and what must be reconsidered.

The primary EntityOfConcern—the thing being changed—is one exact existing FPF pattern edition. The candidate is its proposed successor. The useful result is that candidate plus a bounded account of what actually changed, which uses may be affected, which predecessor ideas remain, and which checks were rerun. Put that account in the decision, review, campaign, or landing result that needs it; this pattern does not require a separate trace object.

First useful move. Put the predecessor and candidate side by side and finish this sentence in ordinary language:

A reader or user who relied on <predecessor passage> may now read, do, check, or conclude <difference>.

If the truthful answer is “nothing”, test that claim against the affected passages and stop after the smallest adequate repair and check. If the answer is uncertain because several materially different repairs remain plausible, open the alternative-comparison branch.

Not this pattern when authoring a first pattern seed with no predecessor; use E.8 and the subject-owning patterns. Do not use E.15 merely to run a wording check, make a design decision, perform a quality review, publish a pattern, or land a candidate: E.10, E.9, E.19 or E.21, E.24.PUB, and the landing process own those distinct questions. Return here when one of those activities changes an existing pattern edition and edition continuity or affected use is in question.

#Problem

Two failure modes pull pattern change in opposite directions.

• A quick patch can preserve the visible sentence while losing a predecessor idea, changing a direct consumer, or leaving an old instruction elsewhere.
• A safety-minded author can turn a small repair into a full search, scoring, evidence, and publication programme whose records cost more than the decision and still do not prove that the chosen text is better.

Labels do not solve the problem. Calling an edit “lexical”, “minor”, “refresh”, or “refactor” does not say whether practitioner entry, inputs, action, conditions, result, ontology, or assurance changed. A version number communicates an already made compatibility judgment; it does not make that judgment true.

#Forces

#Solution

#Recover the actual change

1. Name the predecessor, candidate, question, and receiving use. Use exact editions or recoverable source values. Add a ClaimScope, ReferenceScheme, model-use structure, or other qualifier only when the receiving use depends on it.
2. Read the changed passage in both wholes. Inspect enough of each pattern to recover the passage's function, not only its changed tokens.
3. Describe the actual practitioner effect. Ask separately whether the change alters recognition or entry, required inputs, the first or later action, applicability or stop conditions, returned result, normative claims, ontology, dependent uses, or assurance needed for reliance.
4. Classify only after that comparison. Use the smallest Delta-Class that matches the observed effect in §4.3. The planned label, commit subject, or amount of changed text is evidence to inspect, not the answer.

Keep wording, examples, informative rationale, normative conditions, and public naming distinct; changing one does not silently change the others. Keep ClaimScope and WorkScope distinct when both are current.

If an exact predecessor value needed for this comparison is unavailable, return that bounded continuity gap. Do not reconstruct it from a later edition, a title, or a remembered summary.

#Find the affected reach

Start with the changed claim or instruction and ask who uses it to read, act, check, decide, derive another statement, or preserve a public name. Search results and Relations entries help discover candidates, but neither proves dependence.

For every plausible consumer, decide one of three things:

• depends: its action, interpretation, condition, result, check, or public reference would change if the repaired claim changed;
• mentions only: it cites or describes the pattern but its current action remains valid;
• unresolved: the dependency cannot yet be decided from recoverable content.

Repair the exact dependent loci. Reuse an earlier result only when its conclusion and conditions remain unchanged and the changed premise lies outside its actual dependency. Reopen the smallest affected premise, consumer, example, check, or result; do not rerun an unrelated whole programme merely because an edition number changed.

An undeclared consumer can be real, and a declared dependency can be unused in the current question. Check actual and declared reach when the distinction matters.

#Classify the actual delta

These are impact classes, not mandatory version-number syntax. If a publication uses SemVer or another version policy, map the already justified compatibility decision into that policy. Do not infer the class from major, minor, or patch.

Refine, rephrase, split, merge, generalize, constrain, rename, add, and retire remain useful edit descriptions. None has a fixed Delta-Class without its actual effect. A split that preserves every use may be Δ-1; a one-word change that reverses an obligation is Δ-3.

#Choose the least costly adequate route

Direct bounded repair. Use this ordinary route when the defect and one non-dominated repair are understood. Make the repair, inspect its actual consumers, perform the selected focused checks, and stop. Do not generate dummy alternatives or a search record.

Alternative comparison. Open this branch only when at least two materially plausible designs remain, a current SoTA choice can change the action, or a repeatable search is itself useful. State what the alternatives differ on and which intended use decides among non-dominated candidates. C.18 and C.19 may generate and retain alternatives when novelty or diversity is genuinely part of the question; E.22 and E.21 frame and evaluate pattern qualities.

Keep hard constraints separate from quality comparisons. A failed identity rule, broken reference, missing required result, or unreadable first action is a defect to repair, not a low score to trade away. Compare readability, precision, assurance cost, breadth, or other qualities on their applicable scales. Select by the stated intended use and protected trade-offs; do not add heterogeneous values into an undeclared winner score.

Return a decision gap. If the repair depends on an unresolved ontology, authority, source choice, or architecture decision, return that exact gap to its pattern or decision record. More variants do not compensate for a missing governing distinction.

#Preserve the predecessor by independent probes

For a material rewrite, derive a predecessor-use inventory from the predecessor itself before relying on the author's preservation map. Include each distinct working situation, first move, input, condition, result, prohibition, example function, consequence, source-derived contribution, and consumer-facing promise that the predecessor actually carried.

Then test each probe against the candidate:

• preserved: the same practical or semantic function remains;
• changed intentionally: the successor decision names the new function and why;
• moved: an exact current locus still supplies it without making discovery worse;
• retired: an explicit decision removes it and states the affected use;
• lost or unresolved: repair it or return it before claiming continuity.

Exact copied text may close by identity. A large deletion, compression, move, or rewrite does not close through line count, author intent, or a high-level summary. The independent inventory need not become a permanent row-by-row file when the receiving workflow needs only the verified candidate and aggregate result, but the inspection itself must be complete.

#Check the candidate proportionately

Select checks from the actual change and intended conclusion. A small Δ-0 repair may need one focused check. A Δ-2 or Δ-3 change may require semantic, ontological, consumer, source, preservation, or independent quality checks. Reuse a current check result when candidate, question, conclusion, and conditions are unchanged.

After a material ontological or formal repair, read the whole changed pattern as a cold practitioner. A local token scan cannot establish precise plain language. Check that the working situation, first action, examples, conditions, and result remain understandable without reconstructing the ontology from elsewhere. Simplify the expression, not the distinction. Keep a technical term when it names a real needed object or relation; remove stacked qualifiers and formal notation when they do no action-changing work.

Author-side use of E.10, E.19, or E.21 questions is development evidence. It does not become the independent review, complete quality result, admission, or landing conclusion that a later use may require.

#Keep one useful change account

Use the receiving workflow's existing record. A compact change account normally needs only:

These answers may live in a DRR, review package, campaign result, source-use account, or landing preservation result as that workflow requires. Cite an existing E.21 or E.22 evaluation, F.15 result, source-use record, or decision instead of copying it. Do not mint a dedicated authoring trace, publish a work log with the pattern, or treat a file or publication occurrence as proof that the change was performed well.

#Edition continuity and stop rule

Keep accepted historical editions immutable and recoverable. A successor does not rewrite what an earlier edition meant. A source-edition change reopens only claims and actions that relied on the changed source value; unchanged exact inputs and unaffected premises remain reusable.

E.15 finishes when the candidate answers the change question, every actual dependent locus in scope is repaired or explicitly unresolved, material predecessor functions have dispositions, and the selected checks support the claimed Delta-Class and continuity. Publication, acceptance, registration, and landing remain separate later decisions.

Schedule a living refresh only for a high-value claim likely to change and only when someone will use the signal. Name the trigger and affected claim. Otherwise use ordinary periodic review; a generic “watch SoTA” obligation is not useful work.

#Archetypal Grounding

Tell. Change the smallest semantic unit that solves the problem, but judge continuity at the scale where a reader or consumer could actually be harmed.

#Typo with no semantic reach

An identifier is spelled correctly everywhere except one explanatory sentence. The exact identifier, instruction, and checks remain unchanged. The author repairs the sentence, verifies the identifier and nearby reference, classifies the actual change as Δ-0, and stops. Three alternative phrasings and a DRR would add no value.

#Plain-language repair after an ontology correction

A relation passage is ontologically exact but has grown into two pages of qualifications that hide the first action. The candidate restores one readable explanation and keeps the exact relation test in the assurance section. Because a substantial rewrite can lose ideas, the author independently inventories the predecessor's entry, action, conditions, examples, and prohibitions, then reads the whole candidate as a cold user. If every semantic function remains, the result may be Δ-1 or Δ-2 depending on whether a normative clarification also occurred; the word count does not decide.

#One-word semantic change with dependent consumers

A conformance rule changes may to must. The diff is one word, but admissible use and failure conditions change. The actual class is Δ-3. The author repairs examples, checklist items, and direct consumers that relied on the optional branch and rechecks their conclusions. Unrelated source and publication checks are reused.

#A source edition changes one relied-on premise

A current research edition revises a limitation used by one SoTA decision. The pattern's other sources and practitioner steps do not depend on that premise. The author reopens that one source-use decision and its receiving passage, not every source row and not the whole corpus. If the selected action changes, the affected consumers follow; if it does not, the account states why the current result remains supported.

#A real architecture choice

A pattern could model a new distinction as a local value, a direct relation, or a selected structure, and each choice changes downstream use. No single repair is yet selected. The author records the alternatives in the DRR, uses subject-specific criteria and E.21/E.22 qualities, and may use C.18/C.19 to broaden the candidate set. The comparison stops when the intended use supports one non-dominated architecture; search machinery is not retained as a universal authoring obligation.

#Bias-Annotation

Lenses tested: Gov, Arch, Onto/Epist, Prag, Did. Scope: Universal for changes to existing FPF pattern editions.

The method biases toward continuity and inspectability (Arch, Onto/Epist). The direct-repair route, record-reuse rule, whole-pattern cold-reader check, and first-adequate-result stop protect practical speed and readability (Prag, Did). Decision and review authority remain with their own patterns (Gov).

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

Benefits. Small repairs stay small. Material changes expose their real dependent reach. Historical editions remain usable. Independent predecessor probes make large rewrites safer. Alternative search remains available where it can improve a real decision, and whole-pattern plain-language checking keeps ontological precision usable.

Costs and limits. Actual dependency and predecessor-function inspection require semantic judgment; a repository search cannot automate them completely. A Δ-2 or Δ-3 repair can still be expensive when many consumers truly depend on the changed premise. This pattern reduces redundant checking but cannot make a broad semantic change local by declaration.

Reopen the method when the four Delta-Classes no longer distinguish action-relevant change, when dependency-focused verification demonstrably misses affected uses, or when a lower-effort method provides equal or better preservation and decision quality.

#Rationale

The architecture is deliberately asymmetric. The common case receives a short path because extra alternatives and records cannot improve an already understood bounded repair. The strong branch remains because architecture, ontology, and current-source decisions sometimes have several non-dominated answers.

Exact predecessor comparison and affected-reach analysis work together. The predecessor prevents history from being rewritten; actual dependency prevents an edition label from reopening everything. Independent preservation probes answer a different question from an author's change explanation: they test what the explanation may have omitted.

Delta-Class stays useful as a compact impact signal, but only after the real change is known. E.21/E.22 own pattern quality, E.9 owns content decisions, E.19 owns review, and lifecycle patterns own publication and landing. E.15 connects these results without duplicating them.

#SoTA-Echoing

The selected method combines exact edition comparison with dependency-aware incremental reverification and optional design-space search. No one source supplies the complete FPF procedure.

The non-dominated contribution is therefore not a new authoring trace or scoring system. It is the combination of a cheap direct-repair path, actual-delta classification, independent predecessor preservation, actual-consumer reach, and whole-pattern practitioner-language verification, with stronger search and checking opened only by their real use.

#Relations

Builds on:

• E.8 for first-edition authoring shape and practitioner-facing pattern structure.
• E.10, F.18, and F.19 for wording-use diagnosis, naming, and precise plain language.
• E.9 for a material content decision and E.9.DA when that decision needs adequacy review.
• F.0.1 and F.1 for exact source-local meaning and question-relative source selection.
• A.10 and B.3 when a changed claim actually depends on evidence use or assurance.

Coordinates with:

• A.10.1 for the general move from a changed source claim to bounded actual uses when cross-use discovery is needed. E.15 is the FPF-pattern-edition specialization of that move: its primary object remains one exact existing FPF pattern edition and its successor, and its Delta-Class, predecessor-function continuity, proportionate pattern checks, and candidate-plus-change-account result remain intact.
• E.19 for pattern review, E.21/E.22 for quality evaluation, and E.23 for repeated improvement.
• C.18 and C.19 for optional candidate generation and explore/exploit control when a real alternative-search branch is open.
• F.15 for applicable regression checks and F.9 only when the changed use actually relates distinct local senses.
• B.4 for later evolution-loop scheduling when a named refresh trigger is worth maintaining.
• E.24.PUB and the landing process for later publication and integration; neither follows from an E.15 result.

#E.15:End

---

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