Gerne. Meine Architektur-Einschätzung zu EDs Vorschlag ist **ACCEPT WITH CHANGES**. Die Grundrichtung ist richtig: Für Phase 6 braucht Reconcilix eine persistente Execution-/Evidence-Schicht, damit nicht nur der geplante Discovery-Profile-Snapshot, sondern auch der tatsächlich durchlaufene Pfad je `ReconciliationRunItem` nachvollziehbar wird.

Die wichtigsten Punkte für dein Gespräch mit ED sind:

1. **Keine zusätzliche `DiscoveryExecution`-Entität einführen.** `ReconciliationRunItem` ist bereits die passende Ausführungsklammer. Darunter reicht `DiscoveryStepExecution`.

2. **`sequence` allein ist als Step-Identität zu schwach.** Jeder Profil-Step sollte zusätzlich einen stabilen `step_key` bekommen. `sequence` beschreibt nur die Reihenfolge; `step_key` die Identität eines Steps über Profiländerungen hinweg.

3. **`CandidateDiscoveryEvidence` als n:m-Relation ist richtig.** Ein Candidate kann über mehrere Steps gefunden werden, soll aber nur einmal als `CandidateItem` existieren. Die verschiedenen Fundstellen müssen als eigene Discovery-Evidenzen erhalten bleiben.

4. **`step_rank` und `step_score` gehören auf die Evidence-Ebene.** Derselbe Candidate kann in verschiedenen Steps unterschiedliche Rank-/Score-Werte haben. `CandidateItem.rank/score` sollten dagegen nur den final konsolidierten Profil-Output darstellen.

5. **`DiscoveryResponseCapture` sollte direkt an `DiscoveryStepExecution` angebunden werden.** Die bestehende Relation zu `ReconciliationRunItem` würde ich zunächst aus Migrations-/Debug-Gründen zusätzlich behalten.

6. **Die Statuswerte `EXECUTED`, `SKIPPED`, `FAILED` reichen für v0.1.** Ein separates `condition_result` halte ich derzeit nicht für notwendig; bei komplexeren Conditions kann später ergänzt werden.

7. **Profile müssen versionierbar und immutable sein.** Ein bereits verwendetes Profil darf nicht still verändert werden. Lieber `v0.2` anlegen als `v0.1` inhaltlich überschreiben. Für Phase 6 sollte im Run-Snapshot eindeutig erkennbar sein, welche Profilversion verwendet wurde.

8. **Der wichtigste technische Punkt:** Der `DiscoveryProfileExecutor` kennt während der Laufzeit noch Step, Status und Step-Candidates, gibt am Ende aber nur `DiscoveredCandidate[]` zurück. Genau dort geht die Evidence verloren. Deshalb muss die Execution Evidence während der Profil-Ausführung erfasst werden, bevor die Step-Information verschwindet. Ich würde dafür eher einen kleinen `DiscoveryExecutionRecorder` als Application Port ergänzen, statt den bestehenden `CandidateDiscoveryGateway` umzubauen.

9. **Candidate-Deduplication vereinheitlichen.** Aktuell passiert die Konsolidierung nicht überall identisch. Für Profile sollte gelten: gleiche Candidate-URI → ein finaler Candidate, aber jede Fundstelle bleibt als `CandidateDiscoveryEvidence` erhalten.

Mein minimales Zielmodell wäre damit:

```text
ReconciliationRun
    ↓
ReconciliationRunItem
    ↓
DiscoveryStepExecution
    ├── DiscoveryResponseCapture
    └── CandidateDiscoveryEvidence
             ↓
         CandidateItem
```

mit:

```text
DiscoveryStepExecution
- id
- reconciliation_run_item_id
- step_key
- sequence
- status
- candidate_count
- started_at
- finished_at
```

und:

```text
CandidateDiscoveryEvidence
- candidate_item_id
- discovery_step_execution_id
- step_rank
- step_score
```

Damit ist Reconcilix aus meiner Sicht gut für Phase 6 vorbereitet: Ihr könnt dann nicht nur Profile anhand des Endergebnisses vergleichen, sondern konkret analysieren, **welcher Step zusätzlichen Recall gebracht hat, welche Candidates über welchen Pfad kamen, welche Fallbacks häufig oder selten liefen und welche Discovery-Evidenz später zu akzeptierten fachlichen Entscheidungen führte.**