ASAM CEO Marius Dupuis sat down with HighQSoft's Dr. Ralf Noerenberg for the Fun with Standards series to work through a question the whole industry is asking. Does generative AI make a data standard like ASAM ODS obsolete, or more valuable? 

Please find the full conversation in the YouTube video linked here or read a shortened version with the reasoning behind it below. Additional information on ASAM ODS and AI is found here: ASAM ODS and AI.

The line that opens this page cuts both ways. The standard amplifies what AI can do with test data, and AI amplifies the value of every dataset that was standardized in the first place. Neither is the rival of the other. Each is the multiplier of the other. Here are the six ideas the interview turns on.

AI raises the need for a data contract, it does not remove it. "AI can make sense of anything" is a comforting claim that does not survive contact with regulated engineering work. A data standard is a contract about what a measurement means, and that contract usually spans more than one party, a supplier creating artifacts, an OEM operating a system, a service provider delivering results. In regulated industries that contract is what makes an AI-assisted result defensible. AI can compound the scale of an error as easily as the scale of an insight, so "close enough" fails the only test that matters, whether an answer traces back to the specific measurement, version, and clause it relied on. A system that returns a different answer on each run cannot be validated, and unvalidated work does not ship.

AI takes over the consumption layer while the standard holds the interface. Think of test data access in three layers, the consumption layer where questions get asked, the interface layer that defines the contract for access, and the data layer where the bytes live. AI most plausibly takes over the consumption layer. Agents, novice users, chat interfaces, and dashboards a language model builds on the fly replace the classic rich client. That shift is exactly what a modular product line is built for. HighQSoft's ASAMCommander composes the web experience from independent modules, HQL and pyHQL give one query language across Python, MATLAB, Java, REST, and the browser, and the MCP Server connects Claude or ChatGPT directly to governed test data in plain English. The consumption surface changes, conversational instead of clicked, but every one of those tools still talks to the same standardized interface underneath, so tool use stays deterministic.

The data layer becomes a commodity, so ASAM ODS federates the lake instead of competing with it. The data layer is turning into a commodity, the same way the "big data" wave once threatened to. Storage is no longer the hard part. Where a measurement gets its meaning is. So the job of ASAM ODS shifts from being the thing you query directly toward federating whatever lake or store the data lands in and providing the governed, meaningful view on top. HighQSoft's Janus Platform is that federation layer, virtualizing ODS servers, MDF4 files, TDMS, Parquet, and data lakes behind a single ASAM ODS interface, with no migration. AI, data lakes, and the standard end up complementing each other rather than competing.

A data lake alone lacks the descriptive layer, and three problems follow. A data lake looks sufficient on its own, MDF or Parquet files dropped into cheap storage, and for a while it is. What it lacks is the descriptive layer that ASAM ODS deliberately separates from the mass data, the units, calibration, channel-to-sensor mapping, the raw-versus-derived distinction, lineage, and acceptance criteria. Skip that layer and three problems arrive on schedule. Whoever adds the meaning back ends up re-implementing ODS for a single use case. The lake exposes no standardized interface, so every tool integrates individually. And long-term storage becomes dependent on one, possibly outsourced, provider. Mercedes-Benz is the clearest proof, a top-tier OEM that built petabyte-scale measurement storage on a lakehouse and then hand-built an ODS-shaped semantic model on top of it with its own engineering team. Affordable for Mercedes. For most organizations, adopting the standard is cheaper than rebuilding it.

Standardization sets the order in which a domain can automate. How standardized a domain is determines the order in which it can automate, not just how well. Machine-legible, consistent data lets AI analysis trigger the moment data lands, with a consolidated meaning already behind it. Fragmented naming and formats force a round of harmonization work before anything useful can run. Two organizations with identical AI tooling will diverge purely on how standardized their data was to begin with. Standardization is the precondition for the automation, not something bolted on afterward.

Open standards keep the data moat with the customer, not the vendor. Without open standards, advanced AI-assisted data work becomes the privilege of a few large players with the resources and proprietary formats to build it in-house. Open standards let small and mid-sized companies compete on the same ground, and, just as important, they keep the data with the customer rather than the vendor. If data is the moat in the AI era, that moat should belong to whoever generated the test data, not to whatever tool happens to store it. Interoperability is the anti-concentration argument, and it is also the plain commercial reason a supplier and a customer both benefit from standardizing.

Where this leaves the standard: more invisible and more important at the same time. Engineers stop thinking "I am querying an ODS server" and simply ask a question in plain language, while the standard's role hardens into the contract underneath that guarantees the answer is consistent and auditable whether a human or an agent is asking. The domains that did the unglamorous standardization work early are the ones positioned to win the AI era. When AI comes for test data, standardization amplifies.

Go deeper. See how HighQSoft's platform puts these ideas into production at highqsoft.com.