Quellstrukturen in Passstrukturen

Any2DPP

Ein neues Quellsystem an einen Produktpass anzubinden, sollte nicht bedeuten, neuen Code zu schreiben, und was immer es bedeutet: Das Ergebnis muss sagen, welche Version welcher Abbildung welches Feld erzeugt hat.

Status: Forschungskonzept · unveröffentlichter Prototyp

Any2DPP und AnyDPP

Any2DPP bildet ab und validiert. Es stellt nichts aus.

AnyDPP verantwortet die durchgängige Demonstration: Einlesen, Entscheidung, Zusammenstellung und den veröffentlichten Pass.

Sie treffen sich in einem Adapter. Any2DPP validiert gegen das von AnyDPP selbst festgelegte Schema UNTP 0.7.0 statt gegen eine Kopie davon und kann einen freigegebenen Lauf nur dann an den Composer von AnyDPP übergeben, wenn die Quelle des Laufs eine Korridor-Rückverfolgung ist.

Die Forschungsfrage

Wie lassen sich heterogene Quellstrukturen in ein DPP-kompatibles Zielmodell überführen, ohne Herkunft, Bedeutung oder die Verbindung zur Evidenz zu verlieren, in einer Form, die eine Person prüfen kann?

Wie wird dieses Quellfeld zu jenem Zielfeld?
Welche Abbildungsversion hat es erzeugt?
Was fehlt, und kommt es darauf an?
Welche Evidenz steht hinter jedem Feld?

Das Modell, interaktiv

Ein Lieferantenexport auf Portugiesisch, auf Passfelder abgebildet. Dies sind die Definition und die Quelle aus den eigenen Tests des Moduls. Wählen Sie eine Regel, um ein Feld durchzuverfolgen, oder wechseln Sie die Abbildungsversion, um zu sehen, was sich geändert hat.

Abbildungsversionsupplier-export v1 (veröffentlicht)supplier-export v2 (Entwurf)

Quelle wie exportiertLand als CodeLand ausgeschrieben

Quellstruktur

produto.nome" café ARÁBICA "
produto.pais"br"
produto.data"04/05/2026"
produto.peso"1.200,50"
observacoes"nada"Von keiner Regel gelesen

Abbildungsregeln

Zielstruktur

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

Vollständigkeit

2 von 2 Pflichtfeldern · 3 von 3 optionalen Feldern

Alle Pflichtfelder vorhanden. Die Struktur kann gegen das Schema validiert und von einer Person freigegeben werden.

Grundbausteine

Abbildungsdefinition
MappingDefinition
Eine Regel pro Zielfeld. Daten, kein Code, beim Laden validiert: Eine unbekannte Transformation scheitert beim Laden, nicht still zur Laufzeit.
Feldregel
FieldRule
Ein Quellpfad oder eine Konstante, eine Transformation, Pflicht oder optional, die Evidenzquelle hinter dem Wert und eine Bezeichnung, die eine Person lesen kann.
Geschlossene Liste von Transformationen
Transform
trim, upper, lower, title, iso_date, decimal, country_code. Eine hinzuzufügen ist ein bewusster Schritt mit einem Test; es gibt keine Ausdruckssprache.
Unveränderliche Version
draft → published → retired
Eine veröffentlichte Abbildung kann sich nie ändern. Eine Änderung ist eine neue Version unter demselben Namen, und jeder Lauf erfasst die Version, die ihn erzeugt hat.
Diagnose je Feld
Diagnostic
Abgebildet, Konstante, fehlend oder Transformation fehlgeschlagen, neben dem Feld, dazu die Quellfelder, die keine Regel liest, und Zählungen zur Vollständigkeit.
Freigabe durch eine Person
compose.handoff
Der Moment, in dem eine Ausgabe aufhört, intern zu sein, ist die Entscheidung einer Person, erfasst als Befugnisakt. Eine Maschine wählt ihn nicht.

Ein Szenario, Schritt für Schritt

Vom Export eines Lieferanten zu einer Struktur, die einen Pass speisen könnte.

Schritt 1 von 6: Die Abbildung als Daten schreiben

Regeln für Name, Ursprungsland, Produktionsdatum und Masse, jede mit einer Transformation und, wo es darauf ankommt, der Evidenzquelle.
Die Abbildung wird auf ein Beispiel angewendet. Die Vorschau schreibt nichts, sodass ein Entwurf so oft wie nötig ausprobiert werden kann.
Die Version wird eingefroren. Ab hier hat eine Frage wie „Warum hat dies jenes ergeben?“ immer eine Antwort.
Die Quelle wird gehasht in die Kette aufgenommen, jede Regel erzeugt ihre Diagnose, und das Ergebnis wird gegen das festgelegte UNTP-Schema validiert.
Eine Person gibt den Lauf frei. Ein fehlgeschlagener Lauf kann nicht freigegeben werden; ein freigegebener Lauf behält seine Freigabe, auch wenn die Übergabe abgelehnt wird.
Ein Lauf, dessen Quelle eine Korridor-Rückverfolgung ist, geht an den Composer von AnyDPP. Jede andere Quelle wird mit Begründung abgelehnt, nicht zusammengestellt.

Was existiert und was nicht

Im Repository

app/products/any2dpp/mapping.py: Definition, geschlossene Transformationen, Diagnosen je Feld, Vollständigkeit, ungelesene Quellfelder
service.py: anlegen, Entwurf bearbeiten, veröffentlichen, zurückziehen, Vorschau, ausführen, Freigabe anfordern, freigeben, übergeben
adapters/anydpp.py: die eine Datei, die AnyDPP erreicht, für sein festgelegtes Schema und seinen Composer
Tabellen any2dpp_mappings und any2dpp_runs; 14 authentifizierte Routen
tests/any_family/test_any2dpp.py: Engine, Unveränderlichkeit, die Freigabeschranke, der reale AnyDPP-Adapter (31 Tests)

Forschungsagenda, nicht gebaut

Introspektion des Quellschemas: Die Quelle ist eine Nutzlast, und nichts leitet ihre Form ab
Eine kanonische Zwischendarstellung zwischen Quelle und Ziel
Vokabularabbildung und Einheitenumrechnung über die benannten Transformationen hinaus
Listen und Kardinalität: Pfade sind punktgetrennte Schlüssel in Objekte, vorerst bewusst so
Diffs zwischen Abbildungsversionen und Migration zwischen Versionen des Zielprofils
Eine geführte Erstellungsoberfläche: Vorschau und Diagnosen existieren, der mehrstufige Editor nicht
Die Zusammenstellung eines Passes aus einer beliebigen Quelle: Der Composer von AnyDPP liest laut seinem eigenen Vertrag eine Rückverfolgung

Was es unterscheidet

AnyDPP

Seine Frage

Wie funktioniert eine vollständige Pipeline von der Evidenz zum Pass?

Warum dies nicht dasselbe ist

AnyDPP liest die Quellen, für die es Extraktoren hat. Any2DPP untersucht, wie eine beliebige Quellstruktur dem System als prüfbarer, versionierter Vertrag beschrieben wird.

AnyTrace

Seine Frage

Wo hat sich diese Sache befunden?

Warum dies nicht dasselbe ist

Any2DPP bindet abgebildete Felder an Rückverfolgungsevidenz; es verfolgt nicht die Sache selbst.

AnyVerify

Seine Frage

Stützt die Evidenz diese Aussage?

Warum dies nicht dasselbe ist

Ein abgebildetes Feld ist ein wohlgeformtes Feld, kein verifiziertes.

Wo es in AnyLAI steht

Any2DPP

AnyDPPValidiert gegen das festgelegte Schema UNTP 0.7.0 von AnyDPP und übergibt Läufe aus Rückverfolgungen über einen Adapter an dessen Composer.
AnyTraceEin Lauf verknüpft sich mit dem Rückverfolgungsfall, dessen Daten er abbildet; Felder sind an die Evidenz dieser Rückverfolgung gebunden.
Application kernelLäufe sind Fälle des Kerns; der Quell-Hash liegt auf der Kette; die Freigabe ist ein Befugnisakt.
COADFRegelwissen als Daten, Laden nach Default-Deny und ein deterministischer Pfad ohne Sprachmodell: die Prinzipien von COADF, angewendet, ohne eine Übereinstimmung zu behaupten.

Fallverknüpfung über den Kern
direkte Nutzung eines anderen Moduls oder Systems
Aufruf im Schattenmodus: erfasst, nie ausgeführt

Grenzen und Nicht-Ziele

Es stellt nie einen Pass aus, signiert keinen und veröffentlicht keinen.
Der Passstandard gehört nicht ihm; es prüft gegen das Schema, das AnyDPP festlegt.
Es kann nur Läufe übergeben, deren Quelle eine Korridor-Rückverfolgung ist.
Ein Feld, das sich sauber abbilden lässt, ist wohlgeformt, nicht wahr.

Aktueller Stand

Forschungsstand

Forschungskonzept · unveröffentlichter Prototyp
Unveröffentlicht: Routen abgeschaltet
Kein Produktivbetrieb, keine realen Daten
31 Tests im Repository

Ein Prototyp-Modul über dem gemeinsamen Kern: Abbildungs-Engine, Service, Adapter, Tabellen, Routen und Tests. Abgeschaltet, nicht veröffentlicht, nicht mit realen Lieferantendaten genutzt. Die Forschungsagenda oben ist größer als das, was existiert, und wird als Agenda aufgeführt.

Testsuite: python-backend/tests/any_family/test_any2dpp.py

Forschungsprojekt · Unabhängige F&E · Kein kommerzielles Angebot