1. Introduction
Digital Product Passports (DPPs) and Digital Material Passports are becoming a central mechanism for making product-level information reusable across circular economy value chains. In the CE-RISE project, the passport is part of a broader Resource Information System that connects product data with reuse, repair, refurbishment, recycling, product environmental footprint, and socio-economic and environmental assessment needs.1,2 Such systems require not only individual schemas but modular model ecosystems that can evolve, interoperate, and be compared with sector-specific initiatives.
This creates a model evaluation and selection problem. Traditional data validation asks whether an instance dataset conforms to a model. In early and evolving DPP contexts, representative datasets may not yet exist, while model authors and adopters already need to decide which model components are fit for an application, whether changes across releases improve or weaken the model, whether external models cover equivalent information, and which gaps matter for a use case. Manual inspection is insufficient for model suites with thousands of shapes and properties, frequent revisions, and multiple downstream reuse scenarios.
DP-AWB addresses this problem as a SHACL-based model assessment workbench. The tool reads SHACL specifications directly and computes reproducible assessment, coverage, comparison, prioritisation, and integration recommendation results. The contribution of this article is the software tool and its workflow. The battery DPP comparison is used as a demonstration case showing how the workbench supports evidence-based model evaluation and integration planning.
2. Software description
2.1 Purpose
DP-AWB is designed to turn model specifications into decision evidence. Its central assumption is that SHACL model files contain enough formal structure to support an initial model-level assessment before instance-data validation is possible. The workbench does not replace domain judgement. Instead, it makes structural and coverage evidence explicit, reproducible, and reviewable.
2.2 Distribution and access routes
The tool is distributed through two deployment routes.
•
Python package. The package dpawb is published on PyPI at https://pypi.org/project/dpawb/. At the time of drafting, the verified PyPI metadata reports version 0.1.2, license EUPL-1.2, Python requirement
3.12, and the summary “SHACL-based analytical workbench for digital passport model assessment and use-case coverage”.3
•
MCP server. The workbench is also distributed as a containerised Model Context Protocol (MCP) server. The Official MCP Registry entry is io.github. CE-RISE-software/dpawb; version 0.1.2 is marked as latest and uses the OCI package ghcr.io/ce-rise-software/dpawb-mcp:0.1.2 with stdio transport.4,5
The MCP route exposes deterministic tools for assessment, coverage, comparison, prioritisation, composition recommendation, schema/template discovery, controlled vocabulary discovery, and summarisation. In the replication workflow used for this article, DP-AWB was accessed through its MCP server only.
2.3 Core workflow
The workbench operates on file-based inputs and emits file-based JSON results. The main input artefacts are:
• a composition profile, listing one or more SHACL model sources that together define a model ecosystem;
• an optional use-case file, defining required information items and required concept-to-concept joins;
• an optional alignment file, defining analyst-reviewed equivalences between model entities before deduplication.
Figure 1 summarises DP-AWB as an instrument panel. The five evidence perspectives organise low-level SHACL metrics and diagnostic findings into model-evaluation signals, while the output layer exposes the corresponding decision artefacts.
Figure 1. DP-AWB instrument panel.
Table 1 lists the principal MCP tools used to produce the deterministic result documents.
Table 1. Principal DP-AWB MCP tools used in the reproducible assessment workflow.
| Tool | Role |
|---|
| assess
| Computes structural, explicitness, interoperability, and maintainability metrics for one composition profile. |
| coverage
| Assesses the evidence that one composition profile covers the required items and joins of a use case. |
| compare
| Compares two assessment results, optionally applying an analyst-authored alignment file. |
| prioritize
| Ranks improvement targets from assessment, comparison, and coverage evidence. |
| recommend_composition
| Recommends a deterministic candidate composition from two assessed ecosystems and optional downstream evidence. |
| summarize
| Creates a deterministic summary result from existing result documents. |
3. Assessment method
3.1 Assessment perspectives
DP-AWB computes an instrument panel of complementary evidence categories. The current workflow emphasises five perspectives:
1.
Model structure: number of modules, node shapes, property shapes, object-reference properties, and structural scale.
2.
Constraint readiness: shares of typed and cardinality-bounded properties, constraint density, and related explicitness indicators.
3.
Interoperability: cross-module references, shared vocabulary overlap, and declared or candidate overlaps between model ecosystems.
4.
Maintainability: deterministic findings such as dangling references, contradictions, and redundancy candidates.
5.
Use-case coverage: evidence for required information items and required joins.
3.2 Coverage model
Use-case coverage is intentionally SHACL-only. A use case is formalised as a set of required information items and joins. An information item is a piece of information needed by the application, such as a battery identifier or carbon-footprint value. A join describes an expected connection between such items, for example that product identification should be connectable to material composition or carbon-footprint evidence. The workbench checks what evidence the assessed SHACL sources provide for these requirements. Coverage findings are evidence classes, not expert truth labels. A finding of indeterminate, for example, can mean that the model contains related evidence but that the deterministic SHACL evidence is not specific enough for a direct match.
3.3 Alignment and integration
The comparison workflow can apply analyst-authored equivalence files. This is important because similarity between model labels is not sufficient for deduplication. The alignment file records only equivalences that the analyst is willing to use as explicit overlap evidence. DP-AWB then checks whether the declared left and right entities are present in the corresponding assessment traces and uses the resulting comparison evidence in prioritisation and composition recommendation.
4. Operation
4.1 Minimal package route
The Python package route is intended for local or scripted use:
python -m pip install dpawb
The package documentation and source repository are linked from the PyPI metadata and listed in the Software availability section.6,7
4.2 Containerised MCP route
The MCP route is intended for use by MCP-capable clients and agentic workflows. The registry-supported package is the OCI image:
ghcr.io/ce-rise-software/dpawb-mcp:0.1.2
In a local workspace, a stdio server can be launched with a mounted working directory, for example:
podman run --rm -i \
-v /path/to/workspace:/workspace:Z \
-w /workspace \
ghcr.io/ce-rise-software/dpawb-mcp:0.1.2
This route was used to produce the persisted JSON results in the demonstration.
Figure 2 presents the operational workflow used in the demonstration. The same pattern can be applied to release monitoring, comparison of model alternatives, and documentation of integration decisions.
Figure 2. Reproducible DP-AWB workflow.
5. Use case: battery DPP model integration
5.1 Purpose of the demonstration
The demonstration evaluates the workbench from the viewpoint of a battery Digital Product Passport application. The goal is not to declare a single model ecosystem superior, but to show how DP-AWB can reveal structural differences, use-case evidence, strict overlaps, and integration guidance.
5.2 Compared ecosystems
The left ecosystem is the CE-RISE Digital Passport model ecosystem. For this demonstration, the assessed profile uses a version-pinned CE-RISE generated SHACL release set, covering 12 modules: passport metadata, access and governance, custody, product profile, material profile, traceability and life-cycle events, usage and maintenance, diagnostic results, integrated life-cycle assessment, circularity and end of life, compliance and standards, and RE indicators. The profile version is recorded as ce-rise-versioned-shacl-release-set
.
Table 2 records the corresponding CE-RISE model repository and model version tag used for the assessment.8 This mirrors the treatment of BatteryPass as a specific assessed release, v1.2.0, rather than as an unversioned live source.
Table 2. CE-RISE modules included in the full battery DPP assessment profile.
| Assessment module | Repository | Version |
|---|
|
dp_record_metadata
| dp-record-metadata
| v0.0.2 |
|
dp_access_and_governance
| dp-access-and-governance
| v0.0.3 |
|
dp_record_custody
| dp-record-custody
| v0.0.3 |
| product_profile
| product-profile
| v0.0.3 |
| material_profile
| material-profile
| v0.0.1 |
|
traceability_and_life_cycle_events
| traceability-and-life-cycle-events
| v0.0.3 |
|
usage_and_maintenance
| usage-and-maintenance
| v0.0.2 |
| diagnostic_results
| diagnostic-results
| v0.0.3 |
| integrated_lca
| integrated-lca
| v0.0.3 |
|
circularity_and_eol
| circularity-and-eol
| v0.0.3 |
|
compliance_and_standards
| compliance-and-standards
| v0.0.3 |
|
re_indicators_specification
| re-indicators-specification
| v0.0.5 |
The CE-RISE sources are therefore not treated as an abstract live endpoint in this assessment. The demonstration records the concrete model version used for each module, while the archived composition profile provides the exact SHACL source URLs used to rerun DP-AWB.
The right ecosystem is the BatteryPass v1.2.0 data model ecosystem.9 BatteryPass is distributed as SAMM/RDF Turtle model sources rather than official SHACL shapes. For this assessment, those Turtle sources were converted into inferred SHACL proxy files so that both ecosystems could be assessed through the same SHACL-based workflow. This proxy status is a methodological limitation and is reported explicitly.
5.3 Structural assessment results
Table 3 summarises the structural assessment results emitted by the DP-AWB assess tool for the two composition profiles. The metrics are model-level signals, not validation results over passport instance data.
Table 3. Structural assessment snapshot for the battery DPP demonstration.
| Profile | Modules | Node shapes | Property shapes | Typed share | Bounded share |
|---|
| CE-RISE full battery DPP | 12 | 1515 | 4321 | 0.984 | 0.862 |
| BatteryPass proxy | 7 | 41 | 154 | 1.000 | 1.000 |
The terms used in the table have the following meaning. A module is one SHACL model source included in the assessed profile. A node shape is a SHACL definition of the constraints that apply to an entity or class of objects, for example a product, material, diagnostic result, or lifecycle event. A property shape is a SHACL constraint on one field or relationship of such an entity. The typed property share is the fraction of property shapes that explicitly constrain the kind of value expected, for example through a datatype, class, node shape, or node-kind constraint. The cardinality-bounded property share is the fraction of property shapes with explicit occurrence constraints, such as minimum or maximum counts. Both shares range from 0 to 1. Higher values mean that more properties are explicit in the SHACL model; they do not by themselves mean that a model is better or more complete for a specific application.
The CE-RISE ecosystem is much broader structurally, with 12 modules, 1515 node shapes, and 4321 property shapes. This reflects its role as a wider DPP model ecosystem covering passport infrastructure, lifecycle information, diagnostics, LCA, compliance, circularity, and RE indicators. The BatteryPass proxy is smaller, with 7 modules, 41 node shapes, and 154 property shapes, which is consistent with a focused battery-sector content model. The typed property shares are high in both profiles, meaning that most constrained fields and relationships carry explicit value-type information. The cardinality-bounded share is complete in the BatteryPass proxy and high, but lower, in CE-RISE. This indicates that the BatteryPass proxy is more uniformly bounded in the inferred SHACL representation, while CE-RISE leaves some properties more open across a broader model ecosystem. The difference is therefore interpreted as evidence of different modelling roles, not as a quality ranking.
5.4 Interoperability and maintainability results
Table 4 reports the assessment signals corresponding to the interoperability and maintainability perspectives. Interoperability is represented here by object-reference properties, cross-module references, and shared-vocabulary overlap. An object-reference property is a model field that points to another structured object rather than to a simple value such as text or a number. Shared-vocabulary overlap counts terms that appear to be reused or shared across the compared model evidence. Maintainability is represented by deterministic findings emitted by DP-AWB, in this case redundancy candidates.
Table 4. Interoperability and maintainability signals from the structural assessment.
| Profile | Object refs | Cross-module refs | Shared vocab items | Shared vocab ratio | Findings |
|---|
| CE-RISE full battery DPP | 656 | 6 | 60 | 0.020 | 132 |
| BatteryPass proxy | 37 | 0 | 43 | 0.082 | 2 |
The interoperability signals show different modelling architectures. CE-RISE has many more object-reference properties because it is a larger modular ecosystem, and it contains a small number of explicit cross-module references. BatteryPass has fewer object-reference properties and no cross-module references in the inferred proxy, which is consistent with a more compact sector model. Its shared-vocabulary ratio is higher because a smaller vocabulary contains a larger relative share of terms overlapping with the comparison evidence. The maintainability findings are redundancy candidates rather than validation errors. Their much larger number in CE-RISE mainly reflects the larger model surface and repeated constraint patterns across modules; they identify review targets, not defects by themselves.
5.5 Coverage results
The battery DPP use case combines required information items and required joins.
Table 5 reports the coverage classification counts.
Table 5. Coverage evidence for the full battery DPP use case.
| Profile | Direct | Partial | Indeterminate | No direct |
|---|
| CE-RISE full battery DPP | 17 | 19 | 45 | 0 |
| BatteryPass proxy | 29 | 14 | 28 | 10 |
BatteryPass has stronger direct evidence for core battery passport content, including product identity, battery category, carbon footprint, material composition, circularity, performance and durability, and labelling. CE-RISE has broader evidence for passport governance, custody, traceability, lifecycle events, usage and maintenance, diagnostics, integrated LCA, compliance, circularity and end-of-life information, and RE indicators. BatteryPass has explicit gaps for broader application capabilities such as calculation evidence, diagnostic results, maintenance information, responsible sourcing assurance, and usage history. CE-RISE has many indeterminate findings where the broad model ecosystem contains related evidence but battery-specific mapping needs clarification.
5.6 Alignment and integration results
The alignment step connects the comparison to an integration decision. Structural and coverage metrics show how the two ecosystems differ, but they do not by themselves say which concepts should be treated as the same when the models are combined. For that purpose, DP-AWB accepts an analyst-authored alignment file: a human-reviewed list of candidate equivalences between model entities found on the two sides. Here, an entity means a SHACL node shape or property shape, such as a product identifier property, a material-composition shape, or an end-of-life-information shape; it does not mean a whole model module such as product-profile
.
In this demonstration, an overlap pair means one CE-RISE entity and one BatteryPass proxy entity that may represent the same application concept. A strict application-level overlap means that the pair was judged equivalent for the battery DPP use case, not merely related by topic or wording.
The workflow was therefore: first compile a bounded seed alignment from the assessed model evidence, then review it manually for semantic strictness, then rerun the DP-AWB comparison with the reviewed alignment. The seed alignment is not an exhaustive claim that no other overlaps exist; it is the set of candidate equivalences selected for this demonstration and can be extended in later review cycles. The seed alignment contained 18 candidate equivalences. Review retained 14 strict overlap pairs and excluded four weaker pairs: a related-passport identifier, two spare-parts information pairs, and a broad compliance-statement pair. DP-AWB then checked whether the 14 retained pairs were actually present in the assessed traces on both sides. All 14 were present, giving an alignment coverage ratio of 1.0 for the reviewed alignment. This ratio measures coverage of the declared reviewed alignment, not recall over all possible CE-RISE–BatteryPass overlaps.
DP-AWB then used the reviewed alignment to produce a composition recommendation. In this context, a composition recommendation is not an automatic merge of the models. It is a proposed combined profile plus review items that make duplicate or overlapping entities explicit before implementation. The recommended candidate composition retained 19 modules: all 12 CE-RISE modules and all 7 BatteryPass proxy modules. DP-AWB emitted 14 entity recommendations and 14 deduplication review items, with BatteryPass preferred for reviewed sector-specific duplicates. A deduplication review item is a signal that two aligned entities should not be implemented twice without an explicit modelling decision. The interpretation is a layered composition: CE-RISE remains the broader DPP application and infrastructure layer, while BatteryPass is reused for reviewed battery-sector content overlaps.
6. Discussion
The demonstration shows that DP-AWB is useful when the goal is not to promote one model ecosystem over another, but to make their roles, overlaps, and gaps explicit. The CE-RISE and BatteryPass ecosystems are complementary rather than simply competing. A score-only comparison would obscure this. DP-AWB instead exposes structural scale, explicitness, coverage classes, semantic overlaps, prioritised gaps, and integration candidates.
For CE-RISE development, the assessment points to areas where battery-specific mappings or constraints should be clarified, especially around battery chemistry, carbon-footprint concepts, calculation evidence, compliance declarations, dismantling information, and hazardous-substance information. For BatteryPass reuse, the assessment supports its role as a compact sector-specific content layer while making explicit that broader lifecycle, diagnostic, maintenance, and governance functions require additional model support.
DP-AWB supports application scoping by making required coverage, indeterminate evidence, redundancy candidates, and duplicate integration candidates explicit. These signals help analysts decide which parts of a broader model ecosystem should be retained, reviewed, or left out of an application-specific composition. This is preferable to requiring users to enumerate excluded information in advance, because in large model ecosystems such exclusions would be difficult to define reliably before the assessment evidence is available.
The main limitation is that this assessment is SHACL-only and model-level. It does not validate real instance datasets. A second limitation is the inferred SHACL proxy used for BatteryPass, which is necessary for a common SHACL assessment but is not an official BatteryPass SHACL publication. A third limitation is the snapshot character of the demonstration: it compares the selected CE-RISE module versions available at assessment time with BatteryPass v1.2.0, so it should be interpreted as a reproducible assessment snapshot rather than a permanent comparison of the ecosystems. These limitations are also strengths of the workflow: they are documented as reproducible inputs and can be rerun as the models mature.
7. Conclusions
DP-AWB provides a reproducible instrument panel for Digital Passport model ecosystems. It supports model assessment before mature instance datasets exist, formalises use-case coverage as required items and joins, compares assessed ecosystems, records analyst-reviewed alignments, prioritises improvement targets, and produces integration recommendations. The battery DPP demonstration shows that the tool can turn a complex model comparison into actionable evidence: CE-RISE provides broader DPP infrastructure, BatteryPass provides focused battery-sector content, and a combined composition can be recommended with explicit deduplication review items. Future work will extend the model-level workflow with data-driven validation of instance datasets, recurring violation analysis, constraint activation metrics, and information-preservation analysis for mappings between external models.
Author contributions
Riccardo Boero: conceptualisation, software, methodology, investigation, data curation, validation, visualisation, writing–original draft, writing–review and editing. Miguel Las Heras Hernández: conceptualisation, methodology, writing–review and editing.
Software availability
Software available from: PyPI. dpawb. https://pypi.org/project/dpawb/.
Source code available at: https://codeberg.org/CE-RISE-software/dp-assessment-workbench.
Zenodo, archived source code at: https://doi.org/10.5281/zenodo.20024117.10
Documentation available at: https://ce-rise-software.codeberg.page/dp-assessment-workbench/.
This project contains the following underlying software:
• dpawb v0.1.2 (DP Assessment Workbench Python package)
• io.github. CE-RISE-software/dpawb (MCP server; OCI image ghcr.io/ce-rise-software/dpawb-mcp:0.1.2, stdio transport, registered at https://registry.modelcontextprotocol.io/)
Software is available under the terms of the EUPL-1.2 license.
Ethics and consent
Ethical approval and consent were not required.
AI tool use
The authors used OpenAI ChatGPT and OpenAI Codex, based on the GPT-5 model, during manuscript preparation. These tools were used to support language editing, manuscript structuring, wording of the plain-language summary, preparation of submission metadata, and conversion checks between LaTeX and DOCX. The tools were not used to produce the deterministic assessment results reported in the article, to alter the underlying DP-AWB outputs, or to make final scientific judgements. The authors reviewed and edited the AI-assisted text and take full responsibility for the content of the manuscript.
Data availability
Zenodo. Battery DPP Demonstration Assessment Artefacts. https://doi.org/10.5281/zenodo.20024117.10
This project contains the following underlying data:
• assessment/profiles/ (Composition profiles used in the battery DPP assessment)
• assessment/use_cases/ (Battery DPP use-case file)
• assessment/converted/batterypass/1.2.0/ (BatteryPass-to-SHACL conversion script and generated SHACL proxy files)
• assessment/alignments/ (Reviewed alignment files)
• assessment/results/ (Persisted DP-AWB JSON result documents)
• assessment/replication-notes.md (Replication notes)
Data is available under the terms of the Creative Commons Attribution 4.0 International license.
Acknowledgements
The authors acknowledge the CE-RISE consortium and the developers and maintainers of the public CE-RISE and BatteryPass model resources used in the demonstration.
References
- 1.
CE-RISE Consortium:
CE-RISE: Circular economy resource information system.
Accessed 2026-04-30.
Reference Source
- 2.
European Commission:
Circular economy resource information system (CE-RISE) project fact sheet.
Grant agreement ID 101092281. accessed 2026-04-30. Publisher Full Text
Reference Source
- 3.
Boero R:
dpawb: SHACL-based analytical workbench for digital passport model assessment and use-case coverage.
Version 0.1.2; EUPL-1.2; Python >=3.12; accessed 2026-04-30.
Reference Source
- 4.
Boero R:
Digital Passport Assessment Workbench MCP server.
OCI image ghcr.io/ce-rise-software/dpawb-mcp:0.1.2; registry name io.github. CE-RISE-software/dpawb; transport stdio.
Accessed 2026-04-30.
Reference Source
- 5.
Model Context Protocol Contributors:
Official model context protocol registry.
Accessed 2026-04-30.
Reference Source
- 6.
Boero R:
Digital Passport Model Assessment Workbench documentation.
Accessed 2026-04-30.
Reference Source
- 7.
Boero R:
Digital Passport Model Assessment Workbench.
Zenodo.
2026. Publisher Full Text
Reference Source
- 8.
CE-RISE Consortium:
CE-RISE model repositories.
Repository tags queried via the Codeberg API on 2026-05-04.
Reference Source
- 9.
Battery Pass Project:
Battery pass data model v1.2.0.
Accessed 2026-04-30.
Reference Source
- 10.
Boero R, Las Heras Hernández M:
DP-AWB battery digital product passport model ecosystem assessment: replication package (v0.1).
Zenodo.
2026. Publisher Full Text
