Arkitektur og adgangsrettigheder

Kan jeres platform vise forskellige felter i forbruger­visningen kontra myndighedsvisningen?

Ja. Hvert felt i hvert sektorskema bærer et målgruppe­specifikt adgangsniveau. Forbrugervisningen viser kun felter mærket “offentlig”; en revisor-, genvinder-, reparatør- eller notified body-legitimation åbner de felter, der er mærket til den pågældende målgruppe (opdelingen i §§ 1/2/3/4 i bilag XIII til batteriforordningen er modellen). Begge visninger løses fra samme /p/{code}-URL via Accept-header-forhandling.

Resolver den samme QR-kode forskellige indhold til forskellige målgrupper?

Ja. Samme URL, indhold forhandles via Accept-headeren (HTML til mennesker, JSON-LD til maskiner) og afgrænses af den legitimation, den besøgende fremlægger. Vi opdeler aldrig URL'er pr. målgruppe — ESPR artikel 10 kræver, at URL'en er permanent.

Hvordan autentificerer I en markedsovervågnings­myndighed?

Med en kortlivet, signeret legitimation udstedt gennem et godkendt ansøgningsforløb. Fem roller anerkendes: producent, revisor, genvinder, reparatør, notified body. Legitimationer kan tilbagekaldes fra én admin-flade; en tilbagekaldelse træder i kraft ved næste request. Indtil en medlemsstats eIDAS-til-DPP-integrations­spec lander, sker validering manuelt — encifrede udstedelser pr. måned i pilotskala.

Jurisdiktion

Kan en fransk forbruger se franske genvindings­oplysninger og en tysk forbruger se tyske, fra samme QR?

I dag bærer passet én End-of-Life-blok. Pr.-jurisdiktions blokke (løst via query-parameter, sprog-cookie eller geo-IP, med producentens default som fallback) er sat på næste release; dataformen og resolveren er designet, og de markedsspecifikke indholds­pakker er afgrænset. Indtil det leveres, publicerer producenter, der eksporterer til flere lande, en default-blok skrevet til at være acceptabel EU-bredt.

Hvad med hreflang og sprog?

Allerede leveret. EN, DE, DA, FR, IT, ES og PL renderes nativt på hver side, inklusive den forbrugerorienterede /p/{code}-viewer; reciprokke hreflang-tags udsendes på hver variant; Accept-Language autoregistreres for besøgende, der lander på det bare /p/{code}.

Revision og integritet

Kan en myndighed bevise, hvad der var live på en bestemt dato?

Ja. Hver gemning skriver en passport_revisions-række med hash_before, hash_after og en struktureret diff. Kæden serveres på /p/{code}/audit som JSON, med begrænsede diff-stier strippet for anonyme kaldere og åbnet for legitimerede revisorer. Kædens gyldighed kan verificeres klientside uden at stole på vores infrastruktur.

Hvilken integritetsgaranti bærer dataene?

Hvert pas har en passport_hash (SHA-256 over det kanoniske JSON-LD). Hashen optræder på HTML-visningen, i JSON-LD-svaret og i offline-PDF'en — tre uafhængige flader, en myndighed kan krydsverificere uden at stole på nogen af dem isoleret.

Slettes pas nogensinde?

Nej. ESPR artikel 10(4) kræver livstidsbevaring; et DELETE på et pas returnerer 403. Batteripas vender til is_active=False (artikel 77(8)), når enheden når affaldsstrømmen — viewer'en returnerer 410 Gone for menneskelige læsere, rækken bliver liggende i databasen til revision.

Regulatorisk position

Er I ESPR-compliant?

Bygget på ESPR-arkitekturen. Flere delegerede retsakter (tekstil, elektronik) er endnu ikke endelige, så ingen platform i verden kan i dag hævde fuld sektoral compliance. Vores skemaer følger arbejdsudkastene; når den enkelte delegerede retsakt udkommer, retagger vi skemafelterne — vi genopbygger ikke.

Hvad er jeres forhold til EU-centralregistret?

ESPR artikel 13 mandaterer registret fra 19. juli 2026. Vores integration er abstraheret bag ét enkelt modul med en stub i dag; når Kommissionen offentliggør LinkSet-API'en og udsteder provider-credentials, vender vi tre miljøvariabler — ingen kodeændringer andetsteds. Contenza K/S er medlem af CIRPASS-2-konsortiet, så vi følger de samme arbejdsdokumenter, Kommissionen skriver imod.

Hvilke sektorer dækker I?

Batteri (2023/1542), tekstil (ESPR delegeret retsakt + 2024/3015), byggeri (CPR 305/2011), elektronik (ESPR + Right-to-Repair 2024/1799 + WEEE), dæk (2020/740) og en generel fallback for produkter uden en sektoral retsakt. Maskiner (2023/1230) er bevidst uden for området — den kræver CE-teknisk dokumentation, ikke et DPP.

Drift

Hvor hostes data?

I EU. PostgreSQL + MinIO på EU-hardware i Danmark. Bilag III(l)-backup-copy-provider-feltet er fanget på hvert pas, så en myndighed kan identificere data­forvalteren uden at spørge os.

Kan jeg eksportere mine data?

Ja. JSON-LD-maskinendpointet er eksporten — samme kanoniske form, integritetshashen er beregnet over. CORS er slået til (Access-Control-Allow-Origin: *), så et hvilket som helst værktøj kan hente cross-origin. Et fuldt konto-ZIP-bundle og en portabel resolver-skabelon er sat på næste release; pr.-pas JSON-LD'et er allerede i dag en fuldstændig, maskinverificerbar eksport.

Egne domæner?

Ja. Caddy med on-demand TLS udsteder et certifikat pr. verificeret domæne ved første request. Domæneejerskab verificeres via en TXT-record før udstedelse; uautoriseret domæne­overtagelse er ikke mulig.

Hvad med produkter, der allerede er på markedet — kan jeg passportere dem retroaktivt?

Ja — det er en del af designet. Bulk-CSV-upload (Professional+-niveau) bringer eksisterende SKU'er i compliance; QR'en kan trykkes på etiketter, hangtags eller næste batch emballage. Retroaktiv passportering er præcis den situation, reguleringen forudser i overgangsperioden.

Et spørgsmål, vi ikke har svaret på? Tag fat i os — vi tilføjer det til siden.