{"id":131,"date":"2026-03-13T23:59:25","date_gmt":"2026-03-13T23:59:25","guid":{"rendered":"https:\/\/dev.harmonic-framework.com\/whitepapers\/harmonic-design\/"},"modified":"2026-04-09T02:21:46","modified_gmt":"2026-04-09T07:21:46","slug":"harmonic-design","status":"publish","type":"page","link":"https:\/\/dev.harmonic-framework.com\/es\/whitepapers\/harmonic-design\/","title":{"rendered":"Harmonic Design"},"content":{"rendered":"

A Unified Software Engineering Framework<\/em><\/p>\n

Author:<\/strong> William Christopher Anderson
\nDate:<\/strong> April 2026
\nVersion:<\/strong> 1.0<\/p>\n

\n

Executive Summary<\/h2>\n

Four things are true of every long-lived software system. It has a backend that must evolve. It has an interface that must evolve. It has tests that must survive both kinds of evolution. And it has a project plan that must anticipate, sequence, and resource all three kinds of work. These four concerns are typically treated as separate disciplines, governed by separate frameworks, owned by separate mental models.<\/p>\n

Harmonic Design is the framework that eliminates this separation \u2014 and the friction it causes \u2014 by unifying all four concerns under a single structural discipline.<\/p>\n

Harmonic Design synthesizes four frameworks \u2014 Volatility-Based Decomposition (VBD) for backend system architecture, Experience-Based Decomposition (EBD) for interface architecture, Boundary-Driven Testing (BDT) for test strategy, and Project Design (PD) for project planning and execution \u2014 into a unified practice governed by a single structural map. That map is drawn once, from the volatility of the problem domain, and read at every layer.<\/p>\n

The structural parallel is exact. A Manager in the backend corresponds to an Experience in the interface; both are the primary subject of integration tests (real orchestrator, dependencies mocked) and of E2E tests (full stack); both map to integration milestone work packages in the project plan. An Engine corresponds to a Flow; both are the primary home of unit tests; both map to core work packages where most estimation effort concentrates. A Resource Accessor corresponds to an Interaction; both are exercised in unit tests for translation logic and mocked at the boundary in integration tests; both map to boundary work packages at integration points with external systems. Utility is Utility everywhere \u2014 in the architecture, in the tests, and in the project plan as shared infrastructure work. The roles carry the same responsibilities, the same communication rules, the same test profiles, and the same project planning characteristics at every layer because they isolate the same axes of anticipated change.<\/p>\n

The consequence of this coherence is significant. A change in business logic touches one Engine, one Flow, one set of unit tests, and one work package in the project plan \u2014 structurally bounded, predictably scoped, estimable from the architecture. A new user journey adds one Experience, one or more Flows, one E2E scenario, and one set of dependency edges in the project network. Testing difficulty at any layer signals the same class of structural problem: a boundary is in the wrong place. Estimation difficulty signals the same thing: if a work package is hard to estimate, the component it represents likely spans multiple volatility axes.<\/p>\n

One mental model explains the whole system. One diagnosis applies everywhere. One structural map governs what to build, how to verify it, and how to plan, estimate, schedule, and execute the work.<\/p>\n

Harmonic Design synthesizes its constituent frameworks into a unified whole. Each pillar retains its full set of rules, role definitions, and validation approach \u2014 but HD governs how they connect, how they reinforce each other, and how structural decisions at one layer propagate through all four. The result is a framework where volatility-first reasoning, applied consistently across backend, interface, tests, and project planning, produces structural isomorphism and predictable change propagation across every layer.<\/p>\n

\n

Abstract<\/h2>\n

Harmonic Design is a unified software engineering framework that applies a single organizing principle \u2014 isolating change along its natural axes \u2014 consistently across backend system architecture, interface architecture, test strategy, and project planning. HD synthesizes Volatility-Based Decomposition (VBD), Experience-Based Decomposition (EBD), Boundary-Driven Testing (BDT), and Project Design (PD) into a coherent whole: four pillars governed by one structural map, producing one mental model that holds across every layer of a software system and the project that delivers it. This paper describes the organizing principle, the structural isomorphism that connects the four pillars, the communication and state-flow rules that hold universally, and the emergent properties that arise when all four are practiced together. It offers validation criteria for HD coherence and positions the framework relative to existing methodologies.<\/p>\n

\n

1. Introduction<\/h2>\n

1.1 The Problem with Separate Frameworks<\/h3>\n

Software teams rarely suffer from a lack of frameworks. They suffer from frameworks that do not speak to one another.<\/p>\n

A team might apply Domain-Driven Design to their backend, atomic design to their component library, coverage targets to their test strategy, and agile ceremonies to their project management. Each framework is locally sensible. Together, they produce a system where the backend’s bounded contexts do not correspond to the frontend’s component hierarchy, the test strategy was written by convention rather than derived from the architecture, and the project plan was estimated from user stories rather than from the system’s structural dependencies. When something changes, the engineer must simultaneously reason in four different structural languages. The seams between frameworks become the places where coupling hides and where plans fail.<\/p>\n

The problem is not that the frameworks are wrong. It is that they answer different questions and produce different structural models. A system built across incompatible models carries hidden translation costs at every layer boundary \u2014 including the boundary between the system and the plan to build it.<\/p>\n

1.2 The Unifying Principle<\/h3>\n

Across four frameworks \u2014 VBD, EBD, BDT, and PD \u2014 developed independently and for different domains, the same insight recurs:<\/p>\n

Software should be organized by how it changes, not by what it currently does.<\/strong><\/p>\n

This is the claim of VBD: architect backend components around axes of anticipated change, not around functional domains. It is the claim of EBD: structure interface components around the axes of interface volatility \u2014 functional, structural, cross-cutting, environmental \u2014 not around screens or technical layers. It is the premise of BDT: tests are not a discipline separate from design; they are a mirror of the structure, and their difficulty is diagnostic evidence about where boundaries are wrong. And it is the foundation of PD: project plans derived from the architecture produce accurate estimates, because the components that constitute the work are the same components that isolate change, and the dependencies that constrain sequencing are the same dependencies that define communication rules.<\/p>\n

The same volatility axes appear at every layer. The same four roles \u2014 an orchestrating tier, an execution tier, an external-boundary tier, a cross-cutting tier \u2014 emerge at the backend, at the interface, in the test profile of each tier, and in the work package classification of the project plan. The same communication rules \u2014 state flows downward, results propagate upward as events, horizontal coordination within a tier is prohibited \u2014 hold universally. The same validation mechanism \u2014 trace a core scenario through the hierarchy without bypassing communication rules \u2014 applies to VBD, EBD, BDT, and PD alike.<\/p>\n

This is not coincidence. It is the consequence of asking the same fundamental question at every layer.<\/p>\n

1.3 What HD Is<\/h3>\n

Harmonic Design is the practice of applying volatility-first reasoning coherently, simultaneously, across backend architecture, interface architecture, test strategy, and project planning \u2014 producing a system whose layers are structurally isomorphic and whose project plan is derived from the same structural map.<\/p>\n

Coherent<\/em> has a specific meaning here. In physics, coherent waves are in phase \u2014 they reinforce each other rather than interfering. In Harmonic Design, the four structural models are in phase: the boundaries drawn for volatility reasons in the backend correspond to the boundaries drawn for volatility reasons in the interface, which correspond to the test scope at each level of the spiral, which correspond to the work package boundaries and dependency edges in the project network. They reinforce each other. A structural insight at one layer informs all layers simultaneously \u2014 including the project plan.<\/p>\n

Harmonic Design is a framework in its own right. Its contribution is not new roles, communication rules, test types, or estimation formulas \u2014 those belong to its constituent pillars. HD’s contribution is the structural discipline that connects them: the isomorphism rules, the coherence criteria, the diagnostic signals that cross layers, and the governance model that ensures all four pillars evolve together. Practicing the pillars in isolation produces good results. Practicing them as Harmonic Design produces structural properties that none achieves alone.<\/p>\n

1.4 Scope and Relationship to Constituent Frameworks<\/h3>\n

This paper assumes familiarity with VBD, EBD, BDT, and PD. Readers unfamiliar with any of these frameworks are strongly encouraged to consult the individual papers before proceeding; this paper does not repeat the detailed role definitions, communication rules, estimation formulas, or worked examples that each contains. Instead, it focuses on the connections between them: the structural isomorphism, the coherent communication model, the project planning isomorphism, and the emergent properties that arise from practicing all four together.<\/p>\n

\n

2. The Organizing Principle<\/h2>\n

2.1 Volatility as Architectural Truth<\/h3>\n

Every design decision is a bet about the future. The question is whether the bet is placed consciously or by default.<\/p>\n

Traditional decomposition strategies organize systems by what they do: functional layers, domain boundaries, technical tiers. These are structurally coherent bets about the present. They become structurally incoherent bets about the future when the system begins to evolve \u2014 because the things that change together are rarely the things that do the same kind of work.<\/p>\n

Volatility-first decomposition inverts the organizing question. Instead of asking “what does this component do?”, it asks “how does this component change, and what causes that change?” Components that change for the same reason \u2014 and at the same rate \u2014 belong together. Components that change for different reasons belong apart, regardless of their current functional relationship.<\/p>\n

This is the organizing principle of VBD, EBD, BDT, and PD. Applied to backend systems, it produces Managers, Engines, Resource Accessors, and Utilities. Applied to interface systems, it produces Experiences, Flows, Interactions, and Utilities. Applied to test strategy, it produces a test pyramid whose levels are determined by structural scope rather than convention. Applied to project planning, it produces work packages whose boundaries match component boundaries, dependencies that mirror architectural dependencies, and estimation targets whose volatility characteristics are already known. The principle is the same. The domain of application differs.<\/p>\n

2.2 The Four Universal Axes<\/h3>\n

The four axes of volatility that VBD identifies in backend systems appear in equivalent form at the interface layer:<\/p>\n\n\n\n\n\n\n\n\n
Axis<\/th>\nBackend Driver<\/th>\nInterface Driver<\/th>\n<\/tr>\n<\/thead>\n
Functional<\/td>\nBusiness rules, policy, domain logic<\/td>\nUser actions, field definitions, validation rules, journey composition, flow ordering, step conditions<\/td>\n<\/tr>\n
Non-Functional<\/td>\nPerformance, scalability, reliability<\/td>\nPerformance, responsiveness, offline capability<\/td>\n<\/tr>\n
Cross-Cutting<\/td>\nLogging, auth, observability, tracing<\/td>\nLocale, theme, validation conventions, error format<\/td>\n<\/tr>\n
Environmental<\/td>\nDatabases, external APIs, infrastructure<\/td>\nExecution platform \u2014 rendering environment (React, CLI, WinForms, mobile)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The axes are not identical \u2014 the specific pressures that drive functional change in a backend service differ from those that drive change in a form field. But the type<\/em> of change follows the same pattern, and the appropriate structural response is the same: isolate each axis in a dedicated role, enforce communication rules that prevent axis contamination, and let configuration drive composition within each axis.<\/p>\n

Figure 1a \u2014 Volatility capture in VBD.<\/strong> Functional volatility splits across two tiers: stable orchestration logic lives in the Manager; volatile execution logic lives in the Engine. Environmental volatility \u2014 external systems, data stores, service APIs \u2014 is isolated by Resource Accessors. Cross-cutting capabilities are provided by Utilities. Non-functional volatility (performance, scalability, reliability) is not owned by any single role. It is addressed by the coordinated structure: stable Manager boundaries, isolated Engine volatility, and clean Accessor seams together produce a system whose non-functional properties emerge from correct decomposition.<\/p>\n

graph TB\n    subgraph roles["Component Roles"]\n        FUNC[Functional]\n        ENVR[Environmental]\n        XCUT[Cross-Cutting]\n        MGR[Manager]\n        ENG[Engine]\n        ACC[Resource Accessor]\n        UTL[Utility]\n\n        FUNC -.->|stable layer| MGR\n        FUNC -.->|volatile layer| ENG\n        ENVR -.-> ACC\n        XCUT -.-> UTL\n    end\n\n    subgraph nf["Non-Functional \u2014 Performance \u00b7 Scalability \u00b7 Reliability"]\n        NF_DESC["Not owned by any single role.<br\/>Addressed through correct decomposition:<br\/>stable boundaries, isolated volatility,<br\/>and clean separation of concerns."]\n    end\n\n    style MGR fill:#0053e2,color:#fff,stroke-width:0\n    style ENG fill:#ffc220,color:#000,stroke-width:0\n    style ACC fill:#2a8703,color:#fff,stroke-width:0\n    style UTL fill:#636e72,color:#fff,stroke-width:0\n    style FUNC fill:#f0f4ff,stroke:#0053e2,color:#0053e2,stroke-width:2px\n    style ENVR fill:#f0f0f0,color:#444,stroke:#ccc\n    style XCUT fill:#f0f0f0,color:#444,stroke:#ccc\n    style NF_DESC fill:#f8f8f8,color:#555,stroke:#ddd,stroke-width:1px\n<\/code><\/pre>\n
Figure 1b \u2014 Volatility capture in EBD.<\/strong> The same pattern at the interface layer. Functional volatility spans all three active tiers: the Experience owns the stable journey orchestration, Flows own the volatile goal-directed execution, and Interactions are atomic surface units that can be composed \u2014 they have no external awareness and no backend communication. The Experience handles the Environmental axis, calling the backend API with accumulated state. Cross-cutting capabilities are provided by Utilities. Non-functional volatility (performance, responsiveness, offline capability) is not owned by any single tier. The event-driven structural model \u2014 async dispatch, local store, completion listeners \u2014 is the structural answer to non-functional requirements.<\/p>\n
graph TB\n    subgraph tiers["Interface Tiers"]\n        FUNC[Functional]\n        ENVR[Environmental]\n        XCUT[Cross-Cutting]\n        EXP[Experience]\n        FLW[Flow]\n        INT[Interaction]\n        UTL[Utility]\n\n        ENVR -.-> EXP\n        FUNC -.->|stable orchestration| EXP\n        FUNC -.->|volatile execution| FLW\n        FUNC -.->|atomic surface units| INT\n        XCUT -.-> UTL\n    end\n\n    subgraph nf["Non-Functional \u2014 Performance \u00b7 Responsiveness \u00b7 Offline"]\n        NF_DESC["Not tied to any single tier.<br\/>The event-driven model \u2014 async dispatch,<br\/>local store, completion listeners \u2014<br\/>is the structural answer."]\n    end\n\n    style EXP fill:#0053e2,color:#fff,stroke-width:0\n    style FLW fill:#ffc220,color:#000,stroke-width:0\n    style INT fill:#2a8703,color:#fff,stroke-width:0\n    style UTL fill:#636e72,color:#fff,stroke-width:0\n    style FUNC fill:#f0f4ff,stroke:#0053e2,color:#0053e2,stroke-width:2px\n    style ENVR fill:#f0f0f0,color:#444,stroke:#ccc\n    style XCUT fill:#f0f0f0,color:#444,stroke:#ccc\n    style NF_DESC fill:#f8f8f8,color:#555,stroke:#ddd,stroke-width:1px\n<\/code><\/pre>\n
\n
3. The Structural Isomorphism<\/h2>\n
3.1 One Map, Four Readings<\/h3>\n
The central claim of HD is structural isomorphism: the role taxonomy of VBD, the tier taxonomy of EBD, the test scope taxonomy of BDT, and the work package classification of PD map onto each other exactly. They are four readings of the same underlying structural map.<\/p>\n
Figure 2 \u2014 The Harmonic Design Structural Map: four tiers, each reading identically across VBD, EBD, BDT, and PD. The tiers are structurally isomorphic \u2014 the same position in each framework carries the same responsibilities and constraints. Note: VBD and EBD are parallel frameworks, not a call chain. A Manager does not call a Flow; an Experience does not call an Engine. Each framework governs its own layer. The isomorphism is structural, not communicative.<\/em><\/p>\n
%%{init: {'flowchart': {'padding': 20, 'nodeSpacing': 30, 'rankSpacing': 40}}}%%\ngraph TB\n    subgraph VBD["VBD \u2014 Backend"]\n        direction TB\n        MGR[Manager]\n        ENG[Engine]\n        ACC[Resource Accessor]\n    end\n\n    subgraph EBD["EBD \u2014 Interface"]\n        direction TB\n        EXP[Experience]\n        FLW[Flow]\n        INT2[Interaction]\n    end\n\n    subgraph BDT["BDT \u2014 Testing"]\n        BINT[Integration \u00b7 E2E \u00b7 UAT]\n        BUNT[Unit Tests]\n        BBNT[Unit Tests \u2014 translation only]\n    end\n\n    subgraph PD["PD \u2014 Planning"]\n        IMP[Integration Milestone WP]\n        CWP[Core Work Package]\n        BWP[Boundary Work Package]\n    end\n\n    subgraph UTL_ROW["Utility \u2014 consumed by all tiers across all frameworks"]\n        direction LR\n        VUTL([VBD \u00b7 Utility])\n        EUTL([EBD \u00b7 Utility])\n        BUTL([BDT \u00b7 Unit Tests])\n        SUTL([PD \u00b7 Shared Infrastructure])\n    end\n\n    MGR -->|invokes| ENG\n    MGR -->|invokes| ACC\n    ENG -->|may call| ACC\n\n    EXP -->|composed of| FLW\n    FLW -->|composed of| INT2\n\n    style MGR fill:#0053e2,color:#fff,stroke-width:0\n    style ENG fill:#ffc220,color:#000,stroke-width:0\n    style ACC fill:#2a8703,color:#fff,stroke-width:0\n    style EXP fill:#0053e2,color:#fff,stroke-width:0\n    style FLW fill:#ffc220,color:#000,stroke-width:0\n    style INT2 fill:#2a8703,color:#fff,stroke-width:0\n    style BINT fill:#0053e2,color:#fff,stroke-width:0\n    style BUNT fill:#ffc220,color:#000,stroke-width:0\n    style BBNT fill:#2a8703,color:#fff,stroke-width:0\n    style IMP fill:#0053e2,color:#fff,stroke-width:0\n    style CWP fill:#ffc220,color:#000,stroke-width:0\n    style BWP fill:#2a8703,color:#fff,stroke-width:0\n    style VUTL fill:#636e72,color:#fff,stroke-width:0\n    style EUTL fill:#636e72,color:#fff,stroke-width:0\n    style BUTL fill:#636e72,color:#fff,stroke-width:0\n    style SUTL fill:#636e72,color:#fff,stroke-width:0\n<\/code><\/pre>\n
The table form makes the correspondence precise:<\/p>\n\n\n\n\n\n\n\n\n
Tier<\/th>\nVolatility Axis<\/th>\nVBD Role<\/th>\nEBD Tier<\/th>\nBDT Scope<\/th>\nPD Work Package Type<\/th>\n<\/tr>\n<\/thead>\n
Orchestration<\/td>\nFunctional (stable)<\/td>\nManager<\/td>\nExperience<\/td>\nIntegration \u00b7 E2E \u00b7 UAT<\/td>\nIntegration Milestone<\/td>\n<\/tr>\n
Execution<\/td>\nFunctional (volatile)<\/td>\nEngine<\/td>\nFlow<\/td>\nUnit<\/td>\nCore Work Package<\/td>\n<\/tr>\n
External Boundary<\/td>\nEnvironmental<\/td>\nResource Accessor<\/td>\nInteraction<\/td>\nUnit (translation only)<\/td>\nBoundary Work Package<\/td>\n<\/tr>\n
Cross-Cutting<\/td>\nCross-Cutting<\/td>\nUtility<\/td>\nUtility<\/td>\nUnit<\/td>\nShared Infrastructure<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n
Non-Functional note:<\/strong> Performance, scalability, reliability, and responsiveness are not owned by any single tier. They are properties of the coordinated structure \u2014 Manager stability, Engine isolation, Accessor seams, and (in EBD) the event-driven model together produce the system’s non-functional characteristics.<\/p>\n
BDT note:<\/strong> Integration tests exercise the Orchestration tier \u2014 a real Manager or Experience with Execution and External Boundary dependencies mocked. The External Boundary tier’s own unit tests cover translation logic only; the tier is mocked at the seam in integration tests and real in E2E.<\/p>\n
PD note:<\/strong> The work package type determines estimation characteristics. Core work packages (Engines\/Flows) carry the highest functional volatility and therefore the widest estimation ranges. Integration milestones (Managers\/Experiences) are estimated primarily by the number and complexity of seams they coordinate. Boundary work packages (Accessors) are estimated by the complexity of the external system contract. Shared infrastructure (Utilities) is typically estimated with the tightest ranges, as cross-cutting concerns change least frequently.<\/p>\n<\/blockquote>\n
3.2 What Isomorphism Means in Practice<\/h3>\n
Structural isomorphism means that a developer who understands VBD can read the EBD structure without relearning. The role names differ; the structural position and responsibilities are the same. An Experience orchestrates, does not execute, and communicates downward \u2014 exactly as a Manager does. A Flow executes one goal’s logic, does not coordinate siblings, and communicates results upward \u2014 exactly as an Engine does. A Utility is consumed, never coordinates \u2014 in both frameworks identically.<\/p>\n
More practically, it means that when a developer encounters a structural problem in one layer, they know where to look in the other layers. An Engine with too many responsibilities will have a corresponding Flow with too many responsibilities. A Manager that is doing its own business logic will have a corresponding Experience doing its own API calls. The misalignment propagates coherently \u2014 which means fixing it in one layer guides fixing it in the others.<\/p>\n
For teams, isomorphism reduces the cognitive load of full-stack development. There is one structural model, read at four levels. A senior engineer does not need to context-switch between “backend thinking,” “frontend thinking,” “test thinking,” and “planning thinking” \u2014 they apply the same volatility analysis, draw the same tier map, and verify the same communication rules. The domain of the code changes; the structural discipline does not.<\/p>\n
\n
4. The Universal Communication Model<\/h2>\n
4.1 State Flows Downward; Results Surface as Events<\/h3>\n
The communication model is identical in VBD and EBD, determines the mock structure in BDT, and defines the dependency edges in PD.<\/p>\n
In VBD: orchestration intent flows downward from Manager to Engine to Resource Accessor. Results return upward through function returns and structured response types. Managers do not receive unsolicited signals from Engines; they invoke and receive. Engines do not coordinate with sibling Engines; they are invoked and return. Resource Accessors do not apply business logic; they translate and return. Only Managers emit and consume events; async dispatch, pub\/sub, and queued messaging are Manager-layer concerns. Engines and Resource Accessors operate synchronously within a request.<\/p>\n
In EBD: configuration drives the Experience, which passes shared state downward to Flows. Flows pass props and callbacks to Interactions. Interactions emit atomic events upward to their parent Flow. Flows emit completion events upward to the Experience. The Experience holds the accumulated journey state and is the only tier that communicates outward to the backend API.<\/p>\n
In PD: the same downward flow determines the project network. Manager work packages depend on Engine work packages, which depend on Accessor work packages. The dependency direction in the project network mirrors the communication direction in the architecture. This is not a convention \u2014 it is a structural consequence. You cannot build a Manager before the Engines it coordinates exist; you cannot integrate before the components being integrated are complete.<\/p>\n
Figure 3a \u2014 VBD backend communication: state invoked downward, results returned upward.<\/strong><\/p>\n
graph TB\n    subgraph chain["Call Chain"]\n        direction TB\n        MGR[Manager]\n        ENG[Engine]\n        ACC1[Resource Accessor]\n        ACC2[Resource Accessor]\n        EXT[External System]\n        MGR --> ENG\n        MGR --> ACC2\n        ENG --> ACC1\n        ACC1 --> EXT\n        ACC2 --> EXT\n    end\n\n    UTL([Utility \u2014 consumed by any role])\n\n    subgraph rule["The Rule"]\n        RULE["Manager \u2192 Engine \u00b7 Manager \u2192 Resource Accessor \u00b7 Engine \u2192 Resource Accessor<br\/>No one calls up the chain \u00b7 No sideways calls<br\/>Engines never call other Engines \u2014 Manager composes instead<br\/>Only Managers may communicate sideways \u2014 async only<br\/>No Accessor calls an Engine or another Accessor"]\n    end\n\n    style MGR fill:#0053e2,color:#fff,stroke-width:0\n    style ENG fill:#ffc220,color:#000,stroke-width:0\n    style ACC1 fill:#2a8703,color:#fff,stroke-width:0\n    style ACC2 fill:#2a8703,color:#fff,stroke-width:0\n    style EXT fill:#f0f0f0,color:#444,stroke:#ccc\n    style UTL fill:#636e72,color:#fff,stroke-width:0\n    style RULE fill:#f8f8f8,color:#444,stroke:#ddd,stroke-width:1px\n<\/code><\/pre>\n
Figure 3b \u2014 EBD interface communication: config drives Experience, state passes down, events propagate up. Experience alone calls the backend.<\/strong><\/p>\n
graph TB\n    CFG[Config]\n    EXP[Experience]\n    FLW[Flow]\n    INT[Interaction]\n    UTL[Utility]\n    API[Backend API]\n\n    CFG -->|drives| EXP\n    EXP -->|composed of| FLW\n    FLW -->|passes props| INT\n    INT -.->|emits event| FLW\n    FLW -.->|emits completion| EXP\n    EXP -->|calls with accumulated state| API\n    FLW -->|consumes| UTL\n    INT -->|consumes| UTL\n\n    style EXP fill:#0053e2,color:#fff,stroke-width:0\n    style FLW fill:#ffc220,color:#000,stroke-width:0\n    style INT fill:#2a8703,color:#fff,stroke-width:0\n    style UTL fill:#636e72,color:#fff,stroke-width:0\n    style CFG fill:#f0f0f0,color:#444,stroke:#ccc\n    style API fill:#f0f0f0,color:#444,stroke:#ccc\n<\/code><\/pre>\n
4.2 The Prohibited Patterns Are the Same<\/h3>\n
The communication rules in VBD and EBD prohibit the same structural violations, expressed in the terms of their respective domains:<\/p>\n\n\n\n\n\n\n\n\n
Rule<\/th>\nVBD<\/th>\nEBD<\/th>\n<\/tr>\n<\/thead>\n
No peer coordination<\/td>\nEngines must not call sibling Engines<\/td>\nFlows must not call sibling Flows<\/td>\n<\/tr>\n
No boundary-skipping<\/td>\nAccessor must not call Engines or peer Accessors<\/td>\nInteractions must not consume other Interactions<\/td>\n<\/tr>\n
No external calls below orchestration<\/td>\nEngines do not call external systems; Accessors do<\/td>\nFlows do not call the backend API; the Experience does<\/td>\n<\/tr>\n
Cross-cutting is consumed<\/td>\nAny role may consume Utilities<\/td>\nAny tier may consume Utilities<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
These are not parallel analogies. They are the same prohibition \u2014 horizontal coordination within a tier, and external coupling below the orchestration tier \u2014 applied to the specific roles and artifacts of each layer.<\/p>\n
4.3 Consequence for Test Structure<\/h3>\n
In BDT, where you place mocks follows directly from these communication rules. You mock at the role boundary because the role boundary is where the communication rule enforcement happens. If an Engine must not call sibling Engines, a unit test for that Engine needs exactly one mock: the Resource Accessor below it. If a Manager must not call peer Managers synchronously, an integration test for a Manager needs all its dependencies mocked \u2014 both the Engines and the Resource Accessors it orchestrates. The integration test verifies the Manager’s orchestration logic and seam contracts, not the behavior of its dependencies. The test topology is derived from the communication topology. There is nothing to negotiate.<\/p>\n
4.4 Consequence for Project Structure<\/h3>\n
In PD, the communication topology becomes the project network topology. Dependencies between work packages follow the same direction as dependencies between components:<\/p>\n
    \n
  • Utility work packages have no upstream dependencies and form the leaf nodes of the project network.<\/li>\n
  • Accessor work packages depend on Utility and infrastructure work packages.<\/li>\n
  • Engine work packages depend on Accessor work packages.<\/li>\n
  • Manager work packages depend on Engine and Accessor work packages.<\/li>\n
  • Integration milestones depend on the Manager work packages that compose them.<\/li>\n<\/ul>\n
    This ordering is not arbitrary. It is the natural consequence of the communication model: you cannot build what orchestrates before you build what is orchestrated. The project network is derived from the architecture. There is nothing to negotiate here either.<\/p>\n
    \n
    5. The Four Frameworks as Pillars<\/h2>\n
    The following sections briefly characterize each framework’s core contribution within Harmonic Design. Each framework is documented in full in its individual paper; what matters here is understanding how each pillar carries the same structural weight in the unified practice.<\/p>\n
    5.1 VBD \u2014 The Backend Structural Model<\/h3>\n
    Volatility-Based Decomposition establishes the structural model for backend systems. It identifies four volatility axes and assigns each to a dedicated component role: Managers for non-functional\/orchestration concerns, Engines for functional business logic, Resource Accessors for environmental and infrastructural concerns, and Utilities for cross-cutting concerns. It enforces communication rules that prevent volatility contamination across role boundaries and validates the structural model against a small set of core use cases.<\/p>\n
    VBD’s primary contribution to HD: the role taxonomy, the volatility axis framework, and the proof that organizing backend systems by anticipated change produces systems that can absorb that change without widespread refactoring.<\/p>\n
    The key rule that carries into HD: boundaries should reflect volatility, not current functional grouping.<\/strong><\/p>\n
    5.2 EBD \u2014 The Interface Structural Model<\/h3>\n
    Experience-Based Decomposition applies the same volatility-first logic to interface systems. It establishes three behavioral tiers \u2014 Experiences, Flows, and Interactions \u2014 plus Utilities, each isolating one of the four interface volatility axes. It enforces the same downward state flow and upward event propagation model. It adds one critical rule with no backend equivalent: the Experience is the exclusive communicator with the backend API. Flows never call the API. The Experience accumulates complete journey state across all its Flows and decides when and what to emit.<\/p>\n
    One clarification worth stating explicitly: the tier hierarchy describes behavioral scope, not a rigid nesting requirement. An Experience can directly host an Interaction when the scope is genuinely minimal \u2014 a single dropdown, a confirmation toggle, a preference that requires no multi-step sequence. The tier exists to contain a complete goal-directed sequence; when the goal is atomic, no Flow is needed between the Experience and the Interaction. The rule is that Interactions never coordinate laterally or bypass upward \u2014 not that a Flow must always be present.<\/p>\n
    EBD’s primary contribution to HD: the demonstration that the same structural logic that governs backend systems governs interface systems, with the same tier count, the same communication discipline, and the same validation mechanism.<\/p>\n
    The key rule that carries into HD: the orchestrating tier (Experience \/ Manager) is the only tier that crosses the system boundary outward.<\/strong><\/p>\n
    5.3 BDT \u2014 The Test Strategy Map<\/h3>\n
    Boundary-Driven Testing maps the test spiral to the structural models defined by VBD and EBD. It establishes that the test type is determined by the structural tier under test: Engines and Flows belong at unit scope, seams between tiers belong at integration scope, complete journeys belong at E2E scope. It treats mock placement as an architectural statement \u2014 you mock at boundaries because boundaries are the architecturally significant seams \u2014 and reads test difficulty as structural evidence.<\/p>\n
    BDT’s primary contribution to HD: the demonstration that structural coherence and testing tractability are the same thing. A system with correct boundaries is easy to test. Testing difficulty is diagnostic of structural problems, not of test strategy problems.<\/p>\n
    The key rule that carries into HD: the test spiral is not a testing methodology; it is a structural map. Fix the structure and the tests follow.<\/strong><\/p>\n
    5.4 PD \u2014 The Project Planning Model<\/h3>\n
    Project Design derives the project plan from the architectural decomposition. Components become work packages. Dependencies between components become the project network. The critical path through that network determines the project duration. Compression and decompression of that path determine the feasible range of schedules. Risk is quantified objectively from the float distribution across all activities. The result is not a single plan but a set of viable options \u2014 typically three \u2014 spanning conservative, balanced, and aggressive approaches.<\/p>\n
    PD establishes several principles that carry directly into HD. The activity inventory is architecture-derived: each component identified during VBD or EBD decomposition becomes a work package with a predictable lifecycle (design, implementation, unit testing, integration). Each pair of connected components generates an integration activity. Each core use case generates a system-level verification activity. The one-to-one rule \u2014 each component assigned to one developer \u2014 is a direct consequence of the same boundary discipline that governs the architecture: if a component cannot be built by one developer within the project timeline, it should be decomposed further, and this is an architectural problem, not a staffing problem.<\/p>\n
    PD’s primary contribution to HD: the demonstration that the same structural map that governs what to build and how to verify it also governs how to plan, estimate, schedule, and execute the work. The architecture is the plan.<\/p>\n
    The key rule that carries into HD: you cannot estimate what you have not designed. The architecture must precede the estimate, because the architecture defines the work.<\/strong><\/p>\n
    \n
    6. The Project Design Isomorphism<\/h2>\n
    6.1 The Architecture Is the Plan<\/h3>\n
    The deepest structural connection between PD and the other three pillars is not analogical \u2014 it is definitional. In Project Design, the project plan is not constructed from requirements, user stories, or feature lists. It is derived from the architectural decomposition. This means the same structural map that VBD uses to organize backend components and EBD uses to organize interface components is the map that PD uses to organize the project.<\/p>\n
    Every VBD component \u2014 every Manager, Engine, Resource Accessor, and Utility \u2014 becomes a work package. Every EBD component \u2014 every Experience, Flow, Interaction, and Utility \u2014 becomes a work package. Every dependency arrow in the architecture diagram becomes a precedence relationship in the project network. The critical path through the project is the critical path through the architecture’s dependency graph. The architecture is the plan.<\/p>\n
    This is not a metaphor. When an architect draws a dependency from SchedulingManager<\/code> to EligibilityEngine<\/code>, that arrow means two things simultaneously: at runtime, the Manager invokes the Engine; in the project plan, the Engine work package must complete before the Manager work package can begin integration. The same arrow. Two readings. One structural truth.<\/p>\n
    6.2 Work Package Classification Follows Tier Classification<\/h3>\n
    The tier classification in VBD and EBD directly determines the characteristics of each work package in PD:<\/p>\n
    Orchestration tier (Manager \/ Experience) \u2014 Integration Milestone Work Packages.<\/strong> These work packages are primarily integration work. The Manager or Experience itself contains minimal logic \u2014 it orchestrates. Its work package is therefore dominated by integration effort: wiring the seams, verifying the contracts, handling the error propagation paths. Estimation for these work packages focuses on the number and complexity of seams, not on algorithmic complexity. They are typically on or near the critical path because they depend on everything below them.<\/p>\n
    Execution tier (Engine \/ Flow) \u2014 Core Work Packages.<\/strong> These are where the domain logic lives, and where most estimation effort should concentrate. Engines and Flows carry the highest functional volatility \u2014 they embody the business rules and user-facing logic that change most frequently. This volatility translates directly into estimation uncertainty: the work packages for Engines and Flows should carry the widest estimation ranges. They are the components most likely to require design iteration, and the components whose scope is most likely to be affected by requirement changes during execution.<\/p>\n
    External Boundary tier (Resource Accessor \/ Interaction) \u2014 Boundary Work Packages.<\/strong> These work packages are defined by the complexity of the external system they interface with. The component itself is simple \u2014 translation logic only, no business rules. But the work to build and verify it depends on the external system’s contract stability, documentation quality, and availability for integration testing. Estimation for boundary work packages should account for external system risk, which is often the dominant factor.<\/p>\n
    Cross-Cutting tier (Utility) \u2014 Shared Infrastructure Work Packages.<\/strong> Utilities are the most stable tier \u2014 they change least frequently, they have no domain-specific knowledge, and they have no upstream dependencies. Their work packages are the most parallelizable and carry the tightest estimation ranges. They form the leaf nodes of the project network, enabling early construction starts.<\/p>\n
    Figure 5 \u2014 Work package classification derived from the structural map. Each VBD\/EBD tier maps to a PD work package type with distinct estimation characteristics.<\/em><\/p>\n
    graph TB\n    subgraph PlanView["Project Network"]\n        IM[Integration Milestones<br\/>Manager \u00b7 Experience WPs]\n        CWP[Core Work Packages<br\/>Engine \u00b7 Flow WPs]\n        BWP[Boundary Work Packages<br\/>Accessor \u00b7 Interaction WPs]\n        SWP[Shared Infrastructure<br\/>Utility WPs]\n    end\n\n    subgraph EstView["Estimation Characteristics"]\n        IME[Seam count drives estimate]\n        CWPE[Domain logic drives estimate<br\/>Widest estimation range]\n        BWPE[External contract drives estimate<br\/>External system risk dominant]\n        SWPE[Stable scope \u2014 tightest range]\n    end\n\n    IM -->|depends on| CWP\n    IM -->|depends on| BWP\n    CWP -->|depends on| BWP\n    SWP -.->|consumed by all| IM\n\n    IM -.- IME\n    CWP -.- CWPE\n    BWP -.- BWPE\n    SWP -.- SWPE\n\n    style IM fill:#0053e2,color:#fff,stroke-width:0\n    style CWP fill:#ffc220,color:#000,stroke-width:0\n    style BWP fill:#2a8703,color:#fff,stroke-width:0\n    style SWP fill:#636e72,color:#fff,stroke-width:0\n    style IME fill:#0053e2,color:#fff,stroke-width:0\n    style CWPE fill:#ffc220,color:#000,stroke-width:0\n    style BWPE fill:#2a8703,color:#fff,stroke-width:0\n    style SWPE fill:#636e72,color:#fff,stroke-width:0\n<\/code><\/pre>\n
    6.3 Dependencies Mirror Communication Rules<\/h3>\n
    The communication rules enforced by VBD and EBD \u2014 state flows downward, results propagate upward, no peer coordination \u2014 produce a specific dependency topology. That same topology is the project network.<\/p>\n
    In the architecture: Managers invoke Engines; Engines invoke Accessors; Accessors invoke external systems. No Engine invokes a sibling Engine. No Accessor applies business logic.<\/p>\n
    In the project plan: Manager work packages depend on Engine work packages; Engine work packages depend on Accessor work packages; Accessor work packages depend on infrastructure. No Engine work package depends on a sibling Engine work package (because the components do not communicate). No Accessor work package depends on an Engine work package (because Accessors do not call Engines).<\/p>\n
    The prohibited patterns in the architecture are the prohibited patterns in the project plan. If an Engine calls a sibling Engine \u2014 a communication rule violation \u2014 the corresponding project network would show a dependency between peer work packages, creating a cycle or an unnecessary coupling that complicates the critical path. The communication discipline that produces clean architecture also produces clean project networks.<\/p>\n
    6.4 Risk Maps to Volatility<\/h3>\n
    In PD, risk is quantified objectively from the float distribution across all activities. Activities with zero float are on the critical path and carry maximum risk. Activities with large float can absorb delays.<\/p>\n
    In HD, the volatility axis framework provides an additional dimension to this risk analysis. The most volatile tiers \u2014 Engines and Flows, which carry functional volatility \u2014 are the most likely to experience scope change, design iteration, and estimation error during execution. VBD already identifies these components as the functionally volatile tier. PD already identifies the most schedule-sensitive activities through float analysis. When both analyses converge on the same components \u2014 when a functionally volatile Engine with a wide estimation range is also on the critical path with zero float \u2014 the risk is compound, and the project plan should reflect this.<\/p>\n
    Conversely, the most stable tiers \u2014 Utilities, which carry cross-cutting volatility that changes infrequently \u2014 are the safest components on the schedule. Their estimation ranges are tight, their scope is unlikely to change, and their position as leaf nodes in the network means they have the most float. The volatility analysis and the float analysis agree: these are low-risk work packages.<\/p>\n
    This convergence is not a coincidence. It is a structural consequence of deriving both the architecture and the project plan from the same volatility map. The architecture identifies what changes most. The project plan identifies what is most schedule-sensitive. When both are derived from the same map, the high-volatility components and the high-risk activities are the same things \u2014 which means risk mitigation strategies (assigning the best resources, providing wider estimation ranges, investing in design iteration) target the right components automatically.<\/p>\n
    6.5 Staffing Follows Architecture<\/h3>\n
    PD establishes the one-to-one rule: each component is assigned to one developer. This is a direct application of Conway’s Law \u2014 the interaction between team members mirrors the interaction between the components they build. A well-decomposed architecture with minimized inter-component coupling naturally minimizes inter-developer communication overhead.<\/p>\n
    In HD, this principle extends further. Because the architecture already organizes components by volatility tiers, and because volatility tiers map to estimation characteristics and risk profiles, staffing assignments can be made tier-aware:<\/p>\n
      \n
    • The best resources are assigned to critical-path Engine work packages \u2014 the most volatile, most uncertain, most estimatively risky components.<\/li>\n
    • Boundary work packages (Accessors) are assigned to developers with the most experience with the specific external systems involved.<\/li>\n
    • Utility work packages are assigned flexibly \u2014 their tight estimation ranges and high float make them the most forgiving assignments.<\/li>\n
    • Integration milestone work packages (Managers\/Experiences) are assigned to senior developers who understand the seam contracts \u2014 because integration work is primarily coordination work, and coordination requires structural understanding.<\/li>\n<\/ul>\n
      Team boundaries align with volatility boundaries, which align with component boundaries, which align with work package boundaries. One structural map governs all four.<\/p>\n
      \n
      7. Coherence Properties<\/h2>\n
      When VBD, EBD, BDT, and PD are practiced together as HD \u2014 when the same volatility map governs the backend, the interface, the test strategy, and the project plan simultaneously \u2014 emergent properties appear that none of the individual frameworks produces in isolation.<\/p>\n
      7.1 Change Locality Across All Layers<\/h3>\n
      In an HD system, a change in requirements touches exactly one component at each tier, across all layers \u2014 including the project plan.<\/p>\n
      A new pricing rule touches one Engine in the backend. At the interface, the same change might modify one Flow that presents pricing information. In the test suite, the unit tests for that Engine are updated, the unit tests for that Flow are updated, and the integration test for the Manager-to-Engine seam is updated if the contract changes. In the project plan, the change is one new work package, one new dependency edge, one recalculation of the critical path. Everything else is unaffected.<\/p>\n
      This is stronger than any individual framework achieves alone. VBD localizes backend change. EBD localizes interface change. BDT localizes test change. PD localizes planning change. HD localizes change across all four simultaneously, because the boundaries at each layer correspond. The blast radius is structurally bounded at every layer, not just one.<\/p>\n
      The project plan absorbs architectural change the same way the architecture absorbs requirement change. A new Engine means one new work package, one new dependency edge, one recalculation of the critical path. The plan does not need to be replanned from scratch. It absorbs the change structurally, because its structure mirrors the architecture’s structure.<\/p>\n
      7.2 Test Scope Determinism<\/h3>\n
      In an HD system, a developer never has to ask “what kind of test should I write for this?” The answer is structurally determined.<\/p>\n
      If the component is an Engine or a Flow \u2014 execution tier, functional volatility \u2014 write unit tests. Mock the Accessor or API boundary below. Assert all contract states.<\/p>\n
      If the component is a Manager or Experience \u2014 orchestration tier \u2014 write integration tests at each of its seams. Mock the Engines or Flows it orchestrates. Verify that it correctly handles every state each dependency can emit.<\/p>\n
      If you are verifying a complete user journey \u2014 full stack \u2014 write an E2E test. No mocks. Real infrastructure.<\/p>\n
      The test pyramid is not a recommendation. It is a consequence of the structure. A system with correct HD boundaries produces a correctly shaped pyramid naturally, without any team convention or coverage mandate.<\/p>\n
      7.3 Estimation Accuracy from Volatility Alignment<\/h3>\n
      In an HD system, estimation targets are volatility-aligned. This means the components being estimated are already classified by their anticipated rate of change, and the estimation approach can be calibrated accordingly.<\/p>\n
      High-volatility components (Engines, Flows) get wider estimation ranges \u2014 because they embody the business rules and user-facing logic most likely to change during execution. These are the components where design iteration is most likely, where scope clarification takes the longest, and where estimation error is historically largest. The architecture already identifies them. The estimation process can account for their uncertainty from the start, rather than discovering it during execution.<\/p>\n
      Stable components (Managers, Utilities) get tighter estimation ranges \u2014 because their scope is well-defined, their logic is minimal (orchestration or cross-cutting), and their change rate is low. The architecture already identifies their stability. The estimation process can trust their scope.<\/p>\n
      This calibration is not possible when estimating from requirements or user stories, because requirements do not carry volatility information. A user story about “pricing calculation” gives no structural signal about whether the work is an Engine (high volatility, wide range), a Manager (low volatility, tight range), or an Accessor (external system risk). The HD structural map provides that signal before estimation begins.<\/p>\n
      7.4 Structural Legibility<\/h3>\n
      An HD system has one structural model, not four. Any engineer who understands that model \u2014 the four tiers, their volatility axes, their communication rules \u2014 can navigate the backend, the interface, the test suite, and the project plan using the same conceptual vocabulary.<\/p>\n
      This has compounding effects on team organization and onboarding. An engineer learning VBD implicitly learns EBD’s tier structure, because the structural logic is the same. An engineer who understands why Engines do not call sibling Engines automatically understands why Flows do not call sibling Flows. A project manager who understands the dependency graph in the project network automatically understands the communication topology in the architecture \u2014 because they are the same graph. The mental overhead of learning a new layer is reduced to learning the domain-specific vocabulary, not a new structural theory.<\/p>\n
      7.5 Diagnostic Consistency<\/h3>\n
      Testing difficulty in HD is a single diagnostic, not four separate ones. When something is hard to test at any level \u2014 hard to unit test, hard to write integration tests for, hard to write stable E2E tests for \u2014 the diagnosis is always the same: a boundary is in the wrong place.<\/p>\n
      Hard-to-unit-test Engine: it has absorbed Accessor responsibilities, or it is calling a sibling Engine. Hard-to-unit-test Flow: it is making API calls it should not make, or it is aware of sibling Flows. Hard-to-write-integration-test-for Manager: its seams are not well-defined, or its Accessors are embedded rather than injected. Unstable E2E: the Experience does not represent a complete, semantically stable journey.<\/p>\n
      Hard-to-estimate work package: the component it represents spans multiple volatility axes \u2014 an Engine that also does orchestration, an Accessor that also applies business rules. If the component were correctly decomposed, each resulting work package would be estimable in isolation.<\/p>\n
      The same structural analysis resolves all of these. There is no separate “test problem” or “estimation problem” to debug. There is only a structural problem, and the structural model tells you exactly where it is.<\/p>\n
      7.6 Risk Quantification from Architecture<\/h3>\n
      In a conventional project, risk is assessed subjectively \u2014 experienced practitioners identify likely failure modes and assign probability and impact scores. In an HD system, risk is quantified objectively from two converging sources: the float distribution in the project network (PD) and the volatility classification of each component (VBD\/EBD).<\/p>\n
      Activities with zero float are on the critical path \u2014 maximum schedule risk. Components with high functional volatility carry maximum estimation uncertainty. When a zero-float activity corresponds to a high-volatility Engine, the risk is compound and quantifiable. When a high-float activity corresponds to a stable Utility, the risk is minimal and the float can be traded for staffing flexibility.<\/p>\n
      This convergence means risk mitigation is architectural, not managerial. You do not manage risk by adding buffers to a plan estimated from requirements. You manage risk by ensuring that high-volatility components have adequate float in the project network, that the best resources are assigned to volatile critical-path activities, and that the architecture itself minimizes the number of high-volatility components on the critical path \u2014 which is an architectural decision, not a project management decision.<\/p>\n
      7.7 Configuration-Driven Composition at Every Layer<\/h3>\n
      VBD establishes the principle that configuration should drive composition \u2014 that architectural variants should be produced by supplying different configuration, not by writing different code. EBD applies the same principle at the interface layer: an Experience composes different Flows based on the configuration it receives, without changing the Flows themselves.<\/p>\n
      In an HD system, this principle holds across all layers simultaneously. The same configuration that selects a backend policy variant (a Manager receives different Engine parameters) also drives interface composition (an Experience presents different Flows) and is verified by the same E2E scenario with different configuration inputs. Configuration is a first-class citizen of the architecture, not an afterthought.<\/p>\n
      \n
      8. Configuration as a First-Class Citizen<\/h2>\n
      8.1 The Configurability That Correct Structure Enables<\/h3>\n
      Every team wants systems that can be configured rather than recoded. Few achieve it consistently, because configuration-driven behavior requires structural preconditions that are rarely designed for explicitly. Harmonic Design creates those preconditions as a natural consequence of correct decomposition.<\/p>\n
      The precondition is simple to state: configuration can only drive behavior when the things that vary are cleanly separated from the things that stay the same. In a system where business rules are interwoven with orchestration logic, where API calls are embedded in flows, where test scaffolding is entangled with component logic \u2014 configuration has nowhere to attach. Every configuration variant requires a code change.<\/p>\n
      In a Harmonic Design system, the structure creates natural attachment points at every tier:<\/p>\n
        \n
      • Managers<\/strong> receive configuration that determines which Engines to invoke and in what order \u2014 without embedding that logic inside any Engine.<\/li>\n
      • Experiences<\/strong> receive configuration that determines which Flows to compose, in what sequence, under what conditions \u2014 without embedding that logic inside any Flow.<\/li>\n
      • Engines<\/strong> and Flows<\/strong> receive parameterized inputs that shape their behavior \u2014 without knowing where those parameters came from or what else is running alongside them.<\/li>\n<\/ul>\n
        The result is a system where new behavioral variants are produced by writing configuration, not code.<\/p>\n
        8.2 Configuration-Driven Composition in Practice<\/h3>\n
        The most powerful expression of this principle is not configuration that tweaks a parameter \u2014 it is configuration that assembles entire systems.<\/p>\n
        When Managers are stable orchestrators and Engines are stateless executors, a Manager can be driven entirely by a configuration schema: which Engines to invoke, in what order, under what conditions, with what inputs. A new workflow is a new configuration block, not a new codebase.<\/p>\n
        When Experiences compose Flows based on configuration, and Flows render Interactions based on their own configuration, an entirely new user journey \u2014 different steps, different conditions, different validation \u2014 can be created from a YAML file. The code is infrastructure. The configuration is the product.<\/p>\n
        This is not a theoretical capability. It is the practical outcome of structural discipline applied consistently. Teams that practice Harmonic Design find themselves building systems that derive new capability entirely from configuration \u2014 and eventually, systems that use configuration to generate more systems<\/em>.<\/p>\n
        8.3 Software Factories<\/h3>\n
        The most complete expression of configuration-driven Harmonic Design is the software factory: a system whose structural model is stable enough that new instances of that model can be assembled from configuration alone.<\/p>\n
        A factory built on Harmonic Design principles has the following shape:<\/p>\n
          \n
        • A fixed set of Managers representing the orchestration patterns of the domain. These do not change when new products or workflows are added.<\/li>\n
        • A fixed set of Engines representing the business rule primitives of the domain. New rules are new Engine configurations, not new Engine classes.<\/li>\n
        • A fixed set of Experiences and Flows representing the interaction patterns of the domain. New journeys are new Experience configurations, not new interface components.<\/li>\n
        • A configuration layer \u2014 YAML, JSON, a schema, an administrative UI \u2014 that assembles these structural elements into new product instances.<\/li>\n<\/ul>\n
          The factory itself is a Harmonic Design system. It consumes configuration at its orchestration tier and produces running systems at its output tier. The configuration is the specification; the structural model is the execution engine. New capability is produced from configuration without touching the factory’s codebase.<\/p>\n
          This is not code generation. Code generation produces new source code from templates. A Harmonic Design factory produces running behavior from structural assembly. Structural assembly is safe, testable, and reversible \u2014 because the structural elements being assembled are themselves governed by the same boundary rules, test profiles, and communication contracts as the factory that assembles them.<\/p>\n
          8.4 Configuration Absorbs Change<\/h3>\n
          The most consequential capability of configuration-driven Harmonic Design is that it changes the relationship between requirements and code. In a conventional system, a change in business requirements produces a change in code. In a configuration-driven Harmonic Design system, many classes of requirement change produce only a change in configuration.<\/p>\n
          This is not a small distinction. It means:<\/p>\n
            \n
          • A new validation rule is a new configuration entry, not a pull request.<\/li>\n
          • A new user segment with a different onboarding path is a new Experience configuration, not a new frontend component.<\/li>\n
          • A new document type that a system must process is a new processing rule configuration, not a new Engine class.<\/li>\n
          • A new organizational policy that changes how workflows are sequenced is a new Manager configuration, not a refactoring of orchestration logic.<\/li>\n<\/ul>\n
            The system absorbs these changes because the structure anticipated them. The volatility that would have been expressed as code churn is instead expressed as configuration variation \u2014 contained, reviewable, deployable without a build.<\/p>\n
            8.5 Configuration-Driven Systems End to End<\/h3>\n
            This principle applies equally at every layer \u2014 backend and interface alike. The Harmonic Design system that is fully driven by configuration does not have a configurable frontend and a hardcoded backend. Both layers are configurable, and both are configurable for the same structural reason: the volatile parts (rules, flows, compositions) are separated from the stable parts (orchestration patterns, execution primitives, rendering infrastructure).<\/p>\n
            Backend:<\/strong> A Manager driven by configuration invokes different Engines in different orders for different tenants, segments, or policy contexts \u2014 without a single tenant-specific code path. An Engine parameterized by configuration applies different rule sets to the same computation \u2014 without branching on tenant identity inside the rule. A new workflow is a new configuration block. A new policy variant is a new parameter set. The backend codebase does not grow when the business grows; the configuration does.<\/p>\n
            Interface:<\/strong> An Experience driven by configuration composes different Flows for different user segments, organizational contexts, or product variants \u2014 without a single conditional branch in the Experience code. Each Flow renders different Interactions based on its own configuration. The result is an interface that presents entirely different product experiences from the same structural code.<\/p>\n
            End to end:<\/strong> When both layers are configuration-driven, a new product variant is a new configuration package. Upload it, and both the backend behavior and the interface composition change simultaneously \u2014 no code deployment, no build pipeline, no feature flag cleanup. The new variant is immediately available to whatever context the configuration targets.<\/p>\n
            What this enables in practice:<\/p>\n
              \n
            • White-labeling<\/strong> without branching codebases. Configuration supplies branding, behavioral rules, and workflow sequences at both layers. The codebase is shared.<\/li>\n
            • Multi-tenant variation<\/strong> without tenant-specific code. Configuration describes what each tenant sees and how the backend serves them. Both layers compose accordingly.<\/li>\n
            • Regulatory compliance variants<\/strong> without forking. A different compliance rule set is a different configuration block. The Engines that enforce it are the same Engines that enforce all other rule sets.<\/li>\n
            • Capability extension by upload.<\/strong> New rules, new document types, new process definitions, new assets \u2014 uploaded as configuration, interpreted by the structural model, immediately operational.<\/li>\n
            • Phased capability rollout<\/strong> without feature flags embedded in logic. A capability is present when its configuration is present. When the configuration is absent, the capability does not appear \u2014 no conditionals, no dead code paths.<\/li>\n<\/ul>\n
              Neither the backend nor the interface knows which variant it is serving. The backend knows how to orchestrate Engines and invoke Accessors. The interface knows how to compose Experiences, assemble Flows, and render Interactions. That is the entire codebase. The variation lives in the configuration.<\/p>\n
              8.6 Dogfooding the Structure<\/h3>\n
              The deepest expression of this pattern is a system that uses its own structural model to extend itself. A Harmonic Design system that produces new workflows from configuration can also define new configuration schemas using the same workflow machinery \u2014 because a configuration schema is itself just another workflow, driven by an Experience, composed of Flows, assembled from Interactions.<\/p>\n
              This is the point at which Harmonic Design becomes more than an architectural methodology: a way of building systems that know how to build more of themselves. The structural model is recursive. The factory can configure new factories. The boundary discipline that makes leaf components testable and replaceable also makes the factory composable at the system level.<\/p>\n
              Assets, rules, processes, and capabilities can all be uploaded as configuration. The running system interprets them, routes them through the appropriate tier, and makes them available immediately \u2014 without a deployment, without a code review, without a build pipeline. The code is stable. The system is not static.<\/p>\n
              Twenty years of consistent engineering practice produces a consistent observation: the teams that achieve this level of configurability are not the teams with the best technology \u2014 they are the teams with the most disciplined boundaries. The factory emerges from the structure. The structure comes from the discipline. The discipline is Harmonic Design.<\/p>\n
              \n
              9. How Change Propagates in a Harmonic Design System<\/h2>\n
              The following example traces a single requirement change \u2014 adding a tiered user segment to an onboarding system \u2014 through all four layers of an HD system. The purpose is to demonstrate that the structural map is the same at every layer, and that the change propagates through corresponding tiers.<\/p>\n
              The change:<\/strong> The system must now present a different onboarding path for enterprise users versus individual users. Enterprise users require an organizational profile flow; individual users skip it.<\/p>\n
              9.1 Backend Change (VBD)<\/h3>\n
              A new SegmentEngine<\/code> is added to evaluate user segment from the incoming request. The OnboardingManager<\/code> is updated to call SegmentEngine<\/code> before determining which downstream Engines to invoke. The SegmentEngine<\/code> is unit tested in isolation \u2014 given user attributes, returns the correct segment type. An integration test at the Manager-to-Engine seam verifies that the Manager routes correctly based on each segment value the Engine can return. No other components change.<\/p>\n
              9.2 Interface Change (EBD)<\/h3>\n
              The OnboardingExperience<\/code> is updated to receive segment state from the backend (already present in the API response) and use it to determine which Flows to compose. An OrgProfileFlow<\/code> is added for enterprise users. The OnboardingExperience<\/code> skips it for individual users. OrgProfileFlow<\/code> is unit tested in isolation \u2014 given shared state, steps through Interactions, emits completion. An integration test at the Experience-to-Flow seam verifies that the Experience correctly skips or includes OrgProfileFlow<\/code> based on segment. No existing Flows change.<\/p>\n
              9.3 Test Change (BDT)<\/h3>\n
              One new unit test suite for SegmentEngine<\/code>. One new unit test suite for OrgProfileFlow<\/code>. Two new integration test paths \u2014 one for enterprise, one for individual \u2014 at the Manager-to-Engine seam and the Experience-to-Flow seam. Two new E2E scenarios: enterprise onboarding and individual onboarding, each verifying the complete journey in the real system. No existing tests change.<\/p>\n
              9.4 Project Plan Change (PD)<\/h3>\n
              One new core work package for SegmentEngine<\/code> (design, implementation, unit testing). One new core work package for OrgProfileFlow<\/code> (design, implementation, unit testing). Two new integration activities at the Manager-to-Engine and Experience-to-Flow seams. The SegmentEngine<\/code> work package depends on the existing Accessor work packages (it reads user attributes). The OrgProfileFlow<\/code> work package depends on the existing Interaction work packages it composes. Both new work packages are inserted into the project network with their dependency edges. The critical path is recalculated. If the new Engine is on the critical path, it receives priority resourcing. If it is not \u2014 because it has float via an alternative path \u2014 it can be staffed flexibly.<\/p>\n
              The project plan absorbed the architectural change the same way the architecture absorbed the requirement change: one new component per tier, one new work package per component, recalculate the network. No replanning from scratch. No disconnection between what was designed and what was planned.<\/p>\n
              Figure 4 \u2014 Change Propagation in an HD System: one new SegmentEngine (dashed, NEW) and one new OrgProfileFlow (dashed, NEW) \u2014 one component per tier \u2014 propagate through a feature addition without cross-tier or cross-layer spillover. Engines never call other Engines; the Manager routes to each Engine directly.<\/em><\/p>\n
              graph TB\n    CFG[Config: segment]\n\n    subgraph Backend["Backend (VBD)"]\n        OM[OnboardingManager]\n        SE[SegmentEngine]\n        SUE[SetupEngine]\n        UA[UserAccessor]\n    end\n\n    subgraph Interface["Interface (EBD)"]\n        OE[OnboardingExperience]\n        UIF[UserInfoFlow]\n        OPF[OrgProfileFlow]\n        API[Backend API]\n    end\n\n    CFG -->|segment: enterprise \/ individual| OE\n    OE -->|always| UIF\n    OE -.->|enterprise only| OPF\n    OE -->|accumulated state| API\n    API --> OM\n    OM --> SE\n    OM --> SUE\n    SUE --> UA\n\n    style OM fill:#0053e2,color:#fff,stroke-width:0\n    style OE fill:#0053e2,color:#fff,stroke-width:0\n    style SE fill:#ffc220,color:#000,stroke:#ffc220,stroke-width:2px,stroke-dasharray:4\n    style SUE fill:#ffc220,color:#000,stroke-width:0\n    style UA fill:#2a8703,color:#fff,stroke-width:0\n    style UIF fill:#ffc220,color:#000,stroke-width:0\n    style OPF fill:#ffc220,color:#000,stroke:#ffc220,stroke-width:2px,stroke-dasharray:4\n    style CFG fill:#f0f0f0,color:#444,stroke:#ccc\n    style API fill:#f0f0f0,color:#444,stroke:#ccc\n<\/code><\/pre>\n
              9.5 What the Propagation Pattern Reveals<\/h3>\n
              The change propagated through exactly one new component per tier, at both the backend and interface layers, with corresponding test additions and a localized update to the project plan. Existing components did not change. Tests for existing components did not change. The project plan absorbed the change through insertion, not replanning. The structural boundaries contained the change at every layer.<\/p>\n
              This is not a feature of the specific example. It is the promised behavior of volatility-coherent boundaries: components that change for different reasons are separated, so a change to one reason touches only those components. The feature was added in one Engine, one Flow, and the orchestrating tier that coordinates them \u2014 plus the tests that verify each and the work packages that plan each.<\/p>\n
              A team that did not practice HD would experience the same requirement as a cross-cutting change: logic scattered across multiple Managers, flows embedded in Experience components that now need awareness of segment, tests that can’t be scoped because the structure has no stable seams, and a project plan that must be replanned because the work does not decompose into predictable packages. The same requirement, a different structural experience, because the boundaries were drawn differently.<\/p>\n
              \n
              10. Validation<\/h2>\n
              10.1 The HD Coherence Test<\/h3>\n
              A system is coherent under HD if the following statements are all true:<\/p>\n
              Structural:<\/strong><\/p>\n
                \n
              • Every backend component can be classified as a Manager, Engine, Resource Accessor, or Utility without ambiguity<\/li>\n
              • Every interface component can be classified as an Experience, Flow, Interaction, or Utility without ambiguity<\/li>\n
              • The tier hierarchy is consistent: Managers coordinate Engines; Experiences coordinate Flows; no peer coordination exists within a tier<\/li>\n
              • Utility components in both layers have no domain-specific knowledge and no coordination responsibility<\/li>\n<\/ul>\n
                Communication:<\/strong><\/p>\n
                  \n
                • No Engine calls a sibling Engine; no Flow calls a sibling Flow<\/li>\n
                • No Accessor applies business logic; no Interaction handles flow progression or makes business decisions<\/li>\n
                • No Flow makes direct backend API calls; only Experiences call the backend<\/li>\n
                • Any cross-tier communication that appears is justified by an explicit configuration or composition mechanism<\/li>\n<\/ul>\n
                  Test:<\/strong><\/p>\n
                    \n
                  • Every Engine and Flow has a unit test suite; all dependencies are mocked; all contract states are asserted<\/li>\n
                  • Every Manager-to-Engine, Engine-to-Accessor, and Experience-to-Flow seam has integration tests; dependencies are mocked at the outer boundary<\/li>\n
                  • Every core use case \/ core user journey has an E2E test; no mocks<\/li>\n
                  • Testing difficulty at any level can be traced to a specific structural boundary problem<\/li>\n<\/ul>\n
                    Project:<\/strong><\/p>\n
                      \n
                    • Every component maps to exactly one work package in the project plan<\/li>\n
                    • Every dependency in the architecture maps to a precedence relationship in the project network<\/li>\n
                    • Work package estimation ranges are calibrated to the volatility classification of the corresponding component<\/li>\n
                    • The critical path through the project network corresponds to the critical path through the architectural dependency graph<\/li>\n
                    • Staffing assignments follow volatility boundaries: best resources on volatile critical-path components<\/li>\n<\/ul>\n
                      Coherence:<\/strong><\/p>\n
                        \n
                      • The boundary that separates a Manager from an Engine corresponds to a boundary that separates an Experience from a Flow, a test scope boundary in BDT, and a work package boundary in PD<\/li>\n
                      • A change in business logic touches one Engine, one Flow, the tests for each, and one work package in the plan \u2014 not more<\/li>\n
                      • The test pyramid is naturally shaped by the structure, not enforced by coverage policy<\/li>\n
                      • The project plan absorbs architectural changes through insertion and recalculation, not replanning<\/li>\n<\/ul>\n
                        10.2 Failure Modes and What They Signal<\/h3>\n
                        When a system fails the HD coherence test at one layer, it almost always fails at the corresponding position in all layers.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
                        Failure Mode<\/th>\nStructural Signal<\/th>\nHD Diagnosis<\/th>\n<\/tr>\n<\/thead>\n
                        Engines calling sibling Engines<\/td>\nMissing Manager for that coordination<\/td>\nFlows will also call sibling Flows; Experience will also be missing a coordination layer<\/td>\n<\/tr>\n
                        Flows making API calls<\/td>\nExperience is not carrying journey state<\/td>\nBackend Manager is also likely doing its own DB reads to compensate for missing state<\/td>\n<\/tr>\n
                        Unit tests requiring many mocks<\/td>\nComponent spans multiple tiers<\/td>\nThe corresponding component in the other layer will have the same smell<\/td>\n<\/tr>\n
                        E2E tests are the only reliable safety net<\/td>\nUnit-testable execution tier is hollow<\/td>\nLogic has migrated to orchestration or Accessor tier in both backend and interface<\/td>\n<\/tr>\n
                        UAT surprises not covered by E2E<\/td>\nCore scenario set is incomplete<\/td>\nStructural model does not reflect actual user journeys; Experience composition needs revision<\/td>\n<\/tr>\n
                        Work packages hard to estimate<\/td>\nComponent spans multiple volatility axes<\/td>\nThe corresponding component is also hard to test \u2014 decompose it<\/td>\n<\/tr>\n
                        Project plan collapses on requirement change<\/td>\nArchitecture does not isolate change<\/td>\nThe change touches many components because boundaries are functional, not volatility-based<\/td>\n<\/tr>\n
                        Critical path has many high-volatility items<\/td>\nArchitectural dependencies not optimized<\/td>\nConsider restructuring to move volatile Engines off the critical path where possible<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                        The diagnostic is always structural. When testing is painful at one layer, check the corresponding tier in the other layer. When estimation is painful for a work package, check whether the component it represents has a clean volatility classification. The same boundary problem will be present.<\/p>\n
                        \n
                        11. Naming the Practice<\/h2>\n
                        11.1 Why This Needs a Name<\/h3>\n
                        The four frameworks addressed in this paper \u2014 VBD, EBD, BDT, and PD \u2014 each have names that position them as domain-specific tools. This is appropriate for learning and for consulting the frameworks individually. But it has an unintended consequence: it encourages teams to treat them as separable options, adopting one and ignoring the others.<\/p>\n
                        The unified practice requires a name that signals that it is unified \u2014 that the four frameworks are not a menu but a coherent whole. A team that adopts VBD without EBD will have a well-structured backend and a poorly structured interface; the structural mismatch will surface as friction at the API boundary. A team that adopts EBD without BDT will have a well-structured interface and no principled way to test it. A team that adopts BDT without VBD or EBD will be applying a test strategy to a system whose structure cannot honor it. A team that adopts VBD, EBD, and BDT without PD will have a well-structured, well-tested system \u2014 and a project plan estimated from user stories that bears no relationship to the architecture that was so carefully designed.<\/p>\n
                        The four frameworks are effective in isolation. They are designed to work together.<\/p>\n
                        11.2 Harmonic Design<\/h3>\n
                        The name is drawn from musical acoustics. A vibrating string produces not one frequency but many simultaneously \u2014 a fundamental tone and a series of harmonics above it. The harmonics do not contradict the fundamental; they are expressions of the same underlying physical law at different scales. Each harmonic is complete in itself. Together they produce something richer than any single frequency alone.<\/p>\n
                        VBD, EBD, BDT, and PD are harmonics of the same fundamental: organize by anticipated change. Each is complete in isolation. But practiced together, they produce something qualitatively different from their sum. Structural boundaries reinforce each other across layers. A design decision at one layer resonates into all layers. A structural problem at one layer is audible at all layers. A planning failure signals an architectural misalignment, and an architectural insight simplifies the plan. This mutual reinforcement \u2014 the hallmark of harmonic structure \u2014 is what the name captures.<\/p>\n
                        With four harmonics, the practice reaches its natural completeness. The fundamental (organize by anticipated change) resonates through what to build (VBD), how to present it (EBD), how to verify it (BDT), and how to plan and execute the work (PD). These four concerns \u2014 structure, interface, verification, and delivery \u2014 span the full lifecycle of a software system. There is no fifth concern that the fundamental addresses. The four harmonics are complete.<\/p>\n
                        Harmonic<\/strong> rather than coherent<\/em> or unified<\/em> because the word carries the right connotations: resonance, mutual reinforcement, structure that emerges from a shared fundamental rather than being imposed from outside. A harmonic system is not forced into alignment \u2014 it finds alignment naturally when all parts are tuned to the same principle.<\/p>\n
                        Design<\/strong> because the practice governs how systems are conceived, structured, verified, planned, and evolved \u2014 not just implemented. It applies before the first line of code, persists through all phases of a system’s life, and informs decisions across backend, interface, test strategy, and project planning equally.<\/p>\n
                        \n
                        12. Relationship to Existing Practices<\/h2>\n
                        12.1 Domain-Driven Design<\/h3>\n
                        Domain-Driven Design (Evans, 2003) organizes systems around the conceptual model of the business domain. Bounded contexts define where one model ends and another begins. HD does not conflict with DDD; it adds a dimension to it. Bounded contexts are often natural volatility boundaries \u2014 a domain model that changes for one reason is a natural VBD Manager scope. HD can be read as a structural model that operates within<\/em> DDD bounded contexts, governing how each context organizes its own components rather than how contexts relate to each other.<\/p>\n
                        The distinction: DDD draws boundaries between domains. HD draws boundaries within tiers at every layer. Both are necessary in large systems.<\/p>\n
                        12.2 Clean Architecture<\/h3>\n
                        Martin’s Clean Architecture (2017) organizes systems by dependency direction: high-level policy should not depend on low-level detail. The Dependency Rule \u2014 source code dependencies point inward, toward higher-level policy \u2014 maps closely onto HD’s tier hierarchy: Engines depend on nothing domain-specific, Managers depend on Engine and Accessor interfaces, and Accessors depend on external systems. HD adds the volatility-based reason<\/em> for these dependency directions: Engines are inward because they are the most volatile; Accessors are outward because they isolate environmental volatility.<\/p>\n
                        Harmonic Design and Clean Architecture agree on the communication topology. HD explains why<\/em> that topology is correct.<\/p>\n
                        12.3 Atomic Design<\/h3>\n
                        Brad Frost’s Atomic Design (2013) provides a vocabulary for hierarchical component composition in interfaces: atoms, molecules, organisms, templates, pages. This addresses structural composition at the visual<\/em> level. EBD \u2014 and by extension HD \u2014 addresses structural composition at the behavioral<\/em> level: Interactions, Flows, Experiences.<\/p>\n
                        Both taxonomies are valid and non-competing. An Interaction (EBD) might be composed of several atoms and molecules (Atomic Design). An Experience might correspond to a page template. The two models answer different questions: Atomic Design asks how visual elements compose; EBD asks how behavioral intent composes.<\/p>\n
                        12.4 Test-Driven Development and Behavior-Driven Development<\/h3>\n
                        TDD treats tests as a design tool: writing tests before code forces clarity about interfaces and responsibilities. BDD extends this to behavior specifications. HD extends further: the structure<\/em> of the system determines the structure<\/em> of the tests, which in turn validates the design<\/em> of the system. TDD and BDD inform how you write tests at a given level. BDT tells you which level a given component belongs to.<\/p>\n
                        TDD and BDD can be practiced within an HD system without conflict. HD provides the structural scaffolding; TDD\/BDD provides the micro-design discipline within each structural tier.<\/p>\n
                        12.5 Critical Path Method and Earned Value Management<\/h3>\n
                        CPM (Kelley and Walker, 1959) and EVM (Fleming and Koppelman, 2010) provide the mathematical foundation for Project Design’s network analysis, float calculation, and progress tracking. HD does not replace these techniques \u2014 PD integrates them. What HD adds is the source of the network: the architectural decomposition. In conventional CPM, the activity list and dependencies are constructed manually. In HD, they are derived from the architecture. The network is not an estimate of the work \u2014 it is a structural consequence of the design.<\/p>\n
                        12.6 Agile Methodologies<\/h3>\n
                        Project Design \u2014 and by extension HD \u2014 is not opposed to agile delivery. The distinction is between planning and execution. PD provides the planning discipline that determines what is built, in what order, with what resources, and at what cost. Agile methods provide the execution discipline that governs how the work is performed day to day. The Feed Me or Kill Me decision maps to Sprint Zero or PI Planning commitment. Sprint velocity maps to the earned value rate. The S-curve maps to the cumulative flow diagram or burnup chart.<\/p>\n
                        Good agile combines architectural discipline with iterative delivery. Bad agile uses agile terminology as a justification for skipping architecture and project design. HD provides the structural foundation that makes agile delivery effective.<\/p>\n
                        \n
                        13. Observations from Practice<\/h2>\n
                        The following observations are drawn from applying Harmonic Design across multiple systems over an extended period. They are not prescriptive \u2014 they are patterns that have emerged consistently enough to warrant documentation.<\/p>\n
                        13.1 The Structure Reveals Itself Gradually<\/h3>\n
                        Teams adopting HD for the first time tend to produce architectures that are partially volatility-aligned. Some components are clean VBD roles; others are hybrids that span two tiers. This is normal and expected. The structural map becomes clearer with each requirement change, because changes reveal which components are truly volatile and which are stable. The first decomposition is a hypothesis. The first six months of requirement changes are the experiment. By the end of the first year, the boundaries that survive are the right boundaries.<\/p>\n
                        13.2 Testing Difficulty Is the Earliest Signal<\/h3>\n
                        Before the architecture reveals its weaknesses through requirement changes, the test suite reveals them through testing difficulty. A component that is hard to unit test is almost always misclassified or mis-scoped. Teams that pay attention to testing difficulty as a structural diagnostic \u2014 rather than as a complaint about the testing framework \u2014 catch boundary problems months before they manifest as change-locality failures.<\/p>\n
                        13.3 Estimation Accuracy Improves with Structural Maturity<\/h3>\n
                        On first application, HD-derived project plans are better than requirement-based estimates but still imperfect \u2014 the team has not yet calibrated its estimation ranges to the specific volatility characteristics of its domain. After two or three project cycles, the calibration tightens. Teams learn that their Engines take longer than expected (because functional volatility is underestimated) and their Utilities take less time than expected (because cross-cutting concerns are overestimated). The structural map provides the calibration framework; repeated application provides the calibration data.<\/p>\n
                        13.4 The Plan Absorbs Requirement Changes Without Replanning<\/h3>\n
                        This is the observation that most surprises teams new to HD. When a requirement change adds a new Engine and a new Flow, the project plan update is mechanical: insert two work packages, add dependency edges, recalculate the critical path. There is no replanning meeting. There is no argument about scope. The structural map determines what the change is, and the project network absorbs it. Teams accustomed to requirement changes triggering full replanning sessions find this disorienting at first \u2014 and then indispensable.<\/p>\n
                        13.5 Configuration-Driven Systems Compound<\/h3>\n
                        Systems built with strict HD boundary discipline tend to become more configurable over time, not less. Each new Engine added with clean boundaries is another Engine that configuration can compose. Each new Flow added with clean state isolation is another Flow that configuration can sequence. The configurability is not designed in \u2014 it emerges from the structural discipline. After several years of consistent practice, teams find themselves building new capabilities entirely from configuration, without writing new code. This is not an aspiration; it is a consistent empirical observation.<\/p>\n
                        13.6 Conway’s Law Works Both Ways<\/h3>\n
                        HD aligns team boundaries with component boundaries, which aligns with volatility boundaries. When this alignment is maintained, Conway’s Law becomes an asset: the team structure reinforces the architectural structure. When it is not maintained \u2014 when team boundaries cross volatility boundaries \u2014 the architectural discipline degrades, because the organizational pressure to coordinate across team boundaries introduces the same coupling that HD is designed to prevent. Organizational alignment is not optional; it is a structural precondition.<\/p>\n
                        13.7 The Fourth Pillar Changes the Conversation with Management<\/h3>\n
                        Before PD, the conversation between engineering and management is adversarial by default: engineering estimates, management negotiates, both sides distrust the outcome. After PD, the conversation is structured: here are three options with quantified cost, schedule, and risk; which do you prefer? The options are not opinions \u2014 they are structural consequences of the architecture. Management selects from the feasible zone. Engineering executes the selected plan. The adversarial dynamic is replaced by a decision-making protocol. Teams that adopt PD as part of HD consistently report that the most significant change is not in planning accuracy \u2014 it is in the quality of the relationship between engineering and management.<\/p>\n
                        \n
                        14. Conclusion<\/h2>\n
                        Software systems fail over time not because of poor initial design, but because change accumulates faster than the architecture can absorb it. The conventional response \u2014 adopt a framework, apply it to one layer, and manage the other layers by convention \u2014 does not solve the problem. It solves one layer of the problem and leaves the others unaddressed.<\/p>\n
                        Harmonic Design is the practice of solving all four simultaneously. Not by introducing new concepts, but by recognizing that four independently developed frameworks \u2014 VBD, EBD, BDT, and PD \u2014 share the same organizing principle, the same structural map, and the same communication rules. They are not separate tools. They are one tool, applied at four layers.<\/p>\n
                        The structural isomorphism is the central insight. A Manager corresponds to an Experience corresponds to E2E scope corresponds to an integration milestone work package. An Engine corresponds to a Flow corresponds to unit scope corresponds to a core work package. A Resource Accessor corresponds to an Interaction corresponds to unit (translation) scope corresponds to a boundary work package. Utility corresponds to Utility everywhere. Once a team sees this correspondence, the four frameworks become one. Learning one teaches the others. A problem in one layer predicts a problem in the corresponding position in the others. A fix at one layer guides the fix at all layers.<\/p>\n
                        The emergent properties of this coherence \u2014 change locality across all layers, test scope determinism, estimation accuracy from volatility alignment, structural legibility, diagnostic consistency, risk quantification from architecture, configuration-driven composition \u2014 are not achievable by any individual framework applied to a single layer. They require the full system: backend, interface, test strategy, and project plan organized by the same map, enforcing the same boundaries, communicating by the same rules.<\/p>\n
                        The addition of Project Design as the fourth pillar completes the practice. VBD governs what to build. EBD governs how to present it. BDT governs how to verify it. PD governs how to plan, estimate, schedule, and execute the work. All four are readings of the same structural map. All four are tuned to the same fundamental. The architecture is the plan.<\/p>\n
                        Software engineering has accumulated many frameworks for managing complexity. Harmonic Design is a framework that unifies four of them under a single structural discipline \u2014 and demonstrates that practicing them as one produces a kind of structural coherence that none achieves alone.<\/p>\n
                        That coherence is the goal. Harmonic Design is the path.<\/p>\n
                        \n
                        Appendix A: Glossary<\/h2>\n
                          \n
                        • Boundary Violation<\/strong> \u2014 An instance where a component invokes another in a way that crosses its permitted communication paths, signaling structural misalignment.<\/li>\n
                        • Change Propagation<\/strong> \u2014 How a modification flows through all four layers when boundaries are correctly aligned.<\/li>\n
                        • Coherence<\/strong> \u2014 The state where all four pillars reflect the same structural boundaries and the same volatility classifications.<\/li>\n
                        • Communication Rules<\/strong> \u2014 Constraints on inter-component invocation that hold across all pillars and prevent dependency erosion.<\/li>\n
                        • Configuration-Driven Composition<\/strong> \u2014 The practice of assembling components through external configuration rather than hardcoded structure, enabling change absorption without code modification.<\/li>\n
                        • Core Scenario<\/strong> \u2014 A high-level behavior (use case, user journey, test scenario, project milestone) that validates structural decisions at every layer.<\/li>\n
                        • Diagnostic Signal<\/strong> \u2014 A difficulty indicator (testing difficulty, estimation difficulty, boundary pressure) that reveals structural misalignment.<\/li>\n
                        • Framework Cross-Reference<\/strong> \u2014 The mapping table showing equivalent concepts across VBD, EBD, BDT, and PD.<\/li>\n
                        • Harmonic Design<\/strong> \u2014 A unified software engineering framework that applies volatility-first reasoning consistently across backend architecture (VBD), interface architecture (EBD), test strategy (BDT), and project planning (PD), producing structural isomorphism across all four layers.<\/li>\n
                        • Layer<\/strong> \u2014 One of the four system concerns addressed by HD: backend, interface, tests, project plan.<\/li>\n
                        • Peer Prohibition<\/strong> \u2014 The universal rule that components at the same tier must not invoke each other directly.<\/li>\n
                        • Pillar<\/strong> \u2014 One of the four constituent frameworks of Harmonic Design: VBD, EBD, BDT, or PD.<\/li>\n
                        • Structural Isomorphism<\/strong> \u2014 The property where component roles, communication rules, and volatility boundaries correspond exactly across backend, interface, test, and project layers.<\/li>\n
                        • Structural Map<\/strong> \u2014 The single decomposition drawn from volatility analysis that governs all four pillars simultaneously.<\/li>\n
                        • Tier Correspondence<\/strong> \u2014 The mapping between equivalent roles across pillars: Manager\u2194Experience\u2194E2E scope\u2194Integration Milestone WP.<\/li>\n
                        • Volatility Axis<\/strong> \u2014 A dimension along which change is expected: functional, non-functional, cross-cutting, or environmental.<\/li>\n
                        • Volatility-First Reasoning<\/strong> \u2014 The practice of using anticipated change as the primary driver of all structural decisions.<\/li>\n<\/ul>\n
                          \n
                          Appendix B: Framework Cross-Reference<\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                          Concept<\/th>\nVBD Term<\/th>\nEBD Term<\/th>\nBDT Term<\/th>\nPD Term<\/th>\n<\/tr>\n<\/thead>\n
                          Orchestrating tier<\/td>\nManager<\/td>\nExperience<\/td>\nE2E \/ UAT scope<\/td>\nIntegration Milestone WP<\/td>\n<\/tr>\n
                          Execution tier<\/td>\nEngine<\/td>\nFlow<\/td>\nUnit scope<\/td>\nCore Work Package<\/td>\n<\/tr>\n
                          External boundary tier<\/td>\nResource Accessor<\/td>\nInteraction<\/td>\nUnit (translation only)<\/td>\nBoundary Work Package<\/td>\n<\/tr>\n
                          Cross-cutting tier<\/td>\nUtility<\/td>\nUtility<\/td>\nUnit scope<\/td>\nShared Infrastructure WP<\/td>\n<\/tr>\n
                          Orchestration rule<\/td>\nMGR coordinates ENG and ACC<\/td>\nEXP coordinates FLW<\/td>\nE2E verifies journey<\/td>\nMilestone depends on core and boundary WPs<\/td>\n<\/tr>\n
                          Peer prohibition<\/td>\nENG does not call ENG<\/td>\nFLW does not call FLW<\/td>\nUnit test has one mock boundary<\/td>\nNo peer dependency between same-tier WPs<\/td>\n<\/tr>\n
                          External call ownership<\/td>\nACC reaches external systems<\/td>\nEXP reaches backend API<\/td>\nIntegration tests ACC \/ API seam<\/td>\nBoundary WP estimated by external contract<\/td>\n<\/tr>\n
                          Volatility driver<\/td>\nBusiness rules to Engine<\/td>\nUser actions to Interaction<\/td>\nLogic correctness to Unit<\/td>\nWidest estimation range to Core WP<\/td>\n<\/tr>\n
                          Structural driver<\/td>\nOrchestration to Manager<\/td>\nJourney composition to Experience<\/td>\nCollaboration wiring to Integration<\/td>\nSeam count drives milestone estimate<\/td>\n<\/tr>\n
                          Core validation<\/td>\nCore use cases traced through hierarchy<\/td>\nCore user journeys traced through tiers<\/td>\nSame scenarios at each spiral level<\/td>\nCore scenarios as E2E verification activities<\/td>\n<\/tr>\n
                          Structural diagnostic<\/td>\nBoundary violation = structural problem<\/td>\nBoundary violation = structural problem<\/td>\nTest difficulty = structural signal<\/td>\nEstimation difficulty = structural signal<\/td>\n<\/tr>\n
                          Risk source<\/td>\nFunctional volatility in Engines<\/td>\nFunctional volatility in Flows<\/td>\nMock complexity at seams<\/td>\nFloat distribution across network<\/td>\n<\/tr>\n
                          Change absorption<\/td>\nNew Engine, Manager orchestrates<\/td>\nNew Flow, Experience composes<\/td>\nNew unit suite, integration path<\/td>\nNew WP, recalculate critical path<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                          \n
                          Appendix C: HD Adoption Checklist<\/h2>\n
                          A team beginning to adopt Harmonic Design should verify the following at each layer:<\/p>\n
                          Backend (VBD):<\/strong><\/p>\n
                            \n
                          • Every component is classified as Manager, Engine, Resource Accessor, or Utility<\/li>\n
                          • Engines do not call sibling Engines or hold workflow logic<\/li>\n
                          • Managers do not embed business rules<\/li>\n
                          • Accessors do not apply policy; they translate and return<\/li>\n
                          • Communication rules are enforced by code review and structural convention<\/li>\n<\/ul>\n
                            Interface (EBD):<\/strong><\/p>\n
                              \n
                            • Every component is classified as Experience, Flow, Interaction, or Utility<\/li>\n
                            • Flows do not call sibling Flows or make direct API calls<\/li>\n
                            • Experiences hold accumulated journey state and are the sole API communicators<\/li>\n
                            • Interactions are atomic; they emit events and receive props<\/li>\n
                            • Utilities have no domain-specific knowledge<\/li>\n<\/ul>\n
                              Tests (BDT):<\/strong><\/p>\n
                                \n
                              • Every Engine and Flow has a unit test suite with all Accessor\/API dependencies mocked<\/li>\n
                              • Every Manager-to-Engine, Engine-to-Accessor, and Experience-to-Flow seam has integration tests<\/li>\n
                              • Every core use case and user journey has an E2E scenario<\/li>\n
                              • Test difficulty at any level is treated as a structural signal, not a testing problem<\/li>\n<\/ul>\n
                                Project Plan (PD):<\/strong><\/p>\n
                                  \n
                                • Every component maps to exactly one work package<\/li>\n
                                • Dependencies in the project network mirror dependencies in the architecture<\/li>\n
                                • Estimation ranges are calibrated to volatility tier: widest for Engines\/Flows, tightest for Utilities<\/li>\n
                                • The critical path is identified and the best resources are assigned to it<\/li>\n
                                • At least three project options (conservative, balanced, aggressive) have been presented to management<\/li>\n
                                • Risk is quantified from float distribution, not from subjective assessment<\/li>\n
                                • Staffing assignments follow the one-to-one rule: one component, one developer<\/li>\n
                                • Staged delivery aligns with the architectural tier hierarchy: Utilities first, Managers last<\/li>\n<\/ul>\n
                                  Coherence:<\/strong><\/p>\n
                                    \n
                                  • Backend tiers correspond to interface tiers (Manager to Experience, Engine to Flow, etc.)<\/li>\n
                                  • A change in requirements touches one component per tier, per layer, and one work package in the plan<\/li>\n
                                  • The same core scenarios validate structural boundaries in VBD, EBD, BDT, and PD<\/li>\n
                                  • The project plan absorbs architectural changes through insertion and recalculation, not replanning<\/li>\n
                                  • Estimation difficulty at any work package can be traced to a volatility classification problem in the corresponding component<\/li>\n<\/ul>\n
                                    \n
                                    Appendix D: Case Study \u2014 Healthcare Scheduling Platform<\/h2>\n
                                    This appendix presents a fictional but realistic example of Harmonic Design applied end-to-end across all four pillars. The system is a healthcare scheduling platform that allows patients to book appointments with providers, checking eligibility, searching for available providers, and selecting time slots.<\/p>\n
                                    D.1 VBD Decomposition (Backend)<\/h3>\n
                                    The backend is decomposed into the following components:<\/p>\n
                                    Managers:<\/strong>
                                    \n– SchedulingManager<\/code> \u2014 orchestrates the complete appointment booking workflow: receive patient request, check eligibility, search providers, reserve time slot, confirm appointment.
                                    \n– NotificationManager<\/code> \u2014 orchestrates notification delivery across channels (email, SMS, push) after booking events.<\/p>\n
                                    Engines:<\/strong>
                                    \n– EligibilityEngine<\/code> \u2014 evaluates whether a patient is eligible for a requested appointment type based on insurance, referral requirements, and plan restrictions.
                                    \n– ProviderMatchEngine<\/code> \u2014 matches patients to providers based on specialty, location, network participation, and patient preferences.
                                    \n– SlotAllocationEngine<\/code> \u2014 resolves time slot availability against provider calendars, handles conflict detection, and applies scheduling rules (minimum gap between appointments, maximum daily load).
                                    \n– ConfirmationEngine<\/code> \u2014 generates confirmation records, assigns confirmation numbers, and produces the confirmation payload for both patient and provider.<\/p>\n
                                    Resource Accessors:<\/strong>
                                    \n– PatientAccessor<\/code> \u2014 reads and writes patient records from the patient database.
                                    \n– ProviderAccessor<\/code> \u2014 reads provider profiles, credentials, and network participation from the provider directory.
                                    \n– CalendarAccessor<\/code> \u2014 reads and writes provider calendar entries from the calendar system.
                                    \n– InsuranceAccessor<\/code> \u2014 calls external insurance verification APIs to validate coverage and benefits.
                                    \n– NotificationAccessor<\/code> \u2014 sends notifications through external email, SMS, and push notification services.<\/p>\n
                                    Utilities:<\/strong>
                                    \n– DateTimeUtility<\/code> \u2014 timezone conversions, business hour calculations, recurring schedule generation.
                                    \n– ValidationUtility<\/code> \u2014 input validation, sanitization, format verification.
                                    \n– AuditUtility<\/code> \u2014 audit trail generation, compliance logging.<\/p>\n
                                    D.2 EBD Decomposition (Interface)<\/h3>\n
                                    Experiences:<\/strong>
                                    \n– AppointmentBookingExperience<\/code> \u2014 the complete patient-facing booking journey. Receives configuration, composes Flows, accumulates journey state (selected provider, selected slot, confirmed appointment), and makes the single API call to the backend when the journey is complete.<\/p>\n
                                    Flows:<\/strong>
                                    \n– ProviderSearchFlow<\/code> \u2014 guides the patient through searching for a provider: enter specialty, enter location, view results, select provider. Emits the selected provider upward to the Experience.
                                    \n– TimeSlotSelectionFlow<\/code> \u2014 presents available time slots for the selected provider, allows date navigation, and captures the patient’s slot selection. Emits the selected slot upward.
                                    \n– PatientInfoFlow<\/code> \u2014 collects or confirms patient information: demographics, insurance, contact details. Emits completed patient info upward.
                                    \n– ConfirmationFlow<\/code> \u2014 presents the appointment summary, captures patient confirmation, and displays the confirmation number. Emits confirmation status upward.<\/p>\n
                                    Interactions:<\/strong>
                                    \n– SpecialtyPickerInteraction<\/code> \u2014 dropdown for selecting medical specialty.
                                    \n– LocationInputInteraction<\/code> \u2014 location entry with autocomplete.
                                    \n– ProviderCardInteraction<\/code> \u2014 displays a single provider’s information; emits selection event.
                                    \n– CalendarGridInteraction<\/code> \u2014 renders available time slots in a calendar view; emits slot selection event.
                                    \n– InsuranceFormInteraction<\/code> \u2014 insurance information entry fields; emits form completion event.
                                    \n– ConfirmationSummaryInteraction<\/code> \u2014 read-only appointment summary display.<\/p>\n
                                    Utilities:<\/strong>
                                    \n– FormValidationUtility<\/code> \u2014 client-side validation rules.
                                    \n– FormatUtility<\/code> \u2014 date, time, phone, and address formatting.<\/p>\n
                                    D.3 BDT Test Strategy<\/h3>\n
                                    The test strategy maps directly to the structural decomposition:<\/p>\n
                                    Unit tests:<\/strong>
                                    \n– EligibilityEngine<\/code>: given patient attributes and insurance data (mocked via InsuranceAccessor<\/code>), returns correct eligibility determination for each coverage scenario.
                                    \n– ProviderMatchEngine<\/code>: given patient criteria and provider list (mocked via ProviderAccessor<\/code>), returns correctly ranked and filtered matches.
                                    \n– SlotAllocationEngine<\/code>: given provider calendar (mocked via CalendarAccessor<\/code>), resolves availability correctly including conflict detection and scheduling rules.
                                    \n– ProviderSearchFlow<\/code>: given provider list (via props from Experience), renders search UI, steps through Interactions, emits selected provider.
                                    \n– TimeSlotSelectionFlow<\/code>: given available slots (via props), renders calendar, emits selected slot.
                                    \n– Each Interaction: given props, renders correctly, emits correct events on user action.<\/p>\n
                                    Integration tests:<\/strong>
                                    \n– SchedulingManager<\/code> to EligibilityEngine<\/code> seam: real Manager, mocked Engine \u2014 verify Manager routes correctly based on every eligibility status the Engine can return (eligible, ineligible, pending-referral, coverage-expired).
                                    \n– SchedulingManager<\/code> to SlotAllocationEngine<\/code> seam: verify Manager handles slot-available, slot-taken, no-slots-available responses.
                                    \n– AppointmentBookingExperience<\/code> to ProviderSearchFlow<\/code> seam: verify Experience passes correct state and handles Flow completion correctly.
                                    \n– AppointmentBookingExperience<\/code> to TimeSlotSelectionFlow<\/code> seam: verify Experience receives selected slot and transitions to the next Flow.<\/p>\n
                                    E2E tests:<\/strong>
                                    \n– Happy path: patient searches for provider, selects slot, confirms appointment \u2014 end to end with real infrastructure.
                                    \n– Ineligible patient: patient is denied booking due to insurance restriction \u2014 verify the system handles gracefully without partial booking.
                                    \n– No available slots: patient searches, no slots match \u2014 verify empty state and alternative suggestions.<\/p>\n
                                    D.4 PD Project Plan<\/h3>\n
                                    The project plan is derived directly from the architecture:<\/p>\n
                                    Work Packages (derived from components):<\/strong><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                                    Work Package<\/th>\nType<\/th>\nDepends On<\/th>\nEstimated Duration<\/th>\n<\/tr>\n<\/thead>\n
                                    DateTimeUtility<\/td>\nShared Infrastructure<\/td>\n\u2014<\/td>\n5 days<\/td>\n<\/tr>\n
                                    ValidationUtility<\/td>\nShared Infrastructure<\/td>\n\u2014<\/td>\n5 days<\/td>\n<\/tr>\n
                                    AuditUtility<\/td>\nShared Infrastructure<\/td>\n\u2014<\/td>\n5 days<\/td>\n<\/tr>\n
                                    PatientAccessor<\/td>\nBoundary<\/td>\nDateTimeUtility<\/td>\n10 days<\/td>\n<\/tr>\n
                                    ProviderAccessor<\/td>\nBoundary<\/td>\nValidationUtility<\/td>\n10 days<\/td>\n<\/tr>\n
                                    CalendarAccessor<\/td>\nBoundary<\/td>\nDateTimeUtility<\/td>\n10 days<\/td>\n<\/tr>\n
                                    InsuranceAccessor<\/td>\nBoundary<\/td>\nValidationUtility<\/td>\n15 days<\/td>\n<\/tr>\n
                                    NotificationAccessor<\/td>\nBoundary<\/td>\n\u2014<\/td>\n10 days<\/td>\n<\/tr>\n
                                    EligibilityEngine<\/td>\nCore<\/td>\nPatientAccessor, InsuranceAccessor<\/td>\n15 days<\/td>\n<\/tr>\n
                                    ProviderMatchEngine<\/td>\nCore<\/td>\nProviderAccessor<\/td>\n10 days<\/td>\n<\/tr>\n
                                    SlotAllocationEngine<\/td>\nCore<\/td>\nCalendarAccessor<\/td>\n15 days<\/td>\n<\/tr>\n
                                    ConfirmationEngine<\/td>\nCore<\/td>\nPatientAccessor, CalendarAccessor<\/td>\n10 days<\/td>\n<\/tr>\n
                                    SchedulingManager<\/td>\nIntegration Milestone<\/td>\nEligibilityEngine, ProviderMatchEngine, SlotAllocationEngine, ConfirmationEngine<\/td>\n15 days<\/td>\n<\/tr>\n
                                    NotificationManager<\/td>\nIntegration Milestone<\/td>\nConfirmationEngine, NotificationAccessor<\/td>\n10 days<\/td>\n<\/tr>\n
                                    FormValidationUtility (UI)<\/td>\nShared Infrastructure<\/td>\n\u2014<\/td>\n5 days<\/td>\n<\/tr>\n
                                    FormatUtility (UI)<\/td>\nShared Infrastructure<\/td>\n\u2014<\/td>\n5 days<\/td>\n<\/tr>\n
                                    SpecialtyPickerInteraction<\/td>\nCore (UI)<\/td>\nFormValidationUtility<\/td>\n5 days<\/td>\n<\/tr>\n
                                    LocationInputInteraction<\/td>\nCore (UI)<\/td>\nFormValidationUtility<\/td>\n5 days<\/td>\n<\/tr>\n
                                    ProviderCardInteraction<\/td>\nCore (UI)<\/td>\nFormatUtility<\/td>\n5 days<\/td>\n<\/tr>\n
                                    CalendarGridInteraction<\/td>\nCore (UI)<\/td>\nFormatUtility, DateTimeUtility<\/td>\n10 days<\/td>\n<\/tr>\n
                                    InsuranceFormInteraction<\/td>\nCore (UI)<\/td>\nFormValidationUtility<\/td>\n5 days<\/td>\n<\/tr>\n
                                    ConfirmationSummaryInteraction<\/td>\nCore (UI)<\/td>\nFormatUtility<\/td>\n5 days<\/td>\n<\/tr>\n
                                    ProviderSearchFlow<\/td>\nCore (UI)<\/td>\nSpecialtyPickerInteraction, LocationInputInteraction, ProviderCardInteraction<\/td>\n10 days<\/td>\n<\/tr>\n
                                    TimeSlotSelectionFlow<\/td>\nCore (UI)<\/td>\nCalendarGridInteraction<\/td>\n10 days<\/td>\n<\/tr>\n
                                    PatientInfoFlow<\/td>\nCore (UI)<\/td>\nInsuranceFormInteraction<\/td>\n10 days<\/td>\n<\/tr>\n
                                    ConfirmationFlow<\/td>\nCore (UI)<\/td>\nConfirmationSummaryInteraction<\/td>\n5 days<\/td>\n<\/tr>\n
                                    AppointmentBookingExperience<\/td>\nIntegration Milestone (UI)<\/td>\nProviderSearchFlow, TimeSlotSelectionFlow, PatientInfoFlow, ConfirmationFlow<\/td>\n15 days<\/td>\n<\/tr>\n
                                    Backend-UI Integration<\/td>\nIntegration Milestone<\/td>\nSchedulingManager, AppointmentBookingExperience<\/td>\n10 days<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
                                    Critical Path:<\/strong> DateTimeUtility (5) -> CalendarAccessor (10) -> SlotAllocationEngine (15) -> SchedulingManager (15) -> Backend-UI Integration (10) = 55 days<\/strong><\/p>\n
                                    Parallel paths through InsuranceAccessor (15) -> EligibilityEngine (15) = 30 days from utility start, with 10 days of float relative to the critical path.<\/p>\n
                                    The UI critical path runs: FormValidationUtility (5) -> InsuranceFormInteraction (5) -> PatientInfoFlow (10) -> AppointmentBookingExperience (15) -> Backend-UI Integration (10) = 45 days. This path has 10 days of float relative to the backend critical path.<\/p>\n
                                    Three Options:<\/strong><\/p>\n
                                    Conservative (70 days, lowest risk):<\/em> All-normal durations plus 15-day decompression buffer. Risk index approximately 0.35. Staffing: 4 developers peak.<\/p>\n
                                    Balanced (55 days, moderate risk):<\/em> All-normal durations, no buffer. Risk index approximately 0.50. Staffing: 6 developers peak. Best resources assigned to SlotAllocationEngine and EligibilityEngine (highest functional volatility, critical path or near-critical).<\/p>\n
                                    Aggressive (42 days, highest risk):<\/em> Critical-path compression on SlotAllocationEngine (15 to 10 days) and SchedulingManager (15 to 10 days). Network restructuring to enable parallel Engine development against Accessor interfaces. Risk index approximately 0.70. Staffing: 8 developers peak. Requires top resources on all critical-path activities.<\/p>\n
                                    D.5 Mid-Project Requirement Change: Adding Telehealth<\/h3>\n
                                    Midway through construction, a new requirement arrives: the platform must support telehealth appointments in addition to in-person visits. Patients should be able to choose between telehealth and in-person when booking.<\/p>\n
                                    How the change propagates through all four layers:<\/strong><\/p>\n
                                    VBD (Backend):<\/strong>
                                    \nNo new backend components are required. Telehealth is not a backend architectural concern \u2014 it is a visit type. The SchedulingManager<\/code> books the appointment as requested; the resulting visit record carries a visitType<\/code> field (in-person or telehealth) along with provider contact details. The backend has no awareness of video conferencing, room configuration, or connection logic. No existing Engines change.<\/p>\n
                                    EBD (Interface):<\/strong>
                                    \nTwo new components. A VisitTypeFlow<\/code> is added, positioned before ProviderSearchFlow<\/code> in the AppointmentBookingExperience<\/code>, presenting the patient with a choice between in-person and telehealth. A TelehealthInteraction<\/code> renders the telehealth connection interface once the Experience receives back a confirmed visit with visitType: telehealth<\/code> \u2014 it uses the provider details in the visit record to connect the patient to the appropriate telehealth platform. The Experience uses the visit type to configure downstream Flows \u2014 ProviderSearchFlow<\/code> filters by telehealth-capable providers when applicable. No existing Flows change.<\/p>\n
                                    BDT (Tests):<\/strong>
                                    \nNew unit tests: VisitTypeFlow<\/code> (renders visit type selection, emits choice), TelehealthInteraction<\/code> (given a confirmed telehealth visit record, renders connection UI). New integration test: AppointmentBookingExperience<\/code> to VisitTypeFlow<\/code> seam. New E2E scenario: patient books a telehealth appointment end to end. No backend tests change \u2014 the backend did not change.<\/p>\n
                                    PD (Project Plan):<\/strong>
                                    \nTwo new UI work packages: VisitTypeFlow<\/code> (core UI, 5 days, depends on VisitTypeInteraction<\/code>), TelehealthInteraction<\/code> (boundary UI, 5 days). No new backend work packages \u2014 the backend did not change. Dependency edges are inserted into the interface project network. The critical path is recalculated.<\/p>\n
                                    The structural map contained the change at every layer.<\/strong> Two new interface components; no new backend components. Existing components absorbed the change through configuration. The plan absorbed the change through insertion and recalculation. No replanning session was needed. No existing code was modified \u2014 only the Experience’s Flow composition configuration.<\/p>\n
                                    Figure 6 \u2014 Telehealth change propagation: two new interface components (dashed border \u2014 VisitTypeFlow and TelehealthInteraction). No new backend components \u2014 telehealth is a frontend concern. The backend returns a visit record with type and provider details; the frontend handles the connection.<\/em><\/p>\n
                                    graph TB\n    subgraph Backend["Backend (VBD) \u2014 no new components"]\n        SM[SchedulingManager]\n        EE[EligibilityEngine]\n        PME[ProviderMatchEngine]\n        SAE[SlotAllocationEngine]\n        IA[InsuranceAccessor]\n        CA[CalendarAccessor]\n        PA[ProviderAccessor]\n    end\n\n    subgraph Interface["Interface (EBD)"]\n        ABE[AppointmentBookingExperience]\n        VTF[VisitTypeFlow]\n        TI[TelehealthInteraction]\n        PSF[ProviderSearchFlow]\n        TSF[TimeSlotSelectionFlow]\n        PIF[PatientInfoFlow]\n        CF[ConfirmationFlow]\n    end\n\n    SM --> EE\n    SM --> PME\n    SM --> SAE\n    EE --> IA\n    PME --> PA\n    SAE --> CA\n\n    ABE --> PSF\n    ABE --> TSF\n    ABE --> PIF\n    ABE --> CF\n    ABE --> VTF\n    VTF --> TI\n\n    style SM fill:#0053e2,color:#fff,stroke-width:0\n    style ABE fill:#0053e2,color:#fff,stroke-width:0\n    style EE fill:#ffc220,color:#000,stroke-width:0\n    style PME fill:#ffc220,color:#000,stroke-width:0\n    style SAE fill:#ffc220,color:#000,stroke-width:0\n    style PSF fill:#ffc220,color:#000,stroke-width:0\n    style TSF fill:#ffc220,color:#000,stroke-width:0\n    style PIF fill:#ffc220,color:#000,stroke-width:0\n    style CF fill:#ffc220,color:#000,stroke-width:0\n    style VTF fill:#ffc220,color:#000,stroke:#ffc220,stroke-width:2px,stroke-dasharray:4\n    style TI fill:#2a8703,color:#fff,stroke:#2a8703,stroke-width:2px,stroke-dasharray:4\n    style IA fill:#2a8703,color:#fff,stroke-width:0\n    style CA fill:#2a8703,color:#fff,stroke-width:0\n    style PA fill:#2a8703,color:#fff,stroke-width:0\n<\/code><\/pre>\n
                                    \n
                                    References and Influences<\/h2>\n
                                    William Christopher Anderson<\/strong>
                                    \nAnderson, William Christopher. Volatility-Based Decomposition in Software Architecture.<\/em> February 2026.
                                    \nAnderson, William Christopher. Experience-Based Decomposition.<\/em> March 2026.
                                    \nAnderson, William Christopher. Boundary-Driven Testing.<\/em> March 2026.
                                    \nAnderson, William Christopher. The Design of Projects: A Practitioner-Oriented Articulation.<\/em> February 2026.<\/p>\n
                                    Harmonic Design synthesizes these four frameworks. The role taxonomies, volatility axes, communication rules, estimation methodologies, and validation mechanisms in this paper are taken from these sources. HD’s contribution is the recognition of their structural isomorphism and the articulation of the coherence properties that emerge from practicing all four together.<\/p>\n
                                    Juval Lowy<\/strong>
                                    \nLowy, Juval. Righting Software.<\/em> Addison-Wesley, 2019.<\/p>\n
                                    The Manager-Engine-Resource Accessor taxonomy that underlies VBD \u2014 and by extension the orchestration-execution-accessor tier structure that appears in all four HD frameworks \u2014 originates in Lowy’s IDesign methodology. The project design methodology that derives project plans from architectural decomposition also originates in IDesign. HD extends IDesign’s backend structural model across the interface, test, and project planning layers.<\/p>\n
                                    David L. Parnas<\/strong>
                                    \nParnas, David L. “On the Criteria To Be Used in Decomposing Systems into Modules.” Communications of the ACM<\/em>, 1972.<\/p>\n
                                    Parnas’s information hiding principle \u2014 that modules should be designed around design decisions likely to change \u2014 is the intellectual foundation of volatility-first decomposition. HD is the system-scale extension of this principle, applied simultaneously at the backend, interface, test strategy, and project planning levels.<\/p>\n
                                    Eric Evans<\/strong>
                                    \nEvans, Eric. Domain-Driven Design: Tackling Complexity in the Heart of Software.<\/em> Addison-Wesley, 2003.<\/p>\n
                                    DDD’s bounded context concept and HD’s tier boundaries are complementary rather than competing. HD operates within bounded contexts, governing how each context organizes its internal structure.<\/p>\n
                                    Robert C. Martin<\/strong>
                                    \nMartin, Robert C. Clean Architecture.<\/em> Pearson, 2017.<\/p>\n
                                    Martin’s Dependency Rule and boundary discipline align with HD’s communication model. HD provides the volatility-based account of why those dependency directions are correct.<\/p>\n
                                    Martin Fowler<\/strong>
                                    \nFowler, Martin. “The Practical Test Pyramid.” martinfowler.com<\/em>, 2018.<\/p>\n
                                    BDT builds on Fowler’s test pyramid by grounding its levels in structural tiers. HD extends this further by making the test pyramid a consequence of the structural isomorphism across all four layers.<\/p>\n
                                    James E. Kelley and Morgan R. Walker<\/strong>
                                    \nKelley, James E.; Walker, Morgan R. “Critical-Path Planning and Scheduling.” Proceedings of the Eastern Joint Computer Conference<\/em>, 1959.<\/p>\n
                                    The Critical Path Method provides the mathematical foundation for the network analysis, float calculation, and critical path identification used in Project Design and, by extension, in the HD project planning layer.<\/p>\n
                                    Quentin W. Fleming and Joel M. Koppelman<\/strong>
                                    \nFleming, Quentin W.; Koppelman, Joel M. Earned Value Project Management.<\/em> Fourth Edition. Project Management Institute, 2010.<\/p>\n
                                    Earned value management provides the tracking and projection techniques used during project execution in the PD pillar of HD.<\/p>\n
                                    Frederick P. Brooks Jr.<\/strong>
                                    \nBrooks, Frederick P. The Mythical Man-Month.<\/em> Addison-Wesley, 1975.<\/p>\n
                                    Brooks’s observation that adding people to a late project makes it later is reflected in PD’s treatment of staffing, compression limits, and the one-to-one rule that aligns with HD’s component boundaries.<\/p>\n
                                    \n
                                    Author’s Note<\/h2>\n
                                    Harmonic Design as a unified discipline is the author’s original work. The specific recognition that Volatility-Based Decomposition, Experience-Based Decomposition, Boundary-Driven Testing, and Project Design are harmonics of the same fundamental principle \u2014 that their structural tiers are isomorphic; that practicing all four together produces properties none achieves alone; that the architecture is the plan; and that this coherence is what enables the configuration-driven capability described in Section 8 \u2014 has not, to the author’s knowledge, been articulated before. After twenty years of practicing this way across many systems and organizations, the author has not encountered another practitioner who applies all four as a unified discipline, or who describes the resulting configurability and planning predictability as structural consequences rather than architectural features.<\/p>\n
                                    The four pillars have different origins.<\/p>\n
                                    Volatility-Based Decomposition<\/strong> and Project Design<\/strong> are deep articulations of Juval L\u00f6wy’s IDesign methodology \u2014 the Manager\/Engine\/Resource Accessor taxonomy originates there, as does the practice of deriving project plans directly from architectural decomposition. The author’s contribution is years of applied refinement and the written articulation of these ideas.<\/p>\n
                                    Experience-Based Decomposition<\/strong> builds on Alan Cooper’s goal-directed design, Brad Frost’s Atomic Design, and VBD’s volatility-first thinking. The specific synthesis into a structured tier hierarchy with explicit communication rules, configuration-driven composition, and deliberate isomorphism with the backend component taxonomy is the author’s own; if prior art exists under a different name, the author has not encountered it.<\/p>\n
                                    Boundary-Driven Testing<\/strong> is the natural consequence of applying VBD and EBD correctly, made explicit. The framework that derives each component’s test profile from its architectural role, reads mock placement as boundary evidence, and treats testing difficulty as a structural diagnostic rather than a tooling problem is, to the author’s knowledge, not articulated this way elsewhere.<\/p>\n
                                    The configurability properties described in Section 8 are not theoretical. The author has built production systems driven entirely by configuration \u2014 backends that derive complete workflow behavior from schema, interfaces that compose from YAML, and factories that extend their own capability through configuration uploads without code deployment. The project planning properties described in Section 6 are equally empirical \u2014 the author has planned and delivered projects where the project network was derived from the architectural decomposition, where requirement changes were absorbed through work package insertion rather than replanning, and where management selected from three quantified options rather than negotiating a single estimate. These outcomes were not engineered in as features. They emerged from the structural discipline described in this paper, applied consistently over time.<\/p>\n
                                    The four pillars govern the complete lifecycle: VBD governs what to build, EBD governs how to present it, BDT governs how to verify it, and PD governs how to plan and execute the work. With all four in place, the structural map drawn from volatility analysis governs every phase of a software system’s lifecycle \u2014 from initial decomposition through project planning, implementation, testing, and ongoing evolution. The architecture is the plan. The plan is the architecture. They are one map, read four ways.<\/p>\n
                                    Harmonic Design is a framework, but not in the sense of a tool to be picked up and applied mechanically. It is a framework in the sense of a structural discipline \u2014 one that compounds over time, producing qualitatively different kinds of systems the longer it is applied with consistency.<\/p>\n
                                    \n
                                    Distribution Note<\/h2>\n
                                    This document is provided for informational and educational purposes. It may be shared internally within organizations, used as a reference in architectural and design discussions, or adapted for non-commercial educational use with appropriate attribution. All examples are generalized and abstracted to avoid disclosure of proprietary or sensitive information.<\/p>\n","protected":false},"excerpt":{"rendered":"
                                    A Unified Software Engineering Framework Author: William Christopher Anderson Date: April 2026 Version: 1.0 Executive Summary Four things are true of every long-lived software system. It has a backend that must evolve. It has an interface that must evolve. It has tests that must survive both kinds of evolution. And it has a project plan … Read more<\/a><\/p>","protected":false},"author":0,"featured_media":0,"parent":11,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"_uag_custom_page_level_css":"","footnotes":""},"methodology":[],"class_list":["post-131","page","type-page","status-publish"],"uagb_featured_image_src":{"full":false,"thumbnail":false,"medium":false,"medium_large":false,"large":false,"1536x1536":false,"2048x2048":false,"trp-custom-language-flag":false,"post-thumbnail":false,"hf-card":false,"hf-hero":false},"uagb_author_info":{"display_name":"","author_link":"https:\/\/dev.harmonic-framework.com\/es\/author\/"},"uagb_comment_info":0,"uagb_excerpt":"A Unified Software Engineering Framework Author: William Christopher Anderson Date: April 2026 Version: 1.0 Executive Summary Four things are true of every long-lived software system. It has a backend that must evolve. It has an interface that must evolve. It has tests that must survive both kinds of evolution. And it has a project plan…","_links":{"self":[{"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/pages\/131","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/types\/page"}],"replies":[{"embeddable":true,"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/comments?post=131"}],"version-history":[{"count":10,"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/pages\/131\/revisions"}],"predecessor-version":[{"id":682,"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/pages\/131\/revisions\/682"}],"up":[{"embeddable":true,"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/pages\/11"}],"wp:attachment":[{"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/media?parent=131"}],"wp:term":[{"taxonomy":"methodology","embeddable":true,"href":"https:\/\/dev.harmonic-framework.com\/es\/wp-json\/wp\/v2\/methodology?post=131"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}