CAD.Reference:4.2 - Why these four contributions belong together

CAD.1 answers a functional design question: which decisions should become distinct and why? Its result determines which interactions are no longer solved together. A long-horizon optimizer and a fast feedback law are useful only if their separation addresses a real difficulty, such as calculation time or unequal access to information.

CAD.2 answers a modeling and realization question: what behavior does that separation actually produce? It turns a selected command into an exchange with units, time, interpolation, feedback and reset semantics, then derives the joint evolution. This can reveal that a presumed “same reference” is a different signal after implementation. The result constrains the decomposition: an upper model that cannot be related to the lower dynamics under useful conditions is a reason to retain more state, change the command or abandon that split.

CAD.3 answers a feasibility question: which behaviors can be requested without contradicting the conditions of their realization? Error is not merely a quality score. It consumes physical clearance and correction authority. A command envelope that makes the bound large can leave no useful actuation range; a smaller envelope can restore feasibility but prevent the required task. This result therefore constrains both the interface and the original functional choice. It also distinguishes a possible next action from a domain in which operation can continue.

CAD.4 answers a whole engineering choice: which mutually consistent configuration is worth realizing under the actual demand and resources? It compares the outputs of the other Methods, but it also changes their inputs. A different processor, horizon, model order or scheduling arrangement changes what can be computed on time and therefore which error dynamics and command domain are relevant.

The relation is not that every engineer must perform these Methods in this textual order. The relation is that a claim used by another part must be available with the conditions that make it useful. An inherited result can supply it. A changed condition can withdraw it. A missing result can block one architecture while leaving another usable.