---
title: "Public Passport Pages"
description: "What consumers see — the demo gallery, the passport viewer at model, lot and item level, and template-driven rendering."
canonical_url: "https://openepcis.io/docs/digital-data-management/public-passports"
last_updated: "2026-08-26T20:11:07.845Z"
---

## Where all the curation pays off

Everything described so far in this guide — the master data, the templates, the access tiers, the links — exists for one moment: somebody points a phone at a product, and a page opens. This chapter is about that page.

## Start at the demo gallery

The fastest way to build an intuition for the passport side is `/demo`, DDM's public shop window. It shows a shelf of demo products, each with its GTIN and ready-made QR codes — and pointedly *three* codes per product, one for each level at which the same product exists. Scan one with your phone, or click it, and you follow exactly the path a consumer takes.

![The demo gallery | Figure 1: Demo products with per-level QR codes encoding canonical GS1 Digital Links](/img/13.Digital-Data-Management/demo-gallery.png)

## One product, three levels

Why three codes? Because "the product" means different things in different moments, and GS1 Digital Link expresses the difference directly in the address:

<table>
<thead>
  <tr>
    <th>
      Path
    </th>
    
    <th>
      Level
    </th>
  </tr>
</thead>

<tbody>
  <tr>
    <td>
      <code>
        /01/{gtin}
      </code>
    </td>
    
    <td>
      The <strong>
        model
      </strong>
      
       — this kind of product
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /01/{gtin}/10/{lot}
      </code>
    </td>
    
    <td>
      A <strong>
        batch
      </strong>
      
       — the units produced in one run
    </td>
  </tr>
  
  <tr>
    <td>
      <code>
        /01/{gtin}/21/{serial}
      </code>
    </td>
    
    <td>
      A <strong>
        single item
      </strong>
      
       — this very unit
    </td>
  </tr>
</tbody>
</table>

The address grows more specific from left to right, and the passport grows with it. The model page carries everything true of the product as such — description, materials, certifications. A lot page is about one production run, which is what recalls care about. And an item page is about one physical object: for signed-in users it additionally shows the item's **EPCIS traceability** — the recorded journey of this very unit — when the repository holds events for it.

## The page itself

![A public product passport | Figure 2: The passport page — identity, digital link with QR, and the published attribute sections](/img/13.Digital-Data-Management/public-passport.png)

The page renders straight from the master-data record: a hero with image, brand, name, description, GTIN and the canonical Digital Link (with its QR code, handy for sharing), followed by the attribute sections — specifications, sustainability, certifications, compliance, provenance, and a raw-data view for the technically inclined. Localized fields render in the visitor's language whenever the record carries it; there are no separately maintained language versions of the page, only the multilingual record.

There is deliberately nothing to "publish" here and no separate CMS: when the record is saved, the page is current. For a record whose [access level](/docs/digital-data-management/passport-editor#access-levels) is **Public**, what varies is not *whether* the page exists but *what it shows to whom* — anonymous visitors get the public tier of your [access policy](/docs/digital-data-management/field-access); signing in unlocks further tiers on the same page, under the same address. One printed code serves the consumer, the business partner and the authority, each seeing their slice. A passport that is *not* Public answers anonymous visitors with a plain 404 — to the outside world it does not exist. Signed-in readers still see the page, with a notice explaining that visitors cannot, and a **View as visitor** preview shows exactly what an anonymous scan would get.

## Templates

Not every audience wants the same *arrangement* either. A passport type can have several page layouts — say, a consumer-oriented overview and a compliance-oriented data sheet — and which one renders is decided in a simple order of precedence: an explicit `?template=…` in the URL wins (useful for deep-linking a specific view from your own site), otherwise the product's default template set in the editor, otherwise the deployment's default for the passport type. When several layouts exist, a selector appears at the top of the page, so visitors can switch themselves.

## Where the address comes from

A last piece of orientation, because it explains what the [Linksets](/docs/digital-data-management/linksets) and [Domains](/docs/digital-data-management/resolver-domains) chapters are for. The passport page answers on the DDM deployment — but the address printed in the QR code usually belongs to the **resolver**: `https://id.your-domain.com/01/…`. The resolver looks up the anchor's linkset and its **defaultLink** sends the visitor here. This indirection is deliberate and valuable: the printed code never changes, while everything behind it can — you can redesign the passport, move it, or point the default somewhere else entirely, years after the packaging left the plant.