DPP voor textiel: productdata van leverancier tot vrijgave

Een leverancier stuurt je een spreadsheet met vezelpercentages, een certificaat en de naam van een ververij. In je ERP staat dezelfde trui als één artikel met twaalf maten en kleuren. Een maand later is het certificaat verlopen, heeft de leverancier een nieuwe productierun gebruikt en weet niemand meer welke versie van de data op het label terechtkwam.

De fout zit dan niet in de QR-code. Je hebt productdata behandeld als een eenmalige upload, terwijl textieldata door inkoop, productie, verkoop, reparatie en hergebruik blijft bewegen. Na deze route kun je één textielproductfamilie inrichten met een duidelijke identiteit, een eigenaar per veld, geldigheid, bewijs en een menselijke vrijgave.

Een DPP-dataproces voor textiel is een versieerbare keten van productidentiteit, leveranciersdata, bewijs en toegangsrechten. Je kiest per gegeven of het op model-, batch- of itemniveau geldt, bewaart wie de bronhouder is en tot wanneer bewijs technisch geldig blijft. Alleen een gecontroleerde versie wordt beschikbaar voor consument, ketenpartner, reparateur of toezichthouder.

De basis is een DPP als versieerbaar productdossier met bron, bewijs en vrijgave. Deze gids zoomt in op de lastige textielvraag die daar bewust niet centraal staat: hoe je wisselende leveranciersdata aan de juiste productgranulariteit koppelt zonder oude of onbewezen informatie vrij te geven.

Wat je nodig hebt voordat je bouwt

Een textiel-DPP is pas bruikbaar als identiteit, bron, bewijsstatus en toegangsrol samen worden beheerd. De Europese Commissie noemt voor textiel onder meer productidentificatie, vezelsamenstelling, informatie over gebruik en reparatie, herkomst en relevante marktdeelnemers. Op 21 september 2026 zijn de precieze sectorspecifieke velden nog niet definitief. De Commissie vermeldt Q4 2027 als indicatieve planning voor de vaststelling van de gedelegeerde handeling voor textiel. De juridische basis is Verordening (EU) 2024/1781 over ecodesign voor duurzame producten. Die verordening maakt duidelijk dat registratie en juridische conformiteit verschillende dingen zijn: een registratie-ID is geen bewijs dat het product aan alle toepasselijke regels voldoet.

Leg voor één productfamilie de volgende startset klaar:

• Productmaster: SKU, variant, maat, kleur, GTIN als je die gebruikt, ontwerpversie en marktrol.
• Ketenbronnen: leveranciersbestand, garen- of vezelpartij, ververij, snij- en naaiatelier, verpakking en logistieke eenheid.
• Bewijs: certificaat, testresultaat, leveranciersverklaring, auditdocument of reparatiehandleiding met document-ID, versie, datum en geldigheidsinterval.
• Procesbron: ERP, PIM, PLM, QMS of servicepakket. Wijs per gegeven één leidende bron aan.
• Uitwisselroute: CSV voor de eerste proef, een leveranciersportaal of API voor herhaalbare aanlevering, en een export voor storingen.
• Identiteit en drager: een GTIN, batchnummer of serienummer plus een QR-code of andere drager die naar een stabiele DPP-URI verwijst. GS1 Nederland adviseert bestaande GTIN- en GS1 Digital Link-bouwstenen te gebruiken in plaats van voor ieder project een eigen identificatiesysteem te maken.

Rollen en minimale besluiten

Je hebt voor de eerste productfamilie minimaal deze rollen nodig:

• Producteigenaar: bepaalt welke productvelden en varianten in scope zijn.
• Inkoop of leveranciersbeheer: vraagt data en bewijs op en volgt ontbrekende of verlopen stukken op.
• Kwaliteit of compliance: beoordeelt bewijs, afwijkingen en uitzonderingen.
• Data-eigenaar: bewaakt bronhiërarchie, eenheden, naamgeving en versiebeheer.
• Vrijgever: mag de uitwisselbare versie publiceren of intrekken.
• Technisch beheer: houdt koppelingen, toegangsrollen, logging en de fallback-export werkend.
• Reparateur: leest in deze pilot alleen modelniveau-instructies; individuele reparatiehistorie valt buiten scope.

Maak deze vier besluiten expliciet voordat je een platform kiest:

1. Welke productfamilie en marktrol test je?
2. Welke wijzigingen moeten achteraf naar één batch of één kledingstuk terug te vinden zijn?
3. Welke velden zijn publiek, voor ketenpartners, voor reparateurs of alleen voor een toezichthouder?
4. Wie mag een afwijking sluiten en een nieuwe versie vrijgeven?

0/8

• Eén productfamilie, marktrol en eerste releasedatum zijn vastgelegd.
• De bron voor elk kritisch veld is benoemd, inclusief een vervangende bron bij storing.
• Model-, batch- en itemniveau zijn per veld beoordeeld.
• Leveranciers weten welk bestand, formaat, bewijs en geldigheidsinterval nodig zijn.
• Er is één eigenaar voor ontbrekende data en één bevoegde vrijgever.
• Publieke, zakelijke, reparatie- en toezichtvelden zijn van elkaar gescheiden.
• De reparateur ziet alleen de modelniveau-handleiding; individuele reparatie-events zijn buiten scope.
• Een leesbare export en een terugtrekprocedure bestaan voordat de eerste QR-code wordt gedrukt.

Concrete stappen: van leveranciersbestand naar vrijgave

Je bouwt een gecontroleerde keten van brondata naar DPP-versie. Je kiest per veld de juiste granulariteit, ontvangt ruwe bestanden, koppelt bewijs en geldigheid, legt provenance per claim vast, blokkeert conflicten en laat een bevoegde persoon vrijgeven. Zo kun je achteraf verklaren waarom precies deze versie voor deze batch of dit item zichtbaar was.

Doorloop deze route eerst voor één productfamilie en minstens één volledige leverancierscyclus.

1. Kies de eerste productfamilie en schrijf de scope op

Neem een productfamilie met een vaste eigenaar en een echte ketenvraag. Bijvoorbeeld een jas waarvoor een retailer informatie over herkomst vraagt, of een basiscollectie waarvoor reparatie en hergebruik belangrijk zijn. Noteer productfamilie, varianten, landen, marktrol, betrokken leveranciers en wat buiten scope blijft.

Leg ook de actuele regelgeving vast als bronrecord met controledatum. Zet erbij dat textielspecifieke eisen nog kunnen wijzigen en dat de indicatieve planning voor de gedelegeerde handeling Q4 2027 is. Dat is een reden om nu de data- en eigenaarschapslaag te bouwen, niet om al te doen alsof ieder toekomstig veld wettelijk vastligt.

Controleerbare uitkomst: een scope-record met eigenaar, productfamilie, marktrol, bronnenlijst, uitgesloten onderdelen en datum van de volgende regelcheck.

2. Kies per gegeven model-, batch- of itemniveau

Behandel granulariteit als een inhoudelijk besluit, niet als een technische instelling.

• Modelniveau: gebruik dit voor gegevens die voor alle identieke varianten gelden, zoals een ontwerpversie, wasinstructie of algemene reparatiehandleiding.
• Batchniveau: gebruik dit als grondstofpartij, ververij, productieplaats, certificaat of materiaalclaim kan wisselen. Dit is voor de meeste textielketens het veilige startniveau.
• Itemniveau: gebruik dit voor een uniek kledingstuk met eigen serienummer, reparatiehistorie, doorverkoop, authenticiteit of een andere reden om één stuk los te volgen.

Gebruik een ouder-kindrelatie. Een model kan meerdere productiebatches hebben. Een batch kan veel items bevatten. Een item erft modeldata, maar mag nooit stilzwijgend een bewijs krijgen dat alleen voor een andere batch geldig was.

De studie van de European Parliamentary Research Service over het textiel-DPP onderscheidt grondstofproductie, garen, stof, confectie en verkoop en koppelt productreferentie, batch en unieke identificatie aan betrouwbaarheid en volledigheid. Je ontwerpvraag is daarom: op welk niveau moet iemand een claim kunnen controleren?

Controleerbare uitkomst: per veld staat granularity op model, batch of item, met de reden en de eigenaar van het besluit.

3. Maak een leverancierscontract per veld

Stuur geen algemeen verzoek om alle DPP-data. Een leverancier kan dan een PDF, een Excelbestand of een marketingtekst sturen, terwijl jij nog steeds niet weet welke versie leidend is. Maak een veldcatalogus met minimaal deze kolommen:

De bronhouder is de partij die de informatie inhoudelijk kan bevestigen. Een leverancier die een bestand doorstuurt is niet automatisch de bronhouder. Leg ook een bronhiërarchie vast. Bijvoorbeeld: PLM is leidend voor ontwerp en wasinstructie, ERP voor SKU en productieorder, het leveranciersportaal voor herkomstdata en QMS voor test- en vrijgavebewijs.

Controleerbare uitkomst: een versieerbare veldcatalogus en een leverancierssjabloon die een leverancier kan invullen zonder extra uitleg.

4. Ontvang, normaliseer en wijs elke regel toe

Laat een ontvangstworkflow ieder bestand eerst als ruwe bron bewaren. Geef het een ontvangst-ID, leverancier, ontvangen-op tijdstip en checksum. Pas daarna normaliseer je waarden. Zo kun je terugzien wat de leverancier werkelijk aanleverde en wat je eigen systeem heeft aangepast.

Normaliseer landen naar één afgesproken codering, vezelnamen naar één woordenlijst, hoeveelheden naar een vaste eenheid en bewijsstatussen naar een kleine set. Houd de oorspronkelijke tekst apart wanneer de vertaling betekenis kan verliezen. Een leverancier die recycled polyester schrijft, mag niet zonder bronbesluit automatisch naar een strengere claim worden omgezet.

Maak drie toestanden zichtbaar: ontbreekt, niet van toepassing en nog niet gevalideerd. Een leeg veld is geen status. Laat de workflow een record afwijzen als verplichte data ontbreekt op het gekozen niveau, maar stuur een inhoudelijk onduidelijke regel naar een uitzonderingsqueue in plaats van hem te vullen met een gok.

Controleerbare uitkomst: iedere ontvangen regel heeft een bronrecord, een genormaliseerde waarde, een validatiestatus en een eigenaar voor de volgende actie.

5. Koppel bewijs aan geldigheid en productversie

Bewaar een certificaat niet als nieuwste_certificaat.pdf. Gebruik een document-ID, documentversie, uitgevende partij, ontvangstdatum, valid_from, valid_to, taal, product- of batchrelatie en integriteitscontrole. Sla de relatie op tussen de DPP-versie en precies het bewijs dat bij de vrijgave is beoordeeld.

Gebruik een eenvoudige statusketen: aangevraagd, ontvangen, gecontroleerd, afgewezen, verlopen en vrijgegeven. De leverancier mag ontvangen bevestigen. Alleen jouw kwaliteits- of compliance-rol mag gecontroleerd en vrijgegeven zetten.

Maak twee soorten geldigheid expliciet. Technische historische geldigheid zegt of een claim en bewijs bij een bepaalde DPP-versie geldig waren binnen het vastgelegde valid_from- en valid_to-interval. Juridische geldigheid zegt of het product, de claim en de beschikbare DPP voldoen aan de regels die op de relevante markt en het relevante moment gelden. Een technisch vrijgegeven record is dus niet automatisch juridisch conform.

Plan verval als gebeurtenis, niet als notitie. Een dagelijkse taak zoekt naar bewijs waarvan valid_to nadert, maakt een queue-item aan en markeert alle afhankelijke productversies. Een verlopen certificaat hoeft niet automatisch alle al verkochte producten technisch uit de historie te wissen, maar het kan wel een nieuwe batchvrijgave blokkeren en een juridische beoordeling vereisen.

Controleerbare uitkomst: je kunt voor elke vrijgegeven batch antwoorden op drie vragen: welk bewijs is gebruikt, wie keurde het goed en tot wanneer gold het technisch? Daarnaast staat vast welke juridische controle nog nodig is.

6. Bouw één canoniek model en synchroniseer de bronnen

Laat ERP, PIM, PLM en leveranciersportaal niet rechtstreeks elkaars velden overschrijven. Maak één canoniek model waarin identiteit, eigenschappen, provenance per claim, geldigheid, zichtbaarheid, conflictstatus en vrijgave naast elkaar bestaan. De bronsystemen vullen dat model via CSV, API of een workflow. Het model publiceert daarna een rolafhankelijk DPP.

Een bruikbaar record bevat bijvoorbeeld provenance per claim, niet één bronhouder voor het hele record:

{
  "product_id": "JAS-ALP-220",
  "variant": "navy-m",
  "granularity": "batch",
  "batch_id": "CUT-2026-009",
  "claims": {
    "fiber_composition": {
      "value": {"merino": 80, "recycled_polyamide": 20},
      "granularity": "batch",
      "source_owner": "spinnerij-047",
      "evidence_ids": ["CERT-047-2026-09"],
      "valid_from": "2026-08-12",
      "valid_to": "2027-02-28",
      "visibility": ["public", "partner", "authority"],
      "conflict_status": "resolved"
    },
    "dye_process": {
      "value": "DYE-R01",
      "granularity": "batch",
      "source_owner": "ververij-047",
      "evidence_ids": ["PROC-047-2026-08"],
      "valid_from": "2026-08-12",
      "valid_to": "2027-02-28",
      "visibility": ["partner", "authority"],
      "conflict_status": "none"
    },
    "care_instructions": {
      "value": "WAS-ALP-220-v3",
      "granularity": "model",
      "source_owner": "productontwikkeling",
      "evidence_ids": ["APPROVAL-ALP-220-v3"],
      "valid_from": "2026-06-01",
      "valid_to": null,
      "visibility": ["public", "partner", "repairer"],
      "conflict_status": "none"
    }
  },
  "status": "pending_release",
  "version": 4
}

De EU-registratie verandert dit model niet in een centrale Europese opslag. Op 21 september 2026 is het EU DPP-register operationeel en is ook een aparte testomgeving beschikbaar. Het register is een EU-index voor unieke identificaties, registratiegegevens en metadata; de volledige productinformatie blijft bij de marktdeelnemer of dienstverlener. De precieze textielverplichtingen, verplichte registratievelden en registratie-URI's hangen nog af van de toekomstige sectorspecifieke gedelegeerde handeling en technische specificaties. Bouw dpp_registration daarom als een uitbreidbaar, eventueel nog leeg onderdeel. Een geslaagde technische registratie of registration-ID is geen juridische conformiteitsbeslissing.

Houd je eigen API daarom klein en duidelijk. Vraag een DPP op met product-ID, batch of serie, gewenst tijdstip en rol. Geef nooit de nieuwste versie terug als die voor het gevraagde tijdstip niet was vrijgegeven.

Controleerbare uitkomst: een testrecord doorloopt ingestie, normalisatie, versieopbouw en rolafhankelijke uitlezing zonder handmatig kopiëren tussen systemen, terwijl elke claim zijn eigen provenance en conflictstatus behoudt.

7. Laat regels blokkeren en mensen vrijgeven

Automatiseer controles die altijd hetzelfde zijn:

1. Bestaat de product- of batchidentiteit?
2. Is de relatie met de ouderidentiteit geldig?
3. Zijn verplichte velden op het gekozen niveau aanwezig?
4. Kloppen eenheden, toegestane waarden en bronhouder?
5. Is ieder kritisch bewijs aanwezig en technisch geldig?
6. Zijn vertrouwelijke velden afgeschermd voor de gevraagde rol?
7. Is er een conflict met een andere bron of een eerdere versie?
8. Is de juridische beoordelingsstatus apart vastgelegd van de technische release-status?

Een fout maakt een queue-item met foutcode, ernst, eigenaar, volgende actie, deadline en bronrecord. De queue is geen afvoerput. Geef ieder item een sluitreden en bewaar de vorige waarden. Alleen een bevoegde vrijgever zet pending_release naar released. Bij intrekking maak je de reden, tijd, actor en opvolgende versie zichtbaar.

Na deze stap heb je een werkend proces: brondata komt binnen, bewijs kan verlopen zonder stilzwijgende vervanging, afwijkingen krijgen een eigenaar, juridische beoordeling blijft herkenbaar en een mens beslist welke versie naar buiten gaat.

Valkuilen die je vrijgave onbetrouwbaar maken

Je begint met een QR-code

Een QR-code is een drager, geen bronhouder, validatieregel of dossier. Print pas nadat de identiteit en resolver naar een stabiel record wijzen. De link mag naar nieuwe openbare informatie blijven wijzen, maar de achterliggende versiehistorie moet behouden blijven.

Je zet alle data op modelniveau

Dat lijkt efficiënt, tot twee productieruns een andere ververij of een ander certificaat hebben. Zet het veld op batchniveau zodra een verschil de claim, herkomst, samenstelling of controleerbaarheid verandert. Modeldata mag door batches worden geërfd, batchdata niet andersom.

Je laat een leverancier zichzelf vrijgeven

Een leverancier kan aanleveren en bevestigen wat hij heeft aangeleverd. De marktdeelnemer die het product op de EU-markt brengt blijft verantwoordelijk voor de juistheid en beschikbaarheid van de DPP-informatie. Laat de eigen kwaliteits- of compliance-rol de bewijsbeoordeling en publicatie doen.

Je overschrijft oude waarden

Een nieuwe certificaatversie maakt de oude niet ongedaan. Bewaar oude product- en batchversies met ingangsdatum, reden en opvolger. Een vraag over een jas die in 2025 is geleverd moet de data kunnen tonen die toen gold.

Je maakt ontbrekend gelijk aan niet van toepassing

Niet van toepassing is een gemotiveerde beslissing. Ontbreekt is werk. Nog niet gevalideerd wacht op een controle. Gebruik drie verschillende statussen, anders lijkt je volledigheidspercentage beter dan de werkelijkheid.

Je laat verval alleen een waarschuwing sturen

Een e-mail is geen blokkade. Maak het onderscheid tussen technische historische geldigheid en juridische geldigheid expliciet. Een vrijgegeven versie kan technisch historisch geldig blijven voor de periode waarin het bewijs gold, zodat je de toenmalige toestand kunt teruggeven. Dat zegt niet dat die versie vandaag automatisch juridisch conform is. Een verlopen of ingetrokken bewijs blokkeert daarom de afhankelijke nieuwe versie en kan een juridische beoordeling of intrekking vereisen. Een al verkochte versie wordt niet stilzwijgend uit de historie gewist. Ook een released status of een EU registration-ID bewijst op zichzelf geen juridische conformiteit.

Je deelt één scherm met iedere rol

Een consument heeft vezelsamenstelling en onderhoudsinformatie nodig. Een reparateur heeft in deze pilot de modelniveau-handleiding en toegestane onderdelen nodig, maar geen individuele reparatiehistorie. Een toezichthouder kan bewijsreferenties en conformiteitsinformatie nodig hebben. Maak zichtbaarheid onderdeel van het veldmodel, niet van een later schermontwerp.

Beslis-kader: wanneer model, batch of item?

Gebruik eerst deze regel: kies het kleinste niveau waarop een relevante wijziging, claim, reparatie of terugroepactie terug te vinden moet zijn. Voor veel textielbedrijven betekent dat modelniveau voor ontwerp en onderhoud, batchniveau voor grondstoffen en productie, en itemniveau alleen als het kledingstuk een eigen levensloop heeft.

Kies modelniveau wanneer alle productieruns dezelfde relevante samenstelling, herkomstclaims en bewijslogica hebben. Het past bij een eenvoudig product met weinig wijzigingen. Het breekpunt is een leveranciers- of productiewijziging die je niet meer kunt isoleren.

Kies batchniveau wanneer vezels, verfproces, certificaat, productielocatie of productieperiode kunnen verschillen. Dit is de beste standaard voor een eerste textielproef. Je houdt het aantal records beheersbaar en kunt toch een claim koppelen aan de run die hem veroorzaakt.

Kies itemniveau wanneer je elk kledingstuk individueel moet kunnen identificeren, bijvoorbeeld voor luxeproducten, serienummers, verhuur, reparatie, doorverkoop of aantoonbare authenticiteit. De prijs is operationele discipline: ieder item moet bij productie, labelen, verzending en service dezelfde identiteit houden. In de pilot hieronder blijft individuele reparatie buiten scope, dus de rol repairer leest alleen modelniveau-instructies.

Kies ook de bouwvorm:

• Tabel plus workflow: geschikt voor één productfamilie, beperkte broncomplexiteit en een leerpilot. Gebruik n8n Community Edition als proceslaag als je zelf hosting en beheer kunt dragen.
• Kant-en-klare DPP-dienst: geschikt als je snel een beperkte catalogus met QR-codes en paspoorten wilt publiceren. Controleer export, bewijsversies, verval en toegangsrollen voordat je opschaalt.
• Textieltraceerbaarheid: geschikt als leveranciersdata over meerdere niveaus, productdata en lifecyclegegevens samenkomen. Je koopt dan een bredere data-infrastructuur, niet alleen een QR-pagina.
• Maatwerk-koppeling: geschikt als je al ERP, PIM, PLM, QMS en servicegegevens hebt, maar één bronmodel, strikte datatoegang en een eigen uitzonderingsproces nodig hebt.

De keuzehulp hieronder is een korte route door hetzelfde kader. Hij vervangt de uitleg niet.

Moet je reparatie, doorverkoop of authenticiteit per kledingstuk kunnen tonen?

Ja, per stukNee

Uitgewerkt voorbeeld: een jas van vezel tot DPP

Dit is een fictief voorbeeld met echte proceskeuzes. Gebruik de getallen als rekeneenheid voor je ontwerp, niet als norm voor ieder textielbedrijf.

Luma Knitwear BV brengt de jas Alp 220 op de markt. De collectie heeft drie kleuren en vier maten. Het productteam beheert ontwerp, wasinstructie en algemene reparatiehandleiding op modelniveau. De spinnerij levert merinogaren, een ververij verwerkt de stof en een atelier naait de jas. Individuele reparatie en doorverkoop zijn voorlopig geen onderdeel van de pilot. De repairer-rol blijft wel bestaan voor het lezen van de modelniveau-handleiding.

Stap 1: model en batch scheiden

Het modelrecord JAS-ALP-220 bevat de goedgekeurde pasvorm, wasinstructie, reparatiehandleiding en de productfamilie. De variant navy-m krijgt een eigen product-ID omdat maat en kleur in de verkoopdata verschillen.

Voor de verkoop van 2.400 jassen worden eerst twee runs vrijgegeven:

Op 4 oktober 2026 wordt een nieuwe productierun van 600 jassen geïntroduceerd onder CUT-2026-014. Dit is de derde run, niet de tweede. De derde run blijft wachten op zijn eigen bewijscontrole en telt niet mee in de 2.400 verkochte jassen uit de eerste twee runs. De 2.400 blijven dus gekoppeld aan de twee eerdere batchrecords samen: 1.400 aan CUT-2026-009 en 1.000 aan CUT-2026-011.

De jas erft de modeldata. De herkomst van het garen, de ververij, de productiedatum, het testdocument en de hoeveelheid horen aan de batch. Een QR-code op de verpakking kan naar de variant leiden, waarna de batch via de order of logistieke eenheid wordt geselecteerd. Een item-QR en individuele servicehistorie komen pas in beeld als Luma de pilot uitbreidt.

Stap 2: leveranciersdata ontvangen

De spinnerij levert CSV-regels met garenpartij MER-26-041, vezelsamenstelling 80% merino en 20% gerecycled polyamide, productiedatum 12 augustus 2026 en een certificaat-ID. De ververij levert voor CUT-2026-009 batch DYE-26-018, een locatie-ID, procesverklaring en een document dat geldig is tot 31 augustus 2026. Voor CUT-2026-011 levert de ververij een afzonderlijke batch- en bewijsrelatie. Het atelier levert per run de aantallen per variant en een koppeling naar de stofbatch.

De workflow bewaart eerst de ruwe bestanden. Daarna controleert hij of de vezelpercentages samen 100% vormen, of elke stofbatch aan een bestaande modelvariant hangt en of elk certificaat een geldigheidsinterval heeft. De datumcontrole markeert het ververijdocument voor CUT-2026-009 als verlopen wanneer Luma de data op 21 september 2026 ontvangt. Die batch wordt niet gepubliceerd voordat de bewijsstatus en de juridische beoordeling zijn bijgewerkt.

Stap 3: de uitzonderingsqueue oplossen

De queue bevat drie items:

1. CERT-DYE-018 is verlopen. Inkoop vraagt een actuele procesverklaring op bij de ververij.
2. De atelierlijst bevat twaalf jassen zonder bevestigde batchrelatie. Operations zoekt de ontbrekende productieregels uit.
3. De pakbon vermeldt 80% merino en 20% polyamide, terwijl één leveranciersregel 100% merino zegt. Kwaliteit vergelijkt de bronbestanden en sluit de foutieve regel af als afgewezen.

Er staat geen queue-item voor het toevoegen van een repairer-rol: die rol is al onderdeel van het model voor de beperkte modelniveau-handleiding. Individuele reparatie-events zijn expliciet buiten scope en worden dus ook niet als ontbrekende pilotdata behandeld. Geen van de drie items wordt opgelost door een lege waarde te vullen. De queue bewaart eigenaar, actie, bronbestand en sluitreden.

Stap 4: versie opbouwen, zichtbaarheid instellen en vrijgeven

Na de correcties maakt het systeem een nieuwe batchversie voor CUT-2026-009. De vrijgever ziet modeldata, batchdata, de bewijsrelaties, de validatielog, de conflictstatus en de zichtbaarheid per rol. De zichtbaarheid is in de pilot als volgt:

De prijs van het garen en de interne leveranciersnotitie blijven buiten het DPP. De vrijgever publiceert de twee eerste batchversies op 23 september 2026. Op 4 oktober komt CUT-2026-014 als derde run binnen. De oude batchversies blijven opvraagbaar voor de 2.400 jassen uit de eerste twee runs; de nieuwe run krijgt een eigen bewijscontrole en eigen provenance.

Dit voorbeeld laat zien waarom modelniveau alleen te grof is en itemniveau hier te vroeg komt. De zakelijke waarde zit in de batchrelatie: Luma kan een leveranciersclaim, een bewijsstuk, een productieaantal en een productierun samen terugvinden zonder elk kledingstuk al afzonderlijk te serialiseren.

Vergelijkingstabel: niveau en inrichting

De toolvergelijking hieronder is gebaseerd op actuele product- en prijspagina's die op 21 september 2026 zijn geraadpleegd. De officiële n8n-prijspagina noemt Community Edition als self-hosted optie, hosted Starter voor €20 per maand bij jaarfacturatie en self-hosted Business voor €667 per maand bij jaarfacturatie. De officiële prijspagina van MyProductPassport noemt €0 voor vijf producten, €34 per maand voor vijftig en €94 per maand voor vijfhonderd. De TrusTrace-productpagina werkt met Contact Sales en publiceert geen vast bedrag.

De tabel maakt het belangrijkste verschil zichtbaar. n8n automatiseert de route, een DPP-dienst publiceert snel, een traceerbaarheidsplatform levert een bredere ketenlaag en maatwerk maakt jouw bron- en vrijgaveregels leidend. Kies niet op QR-functionaliteit alleen. Test minstens één conflict, één verlopen bewijs, één historische uitlezing en één rolbeperkte export.

Een textiel-DPP wordt betrouwbaar op het moment dat een ontbrekend certificaat niet meer als een detail wordt behandeld, maar als een bestuurbare uitzondering met een eigenaar. Begin daarom bij de vraag welke versie van welke data op welk niveau technisch en juridisch bewijsbaar moet zijn. De QR-code komt daarna vanzelf op de juiste plek.