How to build the first textile DPP on the CIRPASS D2.1 schema: an operational tutorial

The scope of the tutorial: what is built and what is not

Building an operational Digital Product Passport requires separating regulatory conceptualisation from pure code implementation. This manual documents the construction of a minimum viable DPP. The objective lies in obtaining a machine-readable passport that complies with the semantic specifications of the regulatory framework, without requiring the immediate deployment of an enterprise-grade decentralised architecture. We will not address deep integration with legacy ERP systems nor the configuration of complex IDSA connectors. The priority falls on structuring the underlying data model precisely.

The minimum stack to understand the model is reduced to three components: a code editor to compose the JSON-LD structure, a Git version-control system to trace the modifications of the document, and a public HTTPS endpoint that serves the passport to external requests. This didactic setup isolates the challenge of semantic interoperability from that of distributed hosting, and makes it clear what an ESPR-native platform automates when you move from a demonstration passport to an entire catalogue signed and maintained over time.

The workflow is structured into seven methodological steps derived from the convergence between the CIRPASS D2.1 architecture and the JRC 145830 methodology. The first step requires consolidating the identification of the product at a global level. The second and third steps require classifying the datapoints according to their legal obligatoriness. The fourth step demands the serialisation of the knowledge in graph format. The fifth and sixth steps address the cryptographic encapsulation under the W3C Verifiable Credentials 2.0 standard and its web exposure. The seventh step establishes the final validation of the whole.

Addressing the construction of this minimum viable model reveals the real costs of standardisation. The curation of data from heterogeneous sources consumes the bulk of engineering resources. The digitalisation of the textile supply chain obliges one to interpret fragmented regulations in order to consolidate them into a single coherent digital object.

Step 1 — Define the unique product identifier

The cornerstone of the DPP system lies in the unique product identifier. Article 9 of the ESPR Regulation requires the presence of a persistent identifier that links the physical good with its digital representation. The operational recommendation is to implement the GS1 Digital Link format. This standard allows the traditional Global Trade Identification Number to be transformed into a URI resolvable through standard HTTP protocols. Encoding the product identity through this format guarantees native interoperability with the current infrastructure of commercial scanners.

Defining the granularity of the identifier requires a rigorous technical evaluation. The JRC 145830 methodological framework contemplates resolutions at model level, batch level and individual-item level. For a first operational deployment in the textile sector, batch-level granularity offers the optimal balance between documentary precision and technical feasibility. Assigning a unique identifier per batch allows variations in the origin of raw materials to be recorded without forcing the unit serialisation of every confectioned garment.

The encoding of the URI must strictly follow the syntax defined in the RFC 3986 standard. An operational example structure would take the form `https://dpp.marca-textil.eu/01/08412345678905/10/LOTE-2026-A`. This string includes the domain of the brand’s resolver, the GS1 application identifier for the GTIN (01), the product code itself, the application identifier for the batch (10) and the alphanumeric reference of the specific batch.

Guaranteeing the persistence and non-reuse of these identifiers constitutes a design imperative. Internal systems must reject any attempt to reassign a previously minted URI to a new production cycle. The CIRPASS architecture stipulates that the links must survive even if the economic operator ceases its commercial activity. This technical requirement obliges the planning of domain delegation mechanisms or the transfer of records to long-term archives.

Step 2 — Map mandatory JRC 145830 datapoints

The DPP data structure requires an exhaustive mapping of the European regulatory requirements. The JRC 145830 methodology establishes the obligation to classify the information needs by translating the legal texts into machine-comprehensible vocabularies. In the textile domain, Regulation 2011/1007 dictates the exact syntax for declaring fibre composition. The passport must host this data matrix reflecting the percentage by weight of all constituent fibres in descending order.

The geographic origin of the transformation stages requires standardised encoding. Provenance cannot be declared through free text. The technical recommendation imposes using the NUTS2 nomenclature for facilities within the European space and the ISO 3166-1 alpha-2 country codes for international links. The mapping must contemplate the location of the critical processes defined in the supply-chain matrix: spinning, weaving and final confection.

The identification of the economic operators that intervene in the value chain requires cryptographic precision. The ESPR Regulation requires the inclusion of unique operator and facility identifiers. For this minimum viable model, the registration of the main manufacturer must point to its legal-entity identifier (LEI) or its corporate Decentralized Identifier.

The legal-compliance block requires the inclusion of the durability parameters and the care manuals. The maintenance instructions must be mapped using the symbol encoding defined in the ISO 3758 standard. The estimated durability score in years, required by the ESPR delegated acts, requires a numeric field with its unit of measurement made explicit. Finally, the EU declaration of conformity and the evidence of CE marking must be linked through persistent URIs that point to the manufacturer’s documentary repositories.

Step 3 — Voluntary datapoints of differential value

The classification of data needs of the JRC 145830 methodology contemplates the inclusion of voluntary attributes that improve circular traceability. Integrating these fields into the minimum viable model radically increases the relevance of the information exposed to the consumer and to recycling operators. Recycled content constitutes the first differential vector. The data graph must record the exact percentage of fibres originating from post-consumer recycling processes versus pre-consumer variants.

The reparability of the textile article represents another high-value node. Based on the calculation frameworks driven by the French AGEC legislation, the passport must incorporate a parameterised reparability index. This numeric field informs after-sales workshops about the technical feasibility of replacing zips or reconstructing structural seams.

The product’s carbon footprint requires rigorous semantic treatment to avoid ambiguities. The declared value has no validity unless the functional unit and the boundaries of the evaluated system are made explicit. The record must detail the kilograms of CO₂ equivalent linked specifically to the delineated life cycle.

Private certifications issued by third parties must be structured as nested verifiable credentials. Instead of attaching a simple static GOTS or OEKO-TEX standard logo, the passport must include the reference to the digital certificate issued by the auditing entity. When the certifying entity provides the information through decentralised identifiers, the final consumer obtains the cryptographic guarantee that the organic cotton or the fair labour practices have been independently evaluated.

Step 4 — JSON-LD structure of the DPP

The architecture of the CIRPASS system rules that the passport operate as a knowledge graph. The standard serialisation format to build this information network is JSON-LD. This language allows heterogeneous entities to share a common semantics without depending on a centralised relational database schema. The root of the document must mandatorily declare the `@context` array. This directive links the W3C vocabularies with the regulatory ontologies specific to the textile sector.

The definition of the `type` property is critical for the validation of the document. The main object must be declared as `VerifiableCredential` and accompanied by the specific subtype that represents a European product passport. The `credentialSubject` node encapsulates the core of the textile article’s datapoints. Within this structure are nested the material-composition matrices and the supply-chain records.

The validation of the syntax requires the execution of specialised linters before deployment in production. The CIRPASS D3.2 document stresses the importance of the SHACL language (Shapes Constraint Language) to ensure that the JSON-LD graph strictly complies with the data model required by the ESPR. A failure in the hierarchy of the nodes will cause market aggregators to reject the entire passport.

Operational JSON-LD structure of the textile MVP model:

```json { "@context": [ "https://www.w3.org/ns/credentials/v2", "https://w3id.org/traceability/v1", "https://schema.org/" ], "id": "https://dpp.marca-textil.eu/01/08412345678905/10/LOTE-2026-A", "type": ["VerifiableCredential", "DigitalProductPassport"], "issuer": "did:web:marca-textil.eu", "validFrom": "2026-05-14T08:00:00Z", "credentialSubject": { "id": "urn:epc:class:lgtin:4012345.012345.LOTE-2026-A", "type": "Product", "category": "Apparel", "materialComposition": [ { "type": "TextileFiber", "name": "Recycled Polyester", "percentage": 85 }, { "type": "TextileFiber", "name": "Elastane", "percentage": 15 } ], "manufacturingLocation": { "type": "Place", "addressCountry": "PT", "nutsCode": "PT11" }, "careInstructions": "https://care.marca-textil.eu/iso3758/wash-30" } } ```

Steps 5-6 — Nest Verifiable Credentials 2.0 and configure the public endpoint

The transformation of the JSON-LD document into a legally auditable passport requires its cryptographic encapsulation under the W3C Verifiable Credentials Data Model 2.0 specification. The issuance process requires injecting a `proof` object into the root of the document. This signature block guarantees the integrity of the content against third-party alterations. The implementation of an embedded proof of type `DataIntegrityProof` ensures that the history of modifications is exposed to any algorithmic scrutiny.

The economic operator assumes the role of `issuer` and must use its own public-key infrastructure to seal the passport. The corporate identity is established through a Decentralized Identifier, preferably using the `did:web` method for the minimum viable environment. This method allows the decentralised-identity document to be hosted directly on the manufacturer’s official DNS domain. The cryptographic process calculates the hash of the normalised JSON-LD graph and applies the digital signature using the organisation’s private key.

The deployment of the public HTTPS endpoint materialises access to the passport. The web server must be configured to intercept the requests directed to the resolution URI specified on the physical label. This service does not operate as a simple static-file server. It must behave as a basic resolver capable of negotiating the response format through the HTTP headers. If the `Accept` header requests `application/vc` or `application/ld+json`, the server must serve the raw signed document.

Configuring the security headers of this endpoint prevents attack vectors on the data supply chain. The server must issue strict Content-Security-Policy directives and disable aggressive caching that could serve obsolete passports in product-recall contexts.

Step 7 — JRC 145830 coherence verification and operational closure

The final stage of the deployment requires executing the technical validation stipulated in step D of the JRC 145830 methodology. This internal audit verifies that the proposed data structure functionally covers the regulatory use cases without generating unacceptable technical friction. The implementation team must review a checklist of sixteen critical items. The first block of this review guarantees the uninterrupted accessibility of the URIs referenced in the fields of use manuals and external certificates. A broken link within the passport invalidates the conformity assessment of the entire technical file.

Syntax errors in the processing of Linked Data paralyse the data-ingestion systems. The most destructive error in the testing phase occurs when the `@context` array omits the mapping of key terms, transforming the fibre percentages into text strings devoid of semantic meaning. Another common vulnerability lies in the temporal asymmetry of the cryptographic object. Setting an issuance date in the `validFrom` field later than the date of the digital signature triggers validation failures in the cryptographic libraries of customs inspectors.

Scaling this minimum viable model towards an enterprise infrastructure requires addressing automated data ingestion. The static passport drafted by hand serves to validate the resolution architecture, but mass production demands integration with the manufacturer’s ERP and PLM systems.

All of the above is the model worth mastering. Executing it at catalogue scale — with the CIRPASS D2.1 schema already loaded, the datapoints composed automatically and template contractual clauses for Tier 1-N suppliers — is precisely what [DPP](/recursos/glosario/dpp) Readiness, the TraceWeave module, does: the right way to move from the first DPP to a complete collection, ready to absorb the 2027 delegated act without rewriting anything. → Discover DPP Readiness