#Architecture Decision Adequacy Scales

C.32.ADA · Cluster C.IV - Composite & Macro-Scale · Stable · Architecture evaluation 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 evaluation pattern under C.32 Status: Draft Normativity: Normative unless explicitly marked informative

Use this pattern when a project architecture decision, its method docking, or its ADR-like publication projection must be evaluated for adequacy before use, review, handoff, governance, or improvement.

#Keywords

• architecture decision adequacy
• ArchitectureDecisionAdequacyEvaluation@Project
• declared use
• complete coordinate set
• E.21 labels
• method docking
• publication projection
• no average
• repair target.

#Relations

#Content

#Problem frame

Use this pattern when a project architecture decision, its method docking, or its ADR-like publication projection must be evaluated for adequacy before use, review, handoff, governance, or improvement.

Primary working reader: an architect, reviewer, or architecture-responsible practitioner checking whether a project architecture decision is good enough for a declared use and which repair should happen next.

Typical entry phrases:

"The decision is written, but can developers actually use it?"
"The ADR looks complete; is the architecture decision itself adequate?"
"Which part is weak: candidate basis, trade-off, method instruction, work split, or publication projection?"
"We need a scale like E.21, but for architecture decisions rather than pattern quality."
"Do not average the decision; tell us what must be repaired."

First-minute use slice. A reviewer receives a PAD decision relation and ADR projection for a modularization decision. Using C.32.ADA, the reviewer declares the use: "ready for developer work and ADR publication." The reviewer scores each coordinate with a short rationale. Candidate traceability is 4 wellExpressedForDeclaredUse, architecture-characteristic trade-off is 3 sufficientlyExpressedForDeclaredUse, method docking is 2 partiallyExpressedForDeclaredUse, and publication projection is 4 wellExpressedForDeclaredUse. The result does not approve the decision. It directs repair to the method-use instruction, responsible roles, readiness exit, and expected structure effect before the decision can guide developer work.

The primary EntityOfConcern is ArchitectureDecisionAdequacyEvaluation@Project: an evaluation record over one ArchitectureDecisionRelation@Project, optional ArchitectureDecisionRecordProjection@Project, and declared use.

ArchitectureDecisionAdequacyEvaluation@Project is not a new U.* kind, not a gate, not evidence, not assurance, not pattern-quality evaluation, and not a replacement for [C.32.PAD](/generated/patterns/C.32.PAD). It is a typed adequacy evaluation that sends weak coordinates back to their governing repair patterns.

What goes wrong if C.32.ADA is missed: a decision can appear complete because it has a record, rationale, or diagram, while it is unusable for the declared work. Weak candidate basis, hidden trade-offs, missing method instructions, absent source-return, and vague supersession conditions remain invisible until implementation or review fails.

What C.32.ADA buys in practice: the project can evaluate architecture decisions by complete coordinate set, keep kinds distinct, and repair the weakest live coordinates without turning adequacy into a single score.

Ordinary working move: declare the evaluation use, evaluate every coordinate with an ordinal value and rationale, then return each weak coordinate to the smallest governing pattern that can repair it.

Adoption test: after using C.32.ADA, another practitioner can see the declared use, complete coordinate values, rationales, repair targets, and stop condition for the architecture decision.

Not this pattern when the current object is FPF pattern quality, measurement validity, evidence support, assurance, gate passage, candidate synthesis, comparison, selection, local choice, or ADR publication projection itself. Use the receiving pattern named in Relations.

The first useful output is ArchitectureDecisionAdequacyEvaluation@Project:

ArchitectureDecisionAdequacyEvaluation@Project:
  evaluationId:
  declaredUse:
  architectureDecisionRelationRef:
  architectureDecisionRecordProjectionRef?
  evaluatorRoleRef:
  coordinateValues:
    - coordinateRef:
      value: 0|1|2|3|4|5
      valueLabel: absent|namedOnly|partiallyExpressedForDeclaredUse|sufficientlyExpressedForDeclaredUse|wellExpressedForDeclaredUse|exceptionallyExpressedForDeclaredUse
      adjacentValueRationale:
      evidenceOrSourceRefs?
      repairPatternRef?
      repairInstruction:
  strongestBlockingCoordinates:
  noAveragePolicy: true
  stopCondition:
  reevaluationTrigger:

#Problem

Architecture decisions are multi-kind objects in practice. A decision relation can be strong while its ADR projection is weak. A record can be readable while the decision lacks candidate traceability. A candidate basis can be strong while method docking is absent. A method instruction can be clear while the architecture-characteristic trade-off is hidden.

Because of that, a single pass, single grade, or average score is misleading. Adequacy must be evaluated by coordinates tied to the declared use. "Ready for internal architecture review", "ready for developer work", "ready for ADR publication", and "ready for governance enforcement" can require different stop conditions, but each use still needs complete coordinate inspection.

C.32.ADA supplies an E.21-shaped ordinal evaluation pattern for architecture decisions. It uses the E.21 value domain and labels directly, then defines architecture-decision coordinates over PAD relation, method docking, publication projection, structural description, characteristic trade-off, and evolution. Weak coordinates point back to C.32.PAD, C.32.ADR, C.30.AD, A.15, C.32.ACS, C.32.ACE, C.16, C.25, or another governing pattern.

#Forces

#Solution

Create ArchitectureDecisionAdequacyEvaluation@Project for one declared use. Evaluate the complete coordinate set. Do not average coordinate values. Use the weakest live coordinate to choose the next repair.

#Shared value meanings

Use the same ordinal value domain and labels as E.21. ADA specializes what counts as expression for architecture-decision adequacy; it does not create a second scale.

Values are ordinal content evaluations. They are not measures, averages, votes, maturity ladder names, evidence weights, assurance levels, gate statuses, or implementation approval.

The result-bearing coordinate row uses the E.21 label domain with an architecture-decision coordinate:

5 is not required for every use. Stop conditions are declared before evaluation. A lower diagnostic floor may be used for exploration or internal discussion, but it does not make the decision ready for developer work, implementation commitment, or governance enforcement.

#Complete coordinate set

Evaluate every coordinate. If a coordinate is not live, mark it notTriggered only with a short reason grounded in the declared use.

#Use-specific stop conditions

Declare the use before scoring. Common uses:

Use these as ordinary defaults. A project can declare stricter stop conditions. It must not weaken a triggered coordinate by hiding it under an average, and it must not call a diagnostic result ready for developer work or governance enforcement.

#Small complete evaluation slice

ArchitectureDecisionAdequacyEvaluation@OrderFlow:
  declaredUse: readyForDeveloperWork
  architectureDecisionRelationRef: PAD:order-flow-event-integration
  architectureDecisionRecordProjectionRef: ADR:order-flow-event-integration
  noAveragePolicy: true
  stopCondition: every triggered coordinate >= 4 wellExpressedForDeclaredUse
  strongestBlockingCoordinates:
    - MethodAndWorkDockingAdequacy
    - ArchitectureCharacteristicTradeoffAdequacy
  result: repairBeforeUse

PAD adequate, ADR weak. A fixture architecture decision relation can reach 4 wellExpressedForDeclaredUse on every triggered PAD, method, work-split, trade-off, and reopen coordinate while the trade-study memo omits status and supersession. ADA returns only the publication projection to [C.32.ADR](/generated/patterns/C.32.ADR); it does not rewrite the PAD relation.

ADR readable, PAD weak. A Markdown ADR can have clear headings, status, context, decision, and consequences while the project relation lacks candidate basis, affected selected structures, and method docking. ADA returns the decision relation to [C.32.PAD](/generated/patterns/C.32.PAD), [C.32](/generated/patterns/C.32), and [A.15](/generated/patterns/A.15); template completeness does not make the architecture decision adequate.

#Archetypal Grounding

Developer-work readiness. A service architecture decision has strong candidate traceability and trade-off rationale, but the ADR only says "teams should use events." ADA gives MethodAndWorkDockingAdequacy = 2 partiallyExpressedForDeclaredUse because responsible roles, method description, expected structure effect, and readiness exit are not recoverable. The repair returns to PAD and A.15 before developers are instructed.

ADR-publication readiness. A manufacturing architecture decision is clear, but the trade-study memo omits status and supersession. ADA gives PublicationProjectionAdequacy = 2 partiallyExpressedForDeclaredUse and EvolutionAndReopenConditionAdequacy = 3 sufficientlyExpressedForDeclaredUse. The repair returns to C.32.ADR for record status and supersession rows.

Architecture review. A method-family architecture decision has candidate options and method instructions, but no declared architecture characteristics. ADA gives ArchitectureCharacteristicTradeoffAdequacy = 0 absent. The repair returns to C.32.ACS and C.25 before review can judge the decision.

Governance enforcement. A toolchain-product correspondence decision depends on team and tool structures. ADA evaluates TransformerTransformedCorrespondenceAdequacy; if the correspondence refs are absent, the repair returns to C.32.CONWAY before governance can enforce the method.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

C.32.ADA exists because architecture-decision adequacy is not one property. It is a family of recoverability and use-readiness coordinates across decision relation, selected structures, architecture characteristics, method docking, work split, publication projection, evidence or eval exits, and evolution.

The pattern follows the same discipline as FPF quality evaluation: declared use first, complete coordinate set, ordinal values with rationale, no average, and targeted repair. It remains architecture-specific because the coordinates are tied to PAD, ADR projection, architecture descriptions, candidate synthesis, method-use instructions, and architecture-characteristic trade-offs.

#SoTA-Echoing

These rows document transfers from source practice into C.32.ADA. Keep a source citation only when it changes a coordinate, value meaning, stop condition, or repair exit.

Source-currentness boundary. Recheck a source row when FPF evaluation discipline, architecture-decision practice, ADR violation checking, evolutionary-architecture eval practice, or project governance changes a coordinate, value meaning, or repair exit.

#Relations

• Builds on: C.32.PAD, C.32.ADR, C.32.P2S, C.32, C.32.MLAO, C.32.ACS, C.32.ACE, C.32.CONWAY, C.32.FAIL, C.30.AD, C.30.ASV, A.15, C.16, C.25, C.29, E.17, and E.21.
• Evaluation boundary: ADA evaluates architecture-decision adequacy for declared use. It does not perform candidate synthesis, comparison, selection, selected-set publication, local choice, evidence support, assurance, gate passage, governance enforcement, or pattern-quality evaluation.
• Decision and projection boundary: Use C.32.PAD to repair the decision relation and C.32.ADR to repair ADR-like publication projection.
• Description and structure boundary: Use C.30, C.30.AD, and C.30.ASV for architecture claim, description, and view adequacy.
• P2S docking: Use C.32.P2S when a weak decision-adequacy row must reopen the connected architecturing flow rather than only repair the decision record.
• Method and work boundary: Use A.15, A.15.1, A.15.2, A.15.5, E.8, E.11.PUR, and C.24 for method, work, readiness, pattern-use, and agentic tool-use claims.
• Characteristic and eval boundary: Use C.32.ACS, C.32.HCS, C.25, C.32.ACE, C.16, C.31, and C.31.ASAP for characteristic rows, Q-Bundles, eval programs, measurement, modularity, and scale preference.
• Evidence, assurance, gate, and governance boundary: Use A.10, B.3, A.21, and local governance patterns when those claims are live.

#Footer marker

C.32.ADA closes when ArchitectureDecisionAdequacyEvaluation@Project declares the use and stop condition, cites the evaluated decision relation and optional projection, evaluates every coordinate with an E.21 value label and rationale or grounded not-triggered status, names weakest blocking coordinates, assigns repair patterns and repair instructions, and avoids average-score replacement.

#C.32.ADA:End

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