Textile traceability starts with the data model, not the blockchain

Most textile traceability projects I have seen begin with a platform decision. Which chain, which vendor, which hosting model. That ordering causes problems later, because the hard question is not where the record lives. It is what the record says.

A product is not a person

Verifiable credentials were designed around people. An issuer makes a claim about a subject, the subject holds it, a verifier checks it. Textile traceability breaks that shape immediately. The subject is a bolt of fabric or a finished garment. It cannot hold anything, and it cannot consent to a presentation.

You have two workable options.

Bind the credential to an identifier printed on the item. The physical tag becomes the pointer. Whoever holds the item can resolve the record.

Bind the credential to the producer and reference the item inside it. The weaver or the unit is the subject. The product is an attribute.

The first is simpler for consumer verification. The second is easier when one producer makes thousands of items and you want to avoid issuing thousands of separate credentials.

What actually goes in the credential

The temptation is to put everything in. Resist it. A credential is signed, so anything inside it becomes expensive to change. Anything that changes should live outside and be referenced.

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "TextileProductCredential"],
  "issuer": "did:example:textilesdept",
  "credentialSubject": {
    "id": "urn:item:PTH-2026-004182",
    "productType": "Paithani saree",
    "producer": "did:example:cluster-yeola-0114",
    "productionMethod": "handloom",
    "verifiedOn": "2026-07-15"
  }
}

Notice what is absent. No retail price, no stock location, no current owner. Those change. Put them in a system that expects change.

Read the specification before you design the schema

The W3C Verifiable Credentials Data Model 2.0 became a Recommendation in May 2025, and it is worth reading properly rather than skimming a summary. It defines the three-party model, how credentials are secured against tampering, and the extension points you will need for a product schema. Most of the mistakes I see come from people inventing structure the spec already provides.

Issue per item or per batch

This is the decision that most affects cost and credibility.

Per batch is cheaper. One credential covers a production run. It also means a counterfeit only needs to claim membership in that run, which is easy to fake if the batch identifier is printed on a label.

Per item costs more and gives you something a counterfeit cannot replicate cheaply, because each identifier resolves to a record that either exists or does not.

For heritage textiles the per-item route is usually the right one. The Maharashtra textiles department took that approach for Paithani and Karvati Kathi sarees, giving each registered piece its own record rather than a shared batch number. The Vingatha case study sets out how the registration and verification steps fit together, and there is a longer write-up of the design decisions if you want the reasoning.

Decide what the record proves

Be precise here, because overclaiming is how these systems lose trust.

A signed record proves that a named issuer made a specific claim on a specific date, and that nobody has altered it since. It does not prove the claim was true. If a verification step upstream was sloppy, you have an authentic record of a bad judgement.

That is not a reason to skip the cryptography. It is a reason to design the human process with the same care as the schema, and to be honest in your documentation about which part guarantees what.

Where to start

Write the schema before you choose a platform. Show it to somebody who works in the supply chain you are modelling. If they cannot tell you where each field comes from and who fills it in, the schema is not finished, and no amount of infrastructure will fix that later.