# ALIGNMENT_REVIEW_001

**Projekt:** Reconcilix  
**Review-Gegenstand:** WP1-001A — Domain Foundation und WP1-001B — Application Boundary  
**Baseline:** ADR002 V4, DM001 v0.5, DM002 v0.5 ED-LA, ME001 v0.2-alpha, ME002 v0.6  
**Review-Rolle:** ED  
**Status:** Draft v0.1  
**Datum:** 2026-07-23

---

## 1. Ziel und Scope

Dieses Review gleicht die Lieferungen

- `WP1-001A_Domain_Foundation`
- `WP1-001B_Application_Boundary`

gegen die aktuelle fachliche und architektonische Baseline von Reconcilix ab.

Geprüft wurden:

- die Domain Objects und Invarianten aus WP1-001A,
- die Application Boundary und Candidate-Discovery-Abstraktion aus WP1-001B,
- die zugehörigen Tests und Changelogs,
- die Übereinstimmung mit Provenienzmodell, Aggregate-Grenzen, Methodik und logischem Persistenzmodell.

Nicht geprüft wurden technische Persistenz, Migrationen, Repositorys und Runtime Composition, da diese nicht Bestandteil der beiden Lieferungen sind.

---

## 2. Bewertungsmaßstab

| Status | Bedeutung |
|---|---|
| ✅ Baseline-konform | Die Lieferung entspricht der aktuellen Baseline. |
| 🟡 Teilweise konform / Anpassung empfohlen | Die Grundrichtung stimmt; eine Ergänzung oder Präzisierung ist erforderlich. |
| 🔴 Nicht baseline-konform / Anpassung erforderlich | Die aktuelle Implementierung verletzt oder verfehlt eine verbindliche Baseline-Entscheidung. |
| ⚪ Außerhalb des Lieferumfangs | Der Punkt gehört zur Baseline, war aber nachvollziehbar nicht Gegenstand dieser Lieferung. |

Die Bewertung unterscheidet bewusst zwischen

1. **historisch nachvollziehbarer Abweichung** — die Lieferung entstand vor einer späteren Architekturentscheidung,
2. **aktuellem Alignment-Bedarf** — die Abweichung muss dennoch vor der nächsten Baseline-konformen Weiterentwicklung bereinigt werden.

---

## 3. Executive Summary

WP1-001A und WP1-001B bilden eine gute technische und fachliche Grundlage für den ursprünglichen Interpretation-and-Reconciliation-Kern. Besonders stabil sind:

- die Trennung von Domain, Application und Infrastructure,
- die Abstraktion der Candidate Discovery über einen Application Port,
- die Kapselung des Legacy-Systems im Adapter,
- grundlegende Invarianten für SourceValue, InterpretationGraph, InterpretationNode, CandidateItem und MatchDecision,
- die Beschränkung auf genau einen InterpretationGraph und eine Root Node im ersten Implementierungsschritt,
- die Vermeidung von Persistenzwissen im Domain Model.

Gegen die aktuelle Baseline bestehen jedoch mehrere strukturelle Abweichungen. Die wichtigsten sind:

1. Das vollständige Provenienzmodell `SourceSystem → SourceDelivery → SourceValue` fehlt.
2. `SourceValue.sourceDeliveryId` fehlt; damit ist Immutable Provenance nicht abbildbar.
3. `CandidateItem.sourceSystemUri` verwendet einen überholten und semantisch falschen Begriff; erforderlich ist `candidateProviderUri`.
4. `ReconciliationResult` wird als zweiter Aggregate Root behandelt, obwohl DM001 es innerhalb des `SourceValue` Aggregate verortet.
5. Der Application Service trimmt den Eingangswert und verletzt damit die Anforderung an den unveränderten Original Value.
6. `targetVocabularyUri` fällt ersatzweise auf `preferredEntityTypeUri` zurück; Entity Type und Target Vocabulary sind fachlich unterschiedliche Konzepte.
7. Der tatsächliche Entity Type und der Candidate Provider werden beim Mapping nicht übernommen.
8. Die Invariante „höchstens eine fachlich gültige finale MatchDecision“ ist nicht umgesetzt.
9. `InterpretationProperty`, `VocabularyMatchingPattern` und `ContextItem` sind noch nicht integriert.

**Gesamtbewertung:** 🟡 **fachlich tragfähige Foundation mit zwingendem Baseline-Alignment vor weiterer funktionaler Erweiterung.**

Die Lieferung sollte nicht verworfen oder neu gebaut werden. Die vorhandenen Klassen und Ports können weiterverwendet werden; erforderlich ist ein gezieltes Refactoring entlang der aktuellen Baseline.

---

## 4. Review der Domain Foundation (WP1-001A)

### 4.1 Schichtentrennung und Persistence Ignorance

**Bewertung:** ✅ Baseline-konform

Die Domain-Klassen enthalten keine Abhängigkeiten auf SQL, PDO, Repositorys, Frameworks, HTTP, OpenRefine oder xTree. Persistenzidentitäten werden als fachlicher Zustand behandelt, ohne eine konkrete Persistenztechnologie vorauszusetzen.

Dies entspricht insbesondere den DM002-Prinzipien:

- Aggregate First,
- Persistence Ignorance,
- Separation of Concerns,
- Stable Identity.

Die einmalige Vergabe einer positiven ID ist mit dem Prinzip stabiler Identität vereinbar. Die konkrete Verwendung von `int` ist eine Implementierungsentscheidung und kein Verstoß gegen DM002.

**Maßnahme:** Keine strukturelle Änderung erforderlich.

---

### 4.2 Provenienzmodell: SourceSystem, SourceDelivery und DeliveryChannel

**Bewertung:** 🔴 Anpassung erforderlich

WP1-001A enthält weder

- `SourceSystem`,
- `SourceDelivery`,
- `DeliveryChannel`,
- noch `SourceValue.sourceDeliveryId`.

`SourceValue` besitzt lediglich optionale wertbezogene `provenance`, `sourceField` und `sourceRecordId`. Damit kann die durch ADR002 und DM001 verbindlich festgelegte Provenienzkette nicht abgebildet werden:

```text
SourceSystem
    ↓
SourceDelivery
    ↓
SourceValue
```

Der Changelog weist korrekt darauf hin, dass die Lieferung vor der Integration von ADR002 erstellt wurde. Historisch ist die Abweichung damit nachvollziehbar. Gegen die aktuelle Baseline ist sie dennoch zentral.

**Auswirkung:**

- Jeder SourceValue kann ohne strukturierte Lieferung erzeugt werden.
- Die Zugehörigkeit mehrerer SourceValues zu einer Lieferung ist nicht darstellbar.
- SourceSystem und DeliveryChannel können nicht fachlich getrennt werden.
- Immutable Provenance kann nicht umgesetzt werden.
- Die Vollständigkeitsregel `SourceDelivery → SourceValue [1..*]` kann nicht koordiniert werden.

**Erforderliche Maßnahme:**

- Domain Objects `SourceSystem` und `SourceDelivery` ergänzen.
- `DeliveryChannel` als Value Object innerhalb von `SourceDelivery` ergänzen.
- `SourceValue` um eine verpflichtende, unveränderliche `sourceDeliveryId` erweitern.
- Factory-Methoden so ändern, dass kein neuer SourceValue ohne SourceDelivery-Referenz entsteht.
- Invarianten und Tests für unveränderliche Provenienzreferenzen ergänzen.

---

### 4.3 SourceValue als unveränderter Eingangswert

**Bewertung:** 🟡 Domain-Klasse konform; Application-Nutzung nicht konform

Die Domain-Klasse `SourceValue` besitzt readonly-Eigenschaften und schützt einen leeren Eingangswert. Der Original Value wird nach der Erzeugung nicht verändert. Das entspricht DM001 und DM002.

Die Domain Factory selbst trimmt den Wert nicht. Damit kann sie grundsätzlich einen originalgetreuen Wert speichern.

Die Verletzung entsteht erst im Application Service, siehe Abschnitt 5.2.

**Maßnahme:** Domain-Klasse beibehalten; Aufrufer korrigieren.

---

### 4.4 SourceValue Aggregate und Aggregate-Grenzen

**Bewertung:** 🔴 Anpassung erforderlich

DM001 v0.5 definiert:

```text
SourceValue Aggregate
├── ContextItem
├── InterpretationGraph
├── InterpretationNode
├── ReconciliationResult
├── CandidateItem
└── MatchDecision
```

WP1-001A behandelt dagegen laut Changelog `ReconciliationResult` als zweiten Aggregate Root. Im Code wird ein ReconciliationResult unabhängig vom SourceValue und InterpretationGraph erzeugt. `InterpretationGraph` enthält Nodes, aber keine Result-Zuordnung; `InterpretationNode` enthält keine Result-Sammlung.

Dadurch ist der fachliche Objektzusammenhang nur über optionale numerische IDs angedeutet, nicht innerhalb des Aggregate-Modells repräsentiert.

**Auswirkung:**

- Domain-Invarianten können nicht zuverlässig über den vollständigen SourceValue-Zustand geprüft werden.
- Ein `ReconciliationResult` kann mit `interpretationNodeId = null` erzeugt werden.
- Ein Result kann außerhalb eines SourceValue Aggregate existieren.
- Das Modell weicht von der aktuellen Aggregate-Grenze in DM001 ab.

**Erforderliche Maßnahme:**

- `ReconciliationResult` nicht länger als eigenständigen Aggregate Root behandeln.
- Erzeugung eines Results über beziehungsweise in Verbindung mit einer konkreten `InterpretationNode` koordinieren.
- Den vollständigen Reconciliation-Zustand über das `SourceValue` Aggregate erreichbar machen.
- Die Umsetzung darf intern weiterhin auf mehrere Klassen und später mehrere Mapper verteilt bleiben.

**Hinweis für LA:** Zu entscheiden ist nur die konkrete objektorientierte Repräsentation innerhalb des Aggregate. Die fachliche Grenze selbst ist durch DM001 bereits festgelegt.

---

### 4.5 InterpretationGraph und InterpretationNode

**Bewertung:** ✅ für den Initial Scope, mit 🟡 Erweiterungsbedarf

Baseline-konform umgesetzt sind:

- nicht leerer Graph-Span,
- `spanEnd > spanStart`,
- unverändertes `sourceFragment`,
- Root Node mit `level = 0` und ohne Parent,
- genau ein Graph und eine Root Node im initialen Implementierungsschritt,
- Status, Version und Creation Information.

Die Beschränkung auf einen Whole-Value-Graph ist ausdrücklich mit dem Initial Implementation Scope von DM001 und ME002 vereinbar.

Noch nicht umgesetzt sind:

- Child Nodes,
- lineare Ableitung weiterer Nodes,
- `InterpretationProperty` an einer Node.

Diese Punkte sind keine Fehlmodellierung des vorhandenen Codes, aber offene Baseline-Funktionalität für die nächste Ausbaustufe.

**Empfohlene Maßnahme:**

- Node-Erweiterung erst im dafür vorgesehenen Work Package ergänzen.
- `InterpretationProperty` als kontrollierte URI-Klassifikation `0..*` integrieren.
- Tests für Parent-Level-Invariante bei Child Nodes ergänzen.

---

### 4.6 CandidateItem: Provider, Entity Type und Identität

**Bewertung:** 🔴 Anpassung erforderlich

Positiv umgesetzt sind:

- verpflichtende Candidate URI,
- Display Label,
- Entity Type,
- optionaler Score im Bereich `0..1`,
- positiver Rank,
- optionale Qualifier,
- Eindeutigkeit der Candidate URI innerhalb eines ReconciliationResult.

Nicht baseline-konform ist das Attribut:

```php
sourceSystemUri
```

DM001 v0.5 hat diesen Begriff ausdrücklich durch

```text
candidateProviderUri
```

ersetzt. Der Candidate Provider ist nicht Teil der Provenienz des Eingangswerts und darf nicht mit `SourceSystem` verwechselt werden.

Zudem wird das Feld durch WP1-001B beim Candidate Mapping überhaupt nicht gesetzt.

**Erforderliche Maßnahme:**

- `sourceSystemUri` in `candidateProviderUri` umbenennen.
- Getter und Factory-Parameter entsprechend ändern.
- Candidate Provider im Discovery-Port bereitstellen und beim Mapping setzen.
- Tests ergänzen, die SourceSystem und Candidate Provider semantisch getrennt halten.

---

### 4.7 ReconciliationResult und VocabularyMatchingPattern

**Bewertung:** 🟡 teilweise konform

Vorhanden sind:

- Zielvokabular,
- Matching Strategy,
- Confidence,
- Note,
- Creation Information,
- CandidateItems,
- MatchDecisions,
- optionales `vocabularyMatchingPatternUri`,
- passives `success`-Attribut.

Dass `success` keinen Workflow steuert, entspricht DM001 und dem Changelog.

Problematisch ist, dass `vocabularyMatchingPatternUri` zwar als Constructor Property existiert, aber über `create()` nicht gesetzt werden kann und keine fachliche Methode zur späteren Klassifikation existiert. Die in ME001 festgelegte Kardinalität `0..1` ist strukturell zwar vorbereitet, praktisch aber nicht nutzbar.

**Empfohlene Maßnahme:**

- Fachliche Methode oder geeignete Factory zur einmaligen Klassifikation mit `0..1 VocabularyMatchingPattern` ergänzen.
- Gültigkeit kontrollierter URI-Werte an der Domain-/Application-Grenze absichern.
- Tests für höchstens ein Pattern ergänzen.

---

### 4.8 MatchDecision und finale Entscheidung

**Bewertung:** 🟡 teilweise konform, eine verbindliche Invariante fehlt

Baseline-konform umgesetzt sind:

- Entscheidung und Decision Status als Pflichtwerte,
- optionale Candidate-Auswahl,
- Candidate muss zum selben ReconciliationResult gehören,
- mehrere MatchDecisions sind grundsätzlich möglich,
- Entscheidungen werden nicht überschrieben.

Nicht umgesetzt ist die verbindliche DM001-Invariante:

> Ein ReconciliationResult darf höchstens eine fachlich gültige finale MatchDecision besitzen.

Der Code akzeptiert beliebig viele Entscheidungen mit demselben finalen Status.

**Erforderliche Maßnahme:**

- Die Finalitätssemantik kontrolliert modellieren.
- Beim Hinzufügen einer MatchDecision prüfen, ob bereits eine fachlich gültige finale Entscheidung existiert.
- Test für Ablehnung einer zweiten finalen Entscheidung ergänzen.

---

### 4.9 ContextItem

**Bewertung:** 🟡 Anpassung empfohlen

`ContextItem` ist nicht implementiert. Der Changelog nennt die bewusste Verschiebung bis nach ADR002. DM001 v0.5 trennt ContextItem ausdrücklich von SourceSystem, SourceDelivery und DeliveryChannel.

Für den aktuell sehr engen Concept-Reconciliation-Pfad ohne Kontextauswertung ist das Fehlen nachvollziehbar. Für die vollständige Domain Baseline muss ContextItem jedoch als Bestandteil des SourceValue Aggregate ergänzt werden.

**Maßnahme:**

- `ContextItem` in einem eigenen Alignment-/Erweiterungsschritt ergänzen.
- Keine Provenienzmetadaten als ContextItem modellieren.
- Für v0.5 Kontext weiterhin dem gesamten SourceValue zuordnen.

---

## 5. Review der Application Boundary (WP1-001B)

### 5.1 Dependency Direction und Candidate Discovery Port

**Bewertung:** ✅ Baseline-konform

Die Application Boundary setzt die gewünschte Abhängigkeitsrichtung sauber um:

```text
Transport / Controller
    → ReconciliationApplicationService
        → CandidateDiscoveryGateway
            ← LegacyCandidateDiscoveryAdapter
                → Legacy Orchestrator
```

Die Application Layer kennt weder HTTP/OpenRefine noch das Legacy Query Model, konkrete Provider oder xTree. Der Legacy Adapter normalisiert den Legacy Score in den Bereich `0..1`.

Dies unterstützt die Evolutionsziele aus DM002 und ME002:

- alternative Candidate Provider,
- zusätzliche Discovery Strategies,
- technische Austauschbarkeit der Discovery-Implementierung.

**Maßnahme:** Grundstruktur beibehalten.

---

### 5.2 Erhaltung des Original Value

**Bewertung:** 🔴 Anpassung erforderlich

Der Application Service erzeugt den SourceValue mit:

```php
value: trim($command->sourceValue)
```

DM001 und DM002 definieren `SourceValue` als unveränderten Eingangswert beziehungsweise `Original Value`. Das Trimmen verändert den Eingangswert und kann fachlich relevante Leerzeichen oder Positionsangaben beeinflussen. Besonders kritisch ist dies für `spanStart`, `spanEnd` und `sourceFragment`.

Die Eingabevalidierung darf einen nur aus Whitespace bestehenden Wert ablehnen, ohne den gespeicherten Wert zu normalisieren.

**Erforderliche Maßnahme:**

- Den unveränderten `command->sourceValue` an `SourceValue::create()` übergeben.
- Normalisierte Formen ausschließlich als InterpretationNode oder innerhalb einer Matching Strategy erzeugen.
- Test ergänzen, der die exakte Erhaltung des Eingangswerts prüft.

---

### 5.3 Erzeugung von SourceSystem und SourceDelivery

**Bewertung:** 🔴 Anpassung erforderlich

`ReconciliationCommand` enthält keine Angaben zu SourceSystem, SourceDelivery oder DeliveryChannel. Der Application Service erzeugt unmittelbar einen SourceValue.

Damit kann der Service die verbindliche DM001-Regel nicht erfüllen:

> Jeder neue SourceValue referenziert genau eine existierende SourceDelivery.

Ebenso kann die aggregateübergreifende Vollständigkeitsregel einer Lieferung nicht an der Transaktionsgrenze koordiniert werden.

**Erforderliche Maßnahme:**

Die Application Boundary benötigt entweder

1. Referenzen auf bereits existierende `SourceSystem` und `SourceDelivery`, oder
2. einen Delivery-orientierten Application Command, der SourceSystem, SourceDelivery und mindestens einen SourceValue gemeinsam koordiniert.

Für einzelne OpenRefine-Anfragen ist zu klären, wie eine fachliche Lieferung abgegrenzt und stabil identifiziert wird. Diese Klärung darf nicht dadurch umgangen werden, dass OpenRefine als SourceSystem verwendet wird; OpenRefine ist höchstens DeliveryChannel.

---

### 5.4 Target Vocabulary Mapping

**Bewertung:** 🔴 Anpassung erforderlich

Der Application Service verwendet:

```php
targetVocabularyUri: $command->subVocabularyId ?? $command->preferredEntityTypeUri
```

Der Fallback ist fachlich nicht korrekt:

- `preferredEntityTypeUri` beschreibt den erwarteten Entity Type.
- `targetVocabularyUri` beschreibt das fachliche Zielvokabular.

Beide Konzepte sind nicht austauschbar.

**Erforderliche Maßnahme:**

- `targetVocabularyUri` als eigenständigen verpflichtenden oder kontrolliert optionalen Command-Wert modellieren.
- Kein Fallback auf `preferredEntityTypeUri`.
- `subVocabularyId` nur dann als Target Vocabulary verwenden, wenn es tatsächlich eine fachliche Vocabulary URI repräsentiert.
- Benennung des Command-Felds an die Domain-Semantik angleichen.

---

### 5.5 Mapping des tatsächlichen Candidate Entity Type

**Bewertung:** 🔴 Anpassung erforderlich

Beim Mapping wird für jeden Candidate gesetzt:

```php
entityTypeUri: $command->preferredEntityTypeUri
```

DM001 unterscheidet ausdrücklich:

- `SourceValue.preferredEntityType` = fachliche Erwartung,
- `CandidateItem.entityType` = tatsächlich festgestellter Typ des Candidates.

Die aktuelle Implementierung kopiert die Erwartung in den tatsächlichen Candidate-Typ. Dadurch kann `WRONG_SEMANTIC_CLASS` beziehungsweise `NOT_TARGET_ENTITY_TYPE` methodisch nicht zuverlässig erkannt werden.

**Erforderliche Maßnahme:**

- `DiscoveredCandidate` um den tatsächlichen `entityTypeUri` erweitern.
- Legacy Adapter muss diesen Wert aus Provider-/Candidate-Metadaten ableiten oder ausdrücklich `null/unknown` signalisieren, falls die Baseline dies künftig zulässt.
- Application Service übernimmt den tatsächlichen Candidate Entity Type statt des erwarteten Typs.

---

### 5.6 Candidate Provider Mapping

**Bewertung:** 🔴 Anpassung erforderlich

`DiscoveredCandidate` enthält keine Provider URI. Beim Mapping zu CandidateItem bleibt das vorhandene `sourceSystemUri` leer.

DM001 und DM002 verlangen `candidateProviderUri` als Herkunft des Candidates für den konkreten Reconciliation-Versuch. Der Provider kann vom Target Vocabulary abweichen.

**Erforderliche Maßnahme:**

- `DiscoveredCandidate` um `candidateProviderUri` ergänzen.
- Jeder Candidate-Discovery-Adapter setzt seinen Provider explizit.
- Application Service überträgt die Provider URI in CandidateItem.

---

### 5.7 Interpretation-driven Workflow nach ME002

**Bewertung:** 🟡 teilweise konform

WP1-001B implementiert den ersten linearen Teil des ME002-Workflows:

1. SourceValue erzeugen,
2. Whole-Value-Graph erzeugen,
3. initiale Root Node erzeugen,
4. Candidate Discovery ausführen,
5. ReconciliationResult und CandidateItems erzeugen.

Noch nicht umgesetzt sind:

- ContextItems,
- InterpretationProperties,
- explizite Matching-Strategy-Auswahl anhand der Interpretation,
- VocabularyMatchingPattern,
- Result Quality Evaluation,
- weitere InterpretationNodes beziehungsweise Strategie-Wechsel,
- produktive MatchDecision.

Diese Lücken sind für eine erste Application Boundary nachvollziehbar. Das Paket ist deshalb keine vollständige ME002-Implementierung und sollte auch nicht so dokumentiert werden.

**Maßnahme:**

- Scope in der konsolidierten Dokumentation ausdrücklich als initialer linearer Pfad kennzeichnen.
- Weitere Workflow-Schritte in getrennten Work Packages ergänzen.
- Keine Interpretation des Legacy-`match`-Flags als MatchDecision; diese Entscheidung im Changelog ist korrekt.

---

### 5.8 ReconciliationResult-Zuordnung zur InterpretationNode

**Bewertung:** 🔴 Anpassung erforderlich

Der Service erzeugt ein Result mit:

```php
interpretationNodeId: $graph->rootNode()->id()
```

Da die Root Node zu diesem Zeitpunkt noch keine persistente ID besitzt, ist die Referenz `null`. Der Constructor erlaubt dies.

Damit ist fachlich nicht abgesichert, dass jedes ReconciliationResult genau zu einer InterpretationNode gehört.

**Erforderliche Maßnahme:**

- Result-Erzeugung an eine konkrete Node-Instanz beziehungsweise eine bereits stabile fachliche Identität binden.
- Die Domain-Beziehung darf nicht von einer erst später vergebenen Datenbank-ID abhängen.
- Das spätere Persistence Mapping muss die fachliche Beziehung rehydrierbar abbilden.

---

### 5.9 ReconciliationOutcome

**Bewertung:** 🟡 grundsätzlich geeignet

`ReconciliationOutcome` erhält SourceValue, ReconciliationResult und presentation-relevante Discovery-Daten. Für die Übergangsphase ist das praktikabel.

Nach Korrektur der Aggregate-Grenze sollte geprüft werden, ob ein separates `reconciliationResult` im Outcome noch erforderlich ist oder ob es aus dem SourceValue Aggregate abgeleitet werden kann.

**Maßnahme:** Nach Aggregate-Alignment erneut bewerten; derzeit keine isolierte Änderung vorziehen.

---

## 6. Abgleich mit DM002 — Logical Persistence Model

Da WP1-001A/B keine Persistenz implementieren, wird DM002 hier nur hinsichtlich der Persistierbarkeit des fachlichen Zustands und der Persistenzunabhängigkeit geprüft.

| DM002-Prinzip | Bewertung | Befund |
|---|---|---|
| Aggregate First | 🔴 | ReconciliationResult wird abweichend von DM001 als zweiter Aggregate Root behandelt. |
| Stable Identity | 🟡 | IDs sind stabil zuweisbar; mehrere fachliche Beziehungen hängen jedoch an nullable Persistenz-IDs. |
| Persistence Ignorance | ✅ | Domain und Application kennen keine konkrete Persistenztechnologie. |
| Separation of Concerns | ✅ | Domain, Application Port und Legacy Adapter sind sauber getrennt. |
| Immutable Provenance | 🔴 | SourceDelivery-Referenz und vollständige Provenienzkette fehlen. |
| Evolutionary Persistence | ✅ | Gateway- und Adapterstruktur unterstützt weitere Candidate Provider. |
| Vollständiger persisted state | 🔴 | SourceSystem, SourceDelivery, DeliveryChannel, ContextItem und candidateProviderUri fehlen beziehungsweise sind falsch benannt. |

**Schlussfolgerung:** Die Lieferung ist technisch gut für eine spätere Persistenz vorbereitet, bildet aber noch nicht den vollständigen persistenten fachlichen Zustand der aktuellen Baseline ab.

---

## 7. Abgleich mit ME001 und ME002

### 7.1 ME001 — Controlled Classifications

| Klassifikation | Status | Befund |
|---|---|---|
| InterpretationProperty `0..*` je Node | 🔴 | Nicht implementiert. |
| VocabularyMatchingPattern `0..1` je Result | 🟡 | Property vorhanden, aber über den produktiven Pfad nicht setzbar. |
| Trennung beider Klassifikationsebenen | ✅ konzeptionell | Keine Vermischung im vorhandenen Code. |
| Kontrollierte URI-Codes | 🟡 | URI-Felder vorhanden; zentrale Validierung/Registry bewusst noch nicht umgesetzt. |

### 7.2 ME002 — Processing Model

| Workflow-Bereich | Status | Befund |
|---|---|---|
| SourceValue empfangen | ✅ | Implementiert, aber Original Value wird im Service getrimmt. |
| Interpretierbaren Span bestimmen | 🟡 | Nur Whole-Value-Span im Initial Scope. |
| InterpretationGraph erzeugen | ✅ | Genau ein Graph gemäß Initial Scope. |
| Initiale InterpretationNode | ✅ | Root Node wird erzeugt. |
| InterpretationProperties | 🔴 | Nicht umgesetzt. |
| MatchingStrategy | 🟡 | Statische konfigurierte URI, keine interpretative Auswahl. |
| Candidate Discovery | ✅ | Port und Legacy Adapter vorhanden. |
| ReconciliationResult/Candidates | ✅ strukturell | Aggregate-Zuordnung und Candidate-Metadaten müssen korrigiert werden. |
| VocabularyMatchingPattern | 🔴 produktiv | Nicht gesetzt. |
| Quality Evaluation / Iteration | ⚪ | Noch außerhalb dieser Lieferung. |
| MatchDecision | 🟡 | Domain vorhanden, produktiver Pfad erzeugt keine Entscheidung. |

---

## 8. Testabdeckung

### 8.1 Positiv vorhandene Tests

Die vorhandenen Tests sichern unter anderem:

- genau einen Graph im Initial Scope,
- unverändertes Graph Fragment bezogen auf den Domain SourceValue,
- Root-Level,
- eindeutige Candidate URI je Result,
- Candidate-Sortierung nach Rank,
- Candidate-Auswahl nur innerhalb desselben Results,
- Candidate-Discovery-Gateway-Aufruf,
- Score-Normalisierung indirekt über Adapterstruktur,
- Erhaltung des Legacy-Match-Flags außerhalb der Domain Decision.

### 8.2 Fehlende Baseline-Tests

Für das Alignment sind mindestens folgende Tests zu ergänzen:

1. SourceSystem besitzt stabile Identität und nicht leeren Namen.
2. SourceDelivery referenziert genau ein SourceSystem.
3. SourceSystem-Referenz einer SourceDelivery ist unveränderlich.
4. SourceValue benötigt eine SourceDelivery-Referenz.
5. SourceDelivery-Referenz eines SourceValue ist unveränderlich.
6. DeliveryChannel ist Value Object und kein SourceSystem.
7. Original Value wird ohne Trim oder Normalisierung erhalten.
8. Candidate Provider wird separat vom SourceSystem gespeichert.
9. Candidate Entity Type stammt aus dem Candidate, nicht aus der Erwartung.
10. Target Vocabulary wird nicht aus dem Entity Type abgeleitet.
11. Result gehört zwingend zu einer konkreten InterpretationNode.
12. Node kann `0..* InterpretationProperty` besitzen.
13. Result kann höchstens ein VocabularyMatchingPattern besitzen.
14. Result kann höchstens eine fachlich gültige finale MatchDecision besitzen.
15. ContextItem ist dem SourceValue zugeordnet und nicht mit Delivery Metadata vermischt.

---

## 9. Priorisierte Alignment-Maßnahmen

### Priorität A — zwingend vor weiterer funktionaler Erweiterung

1. **Provenienzmodell ergänzen**
   - SourceSystem
   - SourceDelivery
   - DeliveryChannel
   - verpflichtende SourceDelivery-Referenz im SourceValue

2. **Aggregate-Grenze korrigieren**
   - ReconciliationResult in das SourceValue Aggregate integrieren
   - zwingende Node-Zuordnung herstellen

3. **Original Value erhalten**
   - `trim()` aus dem SourceValue-Erzeugungspfad entfernen

4. **Candidate-Semantik korrigieren**
   - `sourceSystemUri` → `candidateProviderUri`
   - tatsächlichen Candidate Entity Type übernehmen
   - Candidate Provider über Gateway transportieren

5. **Target Vocabulary korrigieren**
   - kein Fallback auf `preferredEntityTypeUri`

6. **Finale MatchDecision absichern**
   - höchstens eine fachlich gültige finale Entscheidung

### Priorität B — erforderlich für vollständige Baseline-Abdeckung

7. `InterpretationProperty` integrieren.
8. `VocabularyMatchingPattern` produktiv setzbar machen.
9. `ContextItem` ergänzen.
10. Child Nodes und lineare Interpretationserweiterung ergänzen.

### Priorität C — Dokumentation und Härtung

11. Changelogs auf die neue Baseline beziehen und historische Scope-Grenzen kennzeichnen.
12. Begriffe `entityType`, `targetVocabulary`, `candidateProvider` und `sourceSystem` durchgehend trennen.
13. Fehlende Baseline-Tests ergänzen.
14. `ReconciliationOutcome` nach Aggregate-Alignment erneut bewerten.

---

## 10. Stabile Architektur- und Implementierungsentscheidungen

Folgende Entscheidungen aus WP1-001A/B können als stabil angesehen und weiterverwendet werden:

1. **Schichtentrennung** zwischen Domain, Application und Infrastructure.
2. **CandidateDiscoveryGateway** als Application Port.
3. **LegacyCandidateDiscoveryAdapter** als Anti-Corruption Layer zum Bestandssystem.
4. **Transport-neutraler ReconciliationCommand** als Grundidee.
5. **Score-Normalisierung im Adapter**, nicht im Domain Model.
6. **Kein Mapping des Legacy-`match`-Flags auf MatchDecision**.
7. **SourceValue als zentraler fachlicher Einstiegspunkt** des Interpretation-and-Reconciliation-Kerns.
8. **InterpretationGraph und InterpretationNode** als explizite Domain Objects.
9. **Whole-Value-Graph und eine Root Node** als zulässige Einschränkung des Initial Scope.
10. **Eindeutige Candidate URI je ReconciliationResult**.
11. **Candidate-Auswahl nur aus demselben Result**.
12. **Domain- und Application-Schichten ohne Persistenzabhängigkeiten**.

Diese Punkte sollten in einem Alignment-Work-Package nicht unnötig neu gestaltet werden.

---

## 11. Empfehlung für das weitere Vorgehen

Die geprüfte Lieferung ist nicht zu verwerfen. Empfohlen wird ein gezieltes Alignment-Paket, das die Baseline-Abweichungen bündelt, ohne die stabilen Schichtengrenzen und Ports neu zu entwerfen.

Für die spätere Konsolidierung sollte dieses Review als erster Baustein des übergreifenden Alignment Reviews verwendet werden.

Ein mögliches Folgepaket könnte enthalten:

```text
POST-WP2-001 / Baseline Alignment

A. Provenance Domain Integration
B. SourceValue Aggregate Alignment
C. Candidate Semantics Alignment
D. Application Command and Mapping Alignment
E. Controlled Classification Integration
F. Domain Invariant and Test Completion
```

Die genaue Paketbildung sollte erst nach den weiteren Alignment Reviews festgelegt werden, damit übergreifende Änderungen nicht mehrfach geplant werden.

---

## 12. Review-Ergebnis

| Bereich | Ergebnis |
|---|---|
| Domain/Application-Schichtung | ✅ Baseline-konform |
| Candidate Discovery Port | ✅ Baseline-konform |
| Legacy-Abgrenzung | ✅ Baseline-konform |
| Initialer InterpretationGraph | ✅ Baseline-konform |
| Provenienzmodell | 🔴 Anpassung erforderlich |
| SourceValue Aggregate-Grenze | 🔴 Anpassung erforderlich |
| Original Value | 🔴 Anpassung erforderlich |
| Candidate Provider | 🔴 Anpassung erforderlich |
| Candidate Entity Type | 🔴 Anpassung erforderlich |
| Target Vocabulary | 🔴 Anpassung erforderlich |
| InterpretationProperty | 🟡 Ergänzung erforderlich |
| VocabularyMatchingPattern | 🟡 Ergänzung erforderlich |
| MatchDecision-Invarianten | 🟡 Ergänzung erforderlich |
| ContextItem | 🟡 Ergänzung erforderlich |
| Persistence Ignorance | ✅ Baseline-konform |

**Gesamturteil:**

> WP1-001A und WP1-001B sind eine solide, sauber geschichtete Foundation des ursprünglichen Reconciliation-Kerns. Sie sind jedoch noch nicht vollständig mit der durch ADR002, DM001 v0.5, DM002 v0.5, ME001 v0.2-alpha und ME002 v0.6 definierten Baseline ausgerichtet. Das erforderliche Alignment ist substanziell, aber überwiegend additiv und refaktorisierend; ein grundlegender Neuaufbau ist nicht erforderlich.

---

## 13. Geprüfte Artefakte

### WP1-001A

- `CHANGELOG_WP1.md`
- `src/Domain/Reconciliation/DomainInvariantViolation.php`
- `src/Domain/Reconciliation/SourceValue.php`
- `src/Domain/Reconciliation/InterpretationGraph.php`
- `src/Domain/Reconciliation/InterpretationNode.php`
- `src/Domain/Reconciliation/ReconciliationResult.php`
- `src/Domain/Reconciliation/CandidateItem.php`
- `src/Domain/Reconciliation/MatchDecision.php`
- `tests/Domain/Reconciliation/DomainFoundationTest.php`

### WP1-001B

- `CHANGELOG_WP1.md`
- `src/Application/Reconciliation/ReconciliationCommand.php`
- `src/Application/Reconciliation/CandidateDiscoveryGateway.php`
- `src/Application/Reconciliation/DiscoveredCandidate.php`
- `src/Application/Reconciliation/ReconciliationApplicationService.php`
- `src/Application/Reconciliation/ReconciliationOutcome.php`
- `src/Infrastructure/Reconciliation/LegacyCandidateDiscoveryAdapter.php`
- `tests/Application/Reconciliation/ApplicationBoundaryTest.php`

### Baseline

- `ADR002_SOURCE_DELIVERY_MODEL_V4.md`
- `DM001_Domain_Model_v0.5_FINAL.md`
- `DM002_Persistence_Model_v0.5_ED-LA.md`
- `ME001_Interpretation_Properties_and_Vocabulary_Matching_Patterns_v0.2_ALPHA.md`
- `ME002_Interpretation_Driven_Reconciliation_v0.6_DRAFT.md`

---

# Document History

| Version | Status | Description |
|---|---|---|
| 0.1 | Draft ED | Initialer Alignment-Abgleich von WP1-001A und WP1-001B gegen die aktuelle Baseline |