E.4.DPF:4.0.3 - Keep pattern addresses stable while publication order changes

Before public references accumulate, declare a short, stable code for the DPF and assign one local locator to each pattern. Together the DPF code and local locator form the PatternID. Within that DPF, each PatternID is unique. The code is only a short reference to that named DPF; it need not be globally unique and does not identify an edition. Settle a new durable public abbreviation through F.18. If the public DPF code later changes while the same DPF continues, preserve old references through an explicit F.13/F.18 rename or alias relation and a reader return; otherwise say where old-code use stops. Do not silently rewrite old citations. Do not assign the old code to another framework where readers may encounter both sets of citations without the full framework name.

A PatternID lets readers refer to a pattern carried forward across editions. The identifier does not prove that two bodies are the same pattern and does not define the pattern’s claims. Keep it while the recurring problem, distinguishing working move, useful result, and ordinary conditions for use, stopping, or returning still describe the same practical answer. A title, wording, Part, publication position, or authoring work package may change while that answer continues. A PlannedCatalogEntry may reserve an unused locator, but it is not yet an addressable PatternRef or evidence that a continuing pattern exists. When a complete pattern is admitted and published, its author may adopt that locator as the pattern’s PatternID. The publication may use it as a PatternRef only after the complete body exists and the continuity judgment has been made; the reservation alone establishes neither identity nor addressability.

When the practical answer no longer continues, decide the split, merge, replacement, or retirement explicitly. Keep an earlier PatternID only for the answer that continues. Give each new pattern a new unused PatternID, and never reuse a retired PatternID for unrelated content. If readers still use an old public reference, publish one maintained migration assertion. It names the earlier PatternID, any current PatternID or PatternIDs, whether the practical answer continued, split, merged, was replaced, or was retired, the uses covered, and where readers continue or stop. Add a structured E.4.PFR row only when a named maintenance use needs it; otherwise the readable assertion is enough. If no migration assertion is maintained, say where use must stop.

The local locator may use the numeric or mnemonic segments allowed by E.8. Prefer a numeric locator when it mainly needs to remain a durable address among many peers. Use a mnemonic segment only when it names an enduring distinction likely to outlast the title and publication position and materially helps recognition. A mnemonic is still an address aid, not a compressed definition. Do not restyle established PatternIDs merely to make the set look uniform.

Keep current publication order separate. The ToC and body collection use the same Parts and the same within-Part order, while a § or position field shows that order separately from PatternID. Non-ascending PatternIDs are valid. State dependencies, Method relations, use order, and replacement relations in their own claims; do not infer them from identifiers, adjacency, Parts, or authoring work packages.

To refer to a pattern, the PatternID is enough when the surrounding text identifies the DPF. Otherwise, name the framework together with the PatternID. A citation intended to select the body published in one edition also names that framework edition.