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.
Digital Product Passport research contains related but distinct strands. Ecosystem and architecture work frames the passport as a socio-technical system spanning actors, lifecycle stages, information governance, and technical interoperability.3 Other work develops cross-sectoral DPP ontology networks and SHACL shapes for data quality and validation,4 while DPP-system requirements research addresses the operational infrastructure needed to collect, govern, and exchange lifecycle data.5 These contributions motivate interoperable formal models and operational DPP systems, but they have different objectives from assessing alternative model specifications before representative data are available.
SHACL itself is a W3C language for validating a data graph against a shapes graph.6 Ontology-quality assessment and schema/ontology matching research likewise provide established methods for evaluating knowledge models or inferring correspondences.7–9 DP-AWB is complementary to these approaches: it does not propose another DPP schema, infer semantic equivalence, or execute conformance checking over instance data. Instead, it analyses the structure and declared constraints of shape graphs, applies a deliberately limited lexical-structural coverage procedure, and produces reproducible comparison and integration-review evidence. To our knowledge, this combination of shape-graph assessment, use-case coverage evidence, reviewed alignments, and composition guidance has not previously been provided for DPP model ecosystems.
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”.10
•
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.11,12
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. |
Every operation emits a persisted JSON result document with result_type, inputs, content, and diagnostics fields. For example, a coverage result records an overall coverage class plus one finding per required item and join; each finding includes its coverage class, explanatory adequacy note, and supporting SHACL trace (matched paths, owner shapes, target classes, and reference targets). The complete machine-readable results used in this article are deposited with the replication package,17 so readers can inspect both the output values and the evidence used to derive them.
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.1.1 Core metric and rule definitions
For reproducibility, let P be the set of property shapes in the composed profile and C the number of SHACL constraint statements attached to them, counted over the workbench released constraint-predicate set. Constraint density is C/|P|(defined as 0 when |P|= 0). It is therefore a count of declared constraints per property shape, not a measure of model quality or regulatory compliance.
For a module m, let V_m be the set of URI IRIs occurring as a subject, predicate, or object in its RDF triples. With U = union(V_m) and R = {v in U: v occurs in more than one V_m}, the shared-vocabulary ratio is |R|/|U| (defined as 0 when U is empty). It measures literal IRI reuse across the supplied modules; it is not label similarity or evidence of semantic equivalence.
Redundancy candidates are calculated within, not across, modules. A candidate group is emitted only when two or more property shapes share the same non-empty six-element signature: (sh:path, sh:datatype, sh:class, sh:node, sh:minCount, sh:maxCount). It is a conservative inspection signal, rather than a determination that the repeated shapes are modelling errors.
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. 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.
Coverage matching is a deterministic lexical-structural procedure, not semantic matching. For each required item, DP-AWB normalises and tokenises its identifier and label, then compares those tokens with the IRIs, labels, property paths, owner shapes, and target classes declared in SHACL. It splits compound identifiers (for example camelCase) and applies a small, explicit set of lexical variant groups, including identifier/id, category/classification, and manufacturer/operator/producer/actor. A direct item match requires every core required token, including an approved lexical variant, to be found; lower token overlap, or a match with weak structural support, yields partial or indeterminate evidence.
The procedure does not perform ontology reasoning, embedding or LLM-based similarity, external-vocabulary lookup, or general semantic-equivalence determination. A required join is direct only when the matched items occur in a shared owner shape or have an explicit object-reference path; otherwise it remains partial or indeterminate. The resulting coverage classes are deliberately conservative evidence classes rather than claims that concepts are semantically equivalent or that a model can represent all instance-level data. Declared equivalences used for deduplication remain analyst-authored and are reviewed separately (Section 3.3).
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.
3.4 Decision rules and boundary of recommendations
The comparison operation first requires the same declared comparison scope on both inputs. It computes a delta for each shared structural metric and orders non-zero observations by a fixed signal priority and normalized absolute delta; it does not calculate an overall quality score or select a universally better model. When an alignment file is supplied, the operation only checks whether each analyst-declared pair is present on the left and right traces. The reported alignment coverage ratio is therefore bilateral declared-pair presence divided by the number of declared pairs, not an estimate of alignment recall or completeness.
Prioritisation is a deterministic follow-up queue with no learned model, hidden weights, or expert-derived numerical scoring. The current fixed rank bases are: not-representable coverage findings (1); partial or indeterminate coverage findings (2); contradictions or dangling references (3); unmatched declared alignment pairs (4); selected structural comparison signals (5); and redundancy candidates (6). Each result includes a rule trace explaining the trigger and the final list is ordered by that fixed basis and target identifier. The reported priority rank is the ordinal position after sorting by (fixed rank basis, target identifier); it is not a composite weighted score.
Composition recommendation is deliberately not an automatic merge or a validated deployment solution. It emits a candidate profile that retains the modules of both declared input profiles, then adds deduplication review items only for analyst-declared equivalence pairs. Coverage evidence determines a preferred side for such a pair, but DP-AWB does not generate transformation rules, canonical concepts, conflict-resolution rules, or executable mappings. Those implementation decisions require domain and system-integration review outside the current model-assessment scope. For each profile, coverage findings receive fixed values of 0 (not representable), 1 (indeterminate), 2 (partially representable), or 3 (representable); their sum divided by three times the number of findings is used only to choose the preferred side of an analyst-declared duplicate. Every input module is retained in the candidate profile.
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.13,14
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.
The battery use case is an author-defined analytical demonstration, not a claim to be an exhaustive regulatory checklist or an industrially validated requirements specification. Its required items and joins deliberately span identity, composition, performance, environmental, compliance, lifecycle, and circularity domains so that the tool can be exercised across the declared model scope. The versioned use-case file and application-scope note in the replication package make those choices inspectable and replaceable for another sector, regulation, or stakeholder-validated application.
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.15 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.16 BatteryPass is distributed as SAMM/RDF Turtle model sources rather than official SHACL shapes. For this assessment, the seven selected v1.2.0 Turtle modules 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.
The conversion is deterministic and is included, together with the copied source files and generated proxies, in the replication archive.17 It maps each SAMM Aspect and Entity to a SHACL NodeShape while retaining the original IRI; SAMM properties become SHACL property links with the original property IRI as sh:path. A SAMM optional flag becomes sh:minCount 0, otherwise sh:minCount 1 is asserted, and non-list characteristics receive sh:maxCount 1. Characteristics are resolved to XSD datatype or class/node constraints; list element characteristics, enumerations, regular-expression constraints, range bounds, inheritance, labels, descriptions, examples, units, and source links are retained or mapped to corresponding SHACL constraints or trace annotations.
The proxies therefore preserve the available source structure and constraint information but are not official BatteryPass SHACL publications. In particular, inferred cardinalities and the SHACL rendering of SAMM constructs can affect shape-level metrics. We consequently interpret the BatteryPass values as a transparent, reproducible proxy assessment, not as an assertion about an official BatteryPass SHACL release; the archived converter can be rerun or reviewed as the source model evolves.17
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
Table 5 reports the coverage classification counts. The battery DPP use case combines 81 required-item and required-join findings. Table 5 reports the resulting lexical-structural coverage evidence. “Direct” means that the deterministic procedure found the required token evidence and, where applicable, adequate structural support; it is not a semantic coverage score.
Table 5. Lexical-structural 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 lexical-structural 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. These comparisons show differing model roles; they are not a semantic quality ranking.
The 45 indeterminate CE-RISE findings require further interpretation. Eleven are item-level findings for battery chemistry, calculation evidence, carbon-footprint concepts, compliance declarations, dismantling information, hazardous substances, manufacturing place, responsible-sourcing assurance, and performance concepts. In each case the model contains only partial lexical evidence under the deliberately narrow matching procedure. The finding does not mean that the information is absent; it identifies a candidate for a battery-specific mapping, a more precise use-case requirement, or a human semantic review.
The remaining 34 indeterminate findings are joins. Several have matched endpoint items but no shared owner shape or explicit object-reference path, while others inherit indeterminacy from one endpoint. This can reflect intentionally layered modules, an undeclared cross-module relationship, or a terminology mismatch; it is not evidence that the connection cannot be implemented. Accordingly, indeterminate results are a review queue, not failures. The appropriate next step is to inspect the persisted traces, add an explicit SHACL relationship or a narrowly documented analyst alignment where justified, and then rerun the assessment rather than recoding the result as a semantic match.
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, analyst-reviewed semantic overlap candidates, 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 interoperability signals in this article are intentionally bounded. Shared vocabulary, object references, and cross-module references are syntactic and structural indicators in the assessed shape graphs. They do not establish semantic interoperability, which requires justified concept mappings and agreement on units, lifecycle boundaries, and regulatory interpretation; nor do they establish operational interoperability, which requires runtime mechanisms for identity, access control, provenance, synchronization, and data exchange. DP-AWB can provide design-time evidence for those later activities, but it does not evaluate or implement them.
The main limitation is that this assessment is SHACL-only and model-level. It does not validate real instance datasets. A second limitation is that use-case coverage is a conservative lexical-structural procedure: it does not establish semantic equivalence, so terminology differences and implicit relationships can yield indeterminate results. A third 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 and includes documented conversion assumptions. A fourth 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 documented as reproducible inputs and can be revisited as the models and mappings mature. This version also does not benchmark DP-AWB against another tool, measure precision or recall against an expert gold standard, conduct an industrial user study, or report runtime and memory benchmarks. Those are distinct empirical evaluations and are planned future work; no scalability or operational-deployment claim is made here.
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 design-time decision evidence: CE-RISE provides broader DPP infrastructure, BatteryPass provides focused battery-sector content, and a combined candidate composition can be emitted 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.
