Textile Model and Batch Composition
A fashion brand holds model data in its PLM system while its tier 1 manufacturer holds batch traceability and conformity data. This use case shows how both parties publish independently and the brand assembles the current product view at verification time.
At a glance
Pattern
Specifications touched
- Digital Product Passport (DPP)
- Digital Traceability Event (DTE)
- Digital Conformity Credential (DCC)
- Identity Resolver (IDR)
- Decentralised Access Control (DAC)
Roles
- Brand — controls the product identifiers, holds model data in PLM, operates or contracts the resolver, and provides the customer experience.
- Tier 1 manufacturer — applies the batch identifier during stitching and publishes production, traceability, and conformity data for that batch.
- Conformity assessment bodies and fibre schemes — issue independent assessments covering the factory, materials, or production lot.
- Customers and machines — resolve the same identifier but consume the resulting graph differently.
The problem
A brand sells a cotton t-shirt in multiple colours and sizes. Its PLM system knows the name, description, design composition, trim, colourway, size chart, imagery, and care instructions. These are model-level facts.
The tier 1 manufacturer knows the facility and country of production, the yarn and chemical inputs, and the organic or recycled-content evidence for a specific production run. These are batch-level facts. They can vary between lots of the same model.
If the factory issues one complete DPP, it must copy brand data that it does not own. If the brand issues it, the brand must first retrieve and copy supplier data and independent assessments into its own credential. Either choice creates a monolithic integration and blurs the provenance of third-party statements.
Applying the pattern
The Accumulating Linked Data pattern separates the logical product view from the document boundary. Brand and factory data can be packaged into one larger credential at issue time, or published as separate objects and assembled at verification time. The graph is the same.
For this scenario, verification-time aggregation better matches where the data is created and maintained.
Stage 1: Identify the model and the batch
The parties agree on:
- a model identifier, such as a GTIN, controlled by the brand; and
- a batch identifier, such as the GTIN qualified by a lot number.
For example:
Model: https://id.brand.example/01/09520123456788
Batch: https://id.brand.example/01/09520123456788/10/LOT20260412
The QR code sewn into the garment contains the batch resolver URL. The factory applies the code, while the brand controls the identifier domain and default customer destination.
Stage 2: Publish model-level data
The brand publishes its model data from PLM. It may issue a model-level DPP containing a stable snapshot, publish a product information page, or provide both.
The model identifier resolves to those resources. It does not claim where every future batch will be produced or which certificates will cover it.
Stage 3: Publish batch-level data
The tier 1 manufacturer publishes independently identified data objects for the production run:
- a DTE describing the make event, facility, country, and input lots;
- DCCs from relevant schemes and assessors; and
- where useful, a batch-level DPP or more granular credential whose subject is a product claim or assessment.
The factory registers links to these objects against the batch identifier, subject to the brand resolver's authorisation policy. It does not need to send every object to the brand for copying and re-issuance.
This does not require a new UNTP architecture. A uniquely identified product, claim, assessment, or event can be a credential subject using the relevant UNTP data type. Whether related nodes are packaged together or discovered separately does not alter their graph relationships.
Stage 4: Resolve and assemble at runtime
A customer scans the QR code without requesting a link type. The Identity Resolver follows its configured default and redirects the phone to the brand's product and batch page.
The brand website then requests the link-set for the same batch identifier. It retrieves the model-level links and the batch-level DTEs, DCCs, and other credentials, verifies them, and assembles the current product view.
The website can provide photography, marketing, notifications, care guidance, and e-commerce pathways while presenting verified supplier evidence and links to individual certificates. It is a bespoke brand application over the graph, not a generic rendering of one credential.
Today a link-set is only a catalogue of links. The Identity Resolver does not carry claims. This use case suggests allowing a resolver to embed claims in the link-set as well: unsigned statements by the identifier controller, here the brand, each with optional evidence links to Verifiable Credentials. Trust in the claim as published is control of the resolver domain. Trust in the evidence remains cryptographic verification of the linked credentials.
A granular credential whose subject is a Claim already produces the same graph relationships, so this is not the only way to reach the outcome. The question the use case raises is whether a brand should have to issue and sign a credential in order to assert something on a domain it already controls.
A query for this lot could return:
{
"linkset": [
{
"anchor": "https://id.brand.example/01/09520123456788/10/LOT20260412",
"claim": [
{
"statement": "Cut, made and trimmed in Vietnam",
"evidence": [
{
"href": "https://credentials.factory.example/dte/make-lot20260412",
"title": "Make event — Da Nang facility",
"type": "application/vc+ld+json"
}
]
},
{
"statement": "This lot is covered by an organic content certificate",
"evidence": [
{
"href": "https://credentials.fibrescheme.example/dcc/organic-lot20260412",
"title": "Organic content certificate",
"type": "application/vc+ld+json"
}
]
}
],
"dte": [
{
"href": "https://credentials.factory.example/dte/make-lot20260412",
"title": "Make event — Da Nang facility",
"type": "application/vc+ld+json"
}
],
"dcc": [
{
"href": "https://credentials.fibrescheme.example/dcc/organic-lot20260412",
"title": "Organic content certificate",
"type": "application/vc+ld+json"
}
],
"pip": [
{
"href": "https://www.brand.example/products/organic-cotton-tshirt?lot=LOT20260412",
"title": "Brand website for this product and lot",
"type": "text/html"
}
]
},
{
"anchor": "https://id.brand.example/01/09520123456788",
"pip": [
{
"href": "https://www.brand.example/products/organic-cotton-tshirt",
"title": "Product information — name, colourway, trim, sizes, care",
"type": "text/html"
}
]
}
]
}
The pip on the lot is the default link, so that is where a camera scan is redirected. The claim array is what the brand website, and any other client, reads from the same resolver at runtime. The dte and dcc arrays remain so existing clients that only understand typed links still find the credentials. A query for the GTIN alone returns only the model context, with no lot claims.
The exact JSON shape is illustrative. The point to decide is whether UNTP extends the link-set so claims can sit in the resolver response, instead of only inside a signed credential or only in HTML the brand happens to host.
The brand cites evidence rather than restating it. It asserts that the lot is covered by an organic content certificate and points at the fibre scheme's DCC. It does not copy a certified percentage into the claim and present that number as verified. A claim with no verifying credential behind it is self-asserted, which is what a printed hangtag has always been. A claim whose linked credential fails verification or has been revoked has lost its evidence, and an assessment should say so.
Three consumers, one graph
| Consumer | Path |
|---|---|
| Most customers | Follow the resolver default to the brand website. The site assembles the current graph and presents selected claims and evidence in the brand experience. |
| Machines | Request the link-set directly, retrieve and verify the linked objects, assemble a transparency graph, and run assessments. They do not use rendered credentials. |
| Curious customers | Use an independent app to follow the same path as a machine and make their own assessment without relying on the brand's presentation. |
The renderMethod on a credential remains useful when a person opens one DCC or DTE, such as an organic content certificate. It is unlikely to replace the brand's rich product experience.
Outcome
- The brand maintains model data in PLM rather than distributing copies to every factory.
- The factory publishes batch facts and evidence without becoming responsible for brand content.
- Independent assessments retain their original issuer and signature.
- The same graph can still be packaged into a larger DPP when a transaction or regulation requires issue-time aggregation.
- Customers get a branded experience, while machines and independent apps can verify the underlying graph themselves.
What this asks of the specification
This use case is illustrative, and one part of it sits ahead of the normative text.
| Area | What the current text says | What this use case needs |
|---|---|---|
| Claims in the link-set | A link-set is a catalogue of links, and title is metadata about a target | Extend the Identity Resolver so a link-set MAY embed controller claims, unsigned and domain-authenticated, with optional evidence links to credentials. Typed dte, dcc, and dpp links remain for clients that do not read claims. Property names are to be designed; the requirement is that claims can live in the resolver, not only in a signed credential or in HTML |
Specifications in play
- Accumulating Linked Data — explains why issue-time and verification-time assembly are equivalent graph representations.
- Identity Resolver — discovers model and batch resources and sends ordinary scans to the brand's default page.
- Digital Product Passport — can provide a model snapshot, a batch snapshot, or a larger issue-time aggregation.
- Digital Traceability Event — records the batch production activity and its inputs.
- Digital Conformity Credential — carries assessments issued by fibre schemes and conformity bodies.
- Decentralised Access Control — governs who may register links against the brand-controlled identifier.