#Project Architecture Decision After Candidate Synthesis

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

Use this pattern when a project has synthesized candidate architecture configurations and must make the project architecture decision that will guide later design, implementation, construction, operation, governance, or change work.

#Keywords

• project architecture decision
• ArchitectureDecisionRelation@Project
• selected architecture option
• affected selected structure
• architecture-characteristic trade-off
• accepted loss
• method-use instruction
• architect-developer split
• reopen condition.

#Relations

#Content

#Problem frame

Use this pattern when a project has synthesized candidate architecture configurations and must make the project architecture decision that will guide later design, implementation, construction, operation, governance, or change work.

Primary working reader: an architect or architecture-responsible practitioner who has enough candidate synthesis, comparison input, and architecture-characteristic pressure to decide what architecture will be pursued now.

Typical entry phrases:

"We have three candidate architecture configurations; which one becomes the project decision?"
"The candidate improves maintainability but worsens evidence reuse; what is the accepted trade-off?"
"Developers need to know which architectural style, method, or pattern use is now required."
"The architecture decision must say where architect-owned structure ends and developer-owned refinement starts."
"The ADR cannot be written yet because the decision relation is not clear."

First-minute use slice. A product-family architect has a C.32 candidate palette with three module, placement, and evidence-structure variants. C.32.ACS names maintainability, substitutability, and evidence reuse as optimization indicators, and C.32.ACE has evaluated the candidates under one parity frame. Using C.32.PAD, the architect records the exact composite project work, selected configuration, affected selected structures, accepted loss in evidence reuse, method-use instruction for product teams, work split between architecture-owned structure and team-owned refinement, source-return condition, and reopen trigger. The result is not an ADR file yet; it is the architecture decision relation concerning that project work which an ADR or another publication form can describe.

The primary EntityOfConcern is ArchitectureDecisionRelation@Project: an architecture decision relation over one bounded architecture question with one exact composite project U.Work as a participant. It links that work, the decision subject, candidate basis, selected architecture option, affected structures, architecture characteristics, rationale, accepted losses, consequences, method and work expectations, publication projection, evidence or eval exits, and reopen conditions.

ArchitectureDecisionRelation@Project is not a new U.* kind. @Project is a compatibility and retrieval cue, not the source of project identity or scope. The relation is project-local only when projectWorkOccurrenceRef identifies the exact composite U.Work that participates in it. When another slot becomes load-bearing as an FPF object, recover the governing pattern for that object.

When this decision designates a project system-of-interest, projectSystemOfInterestRef? names only an independently admitted existing U.System. Before identity inception, keep the intended referent in intendedProjectSystemClaimRef? as U.WorkPlan, decision, system-description, or other claim content. Cite systemOfInterestRoleAssignmentRef? only when A.2 names the role value, taxonomy episteme, effective scheme, and enactment-facing participation and the corresponding A.2.1 U.RoleAssignment separately obtains. Designation, role interpretation, assignment, Work/change/use facts, and the decision remain distinct. The decision neither establishes a compound project-selection truth nor repairs its missing constructor; when that one truth is required, retain every direct fact and return missing-substrate[project-selection-conjunction] through A.15.6.

When the decision uses a transformation-flow network, transformationFlowStructureNetworkRef? names only an independently selected E.18.NET TransformationFlowStructureNetwork@Context <: U.Structure; projectNetworkSelectionResultRef? may cite the separate C.2.1 judgment about why that network answers the project question, and architectureTransformationFlowStructureRelationRef? cites C.30.TFS-REL when architecture use is current. A network record, a C.32.CONWAY frame or exact pair row, and this decision create no network member, cross-flow occurrence, architecture-influence occurrence, architecture relation, or other world-side fact.

What goes wrong if C.32.PAD is missed: a team writes an architecture record, diagram, shortlist, ranking, or local choice without a recoverable architecture decision relation to exact project work. Later workers cannot tell which architecture configuration is selected, which structures are affected, which method they must use, which losses were accepted, or when the decision must be reopened.

What C.32.PAD buys in practice: practitioners performing the project work can turn a candidate palette into one governed decision relation that is strong enough to guide work, publish an ADR-like record, support review, and reopen under architecture evolution.

Ordinary working move: recover the live decision question, cite the candidate basis, select the architecture option or bounded exception, record the trade-off over declared architecture characteristics, then bind the decision to method-use expectations, work split, source-return, and reopen conditions.

Adoption test: after using C.32.PAD, another practitioner can answer: what architecture option was selected, from which candidate basis, for which affected structures, under which architecture-characteristic trade-off, with which method and work consequences, and under which reopen condition.

Not this pattern when the current work is candidate synthesis, architecture-description adequacy, ADR publication projection, adequacy evaluation, evidence, assurance, gate passage, local choice, or performed work. Use the receiving pattern named in Relations for those claims.

The first useful output is ArchitectureDecisionRelation@Project:

ArchitectureDecisionRelation@Project:
  decisionId:
  projectWorkOccurrenceRef: U.EntityRef constrained to exact composite U.Work
  projectSystemOfInterestRef?: U.EntityRef constrained to one independently admitted existing U.System
  intendedProjectSystemClaimRef?: U.WorkPlan, decision, system-description, or other claim episteme ref before identity inception
  systemOfInterestRoleAssignmentRef?: U.EntityRef constrained to one separately obtaining A.2.1 U.RoleAssignment, only with its named A.2 role/taxonomy interpretation
  decisionSubjectRef:
  describedHolonRef:
  boundedContextRef:
  decisionQuestion:
  candidateBasisRefs:
  comparisonOrSelectionRefs?
  structuralInformationLensUseRefs?
  holonTransitionOrBOSCTriggerRefs?
  architectureInfluenceCorrespondenceRef?: C.32.CONWAY frame or exact pair-row ref
  transformationFlowStructureNetworkRef?: exact independently selected E.18.NET TransformationFlowStructureNetwork@Context ref
  projectNetworkSelectionResultRef?: exact C.2.1 result episteme whose EntityOfConcern is transformationFlowStructureNetworkRef
  architectureTransformationFlowStructureRelationRef?: exact C.30.TFS-REL use/trace ref when architecture uses that network
  selectedArchitectureOptionRefs:
  selectedStructureEffects:
    - structureKindRef:
      selectedStructureRef:
      decisionEffect:
      governingPatternRef:
  architectureCharacteristicTradeoffs:
    - architectureCharacteristicRef:
      criteriaRowRef?
      expectedGain:
      acceptedLoss:
      evalResultRef?
      guardrailRef?
  rationaleRefs:
  rejectedOptionRefs:
  consequenceRows:
  architectureDescriptionRefs:
  methodUseInstructions:
    - methodDescriptionRefOrPatternRef:
      expectedStructureEffect:
      responsibleRoleRef:
      workBoundaryRef:
      readinessOrGateExitRef?
  architectDeveloperSplit:
    architectOwnedStructureRefs:
    developerOwnedRefinementRefs:
    sourceReturnCondition:
  publicationProjectionRef?
  evidenceOrAssuranceExitRefs?
  governanceExitRefs?
  reopenConditions:
  supersedesDecisionRefs?
  status:

The field names in this first-output form are publication-friendly filled-reference fields. Durable relation positions must be expressible through [A.6.5](/generated/patterns/A.6.5) SlotSpecs: each position has a local SlotKind, an admitted ValueKind, and a by-value or concrete RefKind filling mode. A field name such as decisionSubjectRef is not a SlotKind, not a U-kind, and not an ADR heading; it is the filled-reference field by which this relation record points to the value governed by the slot-bearing relation.

#Problem

Architecture synthesis produces candidates; the systems and roles performing project work still need a decision. The decision is not the candidate palette, not the selected set publication, not the architecture description, and not the ADR file. It is the architecture decision relation that identifies the exact composite project work, says which architecture option is now pursued for it, and records what follows from that selection.

The problem is difficult because architecture decisions sit between structures and methods. C.30 keeps an obtaining ArchitectureRelation with its exact holon and selected U.Structure separate from an ArchitectureClaim carrying candidate, required, desired, or expected content. A project architecture decision can also tell developer roles which method description, architectural style, pattern use, or work boundary they must follow so that later work aims to produce or preserve the intended structures. For example, "use the client-server style here" is a method-use instruction whose intended result is a module and interaction structure of the described system. The decision relation must keep both sides visible: actual or modal structure content for the described or transformed-side holon, and method and Work expectations for exact systems, roles, assignments, and Work. When C.32.CONWAY supplies an influence-source architecture or selected structure, that source remains non-agentive and does not become the performer.

The problem is also multilevel. The architect may decide selected structures at one holon level while developers later refine lower-level structures. A decision must therefore say where the architect-owned architecture claim stops, where developer-owned refinement starts, which source detail must remain recoverable, and which result can reopen the decision. If that boundary is missing, architecture governance becomes either empty advice or uncontrolled micro-management.

Finally, architecture decisions are evolutionary. They are made under current candidate knowledge, current characteristic criteria, current eval readings, and current organization or tool constraints. They should be explicit enough for present work and cheap enough to supersede when a better candidate, changed characteristic pressure, or architecture-influence/transformed-side fit changes.

C.32.PAD solves the post-synthesis decision problem by making the decision relation explicit before any ADR-like publication projection is written.

#Forces

#Solution

Create ArchitectureDecisionRelation@Project before writing an ADR-like publication record. Treat it as the architecture decision relation that includes the exact composite project U.Work and binds it to the candidate basis, selected architecture option, affected structures, architecture-characteristic trade-offs, rationale, consequences, method expectations, work split, and reopen conditions.

Work in this order:

1. Name the exact composite project U.Work participant and the decision subject: described holon, bounded context, decision question, and status. If the decision designates a project system-of-interest, cite the exact existing U.System or the pre-inception intended-system claim, keep every Work/change/use fact separately governed, and cite a SystemOfInterestRole assignment only with its named A.2 role/taxonomy interpretation and separately obtaining A.2.1 assignment. A decision designation proves no compound project-selection truth; return missing-substrate[project-selection-conjunction] when that stronger truth is required.
2. Cite the candidate basis. Use C.32 for the candidate palette, C.32.MLAO for residual-reducing multilevel candidate frames, C.32.CONWAY when an influence-source architecture and transformed-side architecture content shaped the candidate, and C.32.FAIL for repaired candidate errors. Cite a C.32.CONWAY synthesis frame while either side is modal or the direct influence relation is unresolved; cite an exact pair row only for its already obtaining direct occurrence and two obtaining C.30 architecture-relation participants.
3. Cite comparison or selection input only when it exists. Explicit comparison belongs to A.19.CPM; set-returning selection belongs to A.19.SelectorMechanism; selected-set publication belongs to G.5; local choice belongs to C.11.
4. State the selected architecture option or bounded exception. Name the affected selected structures and the governing pattern for each structure claim.
5. Record the architecture-characteristic trade-off. Use criteria rows from C.32.ACS, eval results from C.32.ACE, measurement support from C.16, Q-Bundles from C.25, modularity or scale support from C.31, and C.29 structural-information lens uses for compressed recoverable structure, accepted description loss, hidden dependency, and source-return. None of those lenses, measures, or bundles decides the architecture by itself.
6. Record rationale, rejected options, accepted losses, and consequences. A rejected option can remain useful as a stepping stone or archive item; do not turn it into a failure unless the receiving failure pattern is triggered.
7. Bind the decision to architecture descriptions. Use C.30.AD for architecture-description adequacy and C.30.ASV for selected-structure view adequacy. A diagram, model, file, or view can describe the decision basis; it does not become the decision relation.
8. Bind the decision to method-use instructions when the architect needs developers to use a method, pattern, style, toolchain step, or work practice so the described or transformed-side holon is intended to gain or preserve the named structure. Use A.15, A.15.1, A.15.2, A.15.5, A.6.M, E.8, E.11.PUR, and C.24 according to the live claim.
9. State the architect-developer split. Name architect-owned selected structures, developer-owned refinement objects, source-return conditions, readiness exits, and governance exits. When the split depends on holon level, changed whole, or BOSC-triggered boundary pressure, fill holonTransitionOrBOSCTriggerRefs? through B.2.P claim-kind recovery or B.2 whole reidentification instead of leaving a generic level note.
10. Choose a publication projection only after the decision relation is clear. Use C.32.ADR for ADR-like publication projection; use E.17 and E.24.PUB for publication-face and publication-use claims.
11. Add evidence, assurance, gate, and governance exits only when those claims are being made. Use A.10, B.3, A.21, and the local governance pattern rather than adding those statuses to the decision relation by name.
12. Write reopen and supersession conditions. Reopen when the candidate basis changes, a protected architecture characteristic crosses its guardrail, an independently typed influence-source structure or arrangement no longer fits the transformed-side actual or modal architecture content, a stronger source changes the accepted loss, or the decision's method-use instruction proves unusable.

If one project question uses an E.18.NET network, first preserve that network's independent A.22/E.18.NET selection. A persistent project-network judgment stays in its C.2.1 result episteme under A.15.6, and architecture use docks through C.30.TFS-REL. A C.32.CONWAY exact pair row may be cited in architectureCorrespondenceRowRefs[] of a network record, but that citation is only a qualified reading: it adds no network member or cross-flow occurrence, and PAD repeats none of the network's member, relation, constraint, endpoint, or use-frame fields.

#Decision readiness

A C.32.PAD decision is ready to draft when the current decision relation identifies the exact composite project U.Work participant and can cite at least one candidate basis, one affected selected structure, one architecture-characteristic trade-off or declared reason for no live trade-off, one expected work consequence, one reopen condition, and any triggered holonTransitionOrBOSCTriggerRefs? or structuralInformationLensUseRefs? needed to preserve source return. When system-of-interest, role-assignment, architecture-influence, or network fields are present, their exact A.15.6, A.2/A.2.1, C.32.CONWAY, E.18.NET, and C.30.TFS-REL preconditions must already be satisfied or the reference remains absent.

If the candidate basis is absent, return to C.32. If architecture-characteristic rows are absent, return to C.32.ACS or C.25. If the decision only says "the metric is best", return to C.32.ACE, C.16, or A.19.CPM before deciding. If the intended work method is not recoverable, return to A.15. If an existing system, role assignment, project-network judgment, network selection, architecture use, or influence pair is unresolved, return to its direct owner and keep only the truthful designation, modal claim, candidate frame, or explicit stop in PAD.

#Constructive architecture decision path

Some architecture decisions are constructive: they prescribe methods that developer roles or other exact assigned systems are expected to use so that later Work aims to produce or preserve intended structures. Admit that path only when the decision names:

• the obtaining architecture relation and selected structure, or the exact modal ArchitectureClaim, to be produced or preserved;
• the method description, architectural style, pattern use, or work practice to be used;
• the exact responsible role and, when assignment identity matters, its separately obtaining U.RoleAssignment; never substitute an influence-source architecture, toolchain structure, or other non-agentive structure for the performer;
• the expected structure effect on the described or transformed-side holon, kept modal until its direct C.30 architecture predicate obtains;
• the work-planning boundary and readiness or gate exit;
• the source-return condition and reopen trigger.

This keeps architecture decisions connected to work without treating the decision description, ADR file, method description, selected network, influence-source structure, or performed Work as the architecture, performer, or proof that the expected structure effect obtains.

#Minimum sufficient relation and slot-change impact

A small complete PAD instance can be this short:

ArchitectureDecisionRelation@OrderFlow:
  decisionId: OrderFlowArchitectureDecision-2026Q3
  projectWorkOccurrenceRef: ProductFamilyQ3OrderArchitectureWork, exact admitted composite U.Work
  decisionSubjectRef: order-integration architecture for product-family Q3
  describedHolonRef: product-family order-flow system
  candidateBasisRefs: [C32CandidatePalette:order-flow-2026-06]
  selectedArchitectureOptionRefs: [event-carried integration with payment exception]
  selectedStructureEffects:
    - structureKindRef: module structure
      selectedStructureRef: order events between service modules
      decisionEffect: preserve service substitutability, accept added event-schema governance
      governingPatternRef: C.30.ASV
  architectureCharacteristicTradeoffs:
    - architectureCharacteristicRef: substitutability
      expectedGain: service replacement without order-flow rewrite
      acceptedLoss: additional schema-version coordination
      guardrailRef: version-skew eval band
  methodUseInstructions:
    - methodDescriptionRefOrPatternRef: event-schema change method
      expectedStructureEffect: compatible event contracts across service modules
      responsibleRoleRef: service-team developer role
      workBoundaryRef: team-owned schema refinement after architect-owned event boundary
  architectDeveloperSplit:
    architectOwnedStructureRefs: [event boundary, payment exception]
    developerOwnedRefinementRefs: [schema fields inside approved event boundary]
    sourceReturnCondition: return to PAD when refinement changes event boundary or version-skew band
  holonTransitionOrBOSCTriggerRefs?: [B.2.P: no new operational whole claimed for team-local schema refinement]
  structuralInformationLensUseRefs?: [C.29: event-flow view compresses deployment and rollout structure; source-return keeps model refs recoverable]
  publicationProjectionRef?: C.32.ADR:order-flow-adr
  reopenConditions: [payment latency guardrail crossed, schema-version coordination cost guardrail crossed]
  status: acceptedForDeveloperWork

When a filled field changes, repair the smallest owner that governs the changed content:

#Archetypal Grounding

Software service architecture. A platform team compares synchronous service calls, event-carried integration, and a bounded shared kernel. The selected option is event-carried integration for order events with a bounded exception for payment authorization. C.32.PAD records affected module and information structures, latency and substitutability trade-offs, the method-use instruction for service teams, the event-schema source-return condition, and the reopen trigger when payment volume crosses the declared eval band.

Manufacturing fixture architecture. A production architect compares a dedicated fixture per product, a universal fixture with adapters, and a mixed cell layout. The selected option uses a universal fixture only for products inside a scale window. C.32.PAD records module, placement, maintenance, and evidence-structure effects, the accepted setup-time loss, the method instruction for cell design, and the trigger for returning to candidate synthesis when adapter complexity exceeds the guardrail.

Project system-of-interest and network. A plant-modernization decision designates already admitted PumpUnit-3 : U.System as the project system-of-interest and cites exact composite PumpUpgradeWork-7. The designation does not create a project container or the compound truth that the project selected the pump. SystemOfInterestRole enters only with the named maintenance-role taxonomy and a separately obtaining PumpUnit-3-QualificationSystemOfInterestAssignment-7 : U.RoleAssignment; each work-to-pump, work-to-change, evaluation, production, or use fact keeps its own governor. An independently selected E.18.NET network may connect production-system change, pump change, and qualification flows for the named project question. PAD cites that exact network, the optional C.2.1 selection judgment, and the C.30.TFS-REL architecture-use trace; it does not recreate network identity or infer cross-flow relations from a record or C.32.CONWAY pair row. If the decision needs the still-unsupported compound project-selection truth, the case returns missing-substrate[project-selection-conjunction].

Method-family architecture. A review-method owner compares role-specialized review, peer rotation, and tool-supported triage. The selected option uses peer rotation plus a tool-supported evidence handoff. C.32.PAD records role, method, evidence, and information structures, the trade-off between teachability and evidence custody, and the developer-owned refinement boundary for local checklists.

Architecture influence and transformed-side fit. An automation project changes both a toolchain and the product it is used to change. C.32.CONWAY supplies a synthesis frame or, only after direct settlement, an exact architecture-influence pair row over the obtaining source-side and transformed-side C.30 architecture relations. C.32.PAD records which toolchain structure is decision-relevant, which product-side structure is selected or intended, which exact systems, assignments, methods, and Work are expected to realize the decision, and which fit change reopens it. The toolchain architecture and pair row neither act nor prove performance or actual transformation.

Digital-twin structural information loss. A built-asset team publishes a 6D-style digital-twin decision view for construction planning. The view intentionally hides supplier-contract and temporary-work structures. C.32.PAD records the selected building, placement, schedule, cost, operation, and evidence structures that the decision uses; C.29 records which hidden structures remain recoverable and which accepted loss reopens the decision. The view count, file, and model do not become the decision authority.

#Bias-Annotation

#Conformance Checklist

#Common Anti-Patterns and How to Avoid Them

#Consequences

#Rationale

C.32.PAD exists because candidate synthesis and architecture decision are different work moments. C.32 builds the option space; PAD commits the project to a current architecture option or bounded exception and records the method and work consequences of that commitment.

The pattern keeps four layers apart: an obtaining C.30 ArchitectureRelation over one exact architecture-bearing holon and selected U.Structure; any ArchitectureClaim that states actual, negative, unresolved, candidate, required, desired, or expected content about the holon, relation, or structure; ArchitectureDecisionRelation@Project, which connects exact composite project Work to the selected option and declared work consequences; and ArchitectureDecisionDescription@Project, whose project use is governed through C.30.AD and which can be published in ADR-like or other forms. Optional system-of-interest, role-assignment, architecture-influence, and network references retain their A.15.6, A.2/A.2.1, C.32.CONWAY, E.18.NET, and C.30.TFS-REL owners. This lets FPF reuse its existing architecture, description, method, work, evidence, assurance, measurement, publication, project, and network patterns instead of creating a separate architecture-decision ontology for those facts.

The pattern is architecture-reusable across holon kinds, not because every decision target is itself a holon kind. The same decision relation can apply to admitted holons such as systems, organizations-as-systems, built assets, AI-agent setups, epistemes, work occurrences, or disciplines, and it can also govern method-side, role-side, or evidence-side structures when those structures are kept under A.3.1, A.2.7, A.10, and A.15 rather than admitted as holons by label.

#SoTA-Echoing

These rows document transfers from source practice into C.32.PAD. Keep a source citation only when it changes a decision-relation field, boundary, or reopen condition.

Source-currentness boundary. Recheck a source row when an ADR template, architecture-description standard, evolutionary-architecture practice, FPF pattern, or project governance practice changes the decision field, method-work boundary, or reopen condition that PAD uses. Reopen only the affected optional docks if A.15.6 changes the actual/intended system or project-selection stop, A.2/A.2.1 changes the role/assignment boundary, C.32.CONWAY changes its frame or exact-pair threshold, or E.18.NET/C.30.TFS-REL changes network identity or architecture-use requirements.

#Relations

• Builds on: A.15.6, A.2, A.2.1, C.30, C.30.ASV, C.30.AD, C.30.TFS-REL, E.18.NET, C.32.P2S, C.32, C.32.MLAO, C.32.ACS, C.32.ACE, C.32.CONWAY, C.32.FAIL, C.25, C.16, C.29, C.31, and C.31.ASAP.
• Comparison and selection boundary: A.19.CPM compares, A.19.SelectorMechanism returns a selected set, G.5 publishes a selected set, and C.11 governs local choice. PAD records the architecture decision relation with its exact composite project-work participant after those inputs are sufficient.
• Description boundary: C.30.AD and C.30.ASV govern architecture-description and selected-structure view adequacy. PAD may cite those descriptions but does not replace them.
• Structural-information boundary: C.33, C.34, and C.35 may support PAD only for captured structure, lost structure, preservation adequacy, generated-carrier typing, or discovered-carrier typing used by the decision relation. PAD keeps decision relation, rationale, consequences, accepted losses, method consequences, work consequences, source-return, repair ownership, and supersession ownership.
• Publication boundary: C.32.ADR projects an ArchitectureDecisionDescription@Project into ADR-like form. E.17 and E.24.PUB govern publication faces and publication-use claims.
• Adequacy boundary: C.32.ADA evaluates a PAD decision relation, method docking, and publication projection for a declared use.
• P2S docking: P2S reaches PAD only when implementation commitment is live; PAD records the decision relation and returns reopen conditions to P2S when actual structures, eval results, or source-return change the architecture question.
• Project system-of-interest boundary: A.15.6 governs exact composite project Work, actual-versus-intended system designation, independent Work/change/use facts, project-network judgment, and missing-substrate[project-selection-conjunction]; A.2 and A.2.1 separately govern SystemOfInterestRole interpretation and obtaining assignment. PAD cites those objects only when the architecture decision uses them and proves none of them.
• Network and architecture-influence boundary: E.18.NET owns selected network identity, members, exact obtaining cross-flow occurrences, constraints, endpoints, and use frame; C.30.TFS-REL owns architecture use; C.32.CONWAY owns the synthesis frame and exact qualified pair row. PAD cites the smallest exact refs and never turns a record or row citation into network membership, a direct relation occurrence, actor identity, performance, or actual structure effect.
• Method and work boundary: A.15, A.15.1, A.15.2, A.15.5, E.8, E.11.PUR, and C.24 govern method descriptions, work plans, readiness, pattern-use recommendations, and agentic tool-use work.
• Evidence, assurance, and gate boundary: A.10, B.3, and A.21 govern evidence relations, assurance calculus, and gate profiles when those claims are current.

#Footer marker

C.32.PAD closes when ArchitectureDecisionRelation@Project names the exact composite project U.Work, decision subject, candidate basis, selected architecture option or bounded exception, affected structures, architecture-characteristic trade-offs, accepted losses, rationale, consequences, architecture-description refs, method-use and work-split expectations, source-return condition, triggered holon-transition or BOSC refs, triggered structural-information lens uses, publication projection exit, and reopen or supersession conditions. When the decision also cites a project system-of-interest, role assignment, architecture-influence correspondence, or transformation-flow network, each ref resolves to its exact separately governed object, every actual world-side relation is independently established, and the applicable A.15.6 project-selection stop and E.18.NET/C.30.TFS-REL non-duplication boundaries remain explicit.

#C.32.PAD:End

Last Updated: 2026-08-04 — upstream FPF commit 8b727cba (github.com/ailev/FPF)