Date: 2026-05-04.

AI agents are reaching the test engineer's desk, and engineers query measurement data in natural language. Data access is generated from sample files, and analysis pipelines are composed of intent descriptions. The strategic question that recurs in customer conversations and on standardization panels has shifted accordingly. With unstructured data growing and large language models doing real work, is ASAM ODS still the right foundation for test data infrastructure?

The argument that follows takes the opposite position from the panel framing. ASAM ODS is not legacy infrastructure to defend out of habit. It is the chassis that AI needs in order to be useful in deterministic, regulated test environments. The architecture must be deterministic at the core and intelligent at the surface. Anything else is unsellable in automotive, maritime, and battery validation.

A pure AI-over-files approach fails on five counts that matter specifically to enterprise test environments.

Thousands of analysis jobs run per day in a typical OEM environment. Each language model inference call over raw files involves loading, chunking, inference, and validation. At enterprise volumes, the per-call cost compares poorly with a structured query that returns in under 100 milliseconds and incurs no per-call API charge. The economics favor structured access at scale.

Language models hallucinate. In general text, this is tolerable. On calibration coefficients, acquisition sample rates, unit conversions, and channel-to-sensor mappings, a hallucinated value can invalidate an entire test campaign. Safety-critical work requires deterministic retrieval, not probabilistic inference.

ISO 9001 traceability, IATF 16949 audit trails, and EU AI Act source-traceability obligations require that the same analysis, when rerun, produces the same result. A structured query against a standardized data layer is reproducible by construction. Synthesis from raw files is not.

MATLAB, DIAdem, AVL Concerto, Spark, and Python pipelines all read engineering data through the same standardized interfaces. Without the standard, each tool needs its own transformation layer, which must be kept in sync as schemas evolve. With the standard, tools plug in once and stay current. AI agents are the latest entrants to this ecosystem and benefit from the same property. Customer investments in existing tools are protected because the data layer speaks the language those tools already read.

Each of these is a hard requirement, not a preference. Together, they establish that the AI surface needs a structured, schema-grounded layer beneath it. That layer is the structured middle. Catalogs ground the semantics. A formal query language gives precision across every interface engineers use. Intelligence sits above, where models translate the engineer’s intent into precise queries against this middle.

That middle layer, built on 25 years of test data domain knowledge, is already available, and components are in production at automotive, maritime, and battery testing organizations. The four components that handle federation, analysis, the client framework, and query language were designed as one chassis.

Janus is HighQSoft's federation layer. Its handler architecture reads from any source and maps it to the standardized ODS server layer. Targets include file formats like Parquet for big-data sharing, search backends, NoSQL document stores, and legacy SQL databases. Data stays where it lives. Schema and query semantics travel to the data, not the other way around.

Merlin, the HighQSoft analysis server, runs production analysis. Engineers keep their Python, MATLAB, Java, or Spark scripts, and Merlin orchestrates them across thousands of jobs per day. Every run records inputs, script version, parameters, job timestamp, and source server, with outputs captured as typed artifacts that carry full lineage. Reproducibility is structural rather than aspirational.

ASAMCommander, the HighQSoft web client framework, keeps the chassis approachable and extensible. Engineers add their own dashboards, workflow steps, AI agents, and domain-specific views as modules, while the framework handles authentication, ODS access, and service orchestration. They simply get the surface they want without rebuilding the infrastructure beneath it.

HQL is the openness commitment. A SQL-like query language across REST, Java, CLI, Python via pyHQL, and MATLAB via matHQL gives engineers, scripters, and developers one language for ASAM ODS data. They reach the standard without learning the underlying ODS API. HQL is also the precision tool that the MCP Server uses to translate natural language. The interface above moves with the technology of the day. HQL stays.

Modularity and openness are what make this chassis valuable. Each component composes with the others without forcing a full-stack commitment. Customers adopt incrementally and mix HighQSoft and third-party tools at every layer. Open interfaces let partners and customers build on the platform rather than around it.