ASAM ODS and AI | Page: 4 of 5 | Previous: Page 3: How AI Assistants Reach ASAM ODS Measurement Data | Next: Page 5: Where to Start with AI on ASAM ODS Test Data

Automated ASAM ODS analysis is work that starts from a trigger or a schedule rather than from a person asking, and that distinction changes which properties matter. Conversational access needs somebody present, which means somebody reads the answer, notices when it looks wrong, and asks again. Production analysis has no such reader. A measurement lands, a job fires, an evaluation runs, a result is written, and the first human eyes on it may arrive weeks later when a number appears in a report. Everything this hub has argued about determinism and traceability applies most sharply here, because this is the point in the lifecycle where nobody is watching.

The scale is what makes it a different problem rather than the same problem repeated. HighQSoft's Merlin Analysis Server runs thousands of analysis jobs daily at major OEMs. Engineers keep their Python, MATLAB, or Spark scripts, and Merlin orchestrates them at scale, which means the automation layer did not require the test department to rewrite its analysis logic in somebody else's framework. Every job records source data, script version, and parameters, so results stay traceable, reproducible, and comparable across runs and across campaigns. That combination, existing analysis code plus enterprise orchestration plus per-run lineage, is the ground on which anything AI-assisted has to be built if it is going to be usable in production rather than in a demonstration.

It is also the ground that most AI claims in this space are missing. A model that can reach measurement data solves the access problem, which page 3 covered. It does not solve the execution problem, which is what happens to output that nobody reads, produced by code that nobody reviewed, against data whose provenance nobody recorded. The rest of this page describes what an analysis run actually contains, what gets recorded when one executes, and why composing a run from parts that already passed review is a fundamentally different proposition from generating one.

Merlin records what produced a result, not just the result. Each processing component that touches a measurement writes a lineage record carrying the component's name, its version string, and a description that identifies the job definition version and the configuration used, related to the measurement it processed. That means the record is not a single log line at the end of a chain. The import tool writes its own record when data arrives, the ODS server records its own on write, and the analysis run writes its own when it executes, so a measurement carries the history of every component that shaped it.

Results themselves are first-class objects in the repository rather than files dropped in a directory. A completed evaluation writes a result set that can hold parameters, meaning computed key figures as typed name and value pairs, and attachments, meaning the reports, plots, and exports the run produced. Each result carries the name of the job that produced it, a type designation such as analysis, validation, or archiving, and a date, and it is linked to the test, subtest, or measurement it belongs to. The evaluation definition is stored in the repository as well, in dedicated elements for the job, its setup, and its parameters, so both what was supposed to run and what actually ran are recorded, and the two can be compared.

Reproducibility built this way is a structural property rather than a discipline. Nobody has to remember to record anything, and no result can be produced by a path that skips the recording, because the recording is done by the components doing the work. That distinction is what makes the property survive staff turnover, tool upgrades, and the eighteen months that typically separate a result from the first serious challenge to it. The practical question in a test department is never abstract. It is what produced this number, which data went in, which version of the script ran, and which parameters were set, asked about a specific figure in a specific report. Without lineage, answering it is archaeology. With lineage, it is a lookup.

This matters on engineering and audit grounds long before anyone reaches for a regulation. A test organization's own quality process already requires that conclusions be defensible, that a second engineer can reproduce a result, and that a reviewer can see what changed between two runs that disagree. By analogy, a production quality system requires that a physical part can be traced to the lot and the process that produced it. The analogy is worth stating explicitly as an analogy, because the mechanism is the same idea applied to analysis rather than to parts, and because a story whose thesis is determinism cannot afford to borrow authority it has not earned. Merlin implements the traceability principle directly. Which named external requirements a given organization must satisfy is a question about that organization, and its own quality process is the honest anchor.

Those three things, the analysis job, its results, and the lineage record, are the entity classes HighQSoft is turning into a typed vocabulary. Part of that is already in place and has been for some time. A result written by an analysis run carries a MIME-type classification saying what kind of result it is, with analysis, validation, and archiving among the values in production use. Evaluation definitions are stored as structured entities inside the repository rather than as configuration files sitting beside it. Lineage records exist per processing component and are written by the component that did the work, which is what the first paragraph of this section described. So the starting point is an existing typed-artifact mechanism running in production, not a concept drawn on a whiteboard.

The direction is to widen that mechanism into a vocabulary and give it a surface. HighQSoft is defining its own MIME types across all three classes, so that a job, a result, and a lineage record each become an addressable entity with a stable contract, deliberately owned and versioned rather than inherited from the ODS base model. Discoverability is the reason for doing it. An entity with a declared type and a stable contract can be found, requested, and broadcast to a consumer that has never seen this particular repository before, and the Model Context Protocol is the natural surface for that, because a protocol client asks what is available before it asks for anything specific. The identifiers themselves are not settled and are not published, so nothing here should be read as a vocabulary an integration can code against today. What is settled is the shape, that the artifacts an analysis run produces are entities with contracts rather than output somebody downstream has to parse.

This is also what lets the pattern reach past ASAM ODS itself. A typed artifact with a stable contract is addressable whether or not the consumer on the other end knows the ODS base model, which means the two-mode access split introduced on page 1, typed artifacts on one side and HQL as the versatile language for everything not yet typed on the other, is not an ODS-only arrangement. It is a general shape that ODS happens to make easy, and the analysis run is where the typed artifacts come from.

A Merlin analysis run is a described pipeline rather than a program, and the description is a JSON file. That file names a job type, a version, and an ordered list of evaluation stages. Each stage performs one atomic operation on a tabular data set of columns and rows, and each declares the function it calls, the inputs a caller must supply when the job starts, and the fixed arguments configured for it. Every job description file placed in the configured directory is exposed automatically as a callable job through the REST API, so describing a pipeline and publishing a service are the same act.

Six stage classes cover the shapes an evaluation takes, in the order data typically flows through them.

Custom code runs as a stage rather than around the pipeline. A Python script placed in the configured location registers itself and is referenced in the job description by filename, executing in a dedicated container image; Java and HTTP stages register as services with the framework. The stage boundary is what makes this composable, because a stage declares what it consumes and what it produces, and anything that satisfies that contract can occupy the position.

One detail connects this page to the previous one. The data format that moves between Merlin stages is the same result format the HQL web service returns. Pages 3 and 4 are therefore not describing two similar things. They are describing one mechanism at two points of the lifecycle. A query is a query whether an assistant drafted it for an engineer reading the answer in a chat window or a pipeline stage carries it into a run that nobody will watch, and in both cases what comes back is the same typed structure. HQL is the precision layer at both ends, which is why the trust argument transfers between them instead of having to be rebuilt.

That architecture is what makes AI-assisted composition a credible direction rather than a hopeful one, and direction is what it is today. The described capability is a model assembling a run from stages that already exist and already passed review, parameterizing the HQL query in the select stage, adapting a supplied routine to the inputs and outputs its stage position declares, and appending the output stage that writes results back. The pipeline it produces is a JSON description that a person can read in full before it runs.

Predictive maintenance is the question this architecture is asked about most often, and the answer is that it needs no new architecture. A time-series foundation model takes a context window of past values, optionally together with covariates, and returns a forecast over a horizon. TimesFM, the decoder-only time-series foundation model Google Research presented at ICML 2024, is the reference example of the class. The property that matters for a test department is that such a model is pretrained and forecasts series it never saw during training, because a test archive holds thousands of distinct channels and nobody is going to train and maintain a model per channel.

Covariate support is what connects the model to a governed repository rather than to a folder of numbers. A covariate is a series or attribute recorded alongside the one being forecast, and the documented demonstrations of the capability use ordinary examples such as rentals forecast against weather. In a test context the covariates are the things the repository already carries, including ambient conditions, load profile, duty cycle, operating point, and the configuration of the unit under test. That descriptive context is exactly what an ASAM ODS application model exists to hold and exactly what raw measurement files on a share do not have, which is why the same forecasting model produces a usable result in one setting and a plausible-looking one in the other.

The mapping onto a Merlin run uses parts this page has already described. A select stage running HQL supplies the metadata and the context, identifying which measurements, which unit under test, and which conditions are in scope. HQLVM, the HQL verb that reads mass data channels from a submatrix, supplies the measured series itself. The forecasting model runs as a map stage, in exactly the way any other Python routine runs as a map stage. A collect stage writes the prediction back as a result linked to the measurement it came from, and the lineage record names the component and version that produced it, the same as for every other run. No new stage class, no new orchestration, and no new trust story are required.

HighQSoft does not ship a TimesFM integration, and the claim here is narrower than one. The claim is that the architecture accommodates a forecasting model without modification, because a forecasting model is another map stage and a prediction is another typed result. That is also the point at which this hub's argument stops being about language models. Composition over validated stages with lineage on every run is a property of the orchestration layer, not of the kind of model that occupies a stage, which is why the same pattern covers a statistical evaluation, a language model composing a run, and a forecast written back into the repository.

Composition beats generated code because the AI never authors production logic from nothing. It selects and parameterizes parts that already passed review, and the orchestrator executes them with the same lineage every other run gets. The search space is finite, the vocabulary is a known set of stage classes and registered functions, and the artifact produced is a declarative description rather than an executable of unknown behavior. A failure is diagnosable because the stage boundary tells you where it happened. A change is reviewable because the diff is a few lines of job description rather than a new program.

The alternative pattern is not hypothetical, and it is worth describing fairly. In a 2025 ASAM application story, NorCom Information Technology and an automotive OEM describe a chatbot in which a large language model translates natural-language questions into executable Python that runs against ASAM ODS data through Apache Spark. The problem they set out to solve is real, that analysis of ASAM ODS data was accessible only to programmers and data scientists rather than to automotive engineers, and the implementation is real, named, and dated. What the published account does not describe is a gate. It reports no conformance step between generation and execution, no accuracy figures or validation results, and no reusable artifact left behind, since in the workflow it sets out each question produces a program that runs. That is the pattern this hub argues against, and it is instructive precisely because it is a serious attempt rather than a straw man.

Fairness cuts the other way too. Runnable, open-source tooling for reaching ASAM ODS data from AI clients does exist in the wider ecosystem, including notebooks that execute against real public datasets and actively maintained bridge code with proper packaging and release history. The largest test and measurement vendors ship AI assistants that update on a real cadence. The honest claim is not that nobody demonstrates anything. It is that nobody demonstrates a governed, standards-checked interaction end to end. Others show that a model can reach the data. What is missing everywhere else is a conformance gate on what the model produces and an orchestration layer that records what it executed.

That gap turns into three questions worth asking any vendor whose material claims agentic capability on test data.

• What executes the AI's output, and does that executor record what it ran, with which inputs and which version?
• What checks the AI's output before it executes, and against which published definition is the check made?
• When the output is wrong, how is that discovered, by whom, and how long does it take?

A vendor with an orchestration layer and a conformance gate answers all three concretely. A vendor with a demonstration answers the first one with "a Python process" and the other two with a description of the roadmap. Page 5 turns the argument into adoption paths, starting with the smallest thing an organization can actually do next.