Eine gemeinsame Kriterienextraktion

Status: angenommen nach unabhängiger Designprüfung. Datum: 21.10.2026.

Anlass

Advanced und V2 lösten dieselbe Aufgabe mit unterschiedlichen Fachmodellen, Startpfaden und Ausführungsregeln. V2 enthielt bereits den fachlichen Ablauf Auftrag/Lose → Dokumentkriterien → Vergleich → Review → Ergänzung. Advanced lieferte zusätzliche Fachfelder sowie Import- und dauerhafte Job-Eigenschaften. Eine reine Umbenennung hätte Felder verloren und die doppelte Verarbeitung erhalten.

Entscheidung

criteria_extraction ist die einzige aktive Pipeline für private und projektbezogene Dokumente. document_intake enthält format- und speicherbezogene Funktionen ohne Abhängigkeit von einem Extraktionsmodell. criteria-1 erweitert den V2-Vertrag um die Kategorie sonstige, strukturierte Anforderungen, Bezugszeiträume, Prüfgegenstand, Nichterfüllungsfolge, Verbindlichkeit, Eignungsreferenz und Notizen. Unbekannte Nachweisangaben bleiben NULL. Pydantic und ein Katalog sind verbindlich; Frontend-Vertrag und Katalog werden deterministisch daraus erzeugt und geprüft.

Bestehende Ergebnistabellen bleiben erhalten. Neutrale Jobs und Checkpoints speichern Manifest, Versionen, Fortschritt und Eigentum. Ein privater Lauf hat eine serverseitige Kontext-ID und NULL für Projekt und Organisation. Der jeweils handelnde Benutzer wird getrennt vom historischen Ersteller autorisiert.

Der API-Aufruf speichert vor Inferenz. Ein Idempotenzschlüssel bezeichnet den ursprünglichen Nutzerauftrag, unabhängig von späteren Modell- oder Ergebnisänderungen. Gezielte Claims, Heartbeats und Schreibzugriffe prüfen gültige Datenbank-Leases. Erfolgreiche Checkpoints sind unveränderlich. Alle Ergebnisse werden gemeinsam veröffentlicht; Ergänzungen und Reviews konkurrieren unter derselben Laufsperre mit Revisionsprüfung. Aktuelle Mitgliedschaften und Dokumentzuordnungen werden erneut in der Veröffentlichungstransaktion geprüft.

Nach Neustart wird keine kostenpflichtige Arbeit automatisch fortgesetzt. Der Benutzer startet bzw. wiederholt ausdrücklich; erfolgreiche Schritte bleiben erhalten. Prozesslokale Tasks dienen nur der Ausführung und dem Herunterfahren. Der Jobstatus kommt aus der Datenbank. Provider-Dateinamen werden für spätere Bereinigung gespeichert, auch wenn das zugehörige Ergebnis inzwischen gelöscht wurde.

Die Oberfläche verwendet einen gemeinsamen Start-, Status- und Reviewpfad. Alte Advanced-Originale, Quellen, Exporte und Auswahlen bleiben lesbar; unbekannte Schemaversionen werden nur als Original angeboten. Alte bezahlte Start-/Retry-Endpunkte antworten mit HTTP 410 und verweisen auf die gemeinsame API. Frühere ADRs dokumentieren historische Implementierungen; diese Entscheidung ersetzt ihre Ausführungsarchitektur.

Konsequenzen und Grenzen

• Neue Fachfelder müssen im kanonischen Modell, der Validierung und den Prompts ergänzt werden; der Generator zeigt abweichende Frontend-Verträge im Test an.
• Fachlich widersprüchliche strukturierte Angaben dürfen nicht still verschwinden. Ein unzulässiger Modellvergleich schlägt sichtbar fehl und bleibt wiederholbar.
• DOCX wird als Textstruktur plus eingebettete Bilder verarbeitet. Nicht unterstützte visuelle Inhalte erscheinen als Warnung. Historische PDF-Konvertierungen bleiben abrufbar; die neue Pipeline benötigt keine doppelte Office-Konvertierung.
• Eine Veröffentlichung ist idempotent. Ein Absturz zwischen Provider-Antwort und erfolgreichem Checkpoint kann bei ausdrücklicher Wiederholung erneut Kosten auslösen. Genau einmalige Abrechnung durch einen externen Anbieter wird nicht zugesichert.
• Additive Migration 202610212330_unified_criteria_extraction.sql ist vor Nutzung erforderlich. Historische Daten werden weder automatisch konvertiert noch neu analysiert.

Nachtrag 01.11.2026: Rückbau auf den v2-Vertrag

Die Übernahme der Advanced-Fachfelder (anforderung, bezugszeitraum, pruefgegenstand, folge_bei_nichterfuellung, verbindlichkeit, zugehoeriges_eignungskriterium_id, review_notizen), der Kategorie sonstige, der erweiterten Fristwerte (vor_zuschlag, waehrend_ausfuehrung, nicht_angegeben) einschließlich leerer frist/herkunft sowie der strengen Merge-Prüfung strukturierter Fachangaben wurde zurückgenommen. Fachlich gilt wieder der v2-Vertrag vom 21.10.2026 (Commit 9d66ece, Schema-Version project-lots-v2.1): sieben Kategorien mit 116 Bezeichnungen, frist genau mit_angebot, mit_teilnahmeantrag oder auf_verlangen als Restkategorie, herkunft genau unternehmensprofil oder angebotsspezifisch, beide nie leer, und die v2-Merge-Regeln. Die gemeinsame Ausführungsarchitektur dieser Entscheidung (Jobs, Worker, Leases, Fortsetzen, Ergänzungen, Dokumentaufnahme, Prompt-Cache, Kostenprotokoll, Entscheidungspause) bleibt unverändert.

Zwischen dem 22.10. und dem 01.11.2026 gespeicherte criteria-1-Ergebnisse sind Altbestand. Sie bleiben über GET /runs/{id} und /criteria lesbar; Review, Fortsetzung und Ergänzung antworten mit HTTP 409 ("nur gelesen und exportiert"). Es gibt keine Datenkonvertierung und keine Migration.

Siehe Service-Vertrag und Abnahmekriterien.