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 governing support surfaces it affects
- several patterns or governing support surfaces must move together and one external decision artefact 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 burden would otherwise force authors to decide the same load-bearing answer separately across several patterns or governing support surfaces
- one deprecation, narrowing, or cross-pattern amendment must stay reviewable without reconstructing intent from patch history, chat memory, or scattered notes
Keywords
- DRR
- design rationale
- decision record
- context
- consequences
- conceptual auditability.
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 governing support surfaces it affects
- several patterns or governing support surfaces must move together and one external decision artefact 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 burden would otherwise force authors to decide the same load-bearing answer separately across several patterns or governing support surfaces
- 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/workflow 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 artefact 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 artefact for coordinated changes, while keeping enduring Core text in the selected patterns and governing support surfaces rather than in the DRR
- one temporary convergence artefact that fixes the selected answer (the chosen content answer for the bounded burden) before later drafting fans out across several selected patterns or governing support surfaces
Governed object in plain terms. The governed object here is one external decision-rationale artefact for one bounded FPF content decision or one bounded coordinated change set. The minimal lens is simple: the artefact 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 governing support surfaces 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 artefact 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 artefact
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 governing support surfaces. In this pattern, the selected answer means the current set of chosen content decisions for that bounded burden: what FPF should say, which selected patterns or governing support surfaces carry it, what stays outside, and what support or loss/recoverability regime applies. In this pattern, a temporary convergence artefact means one external decision artefact that temporarily holds the selected answer while the selected Core patterns and governing support surfaces are still being updated.
A nontrivial DRR may therefore govern one bounded coordinated change set. In that case the DRR is the temporary convergence artefact for the selected answer until selected Core patterns and governing support surfaces are updated; it is not a second permanent law layer.
Minimum decision-support surfaces
A conforming DRR must also make the following decision-support surfaces
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.
| Surface-distribution and outside-boundary map | For each load-bearing selected answer: selected patterns and governing support surfaces, exact content obligations on each selected pattern or support surface, which nearby patterns or support surfaces stay unamended under the current decision, and any cross-surface agreement that those selected patterns and support surfaces must preserve. Named nearby patterns or support surfaces 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 governing support surface is sufficient, or one newly selected pattern or governing support surface is necessary, and why rejected options would misplace, overload, or falsely split semantic authority. | Decision and Rationale. |
| Naming, ontology, and wrong-carrier-confusion account | Head/branch/object/move/outside-work separation, tempting wrong-pattern or wrong-support-surface confusion, and any load-bearing F.18 naming burden needed to keep the selected answer truthful by value. | Problem frame, Decision, and Rationale. |
| Reusable-support disposition when triggered | Whether a potentially reusable support object/view/helper family remains local, is generalized now, is rejected, or is routed outside the current decision with named pattern/support surface/decision record. | Decision and Rationale. |
| Loss and recoverability template when weakening is declared | Preserved distinctions, dropped distinctions, supported use, unsupported downstream use, recoverability class, and reopen/exit rule. | Decision and Consequences. |
| Selected carrier and neighbor-boundary account | Why the selected patterns and governing support surfaces carry the content, which tempting patterns or support surfaces stay outside, and which neighboring reroutes remain authoritative. | Decision and Rationale. |
| Convergence and overlap account when several burden branches touch the same carrier set | Whether overlap is valid convergence or one reopened architecture smell, what cross-surface agreements must hold, and whether a new pattern or support surface 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 burden | Affected patterns and governing support surfaces, practical gains/costs, authority or release consequences when they follow from the content decision, and the remaining validation burden 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 support surfaces are not separate process paperwork. A DRR that keeps only the four labels while leaving basis, first-minute use burden, naming, selected content distribution, pattern/support-surface sufficiency or necessity, overlap handling, impact, or live uncertainty implicit is structurally labeled but still substantively immature.
Together these support surfaces let the DRR act as one decision artefact for one bounded coordinated change set: enough semantic closure that later drafting distributes the selected answer into selected patterns and governing support surfaces rather than inventing it for the first time pattern by pattern.
When one bounded decision coordinates several patterns or governing support surfaces, or one cluster of mutually dependent pattern edits and support-surface edits, the DRR MAY carry additional substantive sections beyond that minimum kernel. Typical Typical substantive additions include obligations on selected patterns and support surfaces, one explicit new-pattern vs existing-pattern decision, one cross-pattern/support-surface impact or non-goal map, cross-surface coverage or agreement maps, 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 governing support surfaces are affected, and what practical burden improves. A DRR carrying richer convergence content MUST NOT become a campaign plan, workflow script, baton carrier, packet checklist, staging log, or other development-process brief.
When one selected answer could plausibly fit one already-existing pattern or support surface or require one newly proposed pattern or support surface, 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 support surface later.
When the accepted basis or the DRR itself already names one pattern or
governing support surface as part of the live distribution question, that
pattern or support surface is not a neutral future watch item. The DRR
must classify it now either as one selected pattern or support surface
with explicit obligation, one explicit boundary neighbor kept unchanged,
one inherited-unchanged neighbor, or one outside-current-decision burden
with named pattern/support surface/decision record. Conditional or
time-relative host prose 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 local support object, view, atlas/helper family, 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, support surface, or decision record.
When one burden involves weakening, attenuation, simplification, redaction, summarization, or other declared loss, the DRR must make the supported-use template explicit by value. Explanation alone is not enough; the decision must say what remains preserved, what is dropped, which branch reading or support surface is supported, which uses are unsupported, what recoverability class applies, and what reopen or exit rule governs cases that exceed the declared weakening.
A nontrivial DRR is mature enough for downstream authoring only when materially live burden-family choices about the governed object, selected patterns and support surfaces, outside-current-decision boundary, reusable-support disposition, and loss/recoverability regime have already been selected, rejected, inherited unchanged, or routed outside the current decision with a named pattern, support surface, 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(s) or other Core support surfaces as explicit normative or informative text (the change is "in the Core"; the DRR is not). A richer DRR MAY remain the temporary convergence artefact while redistribution into selected Core patterns and governing support surfaces 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 support surfaces, and neighboring fit. They SHALL NOT silently revise the selected answer, selected patterns and support surfaces, outside-current-decision boundary, reusable-support disposition, or declared loss/recoverability regime. Any such revision SHALL be routed 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, route order, monolith status, future campaign planning, or one hidden promise that the same current burden will be decided later inside the same decision object. Any undecided remainder must be marked outside the current decision with a named pattern, support surface, or decision record.
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 support object, view, helper family, or neighboring support mechanism, the DRR MUST decide whether it is generalized now, kept local with reason, rejected, or routed outside the current decision with named pattern/support surface/decision record. | Prevents unexamined inheritance of local support forms. |
| CC‑DRR.1g (loss/recoverability template when triggered) | If the decision declares weakening, attenuation, simplification, redaction, summarization, or other loss, the DRR MUST make explicit the preserved distinctions, dropped distinctions, supported uses, unsupported downstream uses, recoverability class, and reopen/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 or wrong-support-surface confusion or load-bearing F.18 naming burden 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 governing support surface, or one newly proposed pattern or governing support surface, the DRR MUST make that sufficiency/necessity judgement by value and MUST explain why rejected options would misplace, overload, or falsely split semantic authority. | 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.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, governing support surface, or neighboring pattern/support surface it supersedes, amends, excludes from the current decision, routes to, or risks impacting, together with any cross-surface agreement the selected patterns and support surfaces must preserve. It MUST also make clear why the selected patterns and support surfaces carry the content, which tempting patterns or support surfaces stay outside, and, when several burden 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 governing support surfaces, and any remaining content-level validation burden or authority/release consequence that still constrains the selected decision by value. | Prevents consequences from collapsing into generic optimism or route 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 burden 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 governing support surfaces. 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 artefact. |
| CC‑DRR.4a (separate-law surface 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, support surface, or checklist surface unless that separate surface is selected by value and shown not to duplicate the DRR or the selected amendment targets. | Prevents unnecessary separate-surface 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 route/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/support surface/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 support surfaces, and neighboring fit, but they SHALL NOT silently revise the selected answer, selected patterns and support surfaces, outside-current-decision boundary, reusable-support disposition, or declared loss/recoverability regime. Any such revision SHALL be routed 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 burden-family choices about the governed object, selected patterns and support surfaces, outside-current-decision boundary, reusable-support disposition, or loss/recoverability regime to be discovered case-by-case during later pattern/support drafting. Those choices MUST already be selected, rejected, inherited unchanged, or routed outside the current decision with named pattern/support surface/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-level evidence or validation burden 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
Consequences
Rationale
FPF evolves by explicit, reviewable deltas rather than silent edits. The DRR is the minimum structured argument—and, when several patterns or governing support surfaces must move together, an allowed temporary convergence artefact—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 governing support surfaces. 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 burden, 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 governing support surfaces (CC‑DRR.4) keeps the specification itself learnable without turning the DRR into a permanent shadow canon. Process-law route, gate, and handoff surfaces 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 adapts that practice to FPF's pattern-governed Core.
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