# DM001 — Reconcilix Domain Model **Version:** 0.7 **Status:** Final **Created:** 2026-07-10 **Updated:** 2026-07-26 **Scope:** Source Provenance, Vocabulary and Entity Reconciliation **Related:** - `ADR001-*.md` - `ADR002_SOURCE_DELIVERY_MODEL_V4.md` - `IA001_ADR002_IMPACT_ON_DM_ME_DRAFT_ED.md` - `DM002_Persistence_Model_v0.3.md` - `ME001_Interpretation_Properties_and_Vocabulary_Matching_Patterns_v0.2_ALPHA.md` - `ME002_Interpretation_Driven_Reconciliation_v0.6_DRAFT.md` **Language Convention:** Fachbegriffe und Notationen in Englisch; erläuternder Fließtext in Deutsch. ## 1. Purpose DM001 beschreibt die fachlichen Objekte und Beziehungen, die Reconcilix für - die nachvollziehbare Herkunft und Gruppierung eingehender Daten, - die Interpretation eines `SourceValue`, - die Candidate Discovery, - die Reconciliation, - und die fachliche Match Decision verwendet. Das Modell ist unabhängig von einer konkreten Softwareimplementierung, API, Persistenztechnologie oder Matching Technique. Der fachliche Gesamtzusammenhang ist: ```text SourceSystem │ └── SourceDelivery ─── DeliveryChannel [1] │ └── SourceValue [1..*] │ └── InterpretationGraph [1..*] │ └── InterpretationNode [1..*] │ └── ReconciliationResult [0..*] ├── CandidateItem [0..*] └── MatchDecision [0..*] ``` Der eigentliche Interpretation-and-Reconciliation-Kern bleibt: ```text SourceValue → InterpretationGraph → InterpretationNode → ReconciliationResult → CandidateItem → MatchDecision ``` `SourceSystem`, `SourceDelivery` und `DeliveryChannel` bilden den fachlichen Herkunfts- und Lieferungskontext oberhalb dieses Kerns. Ein `SourceValue` wird nicht unmittelbar gegen `CandidateItem` gematcht. Zunächst werden eine oder mehrere interpretierbare Fundstellen verwaltet und mögliche Interpretationen rekursiv erschlossen. ## 2. Use Cases DM001 berücksichtigt vier Reconciliation Use Cases: 1. **Concept Reconciliation** — `preferredEntityType = CONCEPT` 2. **Person Reconciliation** — `preferredEntityType = PERSON` 3. **Place Reconciliation** — `preferredEntityType = PLACE` 4. **Text Reconciliation** — `preferredEntityType = MULTIPLE` Die nächste Implementierungsphase beschränkt sich bewusst auf: ```text OpenRefine → Reconcilix → xTree / MCT preferredEntityType = CONCEPT ``` Dabei gilt: ```text SourceSystem = fachliches Ursprungssystem SourceDelivery = konkrete Lieferung DeliveryChannel = technischer Übertragungsweg ``` Beispiel: ```text SourceSystem = digiCULT.web DeliveryChannel = OpenRefine Reconciliation API ``` OpenRefine wird in diesem Beispiel nicht als fachliches Ursprungssystem modelliert. Das Domain Model bleibt offen für weitere Clients, Quellsysteme, Delivery Channels und Target Knowledge Sources. ## 3. Provenance and Delivery Domain Classes ### 3.1 `SourceSystem` Das fachliche Ursprungssystem einer oder mehrerer Datenlieferungen. | Attribute | Meaning | |---|---| | `id` | Stabile interne Identität | | `name` | Fachlich lesbare Bezeichnung | | `uri` | Optionale stabile fachliche URI | Beispiele: - digiCULT.web - MuseumsPlus - Adlib Ein `SourceSystem` beschreibt weder - ein Dateiformat, - eine technische Schnittstelle, - einen Reconciliation Client, - noch einen Transportmechanismus. Ein `SourceSystem` ist ein eigenständiges Aggregate. ### 3.2 `SourceDelivery` Eine konkrete Lieferung aus genau einem `SourceSystem`. | Attribute | Meaning | |---|---| | `id` | Stabile interne Identität | | `tenantId` | Verpflichtende Referenz auf genau einen Tenant | | `sourceSystemId` | Referenz auf genau ein `SourceSystem` | | `deliveryChannel` | Verpflichtender technischer Übertragungsweg | | `externalDeliveryId` | Optionale Kennung aus dem Quell- oder Übertragungsprozess | | `status` | Bearbeitungsstatus der Lieferung | | `receivedAt` | Zeitpunkt, zu dem Reconcilix die Lieferung angenommen beziehungsweise angelegt hat | | `completedAt` | Optionaler Abschlusszeitpunkt | Eine `SourceDelivery` - gehört genau zu einem Tenant, - gehört genau zu einem `SourceSystem`, - muss genau einen `DeliveryChannel` enthalten, - besitzt einen kontrollierten Bearbeitungsstatus, - stellt eine stabile Identität bereit, über die zugehörige `SourceValue` gruppiert werden, - übernimmt jedoch nicht den vollständigen Lebenszyklus der gruppierten `SourceValue`. `SourceDelivery` ist ein eigenständiges Aggregate. Die Mindestkardinalität ```text SourceDelivery → SourceValue [1..*] ``` ist eine fachliche Vollständigkeitsregel über mehrere Aggregate. Sie wird durch den koordinierenden Application Service an der Transaktionsgrenze sichergestellt. ### 3.3 `DeliveryChannel` Der technische Übertragungsweg, über den eine `SourceDelivery` Reconcilix erreicht. Beispiele: - `OPENREFINE_RECONCILIATION_API` - `CSV_IMPORT` - `REST_API` - `BATCH_IMPORT` Für v0.7 wird `DeliveryChannel` eindeutig als Value Object innerhalb von `SourceDelivery` modelliert. Es - besitzt keine eigene fachliche Identität, - besitzt keinen eigenen Lebenszyklus, - kapselt einen kontrollierten Code oder eine URI, - ist kein `SourceSystem`, - ist kein eigenständiges Aggregate, - ist kein Schritt der Reconciliation Pipeline, - ist keine Matching Technique, - ist kein `ContextItem`. ### 3.4 `SourceDeliveryStatus` Der kontrollierte Bearbeitungsstatus einer `SourceDelivery`. Für v0.7 werden folgende Werte vorgesehen: - `RECEIVED` - `PROCESSING` - `COMPLETED` - `FAILED` `SourceDeliveryStatus` wird als Value Object beziehungsweise Enumeration modelliert. Die vollständige Lifecycle-Steuerung, einschließlich Retry- und JobQueue-Logik, ist nicht Bestandteil von ED-04. ## 4. Reconciliation Domain Classes ### 4.1 `SourceValue` Der unveränderte Eingangswert eines Reconciliation-Vorgangs. | Attribute | Meaning | |---|---| | `id` | Stabile interne Identität | | `sourceDeliveryId` | Referenz auf genau eine `SourceDelivery` | | `value` | Ursprünglicher Literalwert | | `sourceField` | Quellfeld oder Datenelement | | `sourceRecordId` | Referenz auf den Quelldatensatz | | `datatype` | Datentyp | | `language` | Sprache | | `preferredEntityType` | Erwarteter Entity Type | | `provenance` | Optionale ergänzende, ausschließlich wertbezogene Provenienz | | `createdAt` | Erstellungszeitpunkt | `sourceDeliveryId` ist verpflichtend. `SourceValue.provenance` enthält ausschließlich ergänzende Provenienzinformationen, die spezifisch für genau diesen `SourceValue` gelten und nicht bereits strukturiert auf Ebene von `SourceSystem`, `SourceDelivery` oder `DeliveryChannel` abgebildet werden. Dazu können beispielsweise gehören: - transformationsbezogene Hinweise, - quellwertspezifische technische Metadaten, - Informationen, die nur diesen konkreten Wert betreffen. Informationen, die für mehrere oder alle `SourceValue` derselben Lieferung gelten, gehören grundsätzlich zur `SourceDelivery` und sollen nicht redundant in jedem `SourceValue.provenance` gespeichert werden. `provenance` ersetzt ausdrücklich nicht die strukturierte Zuordnung zu: - `SourceSystem`, - `SourceDelivery`, - `DeliveryChannel`. `preferredEntityType` wird nach unten vererbt. Es wird nicht redundant an `InterpretationGraph` oder `InterpretationNode` gespeichert. `SourceValue` bleibt ein eigenständiges Aggregate. ### 4.2 `ContextItem` Zusätzliche fachliche Information, die für Interpretation, Candidate Discovery oder Match Decision relevant sein kann. | Attribute | Meaning | |---|---| | `id` | Interne Identifikation | | `contextType` | Typ des Kontexts | | `value` | Kontextwert | | `source` | Optionale abweichende Herkunft | Für v0.7 gilt Kontext für den gesamten `SourceValue`. Eine Zuordnung zu einzelnen `InterpretationGraph`-Instanzen wird bewusst zurückgestellt. `SourceSystem`, `SourceDelivery` und `DeliveryChannel` sind keine `ContextItem`. Fachliche Informationen, die innerhalb einer Lieferung zusätzlich zu einem `SourceValue` bereitgestellt werden, können weiterhin als `ContextItem` modelliert werden. ### 4.3 `InterpretationGraph` Verwaltungs- und Arbeitseinheit für genau eine interpretierbare Fundstelle oder einen interpretierbaren Ausschnitt innerhalb eines `SourceValue`. | Attribute | Meaning | |---|---| | `id` | Interne Identifikation | | `spanStart` | Startposition im `SourceValue` | | `spanEnd` | Endposition im `SourceValue` | | `sourceFragment` | Unveränderter Ausschnitt | | `status` | Bearbeitungsstatus | | `version` | Version oder Lauf | | `createdAt` | Erstellungszeitpunkt | Ein `SourceValue` besitzt fachlich `1..* InterpretationGraph`. In der ersten Implementierung wird zunächst genau ein Graph unterstützt. Für einen nicht leeren interpretierbaren Ausschnitt gilt: ```text spanEnd > spanStart ``` `sourceFragment` muss beim Anlegen eines Graphen exakt aus dem unveränderten `SourceValue.value` anhand von `spanStart` und `spanEnd` gebildet werden. ### 4.4 `InterpretationNode` Ein konkreter interpretierbarer Zustand innerhalb eines `InterpretationGraph`. | Attribute | Meaning | |---|---| | `id` | Interne Identifikation | | `value` | Interpretierter oder abgeleiteter Wert | | `level` | Ableitungstiefe | | `status` | Bearbeitungsstatus | | `createdBy` | Erzeugender Agent oder Systemteil | | `technique` | Optional verwendete Matching Technique | | `note` | Erläuterung | | `createdAt` | Erstellungszeitpunkt | Für `level` gilt: ```text Root Node: level = 0 Child Node: level = parent.level + 1 ``` Eine `InterpretationNode` repräsentiert keinen Bearbeitungsschritt, sondern einen fachlich interpretierbaren Zustand. Eine Node kann durch `0..* InterpretationProperty` klassifiziert werden. In v0.7 besitzt sie höchstens eine Parent Node. Echte konvergierende Graphpfade bleiben eine spätere Erweiterung. ### 4.5 `ReconciliationResult` Ergebnis eines konkreten Reconciliation-Versuchs für eine `InterpretationNode`. Ein `InterpretationNode` kann mehrere `ReconciliationResult` besitzen, beispielsweise für unterschiedliche Target Vocabularies oder Matching Strategies. | Attribute | Meaning | |---|---| | `id` | Interne Identifikation | | `success` | Vorläufiges Attribut ohne abschließend definierte fachliche Semantik | | `matchingStrategy` | Verwendete Matching Strategy | | `confidence` | Confidence des Ergebnisses | | `note` | Erläuterung | | `createdAt` | Erstellungszeitpunkt | | `targetVocabularyUri` | URI des fachlichen Zielvokabulars | `success` wird in der ersten Implementierungsphase nicht für fachliche Entscheidungen, Evaluationen oder Workflow-Steuerung verwendet. Ein `ReconciliationResult` kann: - keinen Candidate enthalten, - einen oder mehrere Candidates enthalten, - mit `0..1 VocabularyMatchingPattern` klassifiziert werden, - eine oder mehrere `MatchDecision` erhalten. `targetVocabularyUri` bleibt für v0.7 bestehen. Eine allgemeinere Modellierung von Target Systems beziehungsweise Knowledge Sources wird in einem späteren Work Package untersucht. ### 4.6 `CandidateItem` Ein potenzielles Zielobjekt eines Reconciliation-Vorgangs. | Attribute | Meaning | |---|---| | `uri` | Fachliche persistente Identifikation | | `displayLabel` | Anzeigeform | | `entityType` | Tatsächlicher Entity Type | | `candidateProviderUri` | URI des Systems oder Dienstes, der den Candidate für den konkreten Reconciliation-Versuch bereitgestellt hat | | `score` | Bewertung im Ergebnis | | `rank` | Rang in der Candidate List | | `qualifier` | Optionaler Qualifier beziehungsweise Homonymzusatz | `candidateProviderUri` beschreibt den Anbieter des Candidates. Der Provider muss nicht identisch mit dem fachlichen Zielvokabular sein. Beispiele: ```text candidateProviderUri = URI eines QLever Endpoint targetVocabularyUri = URI des Material Culture Thesaurus ``` oder: ```text candidateProviderUri = URI der Lobid API targetVocabularyUri = URI der GND ``` `candidateProviderUri` ist semantisch strikt zu unterscheiden von: ```text SourceValue → SourceDelivery → SourceSystem ``` Diese Kette beschreibt die Herkunft des Eingangswerts. `SourceValue.preferredEntityType` ist die Erwartung; `CandidateItem.entityType` ist der tatsächlich festgestellte Typ. Für `rank` bleibt noch offen, ob - eine eindeutige Listenposition, - oder ein Rang mit zulässigen Gleichständen modelliert wird. ### 4.7 `MatchDecision` Fachliche oder automatische Entscheidung zu einem `ReconciliationResult`. | Attribute | Meaning | |---|---| | `id` | Interne Identifikation | | `decision` | Entscheidungstyp | | `confidence` | Confidence der Entscheidung | | `decidedBy` | Person, Rolle oder System | | `comment` | Erläuterung | | `timestamp` | Entscheidungszeitpunkt | | `decisionStatus` | Status der Entscheidung | | `selectedCandidateUri` | Optionale Referenz auf den ausgewählten Candidate | Eine `MatchDecision` kann optional auf ein ausgewähltes `CandidateItem` desselben `ReconciliationResult` verweisen. Ein `ReconciliationResult` kann mehrere `MatchDecision` erhalten. Entscheidungen werden nicht überschrieben. `decisionStatus` kennzeichnet den fachlichen Gültigkeitsstatus einer Entscheidung, beispielsweise: - vorläufig, - fachlich geprüft, - final. Die fachlich maßgebliche Entscheidung ist die als final klassifizierte Entscheidung. ## 5. Controlled Classifications ### 5.1 `InterpretationProperty` Kontrollierte Klassifikation einer `InterpretationNode`. Kardinalität: ```text InterpretationNode → 0..* InterpretationProperty ``` ### 5.2 `VocabularyMatchingPattern` Kontrollierte Klassifikation eines `ReconciliationResult`. Kardinalität: ```text ReconciliationResult → 0..1 VocabularyMatchingPattern ``` Es beschreibt das dominante relationale Muster zwischen Interpretation und Candidate beziehungsweise das charakteristische Ergebnis eines erfolglosen Versuchs. `DeliveryChannel` gehört ausdrücklich nicht zu dieser Kategorie. Es ist ein Value Object innerhalb von `SourceDelivery`. ## 6. Aggregate Boundaries ### 6.1 `SourceSystem` Aggregate Aggregate Root: ```text SourceSystem ``` Verantwortung: - stabile Identität des fachlichen Ursprungssystems, - fachlich lesbare Bezeichnung, - optionale URI. ### 6.2 `SourceDelivery` Aggregate Aggregate Root: ```text SourceDelivery ``` Verantwortung: - Zuordnung zu genau einem Tenant, - Zuordnung zu genau einem `SourceSystem`, - genau ein `DeliveryChannel`, - kontrollierter Bearbeitungsstatus, - Identifikation einer konkreten Lieferung, - Bereitstellung einer stabilen Identität, über die zugehörige `SourceValue` gruppiert werden. `SourceDelivery` speichert oder verändert `SourceValue` nicht automatisch als interne Aggregate-Bestandteile. ### 6.3 `SourceValue` Aggregate Aggregate Root: ```text SourceValue ``` Das `SourceValue` Aggregate umfasst: ```text ContextItem InterpretationGraph InterpretationNode ``` Eine `InterpretationNode` kann auf `0..* ReconciliationResult` verweisen. Die technische Persistenz kann auf mehrere Tabellen und Data Mapper verteilt werden, ohne die fachliche Aggregate-Grenze zu verändern. ### 6.4 `ReconciliationResult` Aggregate Aggregate Root: ```text ReconciliationResult ``` Das `ReconciliationResult` Aggregate umfasst: ```text CandidateItem MatchDecision ``` Ein `ReconciliationResult` gehört fachlich genau zu einer `InterpretationNode`. Die technische Persistenz kann auf mehrere Tabellen und Data Mapper verteilt werden, ohne die fachliche Aggregate-Grenze zu verändern. ### 6.5 Cross-Aggregate References Zwischen den Aggregaten gelten ausschließlich stabile Referenzen: ```text SourceDelivery.sourceSystemId SourceValue.sourceDeliveryId InterpretationNode → ReconciliationResult ``` Ein Application Service kann mehrere Aggregate innerhalb einer Transaktion koordinieren. Dadurch werden die Aggregate-Grenzen nicht aufgehoben. ## 7. Domain Invariants ### 7.1 Provenance and Delivery 1. Jedes `SourceSystem` besitzt eine stabile Identität. 2. `SourceSystem.name` ist nicht leer. 3. Jede `SourceDelivery` besitzt eine stabile Identität. 4. Jede `SourceDelivery` referenziert genau einen Tenant. 5. Die Zuordnung einer `SourceDelivery` zu ihrem Tenant ist nach Anlage unveränderlich. 6. Jede `SourceDelivery` referenziert genau ein existierendes `SourceSystem`. 7. Die Zuordnung einer `SourceDelivery` zu ihrem `SourceSystem` ist nach Anlage unveränderlich. 8. `SourceDelivery.receivedAt` ist gesetzt. 9. Jede `SourceDelivery` enthält genau einen `DeliveryChannel`. 10. Ein `DeliveryChannel` repräsentiert einen gültigen kontrollierten Wert. 11. `SourceDelivery.status` repräsentiert einen gültigen kontrollierten Wert. 12. Bei `COMPLETED` ist `SourceDelivery.completedAt` gesetzt. 13. Jeder `SourceValue` referenziert genau eine existierende `SourceDelivery`. 14. Die Zuordnung eines `SourceValue` zu seiner `SourceDelivery` ist nach Anlage unveränderlich. 15. Ein `DeliveryChannel` ist kein fachliches Ursprungssystem. 16. Ein Wechsel des technischen Übertragungswegs erzeugt nicht automatisch ein neues `SourceSystem`. 17. `SourceValue.provenance` darf die strukturierte Referenz auf `SourceDelivery` nicht ersetzen. 18. Eine `SourceDelivery` übernimmt nicht automatisch den Lebenszyklus ihrer `SourceValue`. 19. Die Mindestkardinalität `SourceDelivery → SourceValue [1..*]` ist eine aggregateübergreifende fachliche Vollständigkeitsregel. Die Vollständigkeitsregel wird durch den koordinierenden Application Service an der Transaktionsgrenze sichergestellt. Während eines technischen Erzeugungsprozesses kann eine `SourceDelivery` vorübergehend noch keinen persistenten `SourceValue` besitzen. Ein solcher Zwischenzustand darf die Transaktion beziehungsweise den Application Service nicht als fachlich vollständige Lieferung verlassen. ### 7.2 Interpretation and Reconciliation 1. Ein `SourceValue.value` ist nicht leer. 2. Ein `SourceValue.preferredEntityType` ist gesetzt. 3. Ein `InterpretationGraph` gehört genau zu einem `SourceValue`. 4. Für einen nicht leeren Graphen gilt `spanEnd > spanStart`. 5. `sourceFragment` entspricht exakt dem bezeichneten Ausschnitt von `SourceValue.value`. 6. Ein Root `InterpretationNode` besitzt `level = 0` und keine Parent Node. 7. Eine Child Node besitzt genau eine Parent Node und `level = parent.level + 1`. 8. Ein `CandidateItem.uri` ist innerhalb eines `ReconciliationResult` eindeutig. 9. Eine `MatchDecision` kann nur einen `CandidateItem` desselben `ReconciliationResult` auswählen. 10. Ein `ReconciliationResult` darf höchstens eine fachlich gültige finale `MatchDecision` besitzen. ## 8. UML — Provenance and Delivery Model ```mermaid classDiagram class SourceSystem { +id +name +uri } class SourceDelivery { +id +tenantId +sourceSystemId +deliveryChannel +externalDeliveryId +status +receivedAt +completedAt } class DeliveryChannel { <> +code +uri } class SourceDeliveryStatus { <> RECEIVED PROCESSING COMPLETED FAILED } class SourceValue { +id +value +sourceField +sourceRecordId +datatype +language +preferredEntityType +provenance +createdAt } SourceSystem "1" <-- "0..*" SourceDelivery : originatesFrom SourceDelivery --> DeliveryChannel : transferredVia SourceDelivery --> SourceDeliveryStatus : hasStatus SourceDelivery "1" <-- "1..*" SourceValue : groupedBy ``` ## 9. UML — Interpretation and Reconciliation Model ```mermaid classDiagram class SourceValue { +id +value +preferredEntityType } class ContextItem { +id +contextType +value +source } class InterpretationGraph { +id +spanStart +spanEnd +sourceFragment +status +version +createdAt } class InterpretationNode { +id +value +level +status +createdBy +technique +note +createdAt } class InterpretationProperty { +uri +code +label +definition +status } class ReconciliationResult { +id +success +matchingStrategy +confidence +note +createdAt +targetVocabularyUri } class VocabularyMatchingPattern { +uri +code +label +definition +status } class CandidateItem { +uri +displayLabel +entityType +candidateProviderUri +score +rank +qualifier } class MatchDecision { +id +decision +confidence +decidedBy +comment +timestamp +decisionStatus } SourceValue "1" *-- "0..*" ContextItem : has SourceValue "1" *-- "1..*" InterpretationGraph : segmentedInto InterpretationGraph "1" *-- "1..*" InterpretationNode : contains InterpretationNode "0..1" --> "0..*" InterpretationNode : derives InterpretationNode "0..*" --> "0..*" InterpretationProperty : classifiedBy InterpretationNode "1" --> "0..*" ReconciliationResult : produces ReconciliationResult "0..*" --> "0..1" VocabularyMatchingPattern : classifiedBy ReconciliationResult "1" *-- "0..*" CandidateItem : contains ReconciliationResult "1" --> "0..*" MatchDecision : receives MatchDecision "0..*" --> "0..1" CandidateItem : selects ``` ## 10. Vocabulary Strategy Sobald die Klassifikationen fachlich stabil sind, werden dafür kleine kontrollierte Vokabulare in xTree angelegt und über den LOD-Dienst bereitgestellt. Vorgesehen sind insbesondere: - `InterpretationProperty` - `VocabularyMatchingPattern` - `MatchDecision.decision` - `MatchDecision.decisionStatus` - `status` - `preferredEntityType` `DeliveryChannel` wird in v0.7 ausdrücklich nicht als eigenständiges kontrolliertes Vokabular modelliert, sondern als Value Object mit kontrolliertem Code oder URI. ## 11. Implementation Boundary DM001 beschreibt das fachliche Zielmodell. Die erste Umsetzung von DM001 v0.7 soll sich beschränken auf: - `preferredEntityType = CONCEPT` - genau eine `SourceDelivery` je eingehender fachlicher Lieferung - verpflichtende Zuordnung jeder `SourceDelivery` zu einem Tenant - verpflichtende Zuordnung jedes neuen `SourceValue` zu einer `SourceDelivery` - genau ein verpflichtender `DeliveryChannel` - kontrollierter `SourceDeliveryStatus` - zunächst genau einen `InterpretationGraph` pro `SourceValue` - MySQL als persistentes Backend - OpenRefine als Client und möglicher `DeliveryChannel` - xTree/MCT als Target Vocabulary - keine komplexe Graph Exploration - keine Qdrant-, BGE- oder LLM-Integration - keine automatische methodische Nutzung von `SourceSystem` oder `DeliveryChannel` Die Einführung von `SourceSystem` und `SourceDelivery` verändert den bestehenden Interpretation-and-Reconciliation-Kern nicht. ## 12. Deferred Design Questions Folgende Fragen werden bewusst nach der nächsten Modellierungs-, Implementierungs- oder Evaluationsrunde erneut geprüft: - Soll `SourceSystem.uri` verpflichtend werden? - Für welche Delivery Types kann eine `externalDeliveryId` zuverlässig bereitgestellt werden? - Wie werden Wiederholungen, Versionen und Replays einer `SourceDelivery` modelliert? - Wie werden fachlich identische Lieferungen erkannt? - Kontext auf Graph- oder Node-Ebene - mehrere Parent Nodes und konvergierende Graphpfade - Versionierung und Replay vollständiger Reconciliation Runs - Spezialisierung von `CandidateItem` - mehrere `preferredEntityType` innerhalb eines `SourceValue` - endgültige Semantik von `ReconciliationResult.success` - Rangmodell bei `CandidateItem.rank` - eigenständiges Aggregate für Target Systems beziehungsweise Knowledge Sources - Abgrenzung zwischen Target Knowledge Source, Candidate Provider und Discovery Channel ## 13. Change Summary v0.6 → v0.7 DM001 v0.7 präzisiert gegenüber v0.6 ausschließlich das `SourceDelivery`-Modell: 1. `tenantId` als verpflichtende, unveränderliche Zuordnung einer `SourceDelivery`. 2. `DeliveryChannel` als verpflichtendes Value Object. 3. `SourceDeliveryStatus` als kontrollierter Status mit `RECEIVED`, `PROCESSING`, `COMPLETED` und `FAILED`. 4. `completedAt` als optionaler Abschlusszeitpunkt; bei `COMPLETED` verpflichtend. 5. Korrektur der UML-Beziehung zu `DeliveryChannel`: keine Komposition, sondern typisierte Verwendung als Value Object. 6. Kleine redaktionelle Korrekturen und Aktualisierung der Versionsbezüge.