Observation Does Not Leave a Copy of the Road#

Data enters the engineering chain next. LiDAR on the following vehicle measures relative distance and speed. Its CAN bus supplies vehicle speed, engine state, and brake state, while DSRC messages carry the lead vehicle’s state. The PATH team also observed that, under their test conditions, LiDAR-relative speed lagged the speed derived from vehicle communication by about 0.5 seconds. They used that feature to help determine whether the LiDAR target was the communicating lead vehicle.¹

Every record passes through sensing, sampling, synchronization, selection, and estimation. The relation between data $Z$ and referent system $W$ should remain explicit:

$K_{\mathrm{obs},P}$ may denote a deterministic measurement procedure or a probabilistic observation kernel. The subscript $P$ records the influence of purpose on observation. Data collected to control headway will not automatically contain everything needed for crash reconstruction, emissions assessment, or a study of driver attention.

Data is not a reduced photograph of $W$. A LiDAR “relative distance” already depends on target detection and coordinate interpretation. A CAN signal depends on an internal vehicle protocol, and a communication message depends on how another vehicle encodes its own state. Missingness, delay, noise, and selection mechanisms belong to the way we encounter the system. Keeping data separate as $Z$ preserves those conditions for later calibration, training, and validation.

A Model Must Specify Behavior and Interpretation#

The move from $W$ to a mathematical model is another transformation. The modeler chooses states, parameters, and relations, specifies admissible behavior, then states what the symbols refer to in the referent system. A semantic model in the narrow sense can be written as

$\operatorname{Sig}_{\mathcal M}$ is a typed signature: variables, parameters, inputs, outputs, and state interfaces. Units can also be encoded in the types. In the PATH equations, $x_r$ means relative distance between the vehicles, while $v_p$ and $v_f$ denote lead- and following-vehicle speed. The interpretation relation tells us which onboard signal supplies each quantity and how its coordinates correspond to the road.

$\operatorname{Beh}_{\mathcal M}$ is a typed semantic object. It may be a static relation, a set of trajectories, a probability kernel, a distribution, or an operator. It specifies the responses the model permits. It need not be time-evolving “dynamics.” Ohm’s law permits a static relation among voltage, current, and resistance. A PDE with initial and boundary conditions may define a solution set or an operator. A statistical model may assign an output distribution to every input. An automaton permits a set of states and transition traces. Calling all of these objects dynamics forces static, probabilistic, and formal models to claim a structure they do not have.

$\operatorname{Int}_{\mathcal M}$ is the interpretation map that sends mathematical symbols back to the referent system. Without it, $\dot x=f(x,u)$ is a formal system that has yet to refer to this engineering object. Once $x$ is identified with vehicle state and $u$ with a speed command, the formal system becomes a model of this engineering problem. Assumptions, validity domains, and qualification records specify the speeds, gears, and operating conditions under which its parameters hold. Two teams may write the same equations yet model different objects because they use different variable interpretations, boundaries, or scales.

This definition deliberately leaves solvers, training scripts, and evaluation programs outside the model. They act on the model and shape the results we see, but “which behaviors are admissible” and “how one behavior is computed” carry different responsibilities. Formal semantics and open-system theory supply languages for separating signatures, behaviors, ports, and composition.² A discretization or solver may change the resulting parameter instance or even the effective equations when it participates in training, is jointly optimized, or becomes a learned object itself. That feedback must then be recorded against both $C_v$ and $M_{\hat\theta}$.³

The Same $\mu$ Can Play Four Different Roles#

Probability notation makes layer confusion easy to see. A distribution $\mu$ can occupy at least four roles:

1. In a probabilistic model, $\mu$ specifies the probability law of a random variable and belongs to $\operatorname{Beh}_{\mathcal M}$.
2. During training, $\mu_{\mathrm{train}}$ describes how samples enter empirical risk and belongs to the data regime and operational criterion.
3. During qualification, $\mu_{\mathrm{val}}$, or a set of test conditions, records the coverage of the available evidence.
4. During operation, $\mu_{\mathrm{deploy}}$ describes the input regime encountered by the artifact, which may have departed from the training and validation conditions.

Neural-operator studies often express operator-learning error as an expectation over a distribution of functions. This does not make the distribution an intrinsic component of the learned operator in every case. A change in sampling distribution may change training and evaluation without changing the mathematical definition of the target operator.⁴ In a generative model, by contrast, the conditional distribution is itself the behavior that the model expresses. The role of $\mu$ depends on whether it defines admissible behavior, produces observations, or bounds evidence.

Observation leaves a record of contact with the referent system. A model states the behavior admitted under a chosen abstraction. Identification, calibration, or training can connect the two without making them interchangeable. Engineering must still turn admissible behavior into desired behavior.

A Goal That Exactly Matches the Task#

Start with a clean case. Given a directed graph $G=(V,E)$ with nonnegative edge weights $c_e\ge 0$, define the task as finding a feasible path from $s$ to $t$ with minimum total edge weight. The specification itself is

Here the operational criterion $J(p)=\sum_{e\in p}c_e$ expresses the task exactly. Dijkstra’s algorithm and A* with an admissible heuristic are different computational methods for obtaining the same object. As long as the edge weights, graph, and definition of optimality remain fixed, solving $J$ fulfills $S$.

If “shortest path” is meant to describe a route that is safe, punctual, smooth, low-carbon, and acceptable to travelers, the same edge-weight sum becomes a proxy that compresses several values. The way risk preference, travel-time reliability, and road restrictions enter $c_e$ determines which part of the larger task it covers.

Operationalization therefore has at least four common forms: exact correspondence, conservative approximation, empirical proxy, and heuristic substitute. A conservative approximation may sacrifice performance to secure a requirement. An empirical proxy relies on a correlation observed in data, while a heuristic measure supplies direction only. A mature engineering argument identifies which form it uses instead of asking one symbol to stand for value, specification, loss, and evidence at once.

What an MPC Cost Function Represents#

Return to the PATH controller. Let $x_r$ be relative distance, $v_f$ the following vehicle’s speed, and $t_{hw}$ the headway selected by the driver. The spacing error is

The discrete model predicts $N$ steps ahead. Its quadratic cost can be summarized as

where $\Delta u$ penalizes abrupt changes in the speed command and $\Delta v$ penalizes the speed difference between the two vehicles. Positive weights $\rho_e,\rho_u,\rho_v$ trade headway tracking against control smoothness and response speed. The prediction is also subject to a lower bound on distance, limits on the speed command, and upper and lower acceleration bounds.¹

The expression does not combine safety, comfort, throughput, and driver acceptance into a natural common unit. Its job is more specific. Within a predictive model and a finite horizon, it uses a distance threshold for part of the safety boundary, acceleration and control variation as partial proxies for comfort, then weights those terms to choose a control sequence. Driver experience still requires road tests. Identifying the cooperating lead vehicle still requires a state machine and fallback. Risks beyond the prediction horizon still need other evidence.

The distinction resolves a common misunderstanding. A hard constraint in an MPC problem holds if the problem is feasible and solved under the stated model; it does not automatically become a hard guarantee for the physical vehicle in every environment. An error in state estimation, a braking response outside the model, or a late message can separate the actual trajectory from the predicted one. “The optimization problem satisfies its constraints” and “the vehicle satisfies its field requirements” are two claims that need a connecting argument.

Figure 2. In the shortest-path example, the specification and objective can coincide exactly. In platoon control, the objective and constraints operationalize only part of the engineering requirements, while computation and field integration continue to alter behavior.

A Solver Operates on a Different Object#

The predictive controller does not solve the continuous equations directly at every time step. The PATH team first discretized the continuous state model as

where $T$ is the sampling period and $\hat\theta_k$ contains parameters identified online. The controller uses this discrete model to generate a future trajectory, solves a constrained optimization problem, applies only the first element of the control sequence, then reads new observations, updates its parameters, and solves again. The MPC “model” therefore spans at least the model family, the current parameter instance, a discrete representation, and one online optimization.

Call the representation, algorithm, code, and runtime configuration that produce output the computational artifact $C$. Its behavior is

the output, timing, and resource traces produced under given inputs, resources, and configuration. The abstract behavior of the semantic model is

An implementation relation asks how far $B_C$ preserves $B_M$. For a numerical model, the answer may be an error bound. A compiled controller brings discretization, tolerance, and finite precision into the relation. A formal system may require a refinement relation. The phrase “the algorithm implements the model” skips the arrow where some of the most consequential failures occur.

A separate multilayer platoon-control experiment gives a closer view of that arrow. Ibrahim and colleagues split each following vehicle’s controller into two layers. The upper distributed MPC received lead-vehicle messages and solved a receding-horizon quadratic program at 10 Hz; the lower state-feedback layer executed desired acceleration on a 2 ms cycle. The researchers used the Fast Gradient Method, fixed matrices that could be computed offline, generated C code automatically from MATLAB, and ran it on four Cohda MK5 units. Packet loss, noise, delay, and short stalls in a non-real-time operating system all left traces in the results.⁵

Ibrahim’s study describes a separate system. It shows how the same MPC idea takes a concrete shape in another artifact. The optimization problem in the paper specifies the object to be solved. Matrix precomputation, the iterative method, code generation, processors, and deadlines determine whether this computation finishes in time. Simulation on four embedded devices supports real-time implementation feasibility. Vehicle dynamics and road deployment still require separate evidence.

Probabilistic Programs, PDEs, and PINNs Pass Through the Same Gate#

This layer is not peculiar to control. In Stan, a program can specify parameters, observations, and a target log density, usually unnormalized, conditional on the data. Independent Bernoulli observations given $\theta$, for example, define the probability kernel

Here $\theta\in[0,1]$ and $y\in\mathcal Y=\{0,1\}^N$. For any event $A\subseteq\mathcal Y$, $K(\theta,A)=\sum_{y\in A}K(\theta,\{y\})$. “Kernel” here means a mapping from a condition to a probability measure, not a similarity function from kernel methods. It belongs to the model’s probabilistic semantics. The Stan statement y ~ bernoulli(theta) increments the target log density; one can then sample with HMC, usually using NUTS, or optimize instead. Changing the inference algorithm does not by itself change the probabilistic semantics, although the output samples and approximation error can change with algorithm, initialization, and computational budget.⁶

A PDE passes through the same distinction. Once function spaces and initial and boundary conditions are specified, the continuous problem

first defines a solution set. It defines a corresponding single-valued solution operator only when the problem is well posed and $a$, $f$, or $g$ is designated as input. A weak solution of a conservation law may also require an entropy condition or another solution-selection rule. A program chooses a mesh $h$, discretization scheme, linearization method, and stopping tolerance. A linear discrete problem can be written as

A more general nonlinear problem may be written $R_h(u_h)=0$, while a time-dependent system produces a time-stepping map. Mesh convergence, residuals, and code comparison provide complementary evidence. No one of them alone shows that a numerical result approaches the selected continuous solution.

A PINN compresses relations from several layers into one training process. PDE residuals, boundary conditions, and observations are often combined as

The equation may define the semantics of the target solution, while a boundary condition may be a hard requirement. Once weighted, all three terms become a training criterion. Gradient imbalance or optimization difficulty can leave the expected solution unlearned even as aggregate loss falls. Failure analyses have traced some cases to an ill-conditioned optimization landscape created by the composite loss rather than to a change in the solution semantics of the target equation.⁷ $J_{\mathrm{res}}$ and $J_{\mathrm{bc}}$ are also usually empirical quantities evaluated at finitely many collocation points. A low empirical loss does not bound the continuous residual everywhere or directly establish error against the true solution. Saying that “physics is in the loss” describes an implementation arrangement. The physical law, training criterion, and optimization algorithm still need separate traces.

We have now moved from behavior admitted by the semantic model to output produced by the computational artifact. The next step determines where that output ends: on an engineer’s screen, or inside a closed loop that changes the referent system.

How a Speed Command Reaches the Wheels#

The PATH MPC outputs a speed command $u=v_c$, not a throttle opening or brake pressure. The following vehicle also contains a fast inner speed-servo loop. Its factory Nissan ACC accepts virtual LiDAR-relative distance and speed, then drives the engine and brakes. The team accepted this longer actuation chain because it reduced modifications to the original ECU. In return, the new controller had to include a factory controller it knew only partially in the closed loop and accept the roughly $0.3g$ braking limit available through that interface.¹

Message identity matters too. The system enters CACC mode only after confirming that the LiDAR target is the same lead vehicle sending DSRC data. If the targets do not match, the state machine passes real LiDAR data back to the factory ACC. This state machine carries responsibility for mode semantics, interface routing, and fallback. Copying only the MPC formula would remove the part of the engineering design closest to its failure boundary.

The same FX45 can appear in both $W$ and $O$. As part of $W$, it is the vehicle we seek to describe and control, with mass, drag, actuation delay, and a driver. As part of $O$, it is the operational system into which the computational artifact is embedded, supplying CAN, sensing, communication, and braking interfaces. The framework distinguishes responsibilities; it does not require a separate physical object for each role.

Field feedback also changes the next round of information. A speed command changes vehicle motion. Motion changes LiDAR and CAN readings. New observations feed the next online identification and optimization. The sequence $W\to Z\to M\to C\to O\to W$ therefore forms a closed loop. Once the computational artifact enters a deployed system, the semantic model continues to describe the world while actions from the closed loop change what the next observation encounters.

Naming the Eight Roles in the Closed Loop#

All eight roles in the engineering model chain have now appeared:

These are not eight independent dimensions or stages that can only proceed forward. A computational budget may force engineers to shorten the prediction horizon or rewrite the objective. Interface tests may uncover an error in state interpretation. Road results may reopen the purpose and system boundary. The structure is better read as a typed responsibility graph: each node holds a kind of object, while each arrow records a transformation and its conditions.

Figure 3. The complete relational map of the engineering model chain. Qualification $Q$ attaches to specific claims and relations, while lifecycle trace $L$ runs along a version track, so neither appears as a ninth peer node.

”Correct” Needs an Object#

The complete map lets us separate several kinds of correctness that often borrow one another’s names. Define

as the behavior object of the semantic model, the execution behavior of the computational artifact, and the set of observable behaviors that a deployed instance may exhibit in a complete operating context $\xi$. Specifications can be separated by the object that carries them:

$S_M$ constrains mathematical behavior, such as conservation, stability, or a logical invariant. $S_C$ constrains the artifact’s resource use, determinism, and failure behavior. $S_O$ constrains field safety, performance, and reliability. $S_R$ constrains correspondence, error, refinement, and interfaces between model and implementation and between implementation and system.

Before comparing computational and abstract behavior, we also need a shared interface, observables, and time base. Let $B_C\in\mathcal B_C$ and $B_M\in\mathcal B_M$, and let $\alpha_{CM}:\mathcal B_C\to\mathcal B_M$ project artifact behavior back into model behavior. A core behavioral argument may include

A mathematical proof may support the first expression. The second instantiates a model-to-implementation relation in $S_R$. Tests and real-time measurements may support the third. The fourth is a robust statement over the qualified context domain $\Xi_Q$. The problem type $\tau$ determines $R^{\tau}_{\varepsilon}$: numerical work may use a norm bound, robust control a disturbance envelope, and formal methods a refinement relation. A probabilistic field claim instead requires $Q$ to supply a joint measure $\nu_Q$ over contexts and behavioral outcomes, together with a declared risk bound $\Pr_{(\xi,b)\sim\nu_Q}[b\models S_O]\ge 1-\delta$ and evidence for its estimate. If the evidence contains one road observation, the conclusion can address only that observation. Not every case needs all eight roles, but every relation carrying the present claim needs evidence.

Mathematical proof, software testing, and road experiments now form a traceable chain without collapsing into one score. A three-vehicle PATH test can observe responses in a finite platoon; it cannot prove a statement quantified over arbitrary platoon length. Conversely, an abstract proof of string stability cannot speak for fielded vehicles on its own if it omits target identification, braking limits, and communication implementation.

Each layer now has claims of its own. The engineering question becomes more precise than “Is the model correct?”: How can local evidence support a judgment adequate to the present use?

Two Evidence Paths Should Not Become a Ladder#

The Turbulence Modeling Resource (TMR) makes evidence addresses unusually clear. It fixes a turbulence-model version, equations, boundary conditions, meshes, and reference results so that different CFD implementations can be compared around the same problem. The pages for the standard Spalart-Allmaras (SA) model expose two distinct evidence paths.⁹

In the three-dimensional bump-in-channel verification case, CFL3D and FUN3D each compute solutions on five nested mesh levels. Engineers inspect trends under mesh refinement and compare how different codes implement the same equations and boundary conditions. Where quantities from both codes converge along a common trend, agreement strengthens the case that the programs consistently solve the declared mathematical problem. The TMR page keeps this question separate from whether the model matches experiments well.

In the two-dimensional convex-curvature validation case, results from three codes on the same $513\times193$ mesh nearly coincide and are then compared with revised experimental data. Code agreement makes a code defect a less likely explanation for any discrepancy. The remaining gap between computation and experiment must still be interpreted among model form, discretization error, boundary conditions, and experimental uncertainty. The page also states that it contains no full grid study, so the results are representative comparisons rather than “truth.”

The two paths are often drawn as a staircase from “low confidence” to “high confidence.” They work better as evidence lines aimed at different relations:

• Code and solution verification addresses the implementation relation between $C$ and $M$: whether the computational artifact faithfully implements the specified mathematical model, and with how much numerical error.
• Model validation addresses $M\leftrightarrow W$: how well the model reproduces the experimental referent for a given use, condition, and quantity of interest.
• Uncertainty quantification traces how inputs, parameters, numerical error, and model discrepancy enter results and claims.

Code verification and experimental comparison narrow different uncertainties, so industrial VVUQ practice records them separately.¹⁰

Figure 4. Evidence has an object address and a version address. Code agreement, physical validation, and field performance accumulate along different relations. When an object changes, engineers must check which old claims can still carry their evidence.

Once evidence has an object address, the next question is whether it survives a change to that object.

A Version Number Only Indexes Change#

Represent all objects and relations in the current case as a graph

When data, parameters, formulas, code, interfaces, purpose, or environment change, the system moves to

The value of $\Delta_t$ lies in identifying what the change touched, not in recording that an “upgrade” occurred. One replacement may leave the semantic model intact while invalidating prior evidence. A parameter update may create a new model instance while preserving some solver tests.

Old evidence can migrate only when the objects and assumptions on which it depends remain unaffected. A version number points to the change. Impact analysis and requalification close the chain of reasoning again.

Adaptive systems bring this question into runtime. Suppose an update rule $U$, new data $D_t$, and governance policy $R_t$ jointly produce

A change in parameters, structure, objective, or interface places at least one new object or relation in $\mathcal G_{t+1}$. Its identity lies in $M$, $J$, $C$, or $O$ according to where the change occurs. These objects may remain within one governed system lineage only if the update range, triggers, acceptance criteria, monitoring, and fallback have been defined. The US Food and Drug Administration’s 2025 final guidance on predetermined change control plans for AI-enabled medical-device software applies this structure to automatic continuous learning. Predetermined modifications, verification and acceptance criteria in the modification protocol, impact assessment, and ongoing post-update monitoring jointly bound acceptable change. The guidance recommends that a modification which fails its preset acceptance criteria and cannot be corrected should be recorded as a failure and not implemented.¹¹

The example comes from medical-device regulation but exposes a general engineering responsibility. The qualified object in online learning includes the update rule, guardrails, observations, and fallback, in addition to the current weights. Once a change leaves the established envelope, the system needs a new fitness-for-use judgment. “Continuous learning” cannot become an alias for automatic inheritance of evidence.

Guarantees Change Shape When Components Are Connected#

Versioning tracks change over time; composition tracks structural connection. Reusing an engineering component requires more than saving its code. A composable primitive record $\pi$ should expose its ports $\partial\pi$, behavioral semantics $\llbracket\pi\rrbracket$, assume-guarantee contract $K_\pi=(A_\pi,G_\pi)$, qualification evidence $Q_\pi$, and version $v_\pi$:

A wiring or composition operation $\omega(\pi_1,\ldots,\pi_m)$ first matches ports, then checks whether one component’s guarantees discharge another’s assumptions, and finally establishes compatibility between the composed behavior and the component semantics. $Q_\pi$ records the basis for these claims. It cannot make a system-level qualification package equal the sum of local evidence.

Platoon control supplies a concrete primitive. The unit should include more than a controller $K_i$; it must package the controller, vehicle dynamics, constant-time-headway policy, and communication boundary as a single “controlled-vehicle” component. We now switch to a different CACC system developed by Ploeg and colleagues. Following their notation, $u_i$ is the desired acceleration of vehicle $i$, not the PATH prototype’s speed command $u=v_c$. In their continuous-time linear model with one-vehicle look-ahead, the propagation channel between adjacent vehicles is

Under homogeneous continuous-time LTI dynamics, unidirectional coupling, identical controllers and headways, the same fixed communication delay, and the conditions in the paper’s Assumption 1, controller synthesis gives

For an input-output analysis with equilibrium initial conditions, homogeneity gives $\Gamma_i=\Gamma$. If ports and assumptions close along the entire string, then for every platoon length $m$ and $2\le i\le m$,

This expression gives the propagation condition for strict $L_2$ string stability. Definition 1 in the paper also requires, for general initial conditions, a bound on the initial-condition response that does not diverge with platoon length. The system-level result comes from composing propagation channels and quantifying over arbitrary platoon length, not from taking the union of several vehicles labeled “locally correct.”¹²

A change in topology changes the form of the guarantee. With two-vehicle look-ahead, each vehicle receives two upstream signals that share causes, so the system can no longer be decomposed into the same single-input adjacent propagation units. Ploeg and colleagues instead use the leader-to-vehicle-$i$ channel

and analyze semi-strict $L_2$ string stability accordingly. Adding one communication link changes both the decomposition and the contract that can be stated. Compatible ports, units, and message formats show that the system can be connected. Assumption closure, error propagation, common-cause failures, and emergent behavior still require system-level evidence.

The example also shows why evidence cannot be added mechanically. Non-amplification of an $L_2$ disturbance is a property of string response, not a guarantee that safe distance holds at every instant. The theoretical model excludes nonlinear limits such as emergency braking. A finite experiment with two or three vehicles cannot exhaust a statement about arbitrary platoon length. Local models, composition theorems, and finite experiments each have a clear address. Together they support one bounded engineering judgment.

The engineering model chain can now follow a controller through purpose, road, data, equations, solution, vehicle, evidence, and version. We can test the view by removing familiar pieces. Does it still work without dynamics, training data, field deployment, or a use that can be enumerated in advance?

Remove “Dynamics”: Static Relations Still Pass Through the Engineering Chain#

The macroscopic traffic-flow theory of Lighthill and Whitham begins with a static relation: flow $q$ depends on vehicle concentration $k$,

This relation has no temporal state. Combining it with vehicle conservation yields what is now called the kinematic-wave equation,

The extended semantic model therefore contains both a static flow-concentration relation and a differential operator constraining the full space-time field. The original paper situates its continuum approximation among many vehicles on long, congested roads and describes the empirical support available at the time as qualitative agreement. That boundary belongs to the model’s interpretation along with the equation.¹³

If an engineer uses only $q=f(k)$ for one capacity calculation, the computational artifact may shrink to a lookup table or a manual calculation procedure. Field deployment $O$ can be marked not applicable. Purpose $P$, referent $W$, semantic model $M$, computation $C$, and qualification $Q$ remain. With no data, $Z$ need not be invented. With no optimization task, $J$ can also be absent. A missing role limits the claims that can be made but does not damage the remaining relations.

Formal models carry this reduction further. A hybrid automaton can represent a thermostat as a combination of discrete modes and continuous temperature. Temperature decays in the off mode and rises in the on mode. Guards permit switching, while invariants restrict the states permitted within each mode. Its behavioral semantics is a set of execution traces alternating continuous flows and discrete jumps, not the single curve drawn by one simulation.¹⁴

In model checking, the referent domain may be the formal system under analysis, the specification $S$ a temporal-logic sentence, the semantic model $M$ the set of admissible traces, and the computational artifact $C$ a state-space search or certificate generator. The satisfaction relation

means that every admissible trace of $M$ satisfies $S$. This relation keeps specification distinct from model. It may involve no sensor data, training loss, or physical deployment. If every “goal” were forced into a functional to be minimized, a logical property would have to change its name. In the relational map it retains its own mathematical type.

Pure mathematical objects show the boundary of applicability. A group, topological space, or differential equation may still have a formal referent domain $W$. It remains outside the engineering model chain when there is no engineering purpose $P$, path of use, or qualification claim $Q$. The missing roles need not be filled. The engineering model chain studies how mathematical objects participate in engineering judgment or become engineering modules; it does not absorb mathematics itself.

Let One Formula Occupy Several Roles#

The second test retains the parts but lets them overlap. The PINN already lets one PDE define solution semantics and contribute to a training loss. A neural-network architecture can define the function family $M_\Theta$ while appearing in the artifact $C_v$ as a computational graph and tensor operators. One stretch of code may occupy several roles, but the implementation relations among those roles must remain visible.

Neural operators provide another angle. A target operator

maps input functions to solution functions. The training distribution $\mu_{\mathrm{train}}$ determines which inputs are encountered more often, while the discrete mesh determines how functions are represented during training and execution. Changing the training distribution usually leaves the target operator $\mathcal G^\dagger$ unchanged but alters aggregate risk, the resulting $M_{\hat\theta}$, and the evidence envelope. For a neural operator that has genuine discretization invariance and fixed parameters, a change of mesh mainly affects $C$. With a fixed-grid architecture or retraining, it may also affect $M_\Theta$ or $M_{\hat\theta}$.

Foundation models push this overlap into large-scale reuse. A pretrained artifact $b$ can accumulate capability tests, training-data documentation, and general risk analysis without yet facing each downstream purpose, interface, and consequence. A more suitable unit of qualification is

The same foundation model may summarize traffic reports, forecast travel demand, recommend signal timing, or participate in safety-related control. The outputs may look similar while error costs and field feedback differ. Base evidence can be reused; permitted use cannot be inherited in bulk.

Underspecification in machine learning shows that several instances can perform similarly on standard tests while behaving very differently under stress or in deployment. Research on goal misgeneralization shows another possibility: a system acquires the required capability on the training distribution but pursues the wrong objective in a new context.¹⁵ Repeating the same average $J_{\mathrm{eval}}$ score cannot resolve either problem. We need to know which $M_{\hat\theta}$ training produced, which $O$ received it, which environments the evaluation evidence covered, and whether the relation between $J$ and the real specification $S$ still holds.

Causal models change the type of query again. The same variables and structure can answer observational, interventional, or counterfactual questions, each under its own identification assumptions. The same data distribution does not imply the same answer to all three. Here the engineering model chain adds relation subtypes rather than a universal numerical dimension called “causality.”

Let the Referent System and Model Move Together#

The third test allows the boundary to change over time. A digital twin is often reduced to a live 3D image next to a physical object, but its persistent relation to a particular entity is the distinguishing feature. The United Kingdom’s Defence Science and Technology Laboratory issued an official definition in 2025 that binds a digital twin to a specific entity, requires the capability for explicit bidirectional data flow, records an assumption set and validation envelope, and maintains synchronization on a timescale fit for the current decision. It also distinguishes connected, semi-connected, and disconnected states.¹⁶

That definition assigns concrete responsibilities: what is bound to what, which way data flows, how stale a state may be while still supporting the current decision, and how the physical system continues safely during disconnection. Its manufacturing example permits updates within a 24-hour window. An aircraft engine must catch up after landing and before its next state update, while control may demand millisecond timing. Purpose determines synchronization; the word “real-time” cannot settle it by itself.

In a connected state, $W\to Z\to M\to C$ repeats at the synchronization rate. A change in physical state refreshes the digital artifact through observation; simulation or optimization results may return as maintenance, scheduling, or control decisions. When a synchronization rule, model parameter, or interface changes, lifecycle trace $L$ must record the new identity and the effect on qualification. A polished 3D interface without binding, synchronization semantics, validity domain, or disconnected behavior provides visualization but does not complete the engineering relation.

A sociotechnical system extends feedback further. Once deployed, a prediction may change people’s choices, resource allocation, and the next data set. Perdomo and colleagues use a distribution map $D(\theta)$ to represent the effect of model parameters $\theta$ on the future data-generating process, then study stability under repeated training in performative prediction.¹⁷ The path $O\to W\to Z$ can therefore describe a controller changing physical state or a score, recommendation, or governing rule changing participants’ behavior.

This is best used as a mechanism check. If deployment helps produce the next data distribution, treating drift only as an external environmental change misses the causal loop. The referent system, data regime, and model instance must be recorded on the same timeline.

Generality Lies in the Relations#

These stress tests leave a small common structure, which is why it is useful. Static relations have no temporal dynamics. Formal models have no training loss. Offline CFD has no deployment loop. Foundation models usually face many downstream uses, while digital twins continuously change state and version. Their internal structures cannot be compressed into one set of orthogonal coordinates.

The framework is general because it identifies recurring engineering functions. Within a declared purpose, we can still trace purpose to referent, semantics to computation, and use to evidence. A model’s internal mathematics cannot discharge those engineering responsibilities on its own.

Data, objective functions, field deployment, and online feedback are conditional roles. Their presence depends on the work assigned to the model. A role that does not apply should be marked as such. If the role is necessary to the claim under review, its absence is an evidence gap. The resulting generality belongs to the observation and organization of relations; it does not require every model to share one ontology.

Structurally, this view contains three responsibility layers, eight candidate roles, two cross-cutting mechanisms, two paths of use, and four common referents. The intent-specification layer holds $P,S$; the referent-semantics layer holds $W,Z,M$; and the implementation-use layer holds $J,C,O$. Qualification $Q$ and lifecycle trace $L$ cross the whole graph. Offline results return to a decision context, while embedded artifacts enter an operational system. Model family, fixed-parameter instance, computational artifact, and deployed instance retain distinct identities. These counts describe different aspects of the view, not dimensions that can be added together.

The precise name for this structure is the layered-relational-qualification framework for engineering model systems. The main text calls it the engineering model chain. “Chain” here means a chain of reasons. It can be followed from purpose to result, or backward from an anomaly through versions, interfaces, and assumptions.