Documentation

VDA 231‑301 defines an open, standardized, and vendor-neutral data model for the digital management of material, substance, and test data. Originally developed to streamline material sampling and approval processes in the automotive industry, it has evolved into a flexible schema for the digitalization of materials information — easily adaptable to diverse use cases through sub-schemas.

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

The recommendation VDA 231‑301 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 Generic Schema defines the core semantic and structural elements of the VDA 231-301 data model. It provides a stable, reusable foundation for the standardised exchange of material-related data and ensures consistency, interoperability, and traceability across different use cases and systems.

Within the modular architecture of VDA 231-301, the Generic Schema represents the central core layer. It contains common concepts, structures, and design principles that are shared across all subschemas. Domain-specific, regulatory, or process-specific aspects are intentionally not defined here — they are implemented in dedicated subschemas that extend the Generic Schema.

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

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 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:

• English guidelines
• German guidelines (Deutsch)