Varför arkitekturfrågan nu hamnar på agendan
Det digitala produktpasset införs stegvis i Europa genom sektorsspecifika rättsakter. För företag kan det lätt ge intrycket att varje produktgrupp behöver sin egen datamodell, sin egen databärare och sin egen integrationslogik. Det är i denna gränsyta som ISO/IEC JTC 5:s arbete börjar: den gemensamma tekniska kommittén inrättades 2026 och ska utarbeta grunderna för sektors- och systemövergripande DPP-interoperabilitet. Dess första annonserade möte äger rum den 7–9 september 2026 i Berlin. ISO/IEC JTC 5 beskriver uttryckligen sitt uppdrag som ett ramverk för DPP-system och DPP-ekosystem; sektorsspecifika standarder förblir de ansvariga expertorganens uppgift.
Detta är varken ett nytt lagkrav eller en publicerad ISO-standard. Det är dock ett välgrundat skäl att skilja den egna arkitekturen från kortsiktiga datafält. Den första arbetspunkten, ISO/AWI 25534-1, befinner sig fortfarande i projektstadiet 10.99; projektet godkändes den 12 februari 2026. Enligt ISO handlar det om begrepp, grundprinciper, datakategorier samt styrnings- och förtroendemekanismer. Den offentliga projektposten anger uttryckligen ”under development”. Den som idag drar slutsatsen att detta innebär ett certifieringskrav eller ett färdigt utbytesformat går händelserna i förväg.
Vad som skiljer det internationella ramverket från EU-kraven
EU fastställer redan konkreta riktlinjer. Kommissionen förklarar att DPP gör produktrelaterad information tillgänglig i en decentraliserad modell: de fullständiga uppgifterna förblir hos den ekonomiska aktören eller hos DPP-tjänsteleverantören; registret innehåller entydiga identifierare och föreskrivna registreringsuppgifter. En databärare som en QR-kod kopplar den fysiska produkten till dess pass. Kommissionens DPP-sida anger dessutom olika åtkomster för roller och sektorsspecifika tidsplaner.
Därtill kommer de europeiska harmoniserade standarderna. Genomförandebeslut (EU) 2026/1736 av den 14 juli 2026 hänvisar till sex DPP-standarder, bland annat om identifierare, interoperabilitet, databärare, API:er, datautbyte och datalagring. Deras roll är konkret: för de krav som de omfattar kan efterlevnad stödja presumtionen om överensstämmelse enligt artikel 10 och 11 i ESPR.
JTC 5 ersätter inte dessa nivåer. Det arbetar ovanför dem: ett sektorsneutralt ramverk ska bidra till att förklara hur begrepp, datakategorier, förtroende och styrning förhåller sig till varandra mellan system. Den praktiska konsekvensen är viktig. En tillverkare bör inte vänta på en framtida ISO-utgåva för att tillhandahålla information om batterier, textilier eller stål. Däremot bör tillverkaren undvika att låsa dagens branschfält som en oföränderlig kärna i en företagsövergripande DPP-modell.
Tre arkitekturbeslut som är meningsfulla redan idag
1. Skilj stabil identitet från verksamhetsprofiler
Ett pass behöver en långlivad teknisk identitet: produkt, variant, parti eller enskild artikel; ansvarig ekonomisk aktör; upplösning via databäraren. Den rättsliga grunden avgör därefter vilken verksamhetsinformation som krävs för detta. Denna information ska ligga i versionshanterade profiler. En batterimodul för CO₂- eller State-of-Health-data är därför inget allmänt grundschema. Inte heller får material-, reparations- eller återvinningsdata endast hamna som ostrukturerad fritext i ett allmänt pass.
I praktiken innebär det att ett stabilt kärn-ID, en dokumenterad profilidentifierare och en profilversion hör ihop. Varje levererad passvy bör visa vilken profil och version som har bestämt innehållet. På så sätt kan team införa en rättsakt, en branschregel eller senare en standard utan att skriva om historiska data eller URL:er.
2. Modellera dataproveniens och åtkomst separat
Interoperabilitet är inte bara ett JSON-format. Den beror på om en mottagare kan bedöma en informations ursprung, giltighet och roll. Spara därför minst källa, giltighetsområde, insamlingstidpunkt, ansvarig part och verksamhetsversion för varje dataelement eller datapaket. Ett internt kvalitetsvärde är något annat än ett rättsligt bindande påstående om överensstämmelse; en leverantörsuppgift är något annat än ett mätvärde.
Den andra delen är åtkomsten. Kommissionen beskriver olika informationsåtkomster för konsumenter, reparationsföretag, återvinnare och myndigheter. Det kräver en medveten åtskillnad mellan offentlig passvy, behörig åtkomst för yrkesverksamma och internt arbetsområde. En URL får inte bli en behörighet. Roller, mandat, datakategorier och beslut som kan loggas måste kontrolleras på serversidan.
3. Testa utbytesgränser som kontrakt
Ett DPP-system har flera övergångar: ERP eller PLM levererar grunddata, leverantörer tillhandahåller underlag, en tjänsteleverantör driftar data, ett register tar emot metadata och externa användare läser en offentlig eller skyddad vy. För varje övergång behövs ett maskinläsbart kontrakt: tillåtna fält, identifierare, semantik, felhantering, versionshantering och bakåtkompatibilitet.
Detta kan testas redan nu. Meningsfulla testfall är okända profilversioner, utgångna underlag, saknad dataproveniens, otillåtna roller, dubbel registrering och en databärare som pekar på ett pass som inte längre är tillgängligt. Testet bevisar ännu inte överensstämmelse med en framtida ISO-standard. Det skapar däremot den spårbarhet som saknas vid en senare övergång, om datamodell och rättigheter redan har blandats samman så att de inte går att skilja åt.
En 90-dagarsplan utan spekulation
Under de närmaste 30 dagarna lönar det sig att skapa en nulägesbild: Vilka produktidentifierare finns, vilka dataprofiler används faktiskt och vilka data finns endast i dokument? Därefter följer ett arkitekturbeslut: kärnmodell, profilregister, proveniensmodell och åtkomstmatris. I ett tredje steg bör en verklig produkt gå genom alla övergångar — från källsystemet via passet till reparationsföretagets eller myndighetens roll.
Gränserna förblir tydliga. ISO/AWI 25534-1 är ingen färdig standard; det finns inga publicerade klausuler som team kan implementera. Inte heller är kommissionens tidslinje bindande, utan den ersätter inte en granskning av den rättsakt som gäller för den aktuella produktgruppen. Nyttan med att följa utvecklingen ligger därför inte i en förtida avprickning på en efterlevnadslista, utan i en arkitektur som kan ta emot nya profiler, roller och utbytesregler på ett välordnat sätt.
