Design-Rationale Record (DRR) Method
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-memory 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.
Type: Governance / authoring pattern Status: Stable Normativity: Normative
- one proposed normative change needs an explicit by-value account of what FPF should say, why this decision is preferred, and which neighboring patterns or selected non-pattern FPF kind-reference pairs it affects
- several patterns or selected non-pattern FPF kind-reference pairs must move together and one external decision record is needed to keep one bounded coordinated change set (one mutually dependent change set) semantically complete while enduring Core text is redistributed
- one bounded content decision question would otherwise force authors to decide the same load-bearing answer separately across several patterns or selected non-pattern FPF kind-reference pairs
- one deprecation, narrowing, or cross-pattern amendment must stay reviewable without reconstructing intent from patch history, chat memory, or scattered notes
Relations
Content
Use this when
- one proposed normative change needs an explicit by-value account of what FPF should say, why this decision is preferred, and which neighboring patterns or selected non-pattern FPF kind-reference pairs it affects
- several patterns or selected non-pattern FPF kind-reference pairs must move together and one external decision record is needed to keep one bounded coordinated change set (one mutually dependent change set) semantically complete while enduring Core text is redistributed
- one bounded content decision question would otherwise force authors to decide the same load-bearing answer separately across several patterns or selected non-pattern FPF kind-reference pairs
- one deprecation, narrowing, or cross-pattern amendment must stay reviewable without reconstructing intent from patch history, chat memory, or scattered notes
Not this pattern when. Do not use E.9 as the permanent location of normative Core law, as a campaign/process brief, or as the main vehicle for purely editorial Δ‑0/Δ‑1 cleanup that fits the lightweight variant in CC‑DRR.5.
What goes wrong if missed
- Core text changes without one explicit rationale account, so later readers cannot recover which alternatives were rejected or which exclusions were intentional
- coordinated multi-pattern amendments drift apart because the temporary selected-answer account survives only in patches, handoffs, or reviewer memory
- future repairs overfit to local wording and silently lose Pillar, taxonomy-lens, impact-graph, practical-use, or pattern-placement discipline
What this buys
- one external decision record that states the bounded FPF change by value before Core text is rewritten
- one minimum kernel that keeps Problem frame, Decision, Rationale, and Consequences recoverable for later review and replay
- one temporary convergence record for coordinated changes, while keeping enduring Core text in the selected patterns and selected non-pattern FPF kind-reference pairs rather than in the DRR
- one temporary convergence record that fixes the selected answer (the chosen content answer for the bounded content decision question) before later drafting fans out across several selected patterns or selected non-pattern FPF kind-reference pairs
First useful move. State the bounded FPF content decision question, the selected answer, the rationale for that answer, and the selected distribution across patterns or selected non-pattern FPF kind-reference pairs before drafting or landing the Core text.
Cheap stop. If the live change is ordinary local wording repair, application of an already accepted pattern, or editorial cleanup that does not change FPF semantics, obligations, boundaries, names, admissible uses, or normative force, do not open a full DRR. Use the lighter governing pattern for the local repair: E.17.AUD.LHR for one overloaded local lexical head inside one publication unit, E.10.SEMIO for one semio-heavy phrase requiring local semantic recovery, E.10 for general lexical repair, F.18 only when a durable reusable name is being minted, and E.8 for authoring-form correction. Leave E.9 for bounded content decisions that need rationale by value.
Governed object in plain terms. The governed object here is one external decision-rationale record for one bounded FPF content decision or one bounded coordinated change set. The minimal lens is simple: the record must keep the problem frame, decision, rationale, consequences, and impact/boundary account recoverable enough that accepted content can be distributed into the selected Core patterns and selected non-pattern FPF kind-reference pairs without semantic invention.
Primary working reader. The first working reader is an FPF author, reviewer, or steward who must evaluate, challenge, or land one bounded content decision. Downstream pattern readers benefit from the landed Core text; they are not the primary reader of the DRR itself.
Problem frame
FPF is engineered for Pillar P‑10 Open‑Ended Evolution: its normative rules must adapt as new calculi and insights arrive. But change without a record of why leads to conceptual erosion and undermines auditability. Hence FPF requires an explicit Design‑Rationale Record (DRR)—a durable conceptual record that precedes every normative change.
Problem
Direct edits to the Core, absent a structured rationale, trigger three systemic hazards:
- Lost provenance – future authors cannot infer the reasoning behind a rule; intent decays.
- Implicit assumptions – discarded alternatives vanish from memory, so debates resurface and churn repeats.
- Conceptual drift – incremental tweaks slip past the Eleven Pillars and Principle Taxonomy lenses, blurring the framework’s foundations.
Forces
Solution — the DRR as a structured argument and temporary convergence record
Any proposal to add, modify or deprecate a NORM, A, D, or GOV
rule MUST be accompanied by a Design‑Rationale Record. By default,
a conforming DRR contains at least four conceptual components (below);
these form the minimum decision kernel recoverable by any conforming DRR.
A lightweight editorial variant is permitted by CC‑DRR.5.
In this pattern, a bounded coordinated change set means one bounded
group of mutually dependent content decisions whose enduring FPF
expression will be distributed across several patterns or selected non-pattern FPF kind-reference pairs.
In this pattern, the selected answer means the current set of chosen
content decisions for that bounded content decision question: what FPF should say, which
selected patterns or selected non-pattern FPF kind-reference pairs carry it, what stays outside, and what support or
loss/recoverability regime applies.
In this pattern, selected non-pattern FPF kind-reference pair is a tuple-like instruction, not one new kind: when a DRR selects a non-pattern publication, view, record, or relation to carry durable content, it must name the exact FPF kind and exact reference by value, for example pattern profile, U.View, source map, support note, authoritySourceRef target, evidence-basis record, review-basis record, or architecture-basis record.
In this pattern, a temporary convergence record means one external
decision record that temporarily holds the selected answer while
the selected Core patterns and selected non-pattern FPF kind-reference pairs are still being updated.
A nontrivial DRR may therefore govern one bounded coordinated change set. In that case the DRR is the temporary convergence record for the selected answer until selected Core patterns and selected non-pattern FPF kind-reference pairs are updated; it is not a second permanent Core-law section.
Minimum decision-support content blocks
A conforming DRR must also make the following decision-support content blocks
recoverable. They may live inside the four kernel components or inside one
dedicated Basis used / decision-support block, but they are part of
substantive DRR adequacy rather than later review-only hardening.
| Content-distribution and outside-boundary map | For each load-bearing selected answer: selected patterns and selected non-pattern FPF kind-reference pairs, exact content obligations on each selected pattern or selected non-pattern FPF kind-reference pair, which nearby patterns or selected non-pattern FPF kind-reference pairs stay unamended under the current decision, and any agreement across selected patterns and selected non-pattern FPF kind-reference pairs that those selected patterns and selected non-pattern FPF kind-reference pairs must preserve. Named nearby patterns or selected non-pattern FPF kind-reference pairs must be classified now, not left as tentative most likely / may need / if later touched watch prose. | Decision. |
| Existing-pattern sufficiency and new-pattern necessity | For each load-bearing selected answer, whether one already-existing pattern is sufficient, one already-existing selected non-pattern FPF kind-reference pair is sufficient, or one newly selected pattern or selected non-pattern FPF kind-reference pair is necessary, and why rejected options would misplace, overload, or falsely split the pattern or selected non-pattern FPF kind-reference pair that governs the selected answer. | Decision and Rationale. |
| Naming, ontology, and wrong-carrier-confusion account | Head/branch/object/move/outside-work separation, tempting wrong-pattern assignment or wrong non-pattern FPF kind-reference assignment, and any load-bearing F.18 naming obligation needed to keep the selected answer truthful by value. | Problem frame, Decision, and Rationale. |
| Reusable-support disposition when triggered | Whether a potentially reusable selected non-pattern FPF kind-reference pair remains local, is generalized now, is rejected, or is placed outside the current decision with named pattern, selected non-pattern FPF kind-reference pair, or decision record. | Decision and Rationale. |
| Loss and recoverability template when source-loss or scope narrowing is declared | Preserved distinctions, dropped distinctions, admissible use, non-admissible downstream use, recoverability class, and reopen/exit rule. | Decision and Consequences. |
| Selected carrier and neighbor-boundary account | Why the selected patterns and selected non-pattern FPF kind-reference pairs carry the content, which tempting patterns or selected non-pattern FPF kind-reference pairs stay outside, and which neighboring pattern assignments remain authoritative. | Decision and Rationale. |
| Convergence and overlap account when several content-decision branches touch the same carrier set | Whether overlap is valid convergence or one reopened architecture smell, what agreement across selected patterns and selected non-pattern FPF kind-reference pairs must hold, and whether a new pattern or selected non-pattern FPF kind-reference pair is actually selected or refused now. | Decision and Consequences. |
| Selected-answer stability boundary | Which elements of the selected answer are fixed now for later FPF drafting, and which later elaborations may strengthen wording, examples, or support without reopening the selected answer. | Decision and Consequences. |
| Impact, practical gains, and remaining validation evidence obligation | Affected patterns and selected non-pattern FPF kind-reference pairs, practical gains/costs, authority or release consequences when they follow from the content decision, and the remaining validation evidence obligation that still constrains later authoring or landing. | Consequences. |
| SoTA and competitive-positioning account when load-bearing | Current anchors that discipline the decision, what problem-owning domain or practice they answer to, and what unresolved uncertainty would materially change the selected answer. | Problem frame, Rationale, and Consequences. |
These decision-support content blocks are not separate process paperwork. A DRR that keeps only the four labels while leaving basis, first-minute use question, naming, selected content distribution, pattern or selected non-pattern FPF kind-reference pair sufficiency or necessity, overlap handling, impact, or live uncertainty implicit is structurally labeled but still substantively immature.
Together these decision-support content blocks let the DRR act as one decision record for one bounded coordinated change set: enough semantic closure that later drafting distributes the selected answer into selected patterns and selected non-pattern FPF kind-reference pairs rather than inventing it for the first time pattern by pattern.
When one bounded decision coordinates several patterns or selected non-pattern FPF kind-reference pairs, or one cluster of mutually dependent pattern edits and selected non-pattern FPF kind-reference pair edits, the DRR MAY carry additional substantive sections beyond that minimum kernel. Typical substantive additions include obligations on selected patterns and selected non-pattern FPF kind-reference pairs, one explicit new-pattern vs existing-pattern decision, one impact or non-goal map across selected patterns and selected non-pattern FPF kind-reference pairs, coverage or agreement maps across selected patterns and selected non-pattern FPF kind-reference pairs, convergence classification, and one provisional decision-law account by value that keeps the bounded change account semantically complete until enduring Core text is distributed.
Such additions do not change the DRR’s kind. A DRR carrying them remains conforming only when it stays about the FPF content decision: what FPF should say, why, what is excluded, how selected patterns and selected non-pattern FPF kind-reference pairs are affected, and what practical use or authoring action improves. A DRR carrying richer convergence content MUST NOT become a campaign plan, process script, baton carrier, packet checklist, staging log, or other development-process brief.
When one selected answer could plausibly fit one already-existing pattern or selected non-pattern FPF kind-reference pair or require one newly proposed pattern or selected non-pattern FPF kind-reference pair, the DRR must decide that sufficiency/necessity question by value. It is not enough to list a tentative carrier list or leave downstream drafting to discover the selected pattern or selected non-pattern FPF kind-reference pair later.
When the accepted basis or the DRR itself already names one pattern or
selected non-pattern FPF kind-reference pair as part of the live distribution question, that
pattern or selected non-pattern FPF kind-reference pair is not a neutral future watch item. The DRR
must classify it now either as one selected pattern or selected non-pattern FPF kind-reference pair
with explicit obligation, one explicit boundary neighbor kept unchanged,
one inherited-unchanged neighbor, or one outside-current-decision item
with named pattern, selected non-pattern FPF kind-reference pair, or decision record. Conditional or
time-relative pattern prose or prose for one selected non-pattern FPF kind-reference pair such as most likely, may need local hardening, if later touched, watch later, or one equivalent
placeholder is non-conforming there because it marks one unmade current
decision rather than one explicit current disposition.
When one accepted basis exposes one potentially reusable selected non-pattern FPF kind-reference pair or neighboring support mechanism, the DRR must not merely note that such support already exists. It must decide whether that support is generalized now, kept local with a substantive reason, rejected, or marked outside the current decision with a named pattern, selected non-pattern FPF kind-reference pair, or decision record.
When one selected answer involves source-loss mode, simplification, redaction, summarization, or other declared loss, the DRR must make the admissible-use template explicit by value. Explanation alone is not enough; the decision must say what remains preserved, what is dropped, which branch reading is admissible and which selected non-pattern FPF kind-reference pair carries it, which uses are unsupported, what recoverability class applies, and what reopen or exit rule governs cases that exceed the declared source-loss or scope-narrowing posture.
A nontrivial DRR is mature enough for downstream authoring only when materially live selected-answer branch choices about the governed object, selected patterns and selected non-pattern FPF kind-reference pairs, outside-current-decision boundary, reusable-support disposition, and loss/recoverability regime have already been selected, rejected, inherited unchanged, or placed outside the current decision with a named pattern, selected non-pattern FPF kind-reference pair, or decision record. If those choices are still missing, the DRR is still basis work rather than one accepted design-rationale record.
The DRR lives outside the normative Core. An accepted DRR SHALL be landed by applying its Decision account and any stabilized enduring content to the relevant pattern or selected non-pattern Core kind-reference pair as explicit normative or informative text (the change is "in the Core"; the DRR is not). A richer DRR MAY remain the temporary convergence record while redistribution into selected Core patterns and selected non-pattern FPF kind-reference pairs is still incomplete, but it SHALL NOT remain the permanent sole semantic carrier once landed Core text exists.
Authors drafting from an accepted DRR MAY elaborate examples, SoTA‑Echoing, recognition surfaces, local wording inside the selected patterns and selected non-pattern FPF kind-reference pairs, and neighboring fit. They SHALL NOT silently revise the selected answer, selected patterns and selected non-pattern FPF kind-reference pairs, outside-current-decision boundary, reusable-support disposition, or declared loss/recoverability regime. Any such revision SHALL be handled through one successor DRR or other named successor decision record.
To preserve P‑2 Didactic Primacy without duplicating meta‑text, authors landing an accepted DRR SHOULD distill stable and reusable parts of its Rationale, Consequences, and other valid convergence sections into the appropriate informative sections of the affected pattern(s) (Rationale, Consequences, SoTA‑Echoing, Archetypal Grounding; per the Pattern Template, E.8). The full DRR remains external as provenance.
A substantive DRR is one current content decision object. It may carry selected content obligations only when they are part of the Decision or Consequences. It MUST NOT carry next-gate posture, handoff/packet state, process-order state, monolith status, future campaign planning, or one hidden promise that the same current content decision question will be decided later inside the same decision object. Any undecided remainder must be marked outside the current decision with a named pattern, selected non-pattern FPF kind-reference pair, or decision record.
Process-source method admission into FPF
When a DRR imports stable method from process-source document-carried method description into FPF, it must decide the admission by value rather than treating process prose as a second canon.
The DRR names:
- the exact process-source passage or accepted process-source basis being considered;
- the reusable FPF method recovered from that passage;
- the current FPF pattern, section, or accepted
DRRthat already carries the method, if any; - the remaining delta that current FPF does not yet carry;
- the receiving FPF pattern selected to carry that delta;
- process-control material excluded from FPF pattern prose, such as role dispatch, seam state, helper behavior, Git recovery, packet transport, review transport, chat cadence, and mutable release posture;
- the source-use result for that passage or basis: exact quote, narrowed scope, instantiated case, decision-bearing use, draft-guidance source, example-only use, or retired source use;
- any meaning loss or addition created by that source-use result: changed scope, relation, evidence basis, admissible use, non-admissible use, reader move, or recoverability condition;
- the first improved FPF use that the admitted method gives to an author, reviewer, or downstream FPF user;
- the current disposition: selected now, inherited sufficient, rejected now, or outside the current decision with the named receiving pattern, accepted
DRR, or accepted basis named by value.
Reusable process-source method is not limited to semio wording or pattern-authoring language. It may enter FPF only when it is separable from local process mechanics, improves FPF use, and has one exact receiving pattern. After the method lands in FPF, process documents should cite the receiving FPF pattern instead of keeping a parallel long-form rule.
Archetypal Grounding (System / Episteme)
Bias-Annotation
Scope: this bias annotation is universal for FPF semantic changes governed by E.9. It does not turn project-management state, helper state, or review logistics into DRR content.
Conformance Checklist
| CC‑DRR.1f (reusable-support disposition when triggered) | When accepted basis exposes a potentially reusable selected non-pattern FPF kind-reference pair or neighboring support mechanism, the DRR MUST decide whether it is generalized now, kept local with reason, rejected, or placed outside the current decision with named pattern, selected non-pattern FPF kind-reference pair, or decision record. | Prevents unexamined inheritance of local support publications, records, views, or relations. |
| CC‑DRR.1g (source-loss and recoverability template when triggered) | If the decision declares a source-loss mode, simplification, redaction, summarization, or other source-to-rendering loss, the DRR MUST make explicit the preserved distinctions, dropped distinctions, admissible uses, non-admissible downstream uses, recoverability class, and reopen or exit rule. | Prevents rhetorical smoothing from masquerading as stable content. |
| CC‑DRR.1h (naming and ontology adequacy) | A conforming DRR MUST make the selected head/branch/object/move/outside-work separation recoverable by value and MUST expose any tempting wrong-pattern assignment or wrong non-pattern FPF kind-reference assignment or load-bearing F.18 naming obligation that materially affects the decision. | Prevents semantically important naming and typing choices from being rediscovered later during pattern drafting. |
| CC‑DRR.1i (existing-pattern sufficiency or new-pattern necessity is explicit) | When a load-bearing selected answer could plausibly live in one already-existing pattern, one already-existing selected non-pattern FPF kind-reference pair, or one newly proposed pattern or selected non-pattern FPF kind-reference pair, the DRR MUST make that sufficiency/necessity judgement by value and MUST explain why rejected options would misplace, overload, or falsely split the pattern or selected non-pattern FPF kind-reference pair that governs the selected answer. | Prevents carrier selection from being rediscovered during downstream drafting. |
| CC‑DRR.1j (selected-answer stability boundary is explicit) | The Decision or Consequences MUST make clear which elements of the selected answer are fixed now for later FPF drafting and which later elaborations may strengthen wording, examples, or support without reopening the selected answer. | Prevents later drafting from silently widening or re-deciding the accepted answer. |
| CC‑DRR.1k (source-use result is explicit). | When a DRR imports a source-borne method, architecture claim, accepted basis, or other reusable source passage, it MUST state how the source is used in the selected answer: exact quote, narrowed scope, instantiated case, decision-bearing use, draft-guidance source, example-only use, or retired source use. It MUST also state any meaning loss or addition in scope, relation, evidence basis, admissible use, non-admissible use, reader move, or recoverability condition. | Blocks free paraphrase and makes source movement reviewable without turning source documents into a second canon. |
| CC‑DRR.2 | A conforming DRR MUST include a rationale account that compares the materially live alternatives and assesses the selected proposal against all Eleven Pillars and the five Principle‑Taxonomy lenses (Gov, Arch, Onto/Epist, Prag, Did). | Keeps evolution aligned, comparative, and cross‑disciplinary. |
| CC‑DRR.3 | The DRR SHALL list every pattern, selected non-pattern FPF kind-reference pair, or neighboring pattern or selected non-pattern FPF kind-reference pair that it supersedes, amends, excludes from the current decision, assigns to a neighboring pattern or selected non-pattern FPF kind-reference pair, or risks impacting, together with any agreement across selected patterns and selected non-pattern FPF kind-reference pairs the selected patterns and selected non-pattern FPF kind-reference pairs must preserve. It MUST also make clear why the selected patterns and selected non-pattern FPF kind-reference pairs carry the content, which tempting patterns or selected non-pattern FPF kind-reference pairs stay outside, and, when several content-decision branches touch the same carrier set, whether that overlap is valid convergence or one reopened architecture smell. | Maintains an explicit impact/boundary graph for coordinated changes. |
| CC‑DRR.3a (practical and validation consequences are explicit) | The Consequences account MUST expose the practical change in use, practical gains/costs, affected patterns and selected non-pattern FPF kind-reference pairs, and any remaining content-scope validation evidence obligation or authority/release consequence that still constrains the selected decision by value. | Prevents consequences from collapsing into generic optimism or process-order prose. |
| CC‑DRR.3b (SoTA shapes the decision when load-bearing) | When SoTA or competitive positioning is load-bearing, the DRR MUST make the current SoTA basis and any uncertainty that would materially change the decision recoverable by value. A literature overview that does not shape the selected answer, boundary, or validation evidence obligation is non-conforming. | Keeps SoTA from becoming decorative appendix material. |
| CC‑DRR.4 | An accepted DRR SHALL have its Decision account landed in the Core as the normative change. When that DRR temporarily carries richer convergence content, authors landing it SHOULD distribute any part that stabilizes into enduring FPF content into the relevant Core patterns and selected non-pattern FPF kind-reference pairs. Authors MAY distill other DRR sections into informative pattern sections (Rationale/Consequences/SoTA‑Echoing/Grounding), but they SHALL NOT introduce new normative constraints except via explicit NORM/A/D/GOV text. | Preserves Core authority while allowing a richer temporary convergence record. |
| CC‑DRR.4a (separate-law content proliferation is blocked) | If the DRR needs compact law/check content, it SHOULD keep that content as one decision-law section or as obligations on selected existing amendment targets. It MUST NOT mint a separate law sheet, profile, selected non-pattern FPF kind-reference pair, or checklist unless that separate selected non-pattern FPF kind-reference pair is selected by value and shown not to duplicate the DRR or the selected amendment targets. | Prevents unnecessary separate-support proliferation and shadow-law duplication. |
| CC‑DRR.4b (current decision object remains singular) | A conforming DRR MUST remain one current content decision object. It MUST NOT carry process-order/gate/handoff/process posture, mutable status, or hidden same-decision future-planning language; any undecided remainder MUST be marked outside the current decision with named pattern, selected non-pattern FPF kind-reference pair, or decision record. | Keeps the DRR ontologically about the FPF decision rather than about the development container. |
| CC‑DRR.4c (downstream authoring stays inside the accepted decision) | Authors drafting from an accepted DRR MAY elaborate examples, SoTA‑Echoing, recognition surfaces, local wording inside the selected patterns and selected non-pattern FPF kind-reference pairs, and neighboring fit, but they SHALL NOT silently revise the selected answer, selected patterns and selected non-pattern FPF kind-reference pairs, outside-current-decision boundary, reusable-support disposition, or declared loss/recoverability regime. Any such revision SHALL be handled through one successor DRR or other named successor decision record. | Keeps later pattern drafting from re-deciding bounded content by drift. |
| CC‑DRR.4d (major decision gaps are not left to drafting-time invention) | A conforming DRR MUST NOT leave materially live selected-answer branch choices about the governed object, selected patterns and selected non-pattern FPF kind-reference pairs, outside-current-decision boundary, reusable-support disposition, or loss/recoverability regime to be discovered case-by-case during later pattern drafting or drafting for one selected non-pattern FPF kind-reference pair. Those choices MUST already be selected, rejected, inherited unchanged, or placed outside the current decision with named pattern, selected non-pattern FPF kind-reference pair, or decision record. | Ensures the DRR actually coordinates one bounded change set rather than serving as a thin preface to later rediscovery. |
| CC‑DRR.5 | A DRR for minor, non‑substantive edits (Δ‑0/Δ‑1; e.g., typos, wording clarity, didactic rearrangements) MAY use a lightweight variant containing Problem‑frame (Context) + Decision only (“no semantic change”), provided it does not alter semantics. | Avoids bureaucratic drag on editorial work. |
| CC‑DRR.6 (evidence boundary) | For Δ‑2/Δ‑3 lexical or authoring-sensitive changes, the DRR SHALL state the content-scope evidence or validation evidence obligation that bears on the decision, and it MAY summarize already-available decisive evidence by value when that evidence materially shapes the chosen content. The DRR SHALL NOT need a LAT id, run-manifest id, gate id, packet id, or other authoring-evidence citation in order to count as complete; those remain in the relevant evidence or authoring record. If later LAT or refresh evidence motivates reopening or revising the decision, that later evidence belongs in a successor DRR or other named successor decision record rather than being retrofitted into the accepted DRR. | Keeps the DRR a design-rationale record while preserving re-runnable evidence in its own evidence or authoring record. |
Common Anti-Patterns and How to Avoid Them
| Decorative SoTA appendix | Sources are listed after the fact but do not shape the selected answer, boundary, or validation evidence obligation. | The record looks researched while the decision remains unchallenged by current practice. | State what each load-bearing source makes the DRR adopt, adapt, or reject, and which uncertainty would materially change the answer. |
Consequences
Rationale
FPF evolves by explicit, reviewable deltas rather than silent edits. The DRR is the minimum structured argument—and, when several patterns or selected non-pattern FPF kind-reference pairs must move together, an allowed temporary convergence record that keeps P‑10 Open‑Ended Evolution compatible with P‑1 Cognitive Elegance and P‑2 Didactic Primacy.
E.9 sets a floor, not a ceiling: every conforming DRR must make Problem‑frame / Decision / Rationale / Consequences recoverable, but it may carry richer substantive coordination content when that prevents shadow documents or semantic invention during distribution into Core patterns and selected non-pattern FPF kind-reference pairs. The same floor also requires the decision-support content that later authoring and review otherwise reconstruct manually: exact basis, use-value, first-minute working situation, scenario basis, alternatives, current disposition map, naming/ontology obligation, selected content distribution, existing-pattern sufficiency/new-pattern necessity, overlap classification, selected-answer stability, impact/boundary graph, practical payoff, and any still-live uncertainty that materially shapes the decision.
Pointer-based DRRs (CC‑DRR.1a) prevent duplicated prose, and distribution into Core patterns and selected non-pattern FPF kind-reference pairs (CC‑DRR.4) keeps the specification itself learnable without turning the DRR into a permanent shadow canon. Process-law ordering, gate, and handoff records stay outside because they are not part of the content answer that FPF is selecting.
SoTA-Echoing
E.9 aligns with contemporary architecture-decision and rationale-capture practice, but its contribution is not the existence of a decision record. ADR practice already carries compact context, decision, and consequence records. FPF uses the DRR as a decision-rationale record for one bounded FPF content decision, with enough by-value rationale to distribute durable content into selected patterns and selected non-pattern FPF kind-reference pairs.
The practical gain is content-selection quality under semantic load: the DRR decides the selected answer, alternatives, losses, boundary, and distribution target before pattern drafting begins. Any durable rule, example, or support obligation that remains useful after acceptance belongs in the selected FPF pattern or selected non-pattern FPF kind-reference pair, not in the DRR as a permanent shadow canon.
Relations
- Instantiates: P‑10 Open‑Ended Evolution, P‑2 Didactic Primacy
- Template governed by:
pat:authoring/pattern‑template(E.8) - Interacts with:
pat:guard/bias‑audit(E.5.4) via lens check - Complemented by:
pat:authoring/code‑of‑conduct(E.12) – etiquette for DRR debate
E.9:End
Last Updated: 2026-04-27 — this section last modified in upstream FPF commit b18acde5 (github.com/ailev/FPF)