---
title: ML Model Description for Airborne Assurance
url: https://www.emergentmind.com/topics/machine-learning-model-description-mlmd
type: topic
---

# ML Model Description for Airborne Assurance

Machine Learning Model Description (MLMD) is an unambiguous, non-volatile, semantically defined description of a trained machine-learning model that sits between the Training Framework Model (TFM) and the Target Model (TIM) in airborne-system development. In the formulation refined for ED-324-aligned assurance, the MLMD excludes training artefacts such as learning rate, loss function, and optimizer, and instead records the inference-relevant computational structure and parameters as a directed acyclic graph (DAG) of operators and dataflow whose semantics can be preserved during implementation in the target environment [2509.18681].

## 1. Definition and conceptual boundaries

In the airborne assurance setting, the TFM is the model as represented inside a training framework such as Keras or PyTorch. It includes framework-specific code, runtime details, and training machinery. The TIM is the implemented model running in the airborne target environment, including its hardware, operating system, compiler, and runtime libraries. The MLMD is the intermediary artifact: it is not the executable training object and not yet the deployed implementation, but the stable description from which implementation proceeds [2509.18681].

This distinction is substantive rather than editorial. The TFM is tied to a complex and evolving software stack, whereas the MLMD is intended to be reviewable, reproducible, and implementation-oriented. Accordingly, the MLMD contains only what is necessary for inference: operator structure, dataflow, tensor shapes, data types, and learned parameters such as weights and biases. The paper on airborne implementation makes this point explicitly by stating that the MLMD does not contain learning rate or loss function, even though those are intrinsic to training the TFM [2509.18681].

Within the lifecycle discussed for ED-324 and the EASA concept paper, the MLMD occupies the junction between the “first V,” where the intended function is designed and verified, and the “second V,” where that verified model must be replicated in the target environment. Its role is therefore both descriptive and normative: it describes the model, and it constrains what counts as a correct implementation.

## 2. Representation, operator semantics, and abstraction levels

The concrete representation adopted in the airborne work is ONNX. In that instantiation, an MLMD is a `Model` containing a `Graph`; the `Graph` contains `Node`s and `Initializer`s; each `Node` is identified by `op_type` and `domain`, and each `Initializer` stores constant tensors such as learned weights and biases. Semantically, execution is the composition of operator functions along the graph’s dataflow, so the MLMD is a DAG whose nodes are operators and whose edges are tensors [2509.18681].

The central technical issue is not merely graph storage but graph semantics. The paper therefore introduces four semantics levels, from abstract mathematics to concrete execution. They organize what it means for an implementation to preserve the MLMD.

| Level | Description | Typical concern |
|---|---|---|
| SL0 | Mathematical level | Operators as functions over $\mathbb{R}$ or $\mathbb{Z}$ |
| SL1 | Machine number representation level | FP32, FP16, BF16, INT, IEEE-754 behavior |
| SL2 | Operational semantics level | Decomposition into scalar operations, approximation of functions |
| SL3 | Execution model level | Rounding modes, FMA behavior, compiler and hardware effects |

At SL0, the model is the mathematical composition of its operators. At SL1, the model is already tied to a machine representation such as FP32 or INT8, so representability, overflow, and rounding become part of the description. At SL2, tensor expressions are decomposed into explicit scalar operations and approximations to functions such as $\exp$, $\tanh$, or $\sigma$. At SL3, the description reaches the level of concrete execution effects, including register usage, fused multiply-add units, extended precision, and compiler decisions. Each level encapsulates the preceding one, so implementation fidelity can be discussed at different granularities [2509.18681].

This layered view is important because safety arguments do not always require bit-exact equality. In some contexts, preserving the mathematical function is sufficient; in others, only a bound at the execution level is acceptable.

## 3. Semantics preservation as a verification relation

The airborne formulation treats semantics preservation as a relation among an unknown ground-truth function $f$, the function realized by the TFM, $\hat f_1$, and the function realized by the TIM, $\hat f_2$, over a dataset $\mathcal{D} = \{x_i\}_{i\in[1,n]}$. Verification of the TFM is expressed with metrics such as $L_\infty$, bias, and MAE. Typical examples are
\[
L_\infty(f,\hat f_1)=\sup_i |f(x_i)-\hat f_1(x_i)| \le R_{L_\infty},
\]
\[
\mathrm{bias}(f,\hat f_1)=\frac{1}{n}\sum_{i=1}^{n}(\hat f_1(x_i)-f(x_i)),
\]
and
\[
\mathrm{mae}(f,\hat f_1)=\frac{1}{n}\sum_{i=1}^{n}|\hat f_1(x_i)-f(x_i)|.
\]
The question is then whether those verified properties survive implementation [2509.18681].

The paper formalizes this with an implementation error bound $\varepsilon_M$ and a verification margin $g_M$. For metrics with upper-bound requirements, the preservation rule is
\[
|M(f,\hat f_1)| \le R_M-g_M \;\wedge\; L_\infty(\hat f_1,\hat f_2)\le \varepsilon_M
\;\Rightarrow\;
|M(f,\hat f_2)| \le R_M.
\]
For lower-bound requirements, the implication is
\[
|M(f,\hat f_1)| \ge R_M+g_M \;\wedge\; L_\infty(\hat f_1,\hat f_2)\le \varepsilon_M
\;\Rightarrow\;
|M(f,\hat f_2)| \ge R_M.
\]
This converts implementation fidelity into a metric-preservation problem [2509.18681].

The simplest case is the $L_\infty$ metric itself, where the triangle inequality gives
\[
L_\infty(f,\hat f_2)\le L_\infty(f,\hat f_1)+L_\infty(\hat f_1,\hat f_2).
\]
In the worst case, $\varepsilon_\infty=0$, which corresponds to bit-exact replication at SL3. More generally, approximate preservation is allowed. The appendix extends the construction to MAE, MSE, variance, EVS, $R^2$, and MAPE, deriving explicit forms of $g_M$ from $\varepsilon_M$ and the TFM’s already verified metrics. The result is a quantitative notion of “same model” that is stronger than architectural similarity and weaker than strict bit identity.

## 4. Function in certification and implementation workflows

Within the W-shaped lifecycle described in the paper, the first V-cycle validates the intended function and its properties on the TFM, while the second V-cycle implements the MLMD into the TIM and demonstrates semantics preservation. This decomposition answers a core certification difficulty: the training framework itself is typically not suitable as airborne software, yet the deployed implementation must be shown to preserve the training-time verification results [2509.18681].

The representation and tool chain reflect that requirement. MLMDs can be exported from Keras or PyTorch into ONNX and then transformed, if needed, into subsets suitable for code generation. The paper discusses code generation or execution routes through ACETONE, onnx2c, SCADE, and ONNX Runtime. The output may then be compiled for platforms such as Intel x86 Linux servers or an NXP T1042 PowerPC target with the Windriver DIAB compiler [2509.18681].

The associated verification strategy is deliberately asymmetric. One first verifies the TFM against ground truth. One then verifies the TIM against the TFM, not directly against ground truth, by checking that the implementation discrepancy stays within the $\varepsilon_M$ budget implied by the earlier metric margins. This separation reduces the burden of duplicating end-to-end model verification on every target platform while keeping the safety argument quantitative.

## 5. Industrial demonstrations and numerical budgets

The paper evaluates the framework on two regression use cases for helicopter avionics. The first, labeled `lstm`, is an aircraft-weight estimation model with three bidirectional LSTM layers followed by a dense layer. It takes a 20-dimensional input feature vector with time frame 16 and uses FP32 in the TFM. Over 4288 test samples, the TFM achieved, among other values, $\mathrm{mae}^{(1)}=0.053$ with requirement $R_{\mathrm{mae}}\le 0.07$. The most restrictive implementation bound came from $R^2$, which yielded $\varepsilon_M = 0.008$. Under that criterion, FP64, FP32, FP16, INT16, and INT14 implementations preserved semantics, whereas BF16, INT12, and INT10 did not [2509.18681].

The second, labeled `linear`, is an aircraft-loads computation model implemented as an MLP with three dense layers and ReLU activations. Over 2000 test samples, the TFM achieved $\mathrm{mae}^{(1)}=0.033$ with requirement $R_{\mathrm{mae}}\le 0.06$. Here the most restrictive bounds came from EVS and $R^2$, both giving $\varepsilon_M = 0.015$. FP32 implementations generated via ONNX Runtime, onnx2c, and ACETONE preserved semantics, as did FP16 and INT16 configurations, whereas BF16, INT14, INT12, and INT10 did not [2509.18681].

These demonstrations clarify the operational meaning of MLMD. It is not simply an exchange format. It is a vehicle for quantifying how much numerical transformation is acceptable when moving from framework inference to airborne implementation. A plausible implication is that MLMD becomes most valuable precisely when one wants to exploit reduced precision, alternative compilers, or heterogeneous hardware without re-opening the full model-verification problem.

## 6. Terminological ambiguity in the arXiv literature

The acronym “MLMD” is not unique to Machine Learning Model Description. In recent arXiv usage it also denotes mixed-language multi-document summarization [2410.09773], machine learning molecular dynamics [2503.05120], and “Masked Language Model-based Detection” for textual adversarial example detection [2304.08767]. An earlier information-theoretic paper on Differential Description Length also uses “MLMD” in the phrase “Machine Learning Model Description,” but there the emphasis is compression-based model and hyperparameter selection rather than airborne implementation semantics [1902.04699].

This ambiguity matters because the airborne notion of MLMD is unusually specific. It refers neither to a class of training methods nor to a model family, but to a semantically constrained artifact positioned between training and deployment. In that sense, the airborne literature narrows the term from a generic “description of a model” to a certification-oriented interface that specifies operators, parameters, numerical representation, and implementation-preservation obligations. This suggests that, in safety-critical contexts, the phrase “Machine Learning Model Description” is best understood together with the TFM/MLMD/TIM triad and the formal language of semantics preservation.

Source: https://www.emergentmind.com/topics/machine-learning-model-description-mlmd