Skip to content
Luiz Hogrefe

Any2DPP

Research prototype on mapping source data into passport structures

Research prototype · unpublished

How can heterogeneous source data become a structure compatible with a digital product passport without losing provenance, meaning or the link to evidence, in a form a person can review?

Overview

31tests in the repository

Any2DPP describes how source data from ERP or PLM exports, XML, JSON, CSV or APIs maps onto a passport structure, as a declarative mapping with a version. A run applies the mapping, reports per field what happened, and validates the result against the passport schema.

A person reviews the preview before anything is released. A field that maps cleanly is well-formed, not true.

The six prototypes share one application kernel in the AnyLAI repository: cases, a hash-chained event timeline, evidence with provenance and three timestamps, tasks and authority acts. Each prototype adds only its own vocabulary and rules.

A mapping, field by field

A mapping, field by field
mapping v3 · publishedcompleteness: 83%

ERP export · CSV

Passport structure

TRIM
product.idmapped
COUNTRY_CODE
countryOfProductionmapped
ISO_DATE
productionDatemapped
DECIMAL
netWeightmapped
TRIM
manufacturer.namemapped
missing
recycledContentmissing

mappedconstantmissingtransform failed

Hover or focus a field to see where it comes from and what happened to it.

Text description of the diagram

On the left, five fields of an ERP export: material number, country, production date, weight in kilograms and supplier. On the right, six fields of a passport structure: product identifier, country of production, production date, net weight, manufacturer name and recycled content. Lines connect them through transforms: trim, country code, ISO date and decimal. Recycled content has no source and is reported as missing.

Building blocks

  • Mapping

    A versioned declaration from source fields to target fields. Once published it cannot change; a new version replaces it.

  • Transform

    A closed list of conversions, such as trimming text, ISO dates, decimals and country codes.

  • Field diagnostic

    Per target field: mapped, constant, missing or transform failed.

  • Run

    One application of a mapping: MAPPED, FAILED, HANDED_OFF or RELEASED.

  • Human release

    A reviewer releases a run after seeing its preview and completeness.

A CSV export

  1. 1

    A manufacturer exports materials from its ERP system as CSV.

  2. 2

    Mapping version 3 converts the country to a two-letter code and the date to ISO format.

  3. 3

    The run reports five fields mapped and recycled content missing, and validates the structure against the schema.

  4. 4

    A reviewer sees the gap and does not release the run until a source for recycled content is added.

How it differs from AnyDPP

  • Any2DPPAnyDPPResearch and demonstration environment

    AnyDPP uses source-specific extraction for a demonstrated corridor and is where a passport is composed and issued. Any2DPP researches generic, declarative mappings and never issues, signs or publishes a passport. The two meet at one adapter that validates against AnyDPP's own schema.

    AnyDPP
  • Any2DPPAnyVerifyResearch prototype · unpublished

    AnyVerify checks whether evidence supports a value. Any2DPP only checks that a value is well-formed in its target.

    AnyVerify

Status

Research prototype · unpublished

Research prototype in the AnyLAI repository, unpublished and not deployed. The boundary to AnyDPP is real but narrow: a run can be handed to AnyDPP only when its source is one of AnyDPP's own ingest traces.

Limitations

  • No schema introspection, unit conversion, cardinality handling or semantic vocabulary mapping yet.
  • Never issues, signs or publishes a passport, and does not own the standard.
  • Well-formed is not true: mapping does not verify content.

Back to Projects