C.32.PAD:10 - 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 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 composite project Work to the selected option and declared work consequences; and ArchitectureDecisionDescription@Project, which can be published in ADR-like or other forms and whose project use requires the exact composite U.Work and an independently obtaining use relation defined by its own pattern. Optional system-of-interest, local-kind, System-classification, assignment-species, assignment-occurrence, architecture-influence, and network references retain their A.15.6, A.2 and A.2.1, C.32.CONWAY, E.18.NET, and C.30.TFS-REL subject patterns. 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. It can also concern Method, evidence, or an exact object or relation recovered from role wording, provided those values stay under A.3.1, E.10.ROLE, A.2.7, A.10, and A.15 rather than being admitted as holons by label.