Entscheidungslogik des AI Agent
Für eine MQLS im Zustand AuthorizedShipment gibt es drei zustandskompatible Transitionen:
AcceptFinally → AcceptedFinally: positiver finaler Abschluss. Reject → Rejected: negativer finaler Abschluss. Publish → AuthorizedShipment: veröffentlicht lediglich den aktuellen Stand und beendet die MQLS nicht.
Du musst daher für jede MQLS entscheiden, ob sie endgültig angenommen, endgültig abgelehnt oder zunächst nicht abgeschlossen werden darf.
Erfolgsfall: MQLS kann endgültig angenommen werden
Führe AcceptFinally nur aus, wenn alle folgenden Aussagen nachweislich wahr sind:
Die MQLS befindet sich noch in AuthorizedShipment.
Der ausführende User Context besitzt die Rolle Quality Customer.
Der ausführende Benutzer ist der dieser MQLS zugeordnete Quality Manager.
Mindestens ein zur MQLS gehörender Approval Request ist positiv abgeschlossen beziehungsweise Approved.
Die MQLS erfüllt ihre grundlegende Authority Invariant:
- Reference vorhanden
- Part Number Context vorhanden
- Creator Context vorhanden
Supplier Ownership Context vorhanden.
Die fachlichen Pflichtangaben sind vollständig:
- Type
- Engine Program
- Grouping Applicable
- Heat
- Heat Code
- Heat Code Suffix
- Manufacturing Approval
- Manufacturing Approval Forging Stock
Method of Manufacturing.
Die bedingten Konsistenzregeln sind erfüllt:
Bei Type = Periodic ist Count of Parts nicht leer.
Bei Grouping Applicable = true ist Grouping nicht leer.
Dann sendest du:
qmQaMqlsAuthorityMqlsCommandAcceptFinally
an die zuständige MQLS-Runtime.
Nach erfolgreicher Ausführung muss die Runtime das Domain Event Material Quality Lot Submission Accepted Finally erzeugen. Daraus folgen:
- Zustandswechsel nach AcceptedFinally
- Erzeugung eines Final Letter
- Erzeugung der Annahmebenachrichtigung
- Veröffentlichung des MQLS-Kontexts als Finalized
- Finalisierung der Parent-State-Projektionen von Attachments und Notifications
Stornierung noch offener Approval Requests des finalisierten Parent Contexts.
Approval Request fehlt oder ist noch nicht positiv abgeschlossen
Mögliche Approval-Situationen sind:
Approval-Situation Aktion des Agents
Kein Approval Request vorhanden AcceptFinally nicht ausführen. Zuständige Approval Capability anstoßen oder an den Verantwortlichen eskalieren.
Approval Request ist Created Approval Request mit der vorgesehenen Transition weiterleiten.
Approval Request ist InProcess Auf die Entscheidung warten beziehungsweise die zuständige Genehmigung anfordern.
Approval Request ist Canceled Nur bei fachlich fortbestehendem Genehmigungsbedarf erneut weiterleiten.
Approval Request ist Rejected Entweder begründet neu in den Approval-Prozess geben oder die MQLS endgültig ablehnen.
Approval Request ist Completed und Approved Approval-Bedingung für AcceptFinally ist erfüllt.
Ein offener oder fehlender Approval Request ist kein Grund, die MQLS automatisch abzulehnen. Er bedeutet zunächst nur, dass eine positive finale Annahme noch nicht zulässig ist.
Die MQLS ist fachlich inkonsistent
Ist ApplicationIsConsistent = false, musst du bestimmen, welche Teilprüfung fehlschlägt.
Fehlendes Pflichtfeld
Das fehlende Feld muss im fachlich verantwortlichen Quellsystem ergänzt und die Situation anschließend neu aufgebaut werden.
Periodic-Konfiguration unvollständig
Type = Periodic
AND Count of Parts fehlt
Lösung: Count of Parts ergänzen.
Das formale Modell prüft derzeit lediglich nicht null. Es prüft nicht, ob die Anzahl größer als null ist. Ein Wert 0 könnte daher formal bestehen, obwohl die fachliche Bedeutung eigentlich eine positive Anzahl erwarten lässt. Als AI Agent solltest du diesen Fall kennzeichnen und nicht stillschweigend als fachlich korrekt darstellen.
Grouping-Konfiguration unvollständig
Grouping Applicable = true
AND Grouping fehlt
Lösung: Grouping ergänzen oder fachlich korrekt Grouping Applicable = false setzen.
Nach jeder Korrektur muss ein neues SituationBook erzeugt werden. Eine alte Situationsbewertung darf nicht als Beweis für die korrigierte MQLS verwendet werden.
Grundlegende Authority Invariant verletzt
- Fehlt einer der folgenden Kontexte
- Reference
- Part Number
- Creator
- Supplier Ownership
liegt keine regulär verarbeitbare MQLS vor.
In diesem Fall darfst du weder AcceptFinally noch Reject ausführen, weil die Invariant für beide Transitionen gilt.
Die Lösung ist eine fachliche beziehungsweise technische Datenreparatur. Kann die Identität oder Eigentumszuordnung nicht verlässlich rekonstruiert werden, muss der Fall manuell eskaliert werden. Der Agent muss hier fail-closed reagieren.
Der Agent beziehungsweise User Context ist nicht autorisiert
AcceptFinally und Reject verlangen beide:
Rolle = Quality Customer
AND Current User = zugeordneter Quality Manager Mögliche Probleme:
- Rolle Quality Customer fehlt
- Benutzer ist zwar Quality Customer, aber nicht der zugeordnete Quality Manager
- Quality Manager ist nicht auflösbar
User Context fehlt oder ist unbestimmt.
Lösung: den Vorgang an den tatsächlich zugeordneten Quality Manager mit der Rolle
Quality Customer übergeben. Der Agent darf keine fremde Identität annehmen oder die
Autorisierung durch eine reine Systemrolle umgehen.
Ein Quality Administrator darf zwar unter bestimmten Bedingungen publizieren, ist dadurch aber nicht automatisch zur finalen Annahme oder Ablehnung berechtigt.
Endgültige negative Entscheidung liegt vor
Soll die MQLS fachlich endgültig abgelehnt werden, sendest du:
qmQaMqlsAuthorityMqlsCommandReject
Die Transition führt von:
AuthorizedShipment → Rejected
Für Reject existieren keine zusätzlichen Requirements oder Guards. Erforderlich bleiben jedoch:
- die grundlegende Authority Invariant
- Rolle Quality Customer
Zuordnung als Quality Manager.
Die Ablehnung finalisiert ebenfalls den Parent Context und verhindert eine weitere Genehmigung innerhalb des aktuellen MQLS-Lebenszyklus.
Wichtig ist die Unterscheidung:
- fehlende Information → zunächst nicht entscheiden
- fehlende Genehmigung → Approval-Prozess fortsetzen
nachgewiesener negativer Qualitätsentscheid → Reject.
Bewertung ist UNDETERMINED
Kann eine Bedingung wegen fehlender Bindings, unvollständiger Derivationen oder nicht auflösbarer Runtime-Daten nicht bewertet werden, darf keine finale Transition ausgeführt werden.
Dann gilt:
UNDETERMINED ≠ FALSE
UNDETERMINED ≠ TRUE
Vorgehen:
Materialisierung beziehungsweise Datenzugriff prüfen.
Fehlende Bindings oder Quellwerte auflösen.
SituationBook neu erzeugen.
Erst bei eindeutigem TRUE oder FALSE entscheiden.
Das SemanticMind Core verlangt bei unvollständiger Materialisierung ausdrücklich ein fail- closed-Verhalten. Der Core führt selbst keine Commands aus; der Agent entscheidet auf Grundlage des SituationBooks und übergibt den Command anschließend an die zuständige Domain Runtime.
Empfohlener Agentenablauf
Für jede MQLS in AuthorizedShipment:
Aktuelles SituationBook aufbauen.
Bei ungültiger oder unbestimmter Situation: stoppen und klären.
Authority Invariant prüfen.
Autorisierung des User Context prüfen.
Approval-Situation prüfen.
Anwendungskonsistenz prüfen.
Liegt eine bestätigte negative Entscheidung vor:
Reject ausführen.
1. Sind Approval und Konsistenz positiv: AcceptFinally ausführen.
2. Andernfalls: Ursache beheben und Situation neu bewerten.
3. Nach dem Runtime Event ein neues SituationBook erzeugen.