Designing a DPP Data Model

Most difficulties on a passport programme trace back to modelling decisions taken in the first fortnight, usually without anybody noticing a decision was being made.

Four of them are worth deliberate attention, because each is cheap to get right at the start and expensive to correct once records exist in the field.

One: class facts and instance facts are different

Some facts are true of every unit of a product. Others are true only of one specific unit. Storing them in the same shape produces a model that cannot express either properly.

The last row is the awkward one and it recurs across regulations. A recycled content figure calculated per model and per plant is neither purely class nor purely instance, and a model that offers only two levels forces an inaccurate choice.

The workable answer is to let attributes attach at several levels — class, batch, and unit — with resolution falling back from the most specific available. A unit inherits its class facts unless something more specific has been recorded.

Two: versioning is a regulatory requirement

A passport is a legal assertion at the moment it is read. When a market surveillance authority asks about a product placed on the market two years ago, the question concerns what the passport said then.

• Every change creates a version, with the time it took effect rather than only the time it was recorded.
• Corrections are distinguishable from updates — a corrected error and a genuine change are different events.
• Reads can be time-qualified, so a record can be reconstructed as at a given date.
• Retention matches the regulatory period, which frequently outlasts the systems the data came from.

Three: attributes need provenance

A bare value is not enough. Two passports declaring the same carbon footprint may rest on a supplier’s unverified statement in one case and an audited assessment in the other, and a verifier needs to tell them apart.

Provenance means recording who asserted a value, when, on what basis, and what evidence supports it. This is what allows a downstream party to decide how much weight to place on a figure rather than accepting all values as equally reliable.

Building this in from the start is straightforward. Retrofitting it means revisiting every value already recorded to establish where it came from, which is frequently impossible for the earliest data.

Four: model the regulation, not your ERP

The most common structural mistake is to model the passport on the shape of an existing internal system, because that makes the first integration easy.

It makes everything afterwards harder. Internal systems are organised around how the business operates — by material group, by cost centre, by planning horizon — and none of those align with how a delegated act describes a product.

Model what the regulation asks about, then map internal systems onto it. The mapping is work either way; the difference is whether the resulting model is stable when a second source system or a second product group arrives.

Extensibility without chaos

Delegated acts will add attributes over time, and a model that requires a schema migration for each one will not keep up.

The usual answer is a core schema of stable structural elements — identity, versioning, provenance, access scope — with attributes carried as typed, validated data against a declared definition. New attributes then become new definitions rather than new columns.

The discipline that keeps this from degenerating is requiring every attribute to reference a definition specifying its type, unit and permitted values. Without it, an extensible model becomes an untyped bag of strings within a year.

Access control belongs in the model

The public and permissioned split is not a presentation concern to be handled in a user interface. It is a property of each attribute and it belongs in the model alongside the value.

Treating it as a view layer concern produces the failure where an API returns everything and only the web interface filters it. Recording the audience scope with the attribute means every access path enforces the same rule, which is the only arrangement that survives an integration you did not anticipate.