Date: 2026-05-05.

A strategic question keeps surfacing in customer architecture reviews and on standardization panels. Should the storage layer for engineering test data use services such as ASAM ODS, or use files such as MDF4, with folder conventions and ad hoc descriptions? Locally, the file-based answer has always been workable. The same engineers create and consume the data, naming conventions are remembered, and re-import is a one-time cost. Data spaces change the calculus. They are infrastructure for system-to-system exchange across organizations that did not agree on anything beforehand, often on a larger scale, often under contracts that demand auditability.

A file dropped into a data space connector arrives at the consumer as a blob to be re-interpreted from filenames and folders. The connector solved transport. It did not solve the meaning. Without meaning, no automated processing happens on either side, and the exchange degrades to delegated re-import, which is exactly what the file-based stack was supposed to avoid.

The argument that follows holds that data spaces strengthen, rather than weaken, the case for ASAM ODS. A file-based stack works as long as the system stays local. The moment it crosses an organizational boundary, the standard is what makes the boundary tractable.

Five properties decide whether an exchange between two organizations becomes useful infrastructure or stays a transport layer with a contract attached.

The Eclipse Dataspace Connector and its Tractus-X derivative move bytes between the provider and the consumer via a control plane and a data plane. They do not move the contents of those bytes. Skip the schema, and the consumer rebuilds the producer's interpretation by hand, from filenames, every time. That work is done once when the producer's schema is the contract. ASAM ODS is the schema layer that naturally travels as data-space metadata because the data is already entity-typed before it crosses the connector.

Sovereignty-relevant exchange happens at sub-file granularity. A signal interval rather than a multi-gigabyte recording. A derived KPI rather than a raw channel. A parameter set with traceability links rather than a folder of intermediate outputs. The catalog entry that explains what a channel actually means. File-level connectors force full recordings when the consumer wants a single window. ASAM ODS publishes a measurement under a contract for a consumer, not an S3 prefix for everyone.

Most cross-organization sharing should be results, not raw recordings. Recording transfers are orders of magnitude larger than the value they deliver, and often the consumer only needs the KPIs, the labels, or the analysis output. A supplier publishing classification results to an automotive customer does not need to ship the source recording every time. A test service provider delivering battery-cycling KPIs to its customer does not need to ship every megasample. Result-level assets need a result-level schema. ASAM ODS already provides one in its parameter set and statistics structures, with traceability links back to the source measurements that produced them.

ATFx, MDF4, and CSV exports bundled as assets are the compliance and customer-delivery class. Underneath ASAM ODS, each export carries provenance back to the structured source. Without it, the export is just a file the consumer must trust on faith, which is an audit posture that does not survive ISO 17025 or IATF 16949 review.

Without a shared catalog of units, quantities, and channel naming, two providers' fuel-consumption channels are not comparable. Without lineage, the consumer cannot prove which tool version produced what they received. Both are ASAM ODS-native and travel naturally as data-space metadata. The closest production parallel today is the Catena-X Product Carbon Footprint exchange. PCF values flow from Tier-2 to Tier-1 to OEM, and they are aggregated, reused, and improved across the chain, only because the Catena-X PCF Rulebook standardizes how each participant interprets each value. The connector moves the number. The Rulebook makes the number meaningful enough to be added to another participant's calculation. For test data, ASAM ODS plays the same role. The schema, the catalog, and the lineage records are what allow a measurement received from one provider to be combined with results computed by another. Without that layer, a connector network is a marketplace of opaque blobs with paperwork attached.

These five properties are not preferences. They determine whether the data space is an auditable infrastructure that engineers can run analyses against, or a transport layer that documents transfers it cannot interpret.

Data spaces are not a replacement for ASAM ODS. They are the cross-organization extension of one of HighQSoft's five test data management principles, the Connected principle. All sources. One interface. Federated. Cloud-native. No migration. Inside an organization, the Janus Platform virtualizes diverse data sources behind a unified ASAM ODS interface, with a cloud-native architecture that scales elastically. Across organizations, a data-space connector is one more handler on the consumer side and one more output channel on the provider side. Same chassis, wider radius.

Data spaces supplement the ASAM ODS Standard. ASAM ODS Servers can be consumers or providers, where catalogs, lineage, and result schemas turn a connector network into something engineers can actually run analyses against. Keep building on the Connected principle across organizational boundaries, and the data-space surface becomes a configuration question rather than a re-architecture.

These questions cover data spaces for engineering test data, how system-to-system exchange across organizations works, and why the ASAM ODS standard is what makes a data-space boundary tractable.