#Architecture Decision Record Projection

C.32.ADR · Cluster C.IV - Composite & Macro-Scale · Stable · Architecture publication pattern under C.32 · Normative unless explicitly marked informative · Part C - Kernel Extension Specifications

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

Type: Architecture publication pattern under C.32 Status: Draft Normativity: Normative unless explicitly marked informative

Use this pattern when an ArchitectureDecisionRelation@Project or equivalent project architecture decision must be published as an ADR-like record, decision memo, trade-study record, certification rationale, or similar decision-description record.

#Keywords

• architecture decision record
• ADR projection
• ArchitectureDecisionDescription@Project
• ArchitectureDecisionRecordProjection@Project
• section function
• rationale
• consequences
• method-use instruction
• supersession
• publication boundary.

#Relations

#Content

#Problem frame

Use this pattern when an ArchitectureDecisionRelation@Project or equivalent project architecture decision must be published as an ADR-like record, decision memo, trade-study record, certification rationale, or similar decision-description record.

Primary working reader: an architect or architecture-responsible practitioner preparing a decision record for developers, reviewers, maintainers, operators, certifiers, or future architects.

Typical entry phrases:

"The project decision is made; now we need an ADR that future developers can use."
"The record must show options, decision, rationale, consequences, and confirmation without becoming the decision itself."
"This is not a software project; can a trade-study memo play the ADR role?"
"The ADR package must link to architecture views without duplicating the whole architecture description."
"A future team must know when this decision is superseded or violated."

First-minute use slice. A platform architect has a C.32.PAD decision relation selecting event-carried integration with a bounded exception. Using C.32.ADR, the architect creates an ADR projection with section functions for problem frame, candidate options, decision outcome, rationale, consequences, method-use instruction, work split, confirmation eval, source-return links, and supersession. The file is short enough for developers to read, but it remains a publication projection of the decision description, not the decision relation and not the architecture itself.

The primary EntityOfConcern is ArchitectureDecisionRecordProjection@Project: a publication projection of ArchitectureDecisionDescription@Project into an ADR-like record or package. Select this pattern only when the work is to publish or package that decision description for a declared reader use; generic ADR advice that cannot be mapped to decision-section functions stays outside C.32.ADR.

ArchitectureDecisionRecordProjection@Project is not a new U.* kind and not a new root publication ontology. It is a project publication projection with filled section-function rows. Use [E.17](/generated/patterns/E.17) and [E.24.PUB](/generated/patterns/E.24.PUB) for publication-face and publication-use claims; use [C.32.PAD](/generated/patterns/C.32.PAD) for the decision relation.

What goes wrong if C.32.ADR is missed: the project either publishes a record-shaped text that hides the actual architecture decision, or it copies architecture descriptions, diagrams, and method material into a record without telling the reader what decision was made and what work must change.

What C.32.ADR buys in practice: a decision record can be small, readable, updateable, and still tied to candidate synthesis, selected structures, architecture characteristics, method-use instructions, work split, confirmation evals, and source-return.

Ordinary working move: start from a PAD decision relation, select the record's publication scope, map each necessary section to the decision content it carries, then publish only what the reader needs to use, check, or reopen the decision.

Adoption test: after using C.32.ADR, a future reader can recover the decision question, considered options, outcome, rationale, consequences, required method or work change, confirmation or eval path, source links, and supersession condition without mistaking the record for the architecture or the decision relation.

Not this pattern when the decision relation is not yet recoverable, the current work is architecture-description adequacy, the record is a general MVPK publication face, or the claim is evidence, assurance, gate passage, local choice, performed work, or pattern authoring. Use the receiving pattern named in Relations.

The first useful output is ArchitectureDecisionRecordProjection@Project:

ArchitectureDecisionRecordProjection@Project:
  projectionId:
  architectureDecisionRelationRef:
  architectureDecisionDescriptionRef:
  publicationCarrierRef:
  publicationScopeRef:
  intendedReaderRefs:
  status:
  sectionFunctionRows:
    - sectionFunction:
      sectionHeadingOrCarrierSlot:
      sourceDecisionSlotRefs:
      requiredReaderUse:
      omittedByDesign?
      sourceReturnCondition?
  architectureDescriptionRefs:
  methodAndWorkRefs:
  confirmationOrEvalRefs:
  supersedesRecordRefs?
  supersededByRecordRef?
  updateOrReopenCondition:
  publicationUseRefs?

#Problem

ADR practice is useful because it makes architectural decisions small enough to read and update. It is also easy to misuse. A record can become a substitute for the decision relation, a loose essay about architecture, a copied architecture description, or a method prescription with no recoverable target structure.

C.32.ADR treats ADR as a publication projection. The project decision relation belongs to C.32.PAD. The architecture description belongs to C.30.AD and related view patterns. The method description or pattern-use recommendation belongs to A.15, E.8, and E.11.PUR when those claims are live. The ADR-like record publishes a decision description for a declared reader and use.

The section question is therefore not "which headings are allowed?" The section question is "which decision functions must a reader recover?" A heading can vary by organization or industry, but the record must carry the decision question, candidate options or reason no candidate set is live, outcome, rationale, consequences, method-use instruction when the decision guides work, work split, confirmation or eval path, source-return, status, and supersession or reopen condition.

ADR-like projection is not software-only. Engineering trade-study records, safety-certification rationale, design review memos, BIM decision logs, method-governance records, and organization-design records can play the same publication role after the project decision relation and record use are typed. The source form may differ; the FPF section functions stay recoverable.

#Forces

#Solution

Create ArchitectureDecisionRecordProjection@Project from an existing ArchitectureDecisionRelation@Project and ArchitectureDecisionDescription@Project. If the decision relation is missing, return to C.32.PAD before writing the record.

Work in this order:

1. Name the publication carrier and intended readers. The carrier can be a Markdown ADR file, decision memo, trade-study record, engineering change note, certification rationale, design-review record, or another typed file or record.
2. Cite the decision relation and decision description. If the record cannot cite them, draft them first.
3. Choose the smallest record scope that lets intended readers use the decision. Avoid copying architecture descriptions or full method descriptions; cite them by value where possible.
4. Map section functions to headings or carrier slots. Use local headings if needed, but keep the function rows recoverable.
5. Carry the candidate basis. Record candidate options from C.32 or the reason no candidate-set question is live. Do not invent options in the ADR after the decision.
6. Carry the decision outcome. State the selected architecture option, bounded exception, or supersession relation from PAD.
7. Carry rationale, accepted losses, and consequences. Include architecture-characteristic trade-offs and guardrails, not only benefits.
8. Carry method-use instruction and work split when the decision guides developer work. Cite A.15, method descriptions, pattern-use refs, readiness exits, and expected structure effects rather than burying them in prose.
9. Carry confirmation, eval, or violation-detection exits. Use C.32.ACE, C.16, A.10, B.3, A.21, or governance patterns when those claims are live.
10. Carry publication and source-return boundaries. Use E.17, E.24.PUB, and C.30.AD for publication-face and architecture-description claims.
11. Carry status, supersession, and update conditions. Old records remain useful as history when superseded; the active decision relation tells which one governs current work.

#Required section functions

The following section functions are required unless the decision relation states why the function is not live for this record use.

#ADR package use

When several records form a package, create a package map that names active, proposed, superseded, and related records. A package map is a publication navigation aid. It does not merge decisions, replace PAD relations, or decide record priority by file order alone.

When one decision changes another, use explicit supersession or amendment links. Do not rewrite history by deleting the old record unless the project has a governed archival policy.

#Archetypal Grounding

Software ADR. A team publishes an ADR for event-carried integration. The record uses local headings, but the function rows recover context, options, selected outcome, rationale, consequences, method-use instruction for event schema work, confirmation eval, and supersession. Developers can see what to implement and when the decision reopens.

Manufacturing trade-study record. A fixture decision is published as an engineering trade-study memo rather than a Markdown ADR. The memo carries candidate fixture variants, selected universal-fixture scope, accepted setup-time loss, cell-design method instruction, evidence links, and reopen threshold. C.32.ADR admits the memo because it projects the decision description for the intended reader.

Certification rationale. A regulated product records a safety-architecture decision in a certification rationale. The record carries the decision outcome, rationale, evidence refs, architecture-description refs, and confirmation path, while evidence and assurance claims stay in A.10 and B.3.

Method-governance record. A method family decides that reviewers must use an evidence handoff pattern before final review. The ADR-like record cites the method description and expected evidence-structure effect; it does not become the method itself or the performed review work.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

ADR practice is valuable when it makes architectural decisions communicable and revisitable. It becomes weak when a record is treated as the decision itself or when a template substitutes for decision work.

C.32.ADR therefore uses the record as a projection. The decision relation is made in C.32.PAD; the record publishes a decision description for a declared reader. This preserves the strongest ADR practice, small and updateable records, while adding FPF kind control for architecture descriptions, method descriptions, evidence, assurance, gate, publication, and performed work.

The pattern also generalizes ADR practice beyond software by using section functions rather than software-specific carrier assumptions. A record can be a Markdown file, engineering memo, or certification rationale if it projects the decision description and keeps receiving claims with their governing patterns.

#SoTA-Echoing

These rows document transfers from source practice into C.32.ADR. Keep a source citation only when it changes section function, projection boundary, or update condition.

Source-currentness boundary. Recheck a source row when ADR template practice, decision-record tooling, violation-detection practice, architecture-description practice, FPF publication patterns, or project governance changes the section function or update rule used by C.32.ADR.

#Relations

• Builds on: C.32.PAD, C.32.P2S, C.30.AD, C.30.ASV, E.17, E.24.PUB, A.15, E.8, E.11.PUR, and C.32.ADA.
• Decision boundary: Use C.32.PAD for the project architecture decision relation. C.32.ADR publishes an ArchitectureDecisionDescription@Project; it is not generic ADR guidance and not a second decision authority.
• Structural-information boundary: ADR-like projections may cite C.33, C.34, or C.35 only to show captured structure, lost structure, preservation adequacy, generated-carrier typing, or discovered-carrier typing behind the projected decision. The ADR projection remains a publication projection of a decision description; it is not the architecture, the decision relation, or generated-carrier authority.
• P2S docking: P2S may cite an ADR projection as one stage where decision, rationale, method expectation, and source-return are published for readers; ADR does not carry the whole architecturing flow.
• Architecture-description boundary: Use C.30.AD and C.30.ASV for architecture-description and view adequacy. ADR carries refs and reader-use slices, not full description authority.
• Pattern and method boundary: Use E.8 when the published object is an FPF pattern, E.11.PUR for pattern-use recommendation, and A.15 for method and work claims.
• Publication boundary: Use E.17 and E.24.PUB for MVPK face, publication carrier, and publication-use claims not specific to architecture decisions.
• Evaluation boundary: Use C.32.ADA for decision adequacy; use C.32.ACE, C.16, A.10, B.3, or A.21 for eval, measurement, evidence, assurance, or gate claims.
• Package boundary: A record package map aids navigation among records. It does not decide active architecture by file order; PAD relations and status refs remain governing.

#Footer marker

C.32.ADR closes when ArchitectureDecisionRecordProjection@Project cites the decision relation and decision description, names carrier, readers, scope, status, section-function mapping, decision outcome, rationale, consequences, method and work refs when live, confirmation or eval exit, publication boundaries, and update or supersession condition.

#C.32.ADR:End

Last Updated: 2026-06-25 — this section last modified in upstream FPF commit 792091cf (github.com/ailev/FPF)