Skip to content

Independent R&D project · Cologne

AnyLAI

Applied research overview

Source structures into passport structures

Any2DPP

Connecting a new source system to a product passport should not mean writing new code, and whatever it means, the result has to say which version of which mapping produced which field.

Status: Research concept · unpublished prototype

Any2DPP and AnyDPP

Any2DPP maps and validates. It issues nothing.

AnyDPP owns the end-to-end demonstration: ingestion, decision, composition and the published passport.

They meet in one adapter. Any2DPP validates against AnyDPP's own pinned UNTP 0.7.0 schema rather than a copy, and can hand a released run to AnyDPP's composer only when the run's source is a corridor trace.

The research question

How can heterogeneous source structures be transformed into a DPP-compatible target model without losing provenance, meaning or the link to evidence, in a form a person can review?

  • How does this source field become that target field?
  • Which mapping version produced it?
  • What is missing, and does it matter?
  • Which evidence stands behind each field?

The model, interactively

A supplier export in Portuguese, mapped to passport fields. These are the definition and source used in the module's own tests. Select a rule to follow one field through, or switch mapping versions to see what changed.

Mapping version
Source as exported

Source structure

  • produto.nome" café ARÁBICA "
  • produto.pais"br"
  • produto.data"04/05/2026"
  • produto.peso"1.200,50"
  • observacoes"nada"Not read by any rule

Mapping rules

Target structure

  • type"DigitalProductPassport"
  • credentialSubject.product.name"Cafe Arabica"Evidence: supplier-export
  • credentialSubject.product.originCountry"BR"Evidence: supplier-export
  • credentialSubject.product.producedOn"2026-05-04"
  • credentialSubject.product.mass"1200.50"

Completeness

2 of 2 required · 3 of 3 optional

All required fields present. The structure can be validated against the schema and released by a person.

Core primitives

  • Mapping definition

    MappingDefinition

    One rule per target field. Data, not code, validated on load: an unknown transform fails at load, not silently at run time.

  • Field rule

    FieldRule

    A source path or a constant, one transform, required or optional, the evidence source behind the value, and a label a person can read.

  • Closed transform list

    Transform

    trim, upper, lower, title, iso_date, decimal, country_code. Adding one is a deliberate act with a test; there is no expression language.

  • Immutable version

    draft → published → retired

    A published mapping can never change. A change is a new version under the same name, and every run records the version that produced it.

  • Per-field diagnostic

    Diagnostic

    Mapped, constant, missing or transform failed, beside the field, plus the source fields no rule reads and completeness counts.

  • Human release

    compose.handoff

    The moment output stops being internal is a person's decision, recorded as an authority act. A machine does not choose it.

One scenario, step by step

From a supplier's export to a structure that could feed a passport.

Step 1 of 6: Write the mapping as data

  1. Rules for name, origin country, production date and mass, each with a transform and, where it matters, the evidence source.

  2. The mapping is applied to a sample. Preview writes nothing, so a draft can be tried as often as needed.

  3. The version is frozen. From here, a question like "why did this produce that" always has an answer.

  4. The source is hashed into the chain, each rule produces its diagnostic, and the result is validated against the pinned UNTP schema.

  5. A person releases the run. A failed run cannot be released; a released run keeps its release even if the handoff is refused.

  6. A run sourced from a corridor trace goes to AnyDPP's composer. Any other source is refused with a reason, not composed.

What exists, and what does not

In the repository

  • app/products/any2dpp/mapping.py: definition, closed transforms, per-field diagnostics, completeness, unread source fields
  • service.py: create, edit draft, publish, retire, preview, run, request release, release, hand off
  • adapters/anydpp.py: the one file that reaches AnyDPP, for its pinned schema and its composer
  • any2dpp_mappings and any2dpp_runs tables; 14 authenticated routes
  • tests/any_family/test_any2dpp.py: engine, immutability, the release gate, the real AnyDPP adapter (31 tests)

Research agenda, not built

  • Source schema introspection: the source is a payload, and nothing infers its shape
  • A canonical intermediate representation between source and target
  • Vocabulary mapping and unit conversion beyond the named transforms
  • Lists and cardinality: paths are dotted keys into objects, by design for now
  • Diffs between mapping versions and migration between target profile versions
  • A guided authoring screen: preview and diagnostics exist, the multi-step editor does not
  • Composing a passport from an arbitrary source: AnyDPP's composer reads a trace, by its own contract

What makes it different

AnyDPP

Its question

How does a complete evidence-to-passport pipeline work?

Why this is not that

AnyDPP reads the sources it has extractors for. Any2DPP studies how any source structure is described to the system as a reviewable, versioned contract.

AnyTrace

Its question

Where has this thing been?

Why this is not that

Any2DPP binds mapped fields to trace evidence; it does not follow the thing itself.

AnyVerify

Its question

Does the evidence support this claim?

Why this is not that

A mapped field is a well-formed field, not a verified one.

Where it sits in AnyLAI

Any2DPP

  • AnyDPPValidates against AnyDPP's pinned UNTP 0.7.0 schema and hands trace-sourced runs to its composer, through one adapter.
  • AnyTraceA run links to the trace case whose data it maps; fields are bound to that trace's evidence.
  • Application kernelRuns are kernel cases; the source hash is on the chain; the release is an authority act.
  • COADFRule knowledge as data, default-deny loading and a deterministic path with no language model: COADF's principles, applied, without a conformance claim.
  • case link through the kernel
  • direct use of another module or system
  • shadow-mode call: recorded, never executed

Limits and non-goals

  • It never issues, signs or publishes a passport.
  • It does not own the passport standard; it checks against the schema AnyDPP pins.
  • It can hand off only runs sourced from a corridor trace.
  • A field that maps cleanly is well-formed, not true.

Current state

Research status

  • Research concept · unpublished prototype
  • Unpublished: routes switched off
  • No production use, no real data
  • 31 tests in the repository

A prototype module over the shared kernel: mapping engine, service, adapter, tables, routes and tests. Switched off, not published, not used on real supplier data. The research agenda above is larger than what exists, and is listed as agenda.

Test suite: python-backend/tests/any_family/test_any2dpp.py

Research project · Independent R&D · Not a commercial offering