Work with products, passports and versions

The product record comes first

A passport is always built from a product, so start in Products. The record holds the name, identifiers, category and the economic operator details that later appear on the passport.

Global Trade Item Numbers are check-digit validated on entry, and the platform can look for an exact duplicate or a similar name before you save. Changing the category is blocked once passports exist, and a published GTIN is locked, because a passport is evidence of what was declared at a point in time.

Drafting the passport

1. Open DPPs and choose Create passport.
2. Pick the product; the form follows its category pack schema.
3. Fill the fields you can support with evidence, using the guided form or the JSON editor.
4. Save. Each save produces an immutable version rather than overwriting history.

Validation is the compliance workspace

Running validation evaluates the version against the deterministic rule engine for the selected markets and stores a validation run: findings with a severity and the rule behind them, a weighted score and grade, and a suggested next action.

A passport without a validation run is not evidence of anything. Validate after every material edit, and read the findings - the engine reports what a rule asked for, it does not certify the product.

Versions, diffs and custody

The version history lists every saved version with its author, and the diff view shows field-level changes between any two versions - useful when someone asks what changed since the version a customer saw.

The same page carries the custody chain (one active holder, transfers recorded and pushed as EPCIS events), remanufacturing lineage, leasing, serialized split and merge, and the carrier panel for QR, GS1 Digital Link, DataMatrix and RFID.

Publishing

Publishing moves a version to the public passport. Check the public preview first and use field redaction for anything commercially sensitive - a redacted path is removed from the public API as well as the page, and it stays withheld everywhere the public payload is reused, including credentials and channel feeds.

After publishing, keep working on the next version. The published one remains available until you publish a newer version.

Components and nested passports

Open a passport and choose Components to record the product's structure: each line can link a passport of your organization (a battery inside a vehicle, a cell inside a module), a component passport another issuer publishes (https or GS1 Digital Link), or be structure only, such as packaging. Links are references, never copies, so a component's own updates show in the assembly.

The summary flags recalled, unpublished, unvalidated or failing component passports, and Used in lists every product that contains a passport. A link that would make a passport its own component is refused. Lines marked public appear on the public passport with name, quantity and link only - never mass or supplier - and a recalled component raises an urgent item in the action inbox.

Serialized items at scale

For item-level traceability without a full passport per item, open a passport and choose Items. Generate up to 1,000,000 serials per job (prefix plus a zero-padded running number, optional batch) in the background, or register serials that already exist; existing serials are skipped, never overwritten. Each serial resolves through its GS1 Digital Link (/01/{gtin}/10/{batch}/21/{serial}) to this passport, and the public page shows the item's own status: in circulation, refurbished, recycled, destroyed or recalled. Sales states (sold, in use, returned) stay in the console and read as in circulation publicly, so sequential serials do not reveal your volumes.

The print / encode export lists every item with its Digital Link URI for QR codes and NFC tags and its GS1 element string for DataMatrix and RFID encoders, in files of 100,000 lines. Split a passport instead when an individual item needs its own data and versions.

Models and variants

Under Catalogue, Models and variants, group the variants of a style or product family under a model: its category, brand, the axes its variants differ by (colour, size, capacity) and the passport data they all share. Give the values per axis and the platform creates every missing combination - each variant is a product of its own, with a SKU from your pattern, a GTIN from your list and a passport that starts with the shared data. Combinations that exist are skipped; a variant that fails (a SKU already taken, a plan limit) is reported without stopping the others.

Change the shared data and apply it: every variant passport where it differs gets a new, validated version, after a preview. Existing products of the same category can be added as variants. Batches and serialized items stay below each variant's passport, so a product line reads Model, Variant, Batch, Item. The public passport of a variant names its model and its variant values.

Can I recover work before saving a version?

Create and edit forms autosave valid structured values after a short pause into a private, organization-and-user-scoped working draft. This is separate from immutable passport history and never publishes. On return, choose Restore, download the recovered JSON, or explicitly discard it. A draft from another base version or schema cannot be silently restored. Another tab's edits cause a revision conflict, not an overwrite.

Recovery access expires after 30 days and the scheduled retention sweep removes older drafts. The form warns before closing with uncommitted values. Invalid developer JSON is not autosaved or included in the structured download: copy that raw text separately. Save/Create still follows the ordinary validation, optimistic version check and publication process.

How do I export one audit package?

Owners and administrators select a version in Evidence & audit package and download the internal JSON snapshot. It contains immutable version data, version-specific validation and publication approvals, evidence links and a file-hash/review manifest, supplier responses and a bounded passport audit history. It contains no original files, storage keys, invitation tokens or signed download URLs.

The export states its time and limitations. Evidence reviews and supplier responses reflect export time, not necessarily the time the passport was saved. A canonical SHA-256 checksum detects changes to the package content, but is not a digital signature or legal certification. Treat the downloaded package as confidential internal information.

What do readers see on the public passport?

The public passport presents the published data as labelled groups - identifiers, manufacturer, the category block, materials and so on - with units on the values, coded values by their names and lists of records as tables. Below the data it shows the authenticity credential, the fields withheld from the public view and who may read them, and links to machine-readable formats: passport JSON, labelled JSON, Asset Administration Shell, the GS1 linkset, the recycler material passport, the credential and the issuer's keys and DID.

The page's QR code encodes the product's GS1 Digital Link when it has a GTIN, which this platform resolves to the passport, with the four-module quiet zone scanners need. If you enter your own link in the data carrier field, make sure your resolver sends that GTIN to this passport.

Screen-by-screen reference

These pages were checked in the organization console on 8 October 2026 using an isolated sample organization. Controls can differ by role, plan, record state and configured providers. Each page below explains its purpose, a practical workflow, the visible controls and what to verify afterward.

Products (/products)

The catalogue contains stable product identities and the identifiers used by passports, stores and GS1 links. Counts distinguish the organization total from the current filtered result.

Use search and category filters to narrow the catalogue, then compare the filtered count with the organization total. Open an identity to edit it or start a passport, and inspect selected rows before a bulk action because selection is page-scoped. Export a CSV when a snapshot of catalogue identities is needed outside the console.

A product category is constrained once passports exist, and a published GTIN is protected.

Controls and options

• Search name, SKU, GTIN, brand or manufacturer, optionally filter Category, then Filter or Clear.
• Add product opens the identity form; Import CSV previews a spreadsheet; Shopify / WooCommerce opens store connections.
• Export CSV downloads the catalogue. Select rows for the available bulk actions, or open a product to inspect and edit its record.
• The table's checkboxes select only the current page; confirm the visible selection before a bulk action.

Create product (/products/new)

Product identity combines name, SKU, category, optional GTIN and model number with brand, image URL, workspace and economic operator details.

Decide the category and stable SKU before saving because later passports use those identifiers and the category's schema. Add GTIN only after confirming ownership and format; optional operator and image fields can be completed from reliable source data. Choose Save and create passport only when you are ready to start the first declaration.

A product record is not a published passport.

Controls and options

• Enter a unique SKU and choose the correct category before saving; the category drives the passport form and validation pack.
• Use GTIN only when it belongs to this product; the form checks format and ownership constraints.
• Save product only creates the catalogue record; Save & create passport continues into the initial declaration.
• Review any duplicate suggestion before creating another record for the same physical product.

Product detail (/products/[id])

The current identity and editable fields sit together so you can confirm what passport versions refer to.

Confirm name, SKU, GTIN, category, and economic-operator details against the physical product before updating them. The page links to passports that use this identity, so a changed field can affect downstream consistency. Restricted edits or deletion may be refused once versioned or published records depend on the product.

Changing a category or GTIN may be refused after passports or publication exist.

Controls and options

• Save product updates allowed identity and operator fields after validation.
• View passports opens the linked passport list; Create passport starts another passport for this product where allowed.
• All products returns to the catalogue.
• Delete product is restricted and should be used only when the record is eligible; published records retain their trace.

Models and variants (/models)

A model groups a product family under shared category, brand and passport data. Each variant remains its own product and passport.

Create a model for a stable product family before generating variants. Category, code, brand, workspace, and variant axes define which individual products can belong to it. Creating the family does not create its combinations; inspect the detail page to decide which variant values and shared passport data should be applied.

Choose the category carefully because variants inherit it.

Controls and options

• Open a model row to inspect its variant axes and products.
• New model requires a code, name and category; optionally choose brand and workspace.
• Variant axes such as colour and size define which value combinations can be generated later.
• Create model stores the family; it does not create every variant until you use Generate on the detail page.

Model detail (/models/[id])

The model page lists variants and lets an editor generate combinations, maintain shared passport data or attach existing products.

Preview the combination list and SKU/name pattern before generating variants to avoid unwanted product identities. Shared passport data can be saved as a model template, then previewed and deliberately applied to existing variants; it is not an automatic silent rewrite. Review skipped or failed combinations and the resulting passport revisions individually.

Generation reports each failed or skipped combination separately.

Controls and options

• Enter values for each axis, check the SKU and name patterns, optionally supply GTINs, and Generate missing combinations.
• Save shared data changes the model template; Preview on variants shows differences before Apply to variants writes new passport versions.
• Add an existing product as a variant only when its category and axis values fit this model.
• Remove from model unlinks a variant without deleting its product or passport.

Passport portfolio (/dpps)

The list is the working entry point for draft, active, archived and recalled passports, with filters, bulk actions and direct links to each record.

Filter the portfolio before selecting rows so the intended passports are visible. Bulk publication and lifecycle actions are state- and role-dependent, and one item can fail while others succeed; read the per-item result. Open a record for evidence, history, visibility, and validation instead of relying on list status alone.

A bulk action can partially succeed; read the result for every item.

Controls and options

• Search by product and filter Status or Category; Filter applies and Clear resets the list.
• New DPP starts a passport for an existing product; Import CSV can create products and draft passports together.
• Select rows to use Publish, Archive or Recall where your role and each record state permit; review the per-item result.
• Merge selected combines eligible serialized outputs, while Print labels prepares carrier sheets for selected passports.
• Open enters one passport's detailed workflow.

Create passport (/dpps/new)

Choose a product and author its first structured passport version using the category schema.

Select an existing product first so the editor can load its category schema. Use guided fields for ordinary entry and Developer JSON only when you need to supply the complete structured payload. Save the first draft, inspect validation findings, and compare its public preview with the intended declaration before any release request.

Creating a passport does not claim that a draft pack is legally approved.

Controls and options

• Select the product; use the guided sections for supported fields or Developer JSON for a full structured payload.
• Fill identifiers, operator and category fields from reliable source material.
• Download the working JSON if you need an offline copy; a valid private working draft can be restored before the first save.
• Create DPP saves a draft version. Validate and review its public preview before publication.

Passport detail (/dpps/[id])

This long record brings product identity, version history, validation findings, obligations, dossiers, public visibility, localization, carriers and lifecycle tools into one place.

Work through this record in sequence: verify product identity and category, inspect evidence and provenance, run the intended market validation, then review public visibility and preview. Publishing freezes a versioned declaration; later edits create another revision. Lifecycle actions such as archive, recall, registry submission, and derived passports have different effects, so read each confirmation before applying it.

A high readiness score does not replace the legally reviewed pack or the accountable override needed for a draft pack.

Controls and options

• Use Evidence & audit package, Provenance, Components, Items and Custody to inspect traceability around the current version.
• Edit creates a new immutable revision; History compares revisions; Preview shows the current public projection.
• Validate EU or EU + UK stores rule findings. Resolve findings in the authoring form and rerun validation before publication.
• Publish or request a publication review according to role and pack status. Archive, Recall and Submit to registry have separate effects and confirmations.
• Public field visibility controls exactly which structured paths reach the public page and downstream exports; check the preview after changing it.
• QR, DataMatrix, GS1 Digital Link and AAS export reuse the published or previewed payload as labelled.

Edit passport (/dpps/[id]/edit)

Edits are staged against the current version and saved as a new version, preserving earlier declarations.

Choose the authoring mode that exposes the fields you need, and confirm any working-draft recovery before typing over current work. Saving creates a new immutable version; it does not rewrite a previous public declaration. Re-run validation and attach evidence to the new version, then inspect its preview before publishing it.

A new version needs its own validation and evidence links.

Controls and options

• Choose Guided, All fields or Developer JSON according to the data you need to edit.
• Use category sections, repeatable rows and field help to enter the source data; invalid JSON must be corrected before switching modes.
• Download current working JSON or restore the private working draft when the page offers recovery.
• Save creates the next version after schema validation; Cancel leaves the current saved version intact.

Passport version history (/dpps/[id]/history)

History lists saved versions and a field-level comparison so a reviewer can see exactly what changed.

Use the comparison to identify which field paths changed between two saved versions, not just that a version number increased. Preserve the chosen version number when discussing validation, evidence, or an audit package. Return to the current passport to see the latest working state, which may differ from a historical published snapshot.

A version row represents an immutable saved snapshot.

Controls and options

• Select two versions where the comparison controls appear.
• Read the From and To columns by field path; unchanged fields are omitted from the change list.
• Use Back to passport to return to the active record and its latest validation.
• Preserve the version number when referencing an audit package or evidence link.

Public preview (/dpps/[id]/preview)

The preview shows identity, visibility policy and the structured payload that a consumer would see.

Compare the public identity and structured data with the saved declaration and visibility policy. Look for both missing information and information that should remain private, especially after a redaction change. A published passport can expose the revised visibility projection immediately, so verify the live page after saving such a change.

For a published release, saving a visibility change affects the public projection immediately.

Controls and options

• Inspect Public identity for product, issuer and operator details.
• Check Visibility policy and Public structured data for paths withheld by redaction.
• Open live passport when a release is published; Back to passport returns to editing and validation.

Passport components (/dpps/[id]/components)

Structure rows represent parts of the product, optionally linking another passport, an external digital link or a supplier.

Add each part with a quantity and the relevant supplier or linked passport when known. Check whether the line should be visible to consumers, since a public component reference can expose more than an internal structure row. Use the reverse Used in list to understand where this passport is referenced by parent products.

A component link is a reference to another passport, not a copy of its data.

Controls and options

• Add a component with name, quantity and optional role, mass, supplier and linked passport.
• Public passport visibility controls whether the consumer sees the component name, quantity and link.
• Inspect Structure for linked component status and Used in for parent passports that reference this one.
• Edit or remove a line on the row where your role permits.