ML Model Description for Airborne Assurance

• MLMD is a semantically defined artifact that omits training artifacts and details a model’s computational DAG and inference parameters.
• It employs a layered semantics framework—from abstract mathematics to concrete execution—to ensure verified properties transfer from training to deployment.
• MLMD supports certification by establishing numerical error bounds and verifying that implementations in airborne systems preserve model fidelity.

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 (Valot et al., 23 Sep 2025).

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 (Valot et al., 23 Sep 2025).

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 (Valot et al., 23 Sep 2025).

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](https://www.emergentmind.com/topics/metric-graph-bundles); the Graph contains Nodes and Initializers; 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 (Valot et al., 23 Sep 2025).

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 (Valot et al., 23 Sep 2025).

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

$\mathbb{Z}$0

$\mathbb{Z}$1

and

$\mathbb{Z}$2

The question is then whether those verified properties survive implementation (Valot et al., 23 Sep 2025).

The paper formalizes this with an implementation error bound $\mathbb{Z}$3 and a verification margin $\mathbb{Z}$4. For metrics with upper-bound requirements, the preservation rule is

$\mathbb{Z}$5

For lower-bound requirements, the implication is

$\mathbb{Z}$6

This converts implementation fidelity into a metric-preservation problem (Valot et al., 23 Sep 2025).

The simplest case is the $\mathbb{Z}$7 metric itself, where the triangle inequality gives

$\mathbb{Z}$8

In the worst case, $\mathbb{Z}$9, which corresponds to bit-exact replication at SL3. More generally, approximate preservation is allowed. The appendix extends the construction to MAE, MSE, variance, EVS, $\exp$0, and MAPE, deriving explicit forms of $\exp$1 from $\exp$2 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 (Valot et al., 23 Sep 2025).

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 (Valot et al., 23 Sep 2025).

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 $\exp$3 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, $\exp$4 with requirement $\exp$5. The most restrictive implementation bound came from $\exp$6, which yielded $\exp$7. Under that criterion, FP64, FP32, FP16, INT16, and INT14 implementations preserved semantics, whereas BF16, INT12, and INT10 did not (Valot et al., 23 Sep 2025).

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 $\exp$8 with requirement $\exp$9. Here the most restrictive bounds came from EVS and $\tanh$0, both giving $\tanh$1. 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 (Valot et al., 23 Sep 2025).

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 (Gao et al., 2024), machine learning molecular dynamics (Mai et al., 7 Mar 2025), and “Masked LLM-based Detection” for textual adversarial example detection (Zhang et al., 2023). 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 (Abolfazli et al., 2019).

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.