The EU product passport rule for textiles is still in draft. It is not in force today. So why would I write a post about textile data interoperability now?
Because the interoperability problem the rule will compound is already here. It just does not get called by that name. It gets called the audit cycle. The Higg refresh. The Sedex submission. The annual certification re-upload. The same kinds of questions, answered in different shapes, every few weeks.
What “the data team’s Monday” actually looks like today
The interoperability tax in textile compliance is not new. Compliance teams at Indian mills have been paying it quietly for years.
Most mid-size exporters serve buyers who use different sustainability questionnaires. Some use Higg. Some use Sedex. Some use their own. The questions overlap heavily. The formats do not.
Then there are the annual certificates. The one for organic content. The one for chemical safety. The one for recycled content. The one for cotton sourcing. Each gets renewed every year. Each gets uploaded into several buyer portals, sometimes more than once when a portal does not keep the file between cycles.
Then there is the per-shipment data. Chemical compliance declarations. Chemistry test results. Fibre composition. Country of origin for each processing step. Each buyer wants this in its own template.
The interoperability problem is not about the data values being the same. They usually are not. Different SKUs have different fibre composition. Different dye batches produce different chemistry results. Different audit cycles produce different findings.
What is the same is the category of question every buyer is asking. Fibre composition is fibre composition. A chemistry test result is a chemistry test result. A GOTS scope certificate is a GOTS scope certificate. The kind of fact is shared. The shape it has to arrive in is not. Every buyer wants the same category of answer in their own field names, their own units, their own portal, their own validity rules.
That is the interoperability tax. It is a shape problem, not a content problem.
Interoperability in textiles is not an abstract word. It is the work that happens every Monday whether anyone names it or not.
The cost is real, even before DPP arrives
What does this cost an export compliance team?
A small compliance team at a mid-size mill can lose meaningful capacity each week to repackaging data it has already recorded once.
When a buyer audit lands, that capacity stretches further. Two weeks of focused effort to gather, re-shape, and submit data in the buyer’s chosen format. Sometimes more, if the buyer asks follow-ups in a different shape than the original submission.
Across a year, that adds up to real team time going to repackaging instead of anything that builds the business.
Why every buyer asks for its own shape
Every buyer built its compliance data stack independently. Each chose its own field names, its own portal, its own format. None of them agreed on a common shape. Even the shared frameworks like Higg, Sedex, and Amfori have their own internal models that do not line up with each other.
You are not any buyer’s only supplier. No buyer is your only buyer. The exporter sits at the meeting point of every buyer’s framework choice.
When N buyers each use a different shape and M suppliers each must speak to all of them, the integration work is N times M. Every buyer-supplier pair carries its own translation cost.
This is not a textile-only problem. It is the shape of every supply chain that has not yet picked a shared grammar. Bank-to-bank payments before SWIFT looked like this. Hospital records before HL7 looked like this. Retail barcodes before GS1 itself looked like this. Each time, the industry paid the N times M cost until the parties picked one format.
The textile data layer has not picked one yet. The EU product passport rule will not pick it for them. The rule will require data, not a specific shape for it. If the parties do not converge on their own, every brand that builds a passport stack will build it differently, and the data team’s Monday will get longer, not shorter.
What a shared format actually does
If everyone agreed on one shape, the integration work would collapse from N times M to N plus M.
Each buyer translates its internal stuff to the shared format once. Each supplier translates its data to the shared format once. The middle disappears.
This is the principle behind every interoperability win in computing history. I wrote about why interoperability is the moat for solution providers earlier. The same logic applies on the exporter side, on the brand side, and on the platform side.
EPCIS as the shared event grammar
EPCIS is the shared format the supply chain world has converged on for event-shaped data.
In plain English: EPCIS is a way of writing down everything that happens to a product, in one consistent shape, that any other system can read.
Every event has five things in it. What happened. Where it happened. When it happened. To which product or batch. By whom.
That is it. Five things. Same shape, every time.
A shipment from your mill to a CMT unit can be written as one event. A batch of fabric coming out of the dye house can be one event. A finished garment leaving for the buyer can be one event. A test certificate attached to that batch can be one event.
EPCIS is not a portal you log into. It is not a vendor product. It is a grammar.
The GS1 DPP Provisional Standard breakdown covers the technical details if you want depth.
What changes if the chain agrees to speak EPCIS
EPCIS only delivers its full benefit when more than one party in the chain speaks it. This is the direction, not today’s reality.
Where the chain agrees, the picture looks like this. A batch shipment becomes one event. The buyer reads it. The audit team reads it. The buyer’s compliance platform reads it. The compliance reviewer reads it when a question comes up. Nobody re-shapes anything at any handoff.
Until then, an exporter who speaks EPCIS at the edge has more optionality than one who does not. When a buyer says “we accept EPCIS,” you are ready. When a passport platform says “our ingest is EPCIS-native,” you plug in without a new integration project. The work is not stranded if the buyer changes its mind.
That optionality is the value you can capture before the rest of the chain catches up.
The pattern is already proven, in food
This is not theory.
The Food Traceability Platform operated by GS1 Germany and benelog GmbH runs across 770+ enterprises in Europe, and runs on EPCIS. A batch of fresh produce moves from a German farm to a Spanish supermarket across borders, across ERPs, across organisational boundaries, in the same data shape. The event leaves one party’s system and lands in the next party’s system without translation.
That platform is what my team and I helped architect, design, and build the backend for. We learned what EPCIS can do at industrial scale when a real chain agrees to speak it.
Textile is not food, and the data fields are different. But the grammar transfers. The textile-specific vocabulary is already being scaffolded in the open by benelog at the OpenEPCIS Textile DPP extension, at version 0.9.5 today, covering fibre, care, durability, environmental footprint, circularity, and chemical safety. The page itself notes it is a community implementation, not official GS1 guidance, and may be superseded by GS1 terms once the textile delegated act finalises. Either way, the data shapes are being worked out in code, not just slides.
What an exporter can do today
You do not rip and replace anything to start.
Your ERP stays. Your Tally stays. Your SAP B1 stays. Your custom MES stays. What changes is what sits at the edge.
You add an EPCIS event layer above the existing system. Events get generated from transactions you already record. Receipts. Shipments. Batch transformations. Despatch advices. The event layer reads from your existing tables and writes events in the shared grammar.
This is not a small project. But it is not a year-long enterprise rebuild either. The standard is stable. The work is wiring up what your operational data already records.
A fair pushback: “buyers are not yet asking for EPCIS, so why move first?” You are not waiting for buyers to ask. You are getting your own data into one shape so you can answer any buyer in the time it takes to run a query. When the passport rule’s downstream effects start showing up in buyer RFQs over the next 18 months, you do not want to be discovering the work at that point.
For EU brand sustainability and sourcing teams
You sit on the other side of the same problem.
Every supplier sends data in their own shape. The same kind of certificate, the same kind of audit attestation, the same kind of compliance declaration, arriving in different field names and different file formats from different suppliers. Your team spends weeks re-shaping it before it ever gets used downstream.
The DPP rule will not fix this when it lands. If anything it will add new categories of data the supplier has to send, on top of the existing ones, without picking a shared shape.
The fix is contractual, not technical.
You can mandate EPCIS conformance in your supplier code of conduct, your platform RFP, and your contractual representations. Each step pushes the shared-grammar cost from your side to the side where the data is generated.
The reward is that the audit cycle, the platform-switching pain, and the per-supplier integration debt all shrink at the same time.
For DPP platform engineering and product leadership
Much of your roadmap is translation work. Per-brand schema mapping. Per-supplier ingest. Every new brand customer is an integration project, not a configuration. Every new supplier means another translation layer.
EPCIS-native ingest is where that work goes from project to configuration. Build it once. Stop paying the translation tax every quarter.
Every engineering hour you save on translation can fund features your customers actually pay you for. Analytics. Brand UX. Compliance attestation. Lifecycle reporting.
The interop pain you absorb today is the margin you cannot grow.
The same pain, three seats
The interoperability problem in textiles is the same pain felt from three seats at the same table.
The exporter re-types. The brand re-reconciles. The platform re-translates.
The waste compounds. The product passport rule will not fix this on its own. If anything it widens the surface area unless the parties pick a common grammar.
EPCIS is the grammar the supply chain world has converged on for event-shaped data. Cross-vertical. Cross-border. Already proven in food. Already pointed to by the EU’s own preparatory work on product passports.
Whichever seat you sit in, the direction is the same. Towards a shared grammar.
What is the messiest part of your per-buyer data assembly today? I want to hear it from the supplier IT side, from the brand sustainability side, and from the platform engineering side. Different seats see different mess. Tell me what each one looks like.
