---
title: "Passport Templates & Requirements"
description: "What each passport type asks for — field obligations, hidden fields and creation defaults, layered from shipped defaults to deployment and tenant overrides."
canonical_url: "https://openepcis.io/docs/digital-data-management/passport-templates"
last_updated: "2026-08-26T20:11:07.854Z"
---

## What a template is, and why it exists

When the [editor](/docs/digital-data-management/passport-editor) marks a field *mandatory*, counts *"6 of 8 requirements met"*, or pre-fills a value on a new record — where does it get all that from? The answer is the record's **passport template**: a machine-readable description of what a passport type *asks for*. One template per type, and everything that guides data entry flows from it.

Keeping this in a template rather than hard-coding it into the form solves a real problem: the obligations are not DDM's opinion — they come from regulation, and regulation changes and differs between deployments. A battery passport's mandatory fields are set by the EU Battery Regulation; a company may additionally decide that *its* battery passports always carry an internal article number; one tenant may hide fields another one needs. Templates make all of this configuration instead of code, in three layers:

1. **Shipped defaults** come with the ontology pipeline (the `dpp-ready` release, whose version is stamped on the page). They encode what the regulation actually says — every obligation traceable to its clause.
2. The **deployment-wide layer** adjusts them for the whole installation.
3. The **tenant layer** adjusts them per tenant.

Each layer only records its *differences* from the one below. When a new `dpp-ready` release updates the regulatory baseline, your overrides survive — they re-apply on top of the new defaults.

One boundary to keep in mind: templates decide what a passport *asks for*. Who may *see* an entered value is the separate concern of [Field Access](/docs/digital-data-management/field-access).

## The requirements matrix

**Passport Templates** shows one template at a time. Pick the scope (product, organization or place) and the template; the tenant field selects the layer you are editing — leave it empty to work on the deployment-wide layer.

![The passport templates matrix | Figure 1: The battery template — obligations, effective state, creation defaults, and the regulatory clause each requirement comes from](/img/13.Digital-Data-Management/requirements-matrix.png)

Each row is one vocabulary term, read from left to right as *"what does the regulation say, what do we say, and what does a new record start with"*:

The **shipped default** column shows the obligation as the profile ships it — *Mandatory* or *Recommended* — and the **clause** column cites where it comes from, for example *Battery Regulation (EU) 2023/1542 Art. 77(3)*. This citation is more than decoration: when an auditor asks why your form demands a field, the answer is on the screen.

The **effective** column is where you intervene. Besides confirming the default you can make a field *Mandatory* or *Recommended* yourself, withdraw a recommendation (*Optional — withdrawn*), or take the field out of the generated form entirely (*Hidden — not in form*). Hiding is the right tool for fields that genuinely never apply in your business — a leaner form beats a form full of eternally empty fields.

The **creation default** column pre-fills new records. It is edited through the same field widget the editor uses — a measurement default is entered as value plus unit, a code-list default through the picker — so a default can never be a value the field itself would reject.

Terms the template does not mention can be pulled in: **Search vocabulary terms…** adds any term of the vocabulary as a new row, starting as *Recommended*. This is how a company-specific requirement — that internal article number — enters the template without touching any code.

## The effective template

The live preview alongside the matrix shows the **effective template**: the merged result of shipped defaults and your overrides, as JSON, with **Copy** and **Download**. It is the exact artifact the editor consumes — what you see here is precisely what the form will do, which makes the preview the fastest way to check a change before anyone creates a record under it.

![The effective template preview | Figure 2: The merged template as JSON — exactly what the editor consumes](/img/13.Digital-Data-Management/requirements-json.png)

Tuned a tenant's template and want the same rules elsewhere? **Copy overrides to another scope** carries them over without re-clicking every row.

## How templates meet the editor

For the person entering data, all of this surfaces as quiet guidance: mandatory fields are required and named in the readiness panel when missing; recommended fields carry a badge and count toward *"m of n requirements met"* — but never block a save, because compliance is a state you work towards, not a precondition for saving work in progress; hidden fields simply do not appear; and creation defaults are already filled in when the form opens.

Editing templates requires the `dpp-admin` role. Every signed-in user can review them read-only — the matrix doubles as the place where anyone can look up *why* the form behaves as it does.