#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: Stable 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. ArchitectureReviewService-4 first has the A.13 core for decision-adequacy evaluation, and A.15.1 independently admits DecisionAdequacyEvaluationWork-12 from 10:00 to 10:20 on 2026-08-12. The Work enacts DecisionAdequacyEvaluationMethod-2 and occurs within the U.System named ProjectArchitectureReviewService-4. This slice expressly represents evaluator accountability: ArchitectureReviewerAssignment-6 is an obtaining occurrence of directly declared species ArchitectureReviewerAssignment, held by the already recovered performer and covering the Work, and the separate F.6 relation is recorded. A Work-only ADA record would omit those assignment and attribution refs; failed F.6 would leave the evaluation Work intact. One separate result episteme states the declared use and coordinate outcomes. It does not approve the decision; it directs the exact bounded repairs needed before the decision can guide developer Work.

The primary governed object is ArchitectureDecisionAdequacyEvaluation@Project: a C.32.ADA-local evaluation record over one ArchitectureDecisionRelation@Project, optional ArchitectureDecisionRecordProjection@Project, and declared use. It is not the evaluated decision, evaluation Work, or result episteme.

ArchitectureDecisionAdequacyEvaluation@Project is a local record form, not a new U.* kind, gate, evidence, assurance, pattern-quality evaluation, or replacement for [C.32.PAD](/generated/patterns/C.32.PAD). Its coordinate table expresses the ADA result content; when that result must be a durable claim, one separately identified C.2.1 episteme states it. The dated evaluation remains separate U.Work, and any actual evaluation operation application remains with its subject pattern.

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 state the repair condition for each weak coordinate and cite the smallest subject-pattern locus containing the required definition or constraint.

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 pattern for the next question named in Relations.

The first useful output is ArchitectureDecisionAdequacyEvaluation@Project:

ArchitectureDecisionAdequacyEvaluation@Project:
  projectWorkOccurrenceRef?: U.EntityRef constrained to U.Work
  architectureDecisionEvaluationProjectUseRelationRef?: U.RelationRef governed by the exact evaluation-use or work-use pattern
  evaluationId:
  claimScopeRef: U.EntityRef referencing one U.ClaimScope
  selectedContextSliceRefs:
  effectiveReferenceScheme:
  referencePlane?:
  evaluationWindow:
  decisionQuestionInputProjectionRef:
  evaluatorSystemRef?: U.EntityRef constrained to U.System
  evaluatorSystemRoleKindRef?: U.KindRef
  evaluatorSystemRoleClassificationJudgmentRef?: U.RelationRef
  evaluatorAssignmentSpeciesRef?: U.RelationKindRef constrained under U.SystemRoleAssignment
  evaluatorAssignmentOccurrenceRef?: U.RelationRef constrained to U.SystemRoleAssignment
  evaluationWorkRef?: U.EntityRef constrained to U.Work
  evaluationPerformedUnderAssignmentRef?: U.RelationRef constrained to one obtaining F.6 performedUnderAssignment relation
  evaluationOperationApplicationRefs?: subject-pattern relation or A.6.1 application references
  adequacyResultEpistemeRef?: U.EpistemeRef
  declaredUse:
  architectureDecisionRelationRef:
  architectureDecisionRecordProjectionRef?:
  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:

Here @Project is a compatibility and retrieval cue only. A project-local ADA record names both the composite U.Work in projectWorkOccurrenceRef and the obtaining record-use relation in architectureDecisionEvaluationProjectUseRelationRef; the evaluated decision's own project relation, the suffix, or either field alone is insufficient. evaluatorSystemRoleKindRef and evaluatorSystemRoleClassificationJudgmentRef remain optional and separate. When actual evaluation is claimed, the evaluator first has its A.13 core and evaluationWorkRef names Work independently admitted under A.15.1. Assignment species, occurrence, and evaluationPerformedUnderAssignmentRef are optional and appear only when the record or receiving use expressly represents precise assignment-bound attribution; any present F.6 ref uses the same obtaining A.13 assignment, and its absence or failure leaves the Work intact. Any operation application and result episteme remain separate. Kind, classification, assignment, Work, attribution, application, responsibility, and result do not substitute for one another.

#Problem

Architecture-decision adequacy concerns several distinct objects. 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.

A single overall grade or average score hides these differences. 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 subject 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
  claimScopeRef: OrderFlow developer-work readiness for the named decision and release slice
  selectedContextSliceRefs: OrderFlow service, named product-family release, and current developer-work window slices
  effectiveReferenceScheme: OrderFlow architecture decision scheme edition 4
  referencePlane: selected architecture and developer-work commitment
  evaluationWindow: review session 2026-07-31
  decisionQuestionInputProjectionRef: PAD decision relation plus its declared-use and source-return fields
  evaluatorSystemRef: ArchitectureReviewService-4
  evaluatorAssignmentSpeciesRef: ArchitectureReviewerAssignment
  evaluatorAssignmentOccurrenceRef: ArchitectureReviewerAssignment-6
  evaluationWorkRef: DecisionAdequacyEvaluationWork-12
  evaluationPerformedUnderAssignmentRef: performedUnderAssignment(DecisionAdequacyEvaluationWork-12, ArchitectureReviewerAssignment-6)
  adequacyResultEpistemeRef: DecisionAdequacyResult-12
  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 identifies only the missing publication-projection assertion and cites [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/Work docking. ADA identifies those missing assertions and cites [C.32.PAD](/generated/patterns/C.32.PAD), [C.32](/generated/patterns/C.32), and [A.15](/generated/patterns/A.15) as their subject-pattern locators; 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 the acting Systems, MethodDescription, expected structure effect, and readiness condition are not recoverable from the instruction. In this case the ADR also expressly requires accountable implementation under an exact assignment, so the absent assignment species/current occurrence and F.6 relation are additional attribution defects; a Work-only instruction would not require them. Any responsibility claim must cite its direct domain predicate or exact missing governor.

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 states the missing record-status and supersession assertions using C.32.ADR.

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 states the missing characteristic assertions using 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 states the missing correspondence assertion using C.32.CONWAY before institutional governance can constrain Method use.

#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 sources inform the coordinates, value meanings, stop conditions, and repair exits used below.

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.2.1, A.2.6, A.15, A.15.1, A.19, C.2.1, C.16, C.25, C.29, E.17, and E.21; uses A.1.1 only when a selected BoundedModelUseStructure changes evaluation interpretation.
• Evaluation boundary: Use ADA only to evaluate architecture-decision adequacy for a declared use. It does not perform candidate synthesis, comparison, selection, selected-set result declaration, actual 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-program framing, typed measurement or evaluation results, modularity, and scale preference. ADA may inspect references to those objects as coordinate evidence; use their subject patterns for any definition change or actual operation.
• 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; binds the exact claim scope and selected context slices, reference scheme and plane, evaluation window, and decision-question input projection; 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, repair patterns, and repair instructions; avoids average-score replacement; and, when actual evaluation is claimed, keeps the A.13-qualified evaluator System, independently admitted A.15.1 Work, operation application, any responsibility relation, and result episteme separately identified. Assignment species, occurrence, and F.6 attribution are present only when the record expressly represents that precise attribution.

#C.32.ADA:End

Last Updated: 2026-09-10 — upstream FPF commit a87d0ef4 (github.com/ailev/FPF)