4.5 KiB
Vergleichsengine für Assessment-Läufe
Stand: 2026-07-17
Zugehörige Planphase: Phase 8
Statusklarstellung 2026-09-11
Der folgende Text dokumentiert den historischen Stand, nicht die Abnahme eines belastbaren objektgenauen Timeslotvergleichs. Insbesondere ist die unten beschriebene Regel resolved = im Ziellauf nicht mehr vorhanden kein ausreichender Behebungsnachweis. Die aktuelle Timeslot-Projektion kann Quell-/Verarbeitungsprüfungen umgehen; die automatisch verwendeten Regel-/Definitionsmatches garantieren keine gemeinsame Objektidentität. Die hier historisch genannten Regel-/Asset- und Merkmalsstufen sind kein Nachweis ihrer aktuellen automatischen Verdrahtung.
Die Erweiterung in TIMESLOT_COMPARISON_PLAN.md definiert den Gegenprüfungs-, Identitäts- und Fortschreibungsvertrag sowie P0-P6 mit Abnahmetests. P0 ist abgeschlossen; P1/P2 sind in Arbeit. Der additive Domänenvertrag und compareProjectTimeslotEvidence arbeiten bereits profilgebunden mit echten Scannerläufen, Dateiprovenienz, Processingkompatibilität, eindeutigem Scope und neuerer Reportzeit. Abwesenheit bleibt konservativ ungeklärt. Dieser sichere Pfad ist noch nicht an Persistenz/API oder Oberfläche angebunden und ersetzt daher die unten dokumentierte Legacyengine im Produkt noch nicht; die frühere Beschreibung bleibt zur Nachvollziehbarkeit erhalten.
Zweck
Die Vergleichsengine ordnet Finding-Vorkommen aus zwei Scan-Läufen reproduzierbar ein. Sie arbeitet ausschließlich auf dem kanonischen Assessment-Modell und benötigt weder React noch Browser-, Tauri- oder Datenbankfunktionen.
Originalwerte und Findings werden durch den Vergleich nicht verändert. Das Ergebnis ist ein separates, versioniertes ScanRunComparison.
Matchingstufen
Die Engine verarbeitet eindeutige Kandidaten stufenweise:
- lokal bestätigte Mappingregel
- bereits gemeinsame Finding-Definition oder gemeinsamer kanonischer Schlüssel
- Quellwerkzeug und Regel-ID
- Framework und Control-ID
- Regel-ID und betroffenes Objekt
- normalisierte Merkmalskombination
- Ähnlichkeitsvorschlag
Eine Stufe erzeugt nur dann ein automatisches Match, wenn sowohl das Finding des Basislaufs als auch das Finding des Ziellaufs in dieser Stufe genau einen Partner besitzen. Doppelte Regel-IDs, mehrfach verwendete Controls oder kollidierende Merkmalskombinationen werden deshalb nicht willkürlich aufgelöst.
Die gemeinsame Finding-Definition und lokale Mappingregeln stehen vor neu berechneten Quellschlüsseln, weil sie eine bereits bestätigte fachliche Identität ausdrücken.
Sichere und unsichere Zuordnungen
Tool-/Regel-ID, Control-ID, Regel-/Asset-Kombination und ausreichend vollständige Merkmalskombinationen können bei Eindeutigkeit automatisch zugeordnet werden. Jede Zuordnung enthält Methode, Entscheidung, Konfidenzwert und Begründung.
Textähnlichkeit erzeugt ausschließlich possibly-identical mit der Entscheidung suggested. Ein solcher Vorschlag wird nicht als gemeinsame Finding-Identität gespeichert. Erst createLocalComparisonRule erzeugt nach einer ausdrücklichen Benutzerbestätigung eine serialisierbare Regel. Wird diese Regel bei einem späteren Vergleich übergeben, lautet die Entscheidung user-confirmed.
Vergleichsergebnisse
persistent: in Basis- und Ziellauf eindeutig vorhandennew: im Ziellauf erstmals vorhandenresolved: im Basislauf vorhanden, im Ziellauf nicht mehr vorhandenreoccurred: im Basislauf abwesend, aber in einem älteren Lauf eindeutig vorhandenpossibly-identical: unsicherer, noch zu bestätigender Vorschlagnot-comparable: Assessment, Werkzeug oder Identitätsmerkmale reichen nicht für eine belastbare Aussage
Für sichere Paare werden Änderungen an Severity, Status, Score, Asset und Evidenz getrennt ausgewiesen. Evidenzvergleiche sind unabhängig von der Reihenfolge der Evidenzeinträge.
Reproduzierbarkeit
Eingaben werden nach stabilen IDs und Schlüsseln sortiert. Das Ergebnis enthält keine aktuelle Uhrzeit und hängt nicht von der Reihenfolge der Arrays im Modell ab. Identische fachliche Eingaben liefern daher identische Vergleichsergebnisse.
Grenzen und nächste Schicht
Lokale Mappingregeln werden seit Phase 9 über den Repository-Vertrag verwaltet. Die In-Memory-Referenzimplementierung ist noch keine dauerhafte Produktdatenbank; die konkrete dauerhafte Ablage folgt mit dem Backend- und PostgreSQL-Adapter. Die heutige lokale Oberfläche erzeugt noch kein vollständiges kanonisches Mehrlaufprojekt.