Machine Readable Product Data: Guide for Product Teams

!Decorative title card illustration with product and botanical elements

TL;DR:

• Machine-readable product data is structured, semantically tagged information that software can interpret and use automatically. Creating such data by mapping product attributes to shared vocabularies like schema.org and the EU DPP semantic model is essential for compliance and automation. Starting with a single product model and validating the data ensures accurate, interoperable records for AI, marketplaces, and regulators.

Machine readable product data is structured, semantically tagged product information that a machine can parse, validate, and act on without human intervention. If your product records live in PDFs, unstructured spreadsheets, or plain-text descriptions, they are invisible to AI agents, marketplace integrations, and the EU Digital Product Passport (DPP) registry. The single most useful thing your team can do this week: pick one representative product model and create a machine-readable record mapped to schema.org and the DPP semantic model.

Before you read further, here are the four steps that matter most:

• Identify a canonical identifier for your product (GTIN or serial number) and treat it as immutable.
• Choose your primary format: JSON-LD embedded on the product page plus an API endpoint for downstream consumers.
• Map mandatory DPP attributes to the European Commission's semantic repository vocabulary.
• Run a schema validator (Google's Rich Results Test or the Schema.org validator) to confirm the record is parseable before you publish.

Regulation (EU) 2024/1781 requires that DPP data be accurate, complete, up to date, and based on open standards to ensure interoperability and avoid vendor lock-in. That is the regulatory floor. The commercial ceiling is higher: AI agents, agentic commerce platforms, and circular-economy applications all depend on the same structured foundation.

• What "machine readable product data" means in practice
• Common misconceptions: what machine readable product data is not
• Why this matters now: AI agents, commerce, and EU regulation
• Which formats and standards should your team use?
• Essential data layers for a machine-readable product record
• How machines actually consume your product data
• A step-by-step implementation roadmap for product teams
• How to tell if your product data is actually machine-readable
• Concrete examples: JSON-LD, CSV, and a minimal DPP payload
• What Central European brands must know about DPP compliance
• Key Takeaways
• A practitioner's view on product data projects
• DDP Grid makes machine-readable product records practical
• Authoritative sources and references for EU DPP work
• FAQ

The term gets used loosely, so a working definition helps. Machine readable product data is product information encoded in a format and vocabulary that software can consume, interpret, and act on without a human reading it first. The key word is interpret: a machine does not just read characters; it understands that "material": "100% organic cotton" refers to fiber composition, not a color or a size.

Two things make data genuinely machine-readable. First, the format must be structured: JSON-LD, CSV with consistent headers, XML, or RDF rather than a scanned PDF or a free-text product description. Second, the semantics must be explicit: attribute names must map to a shared vocabulary, such as schema.org's Product type or the Commission's DPP semantic repository, so that different systems agree on what each field means.

!Infographic showing key concepts of machine-readable product data

There is also a distinction worth drawing between web markup and registry records. A JSON-LD snippet embedded in a product page tells Google and AI crawlers what your product is. A machine-readable product passport stored in a registry or served via an API tells market surveillance authorities, customs systems, and repair platforms what your product contains, where it was made, and how it should be handled at end of life. Both use structured data; they serve different consumers.

Common formats and when to use each:

• JSON-LD + schema.org: best for web markup on product pages; parsed by search engines, AI agents, and rich-result features.
• CSV with canonical headers: suitable for bulk catalog exports and supplier data exchange when column naming and identifier formats are strictly enforced.
• XML / RDF: used in regulated data exchange, EDI pipelines, and semantic repositories where formal ontologies matter.
• API (REST/GraphQL): the preferred delivery mechanism for real-time price, inventory, and DPP attribute queries.
• Linksets (RFC 9264): the recommended way to publish machine-discoverable links from a data carrier (QR code) to multiple resources, including public and restricted passport data.

Getting this wrong costs teams months of rework. Here are the myths that cause the most damage:

• "A QR code stores the product data." It does not. A QR code is a carrier for a GS1 Digital Link URI. The economic operator hosts the passport content; the QR code points to it. There is no central EU storage bucket for all product data.
• "JSON-LD on my product page equals DPP compliance." — SEO-focused schema snippets are a starting point, not a finish line. A regulatory-grade passport requires persistent identifiers, multilingual labels, evidence links, substance data, and conformity with the Commission's semantic repository vocabulary. Schema.org markup alone does not satisfy those requirements.

The practical implication: your team needs both a format strategy and a vocabulary strategy. Picking JSON-LD without mapping to a shared ontology gives you a parseable file that no downstream system can interpret consistently.

Three forces are converging, and they all require the same input: structured product information.

!Two professionals reviewing product compliance report

AI agents and agentic commerce need structured inputs to discover, compare, and act on product facts. When a shopping agent queries your catalog, it does not browse a webpage the way a human does. It calls an API or parses structured markup, extracts attributes, and makes decisions. Products without machine-readable records are simply not in the consideration set. Gartner has flagged the shift to AI-first enterprise architecture as a defining trend, and product data quality is the bottleneck most teams underestimate.

Ecommerce operations gain measurably from structured data: improved marketplace discovery, fewer returns driven by attribute mismatches, and accurate downstream integrations with resellers, repair platforms, and take-back programs. Standardized machine-readable passports also enable circular-commerce features, including repair support, resale markets, and digital wardrobes, by making provenance and material data programmatically accessible.

Regulatory urgency is the most time-bound driver. Regulation (EU) 2024/1781 establishes the DPP framework and requires open, interoperable, machine-readable data based on open standards. The General Product Safety Regulation (GPSR) adds traceability and safety-information obligations for products placed on the EU market. Delegated acts per product group will specify exact attribute lists; companies that have not built a machine-readable data foundation will face significant technical debt when those acts land.

The primary consumers of machine-readable passport data are not only search engines. Market surveillance authorities, customs agencies, and automated recycling and repair systems all depend on structured, interoperable product records to do their jobs. Building for SEO alone leaves most of the regulatory value on the table.

Companies that adopt semantic standards early gain a structural advantage: their attribute mapping work is reusable across product groups, while late movers must retrofit data models under deadline pressure. The EU Digital Product Passport requirements are not a distant concern for Central European brands; the framework is in force and delegated acts are in progress.

The answer depends on use case. No single format covers every scenario, and the EN 18216–18223:2026 harmonized standards family, drafted to support Regulation (EU) 2024/1781, covers data exchange protocols, unique identifiers, data carriers, storage, and APIs across the DPP lifecycle.

GS1 recommends using GS1 Digital Link URI syntax and GTIN-based identification to enable persistent, web-enabled product identifiers suitable for DPP and consumer scanning. The Digital Link standard supports encoding GTINs, serial numbers, and batch data, and it aligns with ISO/IEC 15459 and ISO/IEC 18975.

Identifier best practices:

• Treat the GTIN as immutable once assigned. Never reuse a GTIN for a different product model.
• Distinguish granularity levels: model (all units of a SKU), batch/lot (a production run), and serial instance (one physical item).
• Use GS1 Digital Link URIs as the canonical identifier format for DPP-linked records.
• Register Linksets so machines can discover links from a data carrier to public passport data, restricted compliance data, and repair resources.

The Commission's semantic repository is the authoritative source for DPP data models, semantic definitions, and vocabularies. It is accessible via publicly documented APIs, and metadata must conform to DCAT-AP with multilingual labels. Map your attribute names to this vocabulary before you build your authoring templates.

A complete machine-readable product record is not a flat list of attributes. It has layers, and each layer serves different consumers.

!Hands holding layered product data sheets

The compliance layer is where most teams underinvest. Substance concentration data (for example, restricted substances under ESPR) must be expressed as structured fields with units, not buried in a PDF attachment. Evidence links must point to retrievable documents, not internal file paths.

Multi-granularity representation matters too. A model-level record holds attributes shared by all units of a SKU: materials, design specifications, care instructions. A batch-level record adds production-run data: manufacturing date, facility, test results for that lot. A serial-instance record adds individual ownership history, repair events, and resale provenance. Your data model must support all three and link them correctly.

For lifecycle data, DDP Grid's repair and care features show how structured repair instructions and care guidance can be published as part of a consumer-facing passport, making that data accessible to both humans and machines.

The flow from authoring to machine consumption has five stages, and each one is a potential failure point.

Authoring is where product attributes are captured and mapped to canonical vocabulary terms. This is the hardest stage to get right at scale, because supplier data arrives in inconsistent formats, units vary by market, and attribute names rarely match across sources.

Canonical store and APIs are the single source of truth. Every downstream system, whether a marketplace feed, a DPP registry submission, or an AI agent query, should pull from one authoritative record, not from copies scattered across spreadsheets and platform exports.

Discovery via Linksets and Digital Link is how machines find your data. Linksets (RFC 9264) enable machines to discover links labeled by resource type and format; they can be published as JSON or embedded in web pages. A QR code on a physical product resolves to a GS1 Digital Link URI, which resolves to a Linkset, which points to the public passport page, the restricted compliance record, and the repair resource.

Parsing and normalization is where downstream systems extract and standardize your data. Units must be consistent (grams, not "g" in some records and "grams" in others). Language variants must be labeled with BCP 47 language tags. Variant resolution (size, color, material) must follow a predictable structure.

Validation and consumption is the final gate. Schema validators confirm structural correctness. API contract tests confirm that required fields are present and typed correctly. Automated semantic checks confirm that attribute values map to recognized vocabulary terms.

The normalization step is where most pipelines break silently. A field labeled "weight": "250g" in one supplier's feed and "weight_grams": 250 in another's will cause downstream systems to either fail or produce inconsistent outputs. Catching this requires validation at ingestion, not at publication.

Pro Tip: Set up a lightweight CI check that runs your JSON-LD snippets through the Schema.org validator and your API responses through a contract test on every catalog update. Silent normalization failures are far more common than hard errors, and they compound over time.

Audit your current product data. Identify which product categories are subject to delegated acts under ESPR, which SKUs have the highest return rates (often an attribute-quality signal), and which supplier data is most fragmented. Assign a data steward and a compliance owner before you write a single line of schema.

Pick one product family. Assign or verify GTINs. Map its attributes to the Commission semantic repository vocabulary and to schema.org's Product type. This mapping exercise will surface gaps faster than any audit tool.

Build JSON-LD templates for your product pages and define API response schemas for your catalog endpoint. Document which fields are mandatory for DPP submission versus optional for ecommerce. Get your platform engineer and compliance owner to sign off on the same schema version.

Design an ingestion workflow for supplier documents: test reports, material declarations, facility certificates. Use AI-assisted extraction to pull structured data from PDFs and spreadsheets, but require human review before any extracted value is treated as verified. This is not optional; automated extraction without review introduces errors that are hard to detect later.

Run your sample product through the full validation stack: schema validator, GS1 Digital Link resolution test, API contract test, and a manual check of the DPP attribute completeness against the Commission semantic repository. Publish the passport page with a QR code and verify that the Linkset resolves correctly.

Set up alerts for broken evidence links, expired certificates, and API response errors. Version your data models so you can track changes over time. Plan for delegated-act updates: when the Commission publishes final attribute lists for your product group, you need to be able to update your schema without rebuilding from scratch.

Team roles:

• Product owner: prioritizes product families and owns the roadmap.
• Data steward: maintains the canonical attribute vocabulary and enforces naming conventions.
• Supplier liaison: manages evidence collection workflows and supplier onboarding.
• Platform engineer: builds and maintains API endpoints, ingestion pipelines, and validation checks.
• Compliance owner: maps attributes to regulatory requirements and signs off on DPP submissions.

Pro Tip: Start with a single product family of 10–20 SKUs. Automate supplier evidence collection using structured intake forms rather than email attachments. The time saved on the first family pays for the tooling investment before you reach the second.

Thirty minutes of testing will tell you more than a week of documentation review.

Quick tests:

• Paste your product page URL into the Schema.org validator or Google's Rich Results Test. If required fields are missing or the type is wrong, your web markup is not machine-readable.
• Resolve a GS1 Digital Link URI for one of your products. If it returns a 404 or an unstructured page, your identifier layer is broken.
• Call your catalog API endpoint and check whether the response includes GTIN, material, weight with units, and a Linkset pointer. Missing any of these means downstream systems cannot consume the record reliably.
• Check whether your attribute labels match the Commission semantic repository vocabulary. A label like "fiber_content" that does not map to a recognized term will fail semantic validation even if the JSON is syntactically correct.

Readiness checklist:

• Identifier persistence: GTIN assigned, immutable, and resolvable via GS1 Digital Link.
• Semantic labels: all attribute names map to schema.org or Commission semantic repository terms.
• Evidence links: certificates and test reports are linked as retrievable URLs, not file paths.
• API discoverability: Linkset published and resolving correctly from the data carrier.
• Multilingual labels: key attributes carry BCP 47 language tags for at least the languages of your target markets.
• Granularity: model, batch, and serial records are linked and distinguishable.

Common failure modes:

• Missing identifiers: product records use internal SKUs only, with no GTIN or GS1 Digital Link. Fix: register GTINs and update your authoring templates.
• Inconsistent units: weight in grams in some records, kilograms in others. Fix: enforce a canonical unit at ingestion with a validation rule.
• Evidence missing or in proprietary formats: certificates stored as scanned PDFs with no structured metadata. Fix: require structured intake forms from suppliers and store documents with machine-readable metadata.
• No Linkset: QR code resolves directly to a product page with no machine-discoverable link structure. Fix: publish a Linkset at the Digital Link resolution endpoint.

{
 "@context": "",
 "@type": "Product",
 "name": "Merino Wool Crew Neck Sweater",
 "gtin14": "09501101530003",
 "sku": "MW-CREW-M-NAV",
 "brand": {
 "@type": "Brand",
 "name": "ExampleBrand"
 },
 "material": "100% Merino Wool",
 "weight": {
 "@type": "QuantitativeValue",
 "value": 380,
 "unitCode": "GRM"
 },
 "url": "",
 "subjectOf": {
 "@type": "CreativeWork",
 "url": ""
 }
}

The subjectOf field points to the DPP passport page. For model-level data, the GTIN14 identifies the product class. For a serial instance, add "serialNumber" and link to the instance-level passport record.

CSV is machine-readable when column naming conventions, identifier formats, and units are consistent and validated. The column headers above use camelCase canonical names; your ingestion pipeline should enforce these names and reject rows with missing GTINs.

{
 "passportId": "urn:uuid:a1b2c3d4-e5f6-7890-abcd-ef1234567890",
 "productIdentifier": {
 "gtin": "09501101530003",
 "digitalLinkURI": ""
 },
 "publicAttributes": {
 "productName": "Merino Wool Crew Neck Sweater",
 "material": [{"fiber": "Merino Wool", "percentage": 100}],
 "countryOfManufacture": "PL",
 "repairInstructionsURL": "",
 "recyclingCategory": "Textile"
 },
 "evidenceLinks": [
 {
 "type": "MaterialDeclaration",
 "url": "",
 "format": "application/pdf"
 }
 ],
 "linkset": ""
}

Restricted compliance data (substance concentrations, test reports) goes in a separate access-controlled endpoint referenced via the Linkset, not in the public payload. Market surveillance authorities with appropriate credentials can retrieve it; consumers see only the public fields.

Central European brands selling into the EU market face the same regulatory obligations as any other EU economic operator, and the technical requirements are specific.

The Commission Implementing Regulation (EU) 2026/1778 establishes the DPP semantic repository as the authoritative, machine-readable source for DPP data models, semantic definitions, and vocabularies. The repository is accessible via publicly documented APIs, and access is free of charge except during maintenance windows. Metadata for data models must conform to DCAT-AP, and labels must be multilingual and machine-readable.

The semantic repository is not optional infrastructure. It is the reference point against which your attribute vocabulary will be validated. Brands that map their product attributes to the repository's terms now will find delegated-act compliance far less disruptive than those who build proprietary schemas and retrofit later.

The harmonized EN 18216–18223:2026 standards, drafted to support Regulation (EU) 2024/1781, cover data exchange protocols, unique identifiers, data carriers, storage, and APIs for product passport lifecycle management. Conformity with these standards creates a presumption of conformity with certain DPP requirements.

Practical steps for Central European teams:

• Map your product attributes to the Commission semantic repository vocabulary before building authoring templates.
• Register persistent GTINs and publish GS1 Digital Link URIs as your canonical identifiers.
• Publish Linksets from your data carriers so market surveillance authorities and automated systems can discover both public and restricted passport data.
• Check the GPSR traceability requirements for your product categories, particularly for products sold online into the EU.
• Monitor the Commission's delegated acts schedule for your product group. Textiles and electronics are among the first categories with active delegated act work.

For clothing brands specifically, the clothing Digital Product Passport guide covers the attribute sets most relevant to textile products, including fiber composition, manufacturing location, and care and repair data.

Research on Asset Administration Shell (AAS) and IDTA submodel templates shows that some mandatory ESPR data points require extending standard templates beyond their minimal configurations. Practical DPP implementations require semantic interoperability: map product attributes to IDTA/AAS submodel templates and use Semantic IDs and Concept Descriptions to ensure machine-understandable semantics. Naive JSON-LD without correct semantic IDs may fail regulatory validation even when the JSON is syntactically correct.

Structured, semantically tagged product data is the technical foundation for EU DPP compliance, AI-driven commerce, and circular-economy applications, and the time to build it is before delegated acts impose specific attribute lists.

The gap between "we have structured data" and "our data is machine-readable" is wider than most teams expect, and it almost always comes down to the same three problems.

The first is identifier discipline. Teams treat SKUs as canonical identifiers because that is what their ERP uses. SKUs are internal, mutable, and meaningless to any external system. GTINs are globally resolvable and persistent. The moment you start building DPP records on SKU foundations, you are building on sand. Switching later is painful; switching under a regulatory deadline is worse.

The second is the vocabulary gap. Adopting JSON-LD is not the same as adopting semantic standards. A product record with "material": "wool" and another with "material": "Merino Wool, 100%" are not the same thing to a machine, even if they describe the same product. The Commission semantic repository exists precisely to resolve this: it defines what each attribute means, what values are valid, and how they should be labeled across languages. Teams that skip this mapping step produce data that is syntactically valid but semantically ambiguous.

The third is evidence management. Regulatory-grade passports require evidence: test reports, material declarations, facility certificates. Most brands have this documentation somewhere, but it is scattered across email threads, supplier portals, and shared drives. When a market surveillance authority queries your passport, they expect a retrievable link to a specific document, not a promise that the paperwork exists. Building evidence ingestion and version control into your data workflow from the start is far less expensive than retrofitting it.

One more thing worth saying plainly: discoverability is not automatic. Publishing a JSON-LD snippet and calling it done leaves the Linkset unpublished, the GS1 Digital Link unregistered, and the DPP registry unaware your product exists. The discovery layer, the part that lets machines find your data from a physical product, is a separate engineering task that many teams underestimate until they try to resolve a QR code in a test environment and get a 404.

Building a machine-readable product data infrastructure from scratch requires identifier management, supplier evidence collection, schema authoring, validation pipelines, and passport publication. For most independent brands and Shopify merchants, that is more engineering than the team has capacity for.

!DDP Grid

DDP Grid handles the infrastructure so your team focuses on the data. You can import products directly from Shopify, CSV, or API; collect supplier evidence through structured workflows; use AI-assisted extraction to pull structured attributes from documents, with human review before anything is treated as verified; and publish permanent passport pages with QR codes and machine-readable records at model, batch, and individual-item level. The platform supports GS1 Digital Link, Linkset publication, and the attribute layers required for EU DPP readiness, including materials, manufacturing locations, safety information, care, repair, and recycling data.

For teams preparing for ESPR and GPSR obligations, DDP Grid's product platform centralizes fragmented product and supplier data, identifies missing information, and maintains evidence and version history. It does not provide legal certification, and it does not claim that using the platform automatically makes a product compliant. What it does is give you the data infrastructure and readiness workflows to demonstrate the information your products and target markets require.

Start with a 14-day free trial at dppgrid.com/solutions and map your first product family to a machine-readable record this week.

• Regulation (EU) 2024/1781: The foundational ESPR regulation establishing the DPP framework; defines what data must be open, interoperable, and machine-readable.
• Commission Implementing Regulation (EU) 2026/1778: Establishes the DPP semantic repository, its API access rules, and DCAT-AP metadata requirements.
• Commission Implementing Decision (EU) 2026/1736: References the harmonized EN 18216–18223:2026 standards and their presumption-of-conformity scope for DPP technical requirements.
• Regulation (EU) 2023/988 (GPSR): General Product Safety Regulation; sets traceability and safety-information obligations for non-food products on the EU market.
• European Commission Digital Product Passport overview: Explains the economic operator hosting model, QR code as carrier, and the overall DPP architecture.
• GS1 Standards Enabling the EU Digital Product Passport (V2.2): GS1 guidance on Digital Link URI syntax, GTIN-based identification, and Linkset publication for DPP implementations.
• Resources.data.gov Machine-Readable File Glossary: Authoritative US open-data definition of machine-readable files; useful for CSV validation and format requirements.

These are starting points. Delegated acts per product group contain the final attribute lists and compliance dates. Check the Commission's ESPR delegated act schedule for your specific product category.

Machine readable product data is structured, semantically tagged product information that software can parse, validate, and act on without human intervention. Common formats include JSON-LD, XML, CSV with canonical headers, and API responses mapped to shared vocabularies like schema.org or the EU DPP semantic repository.

CSV is machine-readable when column naming conventions, identifier formats, and units are consistent and validated across all rows. Without strict header conventions and canonical identifiers, CSV introduces ambiguity that breaks automated pipelines.

A JSON-LD snippet embedded in a product page, mapping attributes to schema.org's Product type with a GTIN14 identifier, is a standard example. A DPP payload served via a REST API with GTIN, material composition, and a Linkset pointer is a regulatory-grade example.

Regulation (EU) 2024/1781 requires that DPP data be accurate, complete, up to date, and based on open standards. A Digital Product Passport is, by definition, a machine-readable product record: it must be interoperable, API-accessible, and mapped to the Commission's semantic repository vocabulary.

DDP Grid supports product import from Shopify, CSV, or API, AI-assisted data extraction with human review, and publication of passport pages with QR codes and machine-readable records at model, batch, and item level, covering the identity, compliance, lifecycle, and evidence layers required for EU DPP readiness.

• DPP Grid product platform
• Product Data Centralization for Fashion Brands: DPP Guide