Deutsch

Reference

Documentation

Overview of the VDA 231-301 standard, its structure, and how to work with it.

Overview

VDA 231‑301 is an official VDA recommendation defining a standardized, machine-readable data model for material and test information. It enables interoperable exchange of material-related data — requirements, test results, certificates, and compliance evidence — across systems, companies, and digital ecosystems.

Originally developed to streamline material sampling and approval processes in the automotive industry, it addresses a key challenge in digital supply chains: reliable, structured exchange of material data across company and system boundaries. While originating from automotive requirements, the data model is generically applicable to any industry relying on structured exchange of material information.

It is developed and maintained within the VDA Project Group “Digitales Werkstoff‑Datenmanagement im Bemusterungsprozess”. (https://www.vda.de)

The recommendation benefits from scientific collaboration with the Institute for Engineering Design and Industrial Design (IKTD) at the University of Stuttgart. (https://www.iktd.uni-stuttgart.de)

🔗 Related academic publications and research context: https://www.iktd.uni-stuttgart.de/forschung/publikationen/

Purpose and scope

The data model is represented as open, versioned JSON Schemas so systems can validate, exchange, and process material information automatically.

VDA 231‑301 builds on the standardized material definitions of VDA 231‑300 and extends them with a machine-readable model for test and measurement results. Together, VDA 231‑300 and VDA 231‑301 form a consistent foundation for structured material data exchange. They complement digital ecosystems such as Catena‑X by enabling consistent data flow without proprietary formats, manual re-entry, or interpretation gaps.

Within the modular architecture, the Generic Schema defines the core semantic and structural elements. It provides a stable, reusable foundation for standardised exchange of material-related data and ensures consistency, interoperability, and traceability across different use cases and systems. Domain-specific, regulatory, or process-specific aspects are implemented in dedicated subschemas that extend the Generic Schema.

Applying the standard

Replace document-based processes with validated, system-to-system data exchange. Integrate the open semantic data model into your platforms and toolchains to reduce manual effort, improve data quality, and ensure reliable compliance and sustainability reporting at scale.

Explore the schema, validate example files, and test interoperable material data directly in your browser — no setup required.

Who it is for

The standard is relevant for:

  • OEMs and tier-1 suppliers receiving or transmitting material sampling data
  • Testing laboratories generating structured test reports
  • Software providers building data exchange interfaces
  • Quality assurance teams verifying compliance with material specifications
  • Open source contributors developing tooling or subschemas

Open development

VDA 231‑301 is developed as an open standard. Adoption, technical feedback, and real-world use cases directly shape its evolution. Join the community to contribute expertise, integrate the standard into your systems, and drive long-term interoperability across value chains.

Schema Structure

The VDA 231-301 data model is represented using JSON Schema (draft 2020-12). The schema is designed to be machine-readable, extensible, and suitable for automated validation and processing.

Core elements

The Generic Schema defines essential building blocks reused consistently across all subschemas:

  • Identifiers and references — every referable object carries an internal _id field (UUID v4) that is unique within a transmission file and must not change after assignment
  • Metadata and context — fields such as title, dates, order references, and party information
  • Generic object structures — TestingProject, TestingCenter, Sample, and related entities
  • Patterns for extensibility — subschemas add domain-specific fields while remaining structurally compatible

Design principles

The schema follows these principles:

  • Machine readability over human convenience
  • Consistency across all subschemas through shared $defs
  • Extensibility without schema duplication — subschemas $ref into the Generic Schema
  • Suitability for automated processing and CI-based validation

Identifiers

IDs in VDA 231-301 follow UUID v4 (RFC 4122):

{
  "_id": "123e4567-e89b-12d3-a456-426655440000"
}

Rules:

  • Every referable object must carry _id
  • _id must be unique within a transmission file
  • _id must not be changed after assignment
  • Reference fields (e.g. ContractorID) use the same UUID v4 format

Subschemas

Subschemas extend the Generic Schema with specialised content for a particular standard or recommendation. Each subschema adds domain-specific, process-specific, or regulation-specific attributes while complying with the core definitions and design principles of the Generic Schema.

Lifecycle

A subschema moves through two phases before it is considered official:

Phase 1 — Draft and discussion. Each subschema begins as an independent GitHub repository. These repositories are publicly accessible working drafts that invite discussion and collect feedback via GitHub Issues and Discussions. Subschemas in this phase are not yet officially versioned.

Phase 2 — Official publication. Once a subschema has been reviewed and approved by the responsible VDA Project Group, it is assigned a version number and published in the central schema repository. Only subschemas in the schema repository are considered officially released.

Level of detail

A subschema may define requirements at two levels:

  • Must — mandatory requirements according to the referenced standard
  • Can — optional requirements, often defined by internal factory standards

Both levels are supported in JSON Schema and can be validated accordingly.

Versioning

Each schema must have clear versioning using semantic versioning (e.g. v1.0.0). Changes must be documented in a changelog and introduced only via pull requests to ensure consistency, traceability, and transparency.

Creating a subschema

Guidelines for developing a new subschema are available in the repository: