What a template is, and why it exists

When the 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.

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.

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.

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.