Digital product passports and manageable upkeep

Simple DPP software: Where to make a practical start

Assess simple DPP software with one of your products: ready-made tools, data upkeep, import, permissions, export and effort for your team.

If you want a recommendation for simple software to create digital product passports, I would first try a ready-made platform with one of your own products. Based on their published features, greenable and VERA by Spherity are candidates for an initial shortlist. A shared test needs to establish which one is straightforward for your company to maintain.

For me, simple means that someone responsible can import data, correct an error, approve a change and later trace the resulting state. Your team should not need additional development or help from the provider for every routine maintenance task. Publishing the first passport is only part of that assessment.

Maintain one passport from start to finish

Consider a hypothetical company with several product variants. One variant is selected for the first trial. Its product number, material information and an approved document are available, but they sit in different files and systems.

This information is enough to start a bounded test. First establish which identifier uniquely identifies the variant, who owns the information and which data may be published. Missing or unreviewed information should remain identifiable as such.

The first trial should include the lifecycle of a change. A material value is corrected, a document is replaced or the responsible person changes. That shows whether the software fits your real process.

The information legally required in a product passport depends on the product and applicable requirements. An internal trial does not replace that clarification. Required information and open legal questions should therefore be documented separately from optional information you would like to include.

Judge simplicity by everyday changes

A clear interface helps. For selection, however, I want to know how many steps a frequent task requires and who can perform them. A platform may appear clear during initial creation while making later corrections cumbersome.

I would have someone from your team operate the demonstration. They import a prepared record, correct a value and make the approved version available. The provider explains which steps need no programming and which require additional configuration or development.

Record where questions arise. Is a field name unclear? Is a relationship missing? Or can only the provider make a necessary adjustment? These are different causes with different consequences for ongoing maintenance.

A controlled file import may be sufficient for an initial product area if changes remain manageable. Frequent updates or many variants require an assessment of how data can be transferred reliably from its authoritative system. An interface should solve a specific recurring task.

Two candidates for an initial shortlist

For an initially data-focused task, I would look at greenable. Its published features include structured product data, traceable versions, access permissions and APIs. These provide a concrete demonstration task: import an existing record, correct it and make an approved version available.

If machine-verifiable evidence and cooperation across company boundaries belong to the first use case, I would also assess VERA by Spherity. Its described approach using Verifiable Credentials and standardized data provides a point for discussion. Your own process needs to establish whether your team requires and can manage these capabilities.

This assessment is based on information from the manufacturers. I have not tested the products for this purpose and cannot confirm their usability or implementation effort. They are shortlist candidates rather than a demonstrated overall winner. I would also not treat general compliance statements as evidence for your specific product area.

Test import, correction and export together

For comparison, I would give both candidates the same task. Prepare a complete record and selected variations. Personal or confidential data should only enter an external trial once its use for that purpose has been clarified.

A manageable sequence could be:

  1. Import a record and identify missing or conflicting information.
  2. Correct an error and check whether ownership and change history remain traceable.
  3. Approve a new document version and inspect the visible product passport.
  4. Check permissions for different recipients, including an unauthorized access attempt.
  5. Export data, documents and their relationships, then match them up again outside the platform.

After the trial, record what your team could do itself, what configuration was required and what remains unresolved. Having another responsible person perform a second update is particularly useful. It shows whether the process is documented understandably or still depends on individual participants' knowledge.

A successful import alone would not be sufficient acceptance for me. The complete maintenance process should work with the intended roles and produce an understandable result.

Clarify total costs and the exit route before buying

The effort includes licensing, setup, data cleanup, training and ongoing maintenance. Ask what additional services would be required for more variants, larger data volumes or a new data source. Without those boundaries, proposals are only partly comparable.

I would first assess the cost framework for the bounded product area and consider expansions separately. A proposal should identify its assumptions and the changes that would create additional work. A universal price would say little without that information.

The exit route belongs before the decision too. Which information do you receive back, in what structure and with which limitations? An export becomes useful in practice when identifiers, documents, versions and relationships can be reused.

You then need a short decision brief: requirements met, remaining maintenance tasks, unresolved dependencies and cost assumptions. Management can use it to decide on a limited starting point without committing to a rollout across every product.

Where a ready-made tool and technical preparation meet

For a first product passport, I would assess an existing tool before commissioning a platform of your own. Custom development needs a substantiated gap that suitable existing solutions cannot address sensibly.

My library FluentAAS concerns the creation, validation and export of technical AAS data models. It provides a connection to data modeling and does not replace a ready-made DPP management platform. My technical DPP preparation for existing .NET systems addresses data models and interfaces in stabilized applications.

My DPP guide for medium-sized companies covers further criteria for the broader platform decision. When evidence is the main concern, the article on supplier certifications adds the relevant assessment. Your first step can remain one product passport whose entire maintenance process your team can understand and judge for itself.

The appropriate next step

If the signals described here match your situation, the related service is linked below. You can also tell me what prompted your enquiry. In our first conversation, we will clarify whether and to what extent I can help.