ai-assist Benutzerhandbuch
Fakten
Im Reiter Fakten pflegen Sie Wissenskarten, Berechnungen und Voraussetzungen, die der Chat für freie Antworten, Beratung, Rückfragen und fachliche Bewertung nutzt.
Was Sie hier erledigen
1
2
3
4
5
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Umschalter Wissen & Rechnen | Zeigt Wissenskarten und Berechnungen zum gewählten Service. |
| 2 | Listensteuerung | Sucht, filtert und markiert Wissenskarten. |
| 3 | Detailbereich | Pflegt Titel, Kategorie, Schlüsselwörter, Antworttext und Status. |
| 4 | Status und Aktionen | Stellt Status, Speichern, Hinzufügen, Löschen und gesammelte Statusänderung bereit. |
| 5 | Export | Das Download-Symbol rechts neben der Suche exportiert vorrangig markierte, sonst alle aktuell sichtbaren Wissens- und Berechnungskarten als JSON, CSV oder Markdown. |
Abb. F-01 steht vor der Beschreibung der Wissenspflege. Die linke Liste wählt die Wissenskarte oder Berechnung, der rechte Bereich erklärt den fachlichen Inhalt, die Einordnung und den Status.
1
2
3
4
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Fachlicher Prüfhinweis | Erklärt vor dem Aktivierungsversuch verständlich den Grund der Prüfung. |
| 2 | Beleg und weiterer Schritt | Zeigt den Originalbeleg und erklärt verständlich, was geprüft oder korrigiert werden muss. |
| 3 | Prüfung abschließen | Verlangt eine konkrete Begründung; die Freigabe wird erst ab zehn Zeichen verfügbar. Danach wird genau diese Begründung im grünen Bereich angezeigt. |
| 4 | Status | aktiv ist bei offenem Blocker nicht als normale Statusaktion verfügbar. |
- Wissenskarten als kuratierte Antwortbausteine für einen Service pflegen.
- Berechnungen als geprüfte Rechenlogik für einen Service pflegen.
- Voraussetzungen mit Fragen, Parametern, Bedingungen und Regeln modellieren.
- Einträge per KI vorbereiten und danach fachlich prüfen.
- Aktive Einträge für den Chat freigeben.
- Markierte oder aktuell sichtbare Wissens- und Berechnungskarten sowie Voraussetzungen für Prüfung und Abstimmung exportieren.
Aufbau des Reiters
- Die Umschaltung Wissen & Rechnen und Voraussetzung trennt frei beantwortbares Antwortwissen und geprüfte Berechnungen von Prüflogik.
- Sammlung und Service wählen den fachlichen Kontext.
- Links stehen Suche, Kategorie-Filter, Mehrfachauswahl, KI-Aktion, Neuanlage, Löschen und Listenstatus. Das Download-Symbol befindet sich direkt rechts neben der Suche.
- Die Kopfcheckbox markiert oder entmarkiert alle aktuell sichtbaren Wissens- und Berechnungskarten oder Voraussetzungen.
- Die Zusammenfassung zeigt Trefferzahl, aktive Einträge und die Anzahl markierter Einträge.
- Das Status-Select in der Zusammenfassung setzt den Status der markierten Einträge; ohne Markierung wirkt es auf den aktuell geöffneten Eintrag.
- Der Papierkorb löscht markierte Einträge gemeinsam. Ohne Markierung löscht er den aktuell geöffneten Eintrag.
- Statuspunkte in den Listeneinträgen können direkt weitergeschaltet werden. Bei Voraussetzungen schützt die Oberfläche die Aktivierung, wenn die Regel noch fehlt oder ungültig ist.
- Der Wizard in der Kopfzeile ist beim Start aus Fakten auf Fakten-Aufgaben vorausgewählt. Das Protokollsymbol öffnet das gemeinsame Wizard & KI-> Protokoll und zeigt auch manuell gestartete Fakten-KI→-Läufe und einzelne Regelgenerierungen mit Service, Kategorie, Zeitpunkt und auslösender Person. Der aktuell gewählte Service wird beim Öffnen angesprungen und aufgeklappt.
- Rechts bearbeiten Sie den ausgewählten Eintrag.
Wissenskarten und Voraussetzungen exportieren
Das Download-Symbol steht in Fakten > Wissen & Rechnen und Fakten > Voraussetzung direkt rechts neben Eintrag suchen ... und ist exakt so groß wie die übrigen Aktionsbuttons. Sie benötigen das Leserecht der jeweiligen Sicht, aber kein Schreibrecht. Der Export verändert keine Einträge.
- Wählen Sie Sammlung und Service.
- Wählen Sie Wissen & Rechnen oder Voraussetzung und grenzen Sie die Liste bei Bedarf über Kategorie beziehungsweise Suche ein.
- Markieren Sie einzelne Einträge, wenn nur diese exportiert werden sollen. Markierte Einträge haben Vorrang vor dem sichtbaren Filterergebnis.
- Ohne Markierung werden alle aktuell sichtbaren Einträge exportiert.
- Klicken Sie auf das Download-Symbol und wählen Sie JSON, CSV oder Markdown. Der Browser lädt die Datei unmittelbar herunter.
| Format | Verwendung | Inhalt |
|---|---|---|
| JSON | Maschinelle Auswertung und vollständige technische Prüfung | Versionierter Vollvertrag: bei Karten einschließlich Claims und Berechnungsschema, bei Voraussetzungen einschließlich Teilfragen, Parametern, Regelartefakten und Validierungsstand. |
| CSV | Tabellenprüfung und Sortierung | Eine Zeile je Karte oder Voraussetzung; Listen und strukturierte Felder sind kompakt eingebettet. Formelartige Texte werden für Tabellenprogramme neutralisiert. |
| Markdown | Lesbare fachliche Abstimmung | Eine gegliederte Ansicht der ausgewählten Karten oder Voraussetzungen mit ihren fachlichen Inhalten. |
Der redaktionelle Export ist kein Import-, Restore- oder Backupformat. Er bleibt auf den gewählten Service begrenzt.
Wizard & KI-> Protokoll als Arbeitsliste nutzen
Der Refresh Wizard kann viele Services nacheinander aktualisieren. Nach dem Lauf ist das Wizard & KI-> Protokoll die wichtigste Arbeitsliste: Es zeigt pro Service erfolgreiche Schritte, normale fachliche Prüfaufgaben, konkrete Warnungen und technische Fehlschläge. Öffnen Sie das Protokoll über das Protokollsymbol in Services, Fakten oder Global.
Die Standardsortierung ist Ergebnis Probleme zuerst. Dadurch stehen technisch fehlgeschlagene Services vor Services mit Fachliche Prüfung erforderlich und danach vor Services mit Warnung. Nutzen Sie die Suche, wenn Sie gezielt einen Service bearbeiten möchten. Das Dreieck links im Titel öffnet oder schließt alle sichtbaren Serviceblöcke; das Dreieck am einzelnen Service öffnet dessen Details.
Das Protokoll hält den neuesten Stand je Service und Kategorie fest. Ein späterer kleiner Lauf, zum Beispiel nur für das Glossar, verdeckt deshalb keine offene fachliche Prüfung aus einer anderen Kategorie. Für die Gesamtbewertung gilt immer: technischer Fehler vor fachlicher Prüfung vor Warnung vor Erfolg.
Wenn Sofort aktivieren gewählt ist, merkt der Wizard neu erzeugte Wissens- und Berechnungskarten sowie Glossarbegriffe zunächst nur vor. Erst nachdem alle gewählten Schritte und Aktivierungsprüfungen für den Service abgeschlossen sind, werden diese Einträge und der Service gemeinsam aktiviert. Schlägt diese Abschlussprüfung fehl oder wird der Lauf vorher abgebrochen, bleibt dieser vorgemerkte Satz inaktiv. Die bestehenden Abläufe für Quellen und Voraussetzungen bleiben davon unberührt. Ein fortgesetzter Lauf übernimmt die technischen Laufoptionen und den gespeicherten Zwischenstand; wiederholte identische Aktivierungsaufrufe erzeugen keinen zweiten Aktivierungsvorgang.
Hinweise zu den Quellen werden im geöffneten Schritt und direkt in der betroffenen Wissens- oder Berechnungskarte erklärt. Sie sehen in verständlicher Sprache den Grund, einen Beleg und was als Nächstes geprüft oder korrigiert werden muss. Interne Feldnamen werden nicht angezeigt. Semantische Auffälligkeiten werden nach Ursache gebündelt. Die kompakte Zeile zeigt Anzahl und Status Fachlich prüfen oder Blockiert Aktivierung; aufgeklappt sehen Sie für jeden unterschiedlichen Befund die erzeugte Aussage, die Belegstelle, den vermuteten Unterschied und die empfohlene Aktion. Solange ein blockierender Befund offen ist, ist die normale Statuswahl aktiv gesperrt. Derselbe Quellenmangel kann Wissen, Rechnen und Voraussetzungen betreffen; in der Laufzusammenfassung zählt AIA3 diese gemeinsame Ursache nur einmal, führt aber weiterhin alle betroffenen Objekte auf.
Beim Voraussetzungenlauf trennt das Protokoll die Gesamtextraktion von der Prüfung jedes einzelnen Kandidaten. Liefert die erste Antwort trotz klarer Anspruchssignale keinen lesbaren Kandidatensatz, versucht AIA3 höchstens zwei kompaktere Fassungen. Sobald Kandidaten lesbar sind, bleiben gültige Geschwister unverändert; nur ein fehlgeschlagener Kandidat erhält mit seinem Quellenausschnitt und dem konkreten Prüfgrund bis zu zwei Reparaturfassungen. Eine abgeschnittene JSON-Antwort wird nie teilweise übernommen. Der Server trennt unabhängige Bedingungen, führt eindeutig gleiche Vorschläge samt Quellen zusammen und verwirft reine Berechnungs-, Betrags- oder Auszahlungsangaben ohne eigene Anspruchsbedingung. Eine in derselben Quellbedingung belegte ODER-Alternative, etwa Staatsbürgerschaft oder Gleichstellung, bleibt dagegen bewusst eine gemeinsame Ja/Nein-Voraussetzung, damit daraus nicht fälschlich ein UND wird. Der bestätigte manuelle Neuaufbau ersetzt den Bestand nur, wenn mindestens eine vollständig geprüfte Voraussetzung oder ein bearbeitbarer inaktiver Korrekturentwurf atomar angelegt werden kann. Ein technischer Fehlschlag oder null anlegbare Kandidaten lassen den vollständigen Altbestand unverändert.
| Status im Protokoll | Bedeutung | Was Sie tun |
|---|---|---|
| Technisch fehlgeschlagen | Mindestens ein Wizard- oder Systemschritt ist technisch fehlgeschlagen. | Serviceblock öffnen, roten Eintrag lesen und den passenden Arbeitsbereich über den Statusknopf oder manuell über Services/Fakten öffnen. |
| Fachliche Prüfung erforderlich | AIA3 weist auf eine offene fachliche Aufgabe oder eine konkrete fachliche Auffälligkeit hin. Blockierende Gruppen sind ausdrücklich als Blockiert Aktivierung markiert. | Violetten Eintrag öffnen, Aussage und Beleg fachlich prüfen, bei Bedarf korrigieren und erst danach freigeben. |
| Warnung | Der Schritt hat ein verwertbares Ergebnis geliefert, meldet aber einen konkreten nicht blockierenden Hinweis. Der normale Human Review allein erzeugt keine zusätzliche Warnung. | Gelben Eintrag öffnen und den konkreten Hinweis prüfen. |
| Erfolgreich | Der letzte Eintrag dieser Kategorie ist ohne zusätzliche Auffälligkeit abgeschlossen. KI-generierte Inhalte bleiben trotzdem fachlich zu prüfen. | Inhalt fachlich prüfen und bei Bedarf im Reiter Testen absichern. |
| Nicht durchgeführt | Für diesen Service liegt im aktuellen Protokoll kein Ergebnis vor. | Prüfen, ob der Service im Wizard-Scope enthalten war oder ob die Aufgabe im Wizard abgewählt wurde. |
Prüfungen, Warnungen und technische Fehler der Reihe nach bearbeiten
- Sortierung Ergebnis Probleme zuerst verwenden und den ersten roten, violetten oder gelben Service öffnen.
- Den obersten auffälligen Detail-Eintrag lesen. Wichtig sind Kategorie, Status, Meldung, Zeitpunkt und auslösender Benutzer.
- Bei Aggregierte Quellinformationen in Services wechseln, offene Quellenkonflikte entscheiden, fehlende Quellen ergänzen oder die Aggregation neu erzeugen.
- Bei einem strukturierten Quellenhinweis zuerst die empfohlene Aktion lesen. Fehlende Periode, Grenzwert, Einheit oder Beleg werden in der Quelle ergänzt; widersprüchliche Quellenfassungen werden im Aggregationskonflikt fachlich entschieden. Danach die betroffenen Karten oder Voraussetzungen erneut erzeugen beziehungsweise prüfen.
- Bei Kurze Beschreibung, Lange Beschreibung oder Schlüsselwörter das jeweilige Servicefeld prüfen, korrigieren und speichern.
- Bei Wissen & Rechnen in Fakten > Wissen & Rechnen wechseln. Wissenskarten prüfen und aktivieren. Zeigt die Karte einen Prüfhinweis, korrigieren und speichern Sie den Inhalt zuerst. Bleibt der Hinweis trotz der Prüfung bestehen, geben Sie eine konkrete Begründung ein und wählen Prüfung abschließen und Karte freigeben. Berechnungskarten zusätzlich über Übersicht, JSON-Hilfe und Testbutton prüfen; erst mit vollständigem Schema und erfolgreichem Testfall aktivieren.
- Bei Voraussetzungen in Fakten > Voraussetzung wechseln. Frage, Parameter-ID, Antworttyp, Folgeaktion und Reihenfolge prüfen. Fehlende oder ungültige Regeln mit KI→ erzeugen oder im Regelbereich manuell korrigieren.
- Bei Sofort aktivieren - Voraussetzungen prüfen, ob Quellenkonflikte erledigt sind und ob jede Voraussetzung eine gültige Regel oder eine fachlich ausreichende einfache Frage besitzt. Danach Voraussetzungen bewusst aktivieren.
- Bei Sofort aktivieren - Wissen & Rechnen alle betroffenen Wissens- und Berechnungskarten prüfen. Die Sammelaktivierung überspringt Karten mit blockierenden Befunden und meldet sie als Prüffälle statt als technischen Fehler. Solche Karten werden ausschließlich einzeln nach manueller Korrektur und, falls fachlich erforderlich, mit einer begründeten fachlichen Bestätigung aktiviert.
- Bei Sofort aktivieren - Service zeigt ein erfolgreicher Eintrag den gemeinsamen Abschluss für die vorgemerkten Wissens- und Berechnungskarten, Glossarbegriffe und den Service. Scheitert dieser Abschluss, bleibt dieser vorgemerkte Satz inaktiv; prüfen Sie den ersten blockierenden Detailhinweis und starten Sie erst nach der Korrektur erneut.
- Speichern Sie die Korrektur im jeweiligen Detaildialog. AIA3 gleicht das Protokoll danach im Hintergrund mit dem aktuellen Datenstand ab. Beim erneuten Öffnen sehen Sie den aktualisierten Stand; mit Status können Sie den Abgleich zusätzlich jederzeit manuell auslösen.
Was der Status-Button aktualisiert
Der Button Status vergleicht offene Protokolleinträge mit dem aktuellen Datenstand. Er ersetzt keine fachliche Vollprüfung, erkennt aber typische manuelle Nacharbeiten:
- Offene Aggregationskonflikte wurden gelöst.
- Ein Aktivierungsblocker für Voraussetzungen beruhte auf Quellenkonflikten und diese Konflikte sind erledigt.
- Ein konkret referenzierter Wissens- oder Berechnungsentwurf wurde repariert, in eine passende Wissenskarte umgewandelt oder ersetzt und der aktuelle Kartenbestand ist strukturell gültig.
- Alle Wissens- und Berechnungskarten eines betroffenen Services sind inzwischen aktiv.
- Ein Service, der zuvor nicht aktiviert werden konnte, ist inzwischen aktiv.
Wenn nach Status weiterhin eine fachliche Prüfung oder Warnung sichtbar bleibt, ist der Punkt entweder noch nicht erledigt oder nicht automatisch aus den aktuellen Daten ableitbar. Öffnen Sie dann den Detail-Eintrag erneut, korrigieren Sie den fachlichen Inhalt und starten Sie bei Bedarf die einzelne KI→-Aktion erneut.
Beispiel: Protokollwarnung zu Berechnungskarten
Im Protokoll steht Sofort aktivieren - Wissen & Rechnen mit der Meldung, dass einige Entwürfe zur Prüfung inaktiv geblieben sind. Öffnen Sie den Service in Fakten > Wissen & Rechnen und prüfen Sie den angezeigten Grund und Beleg. Korrigieren und speichern Sie die Karte; testen Sie Berechnungsschemata zusätzlich mit ▶. Eine fälschlich angelegte Berechnung mit festem Betrag können Sie als normale Wissenskarte speichern. AIA3 gleicht den zugehörigen Erzeugungshinweis danach automatisch ab. Bleibt ein fachlicher Quellenhinweis bestehen, tragen Sie eine Begründung ein und wählen Prüfung abschließen und Karte freigeben. Danach zeigt der grüne Bereich Ihre eingegebene Begründung. Beim erneuten Öffnen des Protokolls ist der aktuelle Stand sichtbar; Status stößt den Abgleich bei Bedarf nochmals manuell an.
Beispiel: Protokollproblem durch Quellenkonflikt
Ein Service zeigt Problem, weil Sofort aktivieren - Service blockiert wurde. Im Detail steht, dass noch offene Quellenkonflikte vorhanden sind. Öffnen Sie den Service in Services, klicken Sie Konflikte prüfen, entscheiden oder verwerfen Sie die offenen Informationen mit Begründung und speichern Sie. Danach klicken Sie im Protokoll Status. Die erledigten Aggregations- und Aktivierungsblocker wechseln auf Erfolgreich; den Service aktivieren Sie erst nach fachlicher Kontrolle und Testdialog.
Arbeitsablauf: Wissenskarten anlegen
Wissenskarten beantworten freie Fragen in der Startberatung. Sie sind kein Ersatz für Voraussetzungen und kein Glossar: Begriffe gehören in Global > Glossar, prüfbare Bedingungen in die Sicht Voraussetzung.
- Wählen Sie Sammlung und Service.
- Öffnen Sie die Sicht Wissen & Rechnen.
- Lassen Sie Wissenskarten und mögliche Berechnungsentwürfe per KI aus der aktuellen
aggQuellevorbereiten. - Nutzen Sie Suche und Kategorie-Filter, um fachlich zusammengehörige Karten zu prüfen.
- Prüfen Sie pro Karte Titel, Kategorie, Schlüsselwörter und Antworttext fachlich.
- Prüfen Sie bei einem Bedeutungswarnhinweis den angezeigten Originalbeleg gegen die erzeugte Aussage. Negation, Verpflichtungsgrad, Zahlungsrichtung, Akteur und Geltungsbereich dürfen sich nicht verändern. Blockierende Hinweise halten den neuen Entwurf inaktiv; eine Vermischungswarnung bleibt eine Entscheidung des Fachbereichs.
- Korrigieren und speichern Sie Karten mit Prüfhinweis. Ist die Ursache danach geklärt, aber der Hinweis weiterhin vorhanden, beschreiben Sie Ihre Prüfung im Begründungsfeld und wählen Prüfung abschließen und Karte freigeben. KI-Reparatur und Sammelaktivierung dürfen diesen Schritt nicht ausführen.
- Gleich benannte, aber fachlich unterschiedliche KI-Vorschläge erhalten einen kurzen Titelzusatz. Bei ungewöhnlich vielen Einzelkarten zeigt das Wizard-/KI-Protokoll eine Warnung; vorhandene Karten werden dadurch nicht gelöscht.
- Entfernen Sie reine Begriffserklärungen oder verschieben Sie sie ins Glossar.
- Aktivieren Sie nur Karten, die fachlich geprüft und verständlich formuliert sind.
- Prüfen Sie freie Fragen in Testen und bei Bedarf in der QS-Startberatung.
Beispiel: beantwortbare Wissensfrage
Eine Karte zur Frage „Welche Unterlagen brauche ich?“ enthält eine kurze Antwort mit den wichtigsten Nachweisen, passenden Schlüsselwörtern und einer Kategorie wie Nachweise. Die Karte wird erst aktiviert, wenn der Fachbereich die Antwort bestätigt hat.
Beispiel: Berechnungsentwurf prüfen
Wenn die Quelle eine Formel, eine Flächenstaffel oder eine Einkommensgrenze enthält, kann KI→ zusätzlich eine Berechnung vorbereiten. Prüfen Sie Eingabefragen wie Erwachsene im Haushalt, Kinder im Haushalt, Wohnfläche oder Einkommen, kontrollieren Sie Rechenschritte und Testfall und aktivieren Sie die Berechnung erst nach erfolgreicher Prüfrechnung.
Berechnungsschema manuell korrigieren
Berechnungskarten enthalten im Feld Berechnungsschema die strukturierte Rechenlogik als JSON. Im normalen Zustand sehen Sie eine kompakte Übersicht mit Eingaben, Rechnung, Ergebnis und Status. Über den Stift öffnen Sie den JSON-Editor. Der ?-Button am Feld öffnet eine ausführliche Hilfe mit Aufbau, Beispielen und typischen Korrekturen. Der Testbutton ▶ führt die gespeicherten Testfälle aus und zeigt Ergebnis, Erwartungswert und Rechenschritte in einem Overlay.
Nutzen Sie manuelle Korrekturen, wenn der fachliche Inhalt klar ist und nur die Struktur angepasst werden muss. Wenn Grenzwerte, Perioden, Staffeln oder Quellen unklar sind, korrigieren Sie zuerst die Quelle oder lassen Sie die betroffene Karte erneut mit KI→ vorschlagen. Werte dürfen nicht geraten werden.
inputsenthält die Fragen an den Benutzer.idist der gespeicherte Eingabewert,varder kurze Name für Formeln.- Auswahl- und Ja/Nein-Werte, die schon aus einer Chatfrage übernommen werden sollen, brauchen eindeutige Werte und Aliase in
choices,options,allowed_valuesoderenum. Allgemeine Wörter aus Beschriftung oder Frage werden nicht als Antwort geraten. stepsenthält Rechenschritte. Jeder Schritt braucht eine eindeutigeidund eine Operation wieformula,min,max,lookupoderround.- Bei einem Höchstbetrag pro Tag, Woche, Monat oder Jahr und einem Gesamtzeitraum muss
inputsdie passende Anzahl enthalten.stepsmultipliziert zuerst den Periodenbetrag mit dieser Anzahl; erst danach wird mit Kosten oder einer Gesamtgrenze gedeckelt. Das Ergebnis wird als Gesamtzeitraum bezeichnet. Ein ausdrückliches Ergebnis pro Tag, Woche, Monat oder Jahr ist dagegen eine Einperiodenberechnung und benötigt keine Periodenanzahl; Zeitangaben aus einem fachlich anderen Quellenabschnitt dürfen sie nicht zum Gesamtzeitraum machen. resultlegt fest, welcher Schritt ausgegeben wird und welche Einheit oder Rundung gilt.test_casesenthält mindestens eine Prüfrechnung mit Beispielwerten und erwartetem Ergebnis. Ohne erfolgreichen Testfall kann die Berechnung nicht aktiviert werden.
Beispiel: einfache Tagespauschale
Dieses Schema fragt eine Anzahl Tage ab, multipliziert mit 20 Euro und prüft den Fall „3 Tage = 60 Euro“.
{
"schema_version": 1,
"inputs": [
{
"id": "calculation.days",
"var": "days",
"label": "Tage",
"question": "Für wie viele Tage gilt der Zuschuss?",
"data_type": "number",
"required": true
}
],
"steps": [
{ "id": "amount", "op": "formula", "expression": "days * 20" }
],
"result": { "step": "amount", "unit": "EUR", "rounding": "whole_eur" },
"test_cases": [
{ "inputs": { "calculation.days": 3 }, "expected_result": 60 }
]
}
Beispiel: Mindest- und Höchstbetrag
Funktionsaufrufe wie min(...) oder max(...) gehören nicht in eine Formel. Modellieren Sie sie als eigene Rechenschritte, damit die Aktivierungsprüfung die Berechnung nachvollziehen kann.
"steps": [
{ "id": "raw_amount", "op": "formula", "expression": "income * 0.1" },
{ "id": "capped_amount", "op": "min", "values": ["raw_amount", 300] },
{ "id": "amount", "op": "max", "values": ["capped_amount", 50] }
],
"result": { "step": "amount", "unit": "EUR", "rounding": "whole_eur" }
| Status im Berechnungsschema | Bedeutung und Korrektur |
|---|---|
| Schema vollständig | Pflichtteile und Testfall sind vorhanden. Prüfen Sie trotzdem fachlich und aktivieren Sie erst danach. |
| Schema unvollständig | Eingaben, Rechenschritte oder Ergebnis fehlen. Ergänzen Sie den fehlenden Bereich. |
| Periodenanzahl fehlt | Eine Mehrperiodenfrage darf nicht mit einem einzelnen Tages-, Wochen-, Monats- oder Jahresbetrag beantwortet werden. Lassen Sie die Karte nach korrigierter Quelle erneut über KI→ erzeugen oder ergänzen Sie Anzahl, Multiplikation und Testfall fachlich geprüft. |
| Testfall fehlt | Ergänzen Sie mindestens einen realistischen Testfall mit inputs und expected_result. |
| JSON ungültig | Prüfen Sie Klammern, Kommas und Anführungszeichen im Editor. |
| Formelsyntax prüfen | Lagern Sie min, max, clamp oder ähnliche Funktionslogik in eigene Rechenschritte aus. |
Testlauf nach einer Korrektur
Speichern Sie das geänderte Schema und klicken Sie danach auf ▶. Das Overlay zeigt je Testfall, ob der erwartete Wert erreicht wurde. Klappen Sie Schritte anzeigen auf, wenn Sie sehen möchten, welcher Zwischenschritt einen falschen Wert erzeugt. Ungespeicherte Änderungen werden nicht getestet.
Arbeitsablauf: Voraussetzungen anlegen
Der gemeinsame KI→- und Wizard-Pfad erzeugt Fragen, Parameter, Decision-IR, Testfälle und die deterministische JavaScript-Regel als zusammengehörigen Kandidaten. Beim manuellen KI→-Lauf erscheinen die Ergebnisse in einem kompakten Overlay. Die Zusammenfassung unterscheidet erstellt, erstellt · manuell prüfen, nicht erstellt und gegebenenfalls verworfen; vollständig übernommene Kandidaten sind zunächst eingeklappt, offene Prüffälle geöffnet. Der Fakten-Detailbereich bleibt dadurch nutzbar.
Beim manuellen KI→-Aufruf weist ein kurzer Dialog darauf hin, dass bestehende Voraussetzungen durch das neue, vollständig geprüfte Ergebnis ersetzt werden. Mit Abbrechen bleibt alles unverändert; erst Neu erstellen startet die vollständige Erzeugungskette. Ein fehlgeschlagener Lauf oder ein Lauf ohne übernahmefähige Voraussetzung löscht den bisherigen Bestand nicht. AIA3 liest Voraussetzungen aus den aggregierten Quellen, ermittelt Fakten und benötigte Eingaben, erzeugt Fragen und Parameterbindungen und kompiliert daraus eine geprüfte JavaScript-Regel. Eine vollständig in der Quelle genannte Mindestdauer wird dabei als direkt beantwortbare Ja/Nein-Frage angelegt, zum Beispiel Haben Sie seit mindestens sieben Monaten Ihren Hauptwohnsitz im Burgenland? AIA3 verlangt dafür weder ein genaueres Startdatum noch eine Dauerzahl und kann die source-belegte Ja-Antwort unmittelbar zu einer gültigen Regel kompilieren. Fehlt der eindeutige Quellenbeleg, bleibt der Kandidat stattdessen auf Review nötig. Vollständig erkannte Regeltabellen werden direkt aus ihrer strukturierten Aggregationsfassung verarbeitet; die sichtbare Markdown-Tabelle bleibt als prüfbarer Quellenbeleg erhalten. Die Bezeichnung wird immer als kurzer deutscher Titel mit zwei bis fünf Wörtern erzeugt, etwa Hauptwohnsitz Burgenland oder Mindestentfernung 30 km. Itemliste, Detailkopf und Feld Bezeichnung der Voraussetzung zeigen denselben Titel; die vollständige Bedingung bleibt im Hinweis der Frage und im Quellenbeleg erhalten. Vor der Übernahme werden die Parameter-IDs mit der globalen Parameterliste abgeglichen und in Frage, Regel und Decision-IR einheitlich verwendet.
Das Ergebnis erscheint als schreibgeschütztes KI-Protokoll Voraussetzungen. Für jede erkannte Voraussetzung zeigt es genau sechs Schritte: Quelle, Fakten und Eingaben, Fragen und Parameter, JavaScript-Regel mit Prüfung, Übernahme sowie den sicheren Abschluss aus Parameterabgleich, Aktivierung und Service-Bereitschaft. Erstellt · aktiv bedeutet, dass dieser Kandidat vollständig geprüft und bei aktueller, konfliktfreier Quellenbasis aktiviert wurde. Andere offene Kandidaten verhindern das nicht. Erstellt · manuell prüfen bedeutet, dass brauchbare Fragen und Parameter als inaktive Voraussetzung angelegt wurden. Sie können diese Voraussetzung nach dem Schließen des Protokolls im normalen Faktenformular korrigieren; automatisch aktiviert wird sie nicht. Erstellt · Aktivierung blockiert bedeutet, dass eine vollständig angelegte Voraussetzung wegen eines gemeinsamen Abschlussguards inaktiv bleibt. Nicht erstellt bedeutet, dass keine editierbare Frage-/Parameterstruktur erzeugt werden konnte. Das Protokoll enthält keine Bearbeitungs-, Ablehnungs-, Freigabe-, Auswahl-, Übernahme- oder Aktivierungsaktion.
Öffnen Sie eine Protokollkarte, um Quellenbelege, erkannte Fakten, konkrete Fragen und Parameter, den JavaScript-Code, Testvektoren sowie Übernahme- und Aktivierungsgründe nachzuvollziehen. Kurze Bezeichnung, Bürgerfrage und fachlicher Hinweis werden getrennt erzeugt; der vollständige Hinweis wird nicht durch den Listentitel ersetzt. Eine leere oder strukturell unlesbare Gesamtextraktion wird bei klaren Anspruchssignalen höchstens bis zur dritten Fassung wiederholt. Liegt ein lesbarer Kandidatensatz vor, bleiben gültige Voraussetzungen unverändert; nur ein fehlgeschlagener Kandidat erhält mit seinem Quellenausschnitt und dem konkreten Prüfgrund höchstens zwei gezielte Reparaturfassungen. Unter JavaScript-Regel kompiliert und geprüft zeigt das Protokoll jeden solchen Validierungs- und Reparaturversuch mit Status und Ursache. Bleibt der Kandidat offen, werden vorhandene Fragen und Parameter als inaktiver Korrekturentwurf gespeichert. Korrigieren Sie ihn nach dem Schließen des Protokolls im normalen Faktenformular; fehlt bereits diese editierbare Struktur, bleibt der Kandidat nur im Protokoll. Ein unbekannter Parameter wird nicht als OLD:-Teilergebnis akzeptiert. Zusätzliche paarige Anführungszeichen um ein ansonsten exaktes Quellenzitat werden technisch bereinigt und lösen allein keinen Prüfblocker aus.
Sie können das Protokoll schließen, den Reiter verlassen und den zuletzt geöffneten Lauf später für denselben Service über das Symbol KI mittig vor einer Liste neben KI→ erneut öffnen. Ist mindestens eine Voraussetzung noch nicht über alle sechs Schritte vollständig abgeschlossen, erscheint dieser Knopf rot; ein vollständiger Lauf bleibt neutral. Der Tooltip lautet Letztes Voraussetzungen-KI-Protokoll öffnen. Beim Ansteuern des Reiters öffnet sich das Protokoll nicht automatisch. Ein abgebrochener Langlauf bleibt mit seinem Grund erhalten; ein erneuter Start mit demselben Laufbezug setzt ihn fort, ohne einen zweiten Kandidatenbestand anzulegen.
Erstellt · manuell prüfen ist ein nutzbares Teilergebnis und kein globaler Fehler. Ergänzen Sie fehlende Periode, Polarität, Tabellendimension oder Quelle und validieren Sie erneut. Freie ältere KI-Regelentwürfe können als Hinweis sichtbar sein, werden aber nie automatisch als sicher freigegeben.
1
2
3
4
5
6
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Umschalter Voraussetzung | Wechselt von Wissen zu prüfbaren Voraussetzungen. |
| 2 | Voraussetzungsliste | Zeigt, sucht, markiert und ordnet vorhandene Voraussetzungen des Services. |
| 3 | Frage | Definiert, was der Chat abfragt; darunter folgen Beschreibung und Parameterzuordnung. |
| 4 | Prüfregel und Prüfstatus | Zeigt den Regelcode, die KI-Aktion und den aktuellen Prüfstatus. |
| 5 | Statusaktionen | Aktiviert, speichert oder löscht die Voraussetzung. |
| 6 | Export | Das Download-Symbol rechts neben der Suche exportiert vorrangig markierte, sonst alle aktuell sichtbaren Voraussetzungen als JSON, CSV oder Markdown. |
Abb. F-02 zeigt die Sicht, auf die sich der folgende Arbeitsablauf bezieht: Voraussetzung auswählen, Frage pflegen, Parameter binden, Regel prüfen und erst danach aktivieren.
1
2
3
4
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Fachlicher Prüfhinweis | Zeigt, welcher Quellen-, Beleg- oder Zahlenprovenienzbefund die normale Aktivierung blockiert. |
| 2 | Nächster Prüfschritt | Beschreibt die empfohlene fachliche Prüfung; technische, strukturelle und unbekannte Fehler bieten keine Freigabeaktion. |
| 3 | Begründung | Dokumentiert die fachliche Entscheidung mit mindestens zehn Zeichen und wird zusammen mit der angemeldeten Person auditiert. |
| 4 | Manuelle Freigabe | Gibt nur den geprüften aktuellen Inhalt frei. Änderungen an Regel, Fragen, Parametern, Decision-IR oder Quellenstand entwerten die Freigabe. |
1
2
3
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Laufzusammenfassung | Trennt erstellte, manuell zu prüfende und nicht erstellte Kandidaten. |
| 2 | Abgeschlossener Kandidat | Zeigt sechs abgeschlossene Schritte und den Zustand erstellt · aktiv. |
| 3 | Korrekturentwurf | Zeigt, wie viele Schritte abgeschlossen sind und dass der Eintrag manuell geprüft werden muss. |
Die kurze deutsche Bezeichnung steht identisch in der Itemliste, im Detailkopf und im Feld Bezeichnung der Voraussetzung. Darunter folgen die vollständigen Fragen und die Prüfregel. Kurztitel, Bürgerfrage und Hinweis haben unterschiedliche Aufgaben: Die Frage wird direkt und als vollständiger Fragesatz formuliert; der Hinweis erklärt die fachliche Bedingung als vollständigen Aussagesatz. Ein Kurztitel wie Hauptwohnsitz Burgenland darf nicht zugleich als Frage oder Hinweis verwendet werden. Lange ältere Bezeichnungen zeigt die Oberfläche automatisch als kompakten deutschen Titel; der vollständige fachliche Text bleibt im Hinweis der Frage erhalten. Im Kopf der Prüfregel erzeugt KI→ den Code; das Fragezeichen öffnet eine kompakte Hilfe zu Format, Parameterzugriff, Datentypen und Rückgabewerten. Auf breiten Ansichten stehen die Hinweise links und das Codebeispiel rechts, auf schmalen Ansichten untereinander. Der Text Neu, Aktiv oder Inaktiv gehört zum Status der Voraussetzung; ✓ Regel gültig bestätigt separat die erfolgreiche Regelprüfung. Eine vorhandene Regel ohne Validierung wird als Regel ungeprüft angezeigt.
Der vollständige Regelcode bleibt direkt im Editor sichtbar und vertikal vergrößerbar. Eine deterministische Einkommens- oder Bemessungsstaffel zeigt AIA3 als kurze Fachlogik: Eingaben, Grenzwerttabelle, ausdrücklich belegte Zuschläge und abschließender Vergleich. Decision-IR, Quellenbelege und Prüfdaten bleiben getrennt im Datensatz und Protokoll. Nur tatsächlich komplexe Entscheidungsgraphen benötigen weiterhin den technischen Universal-Unterbau. Ältere, kompakt gespeicherte Decision-IR zeigt AIA3 automatisch mehrzeilig eingerückt in einer Code-Schrift an. Diese Darstellung ändert die Prüfung nicht. Geänderter Code erscheint bis zum Speichern und Prüfen als Entwurf ungeprüft.
Ist eine einzelne Voraussetzung als Review nötig oder Inaktiv angelegt, öffnet KI→ im Regelbereich zuerst den Dialog Regel neu erstellen. Dort durchsuchen Sie die aktiven Wissenskarten desselben Services nach Nummer, Titel, Kategorie, Schlagwort, Antworttext oder Berechnungsschema und wählen bei Bedarf mehrere Karten als Berechnungsgrundlage aus. Lange Antworten erscheinen zunächst als dreizeilige Vorschau; mit Mehr anzeigen öffnen Sie den vollständigen Kartentext und mit Weniger anzeigen klappen Sie ihn wieder zu. Aufklappzustand und Markierung bleiben erhalten, während Sie nacheinander nach weiteren Karten suchen; bis zu zwölf Karten können gemeinsam verwendet werden. AIA3 leitet daraus und aus den aktuellen Quellen die erforderlichen Rohdatenfragen und Parameter neu ab und kompiliert anschließend die Regel. Eine direkt beantwortbare Mindestdauer bleibt dabei eine vollständige Ja/Nein-Frage, zum Beispiel Wohnen Sie schon seit mindestens zwei Jahren …?; AIA3 verlangt kein genaueres Startdatum und korrigiert einen fehlenden Entscheidungsbeleg einmal gezielt. Bei anderen Ja/Nein-Fragen kann je nach sichtbarer Frage und Quelle Ja oder Nein die Voraussetzung erfüllen. Reine Hinweise zur Berechnung, Zählung oder Umklassifizierung werden nicht als eigenständige Ja/Nein-Regel erzeugt; AIA3 weist stattdessen darauf hin, dass sie als Rohdaten in die zugehörige Gesamtregel gehören. Die Karten dienen nur als Strukturhinweise; Grenzwerte und Tabellen müssen weiterhin in den aktuellen Quellen belegt sein. Ohne Auswahl wird ausschließlich mit den aktuellen Quellen gearbeitet. Abbrechen lässt die Voraussetzung unverändert. Auch ein erfolgreich neu aufgebauter Eintrag bleibt zunächst inaktiv und wird erst über die normale Statusaktion aktiviert.
1
2
3
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Volltextsuche | Filtert aktive Wissenskarten nach Titel, Inhalt, Kategorie, Schlagwort und Berechnungsschema. |
| 2 | Kartentext und Mehrfachauswahl | Mehr anzeigen öffnet den vollständigen Kartentext. Bis zu zwölf Karten können markiert werden; Treffer- und Auswahlzahl bleiben sichtbar. |
| 3 | Quellenhinweis und Aktionen | Nur aktuelle Quellen gelten als Beleg. Abbrechen erhält den Eintrag; Neu erstellen startet den kontrollierten Neuaufbau. |
- Wählen Sie Sammlung und Service.
- Öffnen Sie die Sicht Voraussetzung.
- Legen Sie eine Voraussetzung an oder lassen Sie sie per KI vorschlagen.
- Pflegen Sie eine verständliche Frage und binden Sie einen passenden Parameter.
- Definieren Sie den Antworttyp. Bedingungen und Folgeaktion pflegen Sie nur bei einer Voraussetzung mit mehreren Fragen.
- Nutzen Sie den Regelbereich für fachliche Logik, die nicht allein aus der Frage entsteht. Bei einem unvollständigen KI-Entwurf können Sie über KI→ aktive Wissenskarten volltextlich suchen, lange Kartentexte vollständig aufklappen und mehrere passende Karten als Berechnungsgrundlage markieren.
- Ordnen Sie die Voraussetzung per Drag-and-drop fachlich sinnvoll ein.
- Testen Sie den Dialog in Testen, bevor Sie aktivieren.
Beispiel: einfache Ja/Nein-Voraussetzung
Für die Frage „Haben Sie Ihren Hauptwohnsitz im Bundesland?“ wählen Sie den Antworttyp Ja/Nein, binden den Parameter hauptwohnsitz_bundesland und aktivieren die Voraussetzung erst nach einem Testdialog. Bei dieser einzelnen Frage werden Weiter mit und …wenn Antwort ist nicht angezeigt; die Antwort wird direkt im Regelbereich bewertet.
Beispiel: Regel mit mehreren Angaben
Für eine Einkommensgrenze können mehrere Fragen nötig sein, etwa haushaltspersonen und nettoeinkommen_monat. In diesem Fall bleiben die Fragen getrennt, aber die Voraussetzung bekommt eine Regel, die beide Parameter gemeinsam bewertet. Nach einer Änderung an einer Parameter-ID muss die Regel bewusst neu geprüft werden.
Erst bei mindestens zwei Fragen zeigt AIA3 die Felder Weiter mit und …wenn Antwort ist. Damit können Sie Folgefragen überspringen oder den Fragenblock vorzeitig abschließen. Bei genau einer Frage sind diese Angaben weder manuell noch für einen KI-Vorschlag erforderlich.
Betrifft eine Detailfrage eine weitere, andere oder zusätzliche Person im Haushalt, erzeugt AIA3 einen bedingten Zweierschritt: Zuerst wird gefragt, ob mindestens eine solche Person im Haushalt lebt. Bei Nein ist keine Detailangabe nötig und der Fragenblock wird positiv abgeschlossen; nur bei Ja folgt zum Beispiel die Frage nach Einkommen oder Status dieser Person. Prüfen Sie bei manuell gepflegten Altbeständen dieselbe Reihenfolge und die Folgeaktion Voraussetzung erfüllt für die Antwort Nein.
Bei einer Einkommensstaffel nach Kinderzahl ergänzt der KI-Vorschlag die benötigte Anzahlfrage im selben Prüfblock. Prüfen Sie anschließend, ob die Regel die Kinderzahl und die Einkommensbeträge gemeinsam verwendet, einschließlich des Zuschlags für weitere Kinder. Sind aggregierte Quellen und Wissenskarten bereits vollständig, erzeugen Sie nur die Voraussetzungen und deren Regeln erneut.
Der Tabellen-Guard richtet sich nach der strukturiert erkannten Staffel und nicht nach einer bestimmten Überschrift. Deshalb werden auch Bezeichnungen wie Bemessungsgrundlage als Einkommensprüfung verarbeitet: AIA3 ergänzt bei ein- und mehrstufigen Tabellen Einkommen beziehungsweise Bemessungsgrundlage, Anzahl Erwachsene und Anzahl Kinder und kompiliert den Vergleich samt belegten Fortschreibungen. Die sichtbaren Angaben bleiben dabei in einem gemeinsamen Prüfblock; die passende Haushaltsgrenze wird intern ausgewertet. Unterschiedliche technische Tabellenformen einer KI-Antwort werden zuvor aus den exakten Quellzeilen in eine einheitliche Tabellenstruktur überführt; vollständig belegte Einkommensstaffeln benötigen deshalb keinen zufällig passend formatierten Reparaturversuch.
Steht in allen Zeilen dieselbe Erwachsenenanzahl und ändert sich nur die Kinderzahl, wird die Erwachsenenanzahl nicht zusätzlich als Staffeleingabe abgefragt. Bei wechselnder Erwachsenenanzahl oder einem Zuschlag je weiterem Erwachsenen bleibt sie erforderlich. Eigenständige Bedingungen zur Haushaltszusammensetzung werden weiterhin geprüft.
Die sichtbare Einkommensfrage nennt die in der Quelle belegte Bezugsperiode ausdrücklich, zum Beispiel „Wie hoch ist Ihr Netto-Haushaltseinkommen pro Monat?“ oder „Wie hoch ist Ihr Jahres-Nettoeinkommen?“. Eine Periodenangabe nur in der Beschreibung oder Parameter-ID reicht nicht. Fehlt sie in der servicebezogenen Darstellung, darf eine konfigurierte Richtlinienanlage pro Monat oder pro Jahr nur ergänzen, wenn Haushaltszeilen, Grenzwerte und Zuschläge exakt dieselbe Einkommensmatrix bilden. Fehlt dieser eindeutige Match oder widersprechen sich die Angaben, bleibt die Voraussetzung als Review nötig inaktiv. AIA3 leitet aus einem hohen Betrag nicht automatisch ein Jahreseinkommen ab.
Die KI soll Bürger:innen nicht fragen, ob sie eine Rechts- oder Einkommensgrenze selbst erfüllen. Erkennt AIA3 eine solche Ja/Nein-Selbsteinschätzung, wird gezielt ein Reparaturvorschlag mit den belegten Rohdatenfragen erzeugt, zum Beispiel zum monatlichen Netto-Haushaltseinkommen sowie zur Zahl der Erwachsenen und Kinder. Die Grenzprüfung selbst bleibt in der serverseitigen Regel. Wurde der erste Modellaufruf am Antwortlimit abgeschnitten, übernimmt AIA3 kein offenes Teil-JSON. Vollständig abgeschlossene Einträge dürfen nur anhand eindeutig festgestellter Bestandslücken gezielt vervollständigt werden; andernfalls folgt der streng kompakte Fallback.
Kann eine Einkommensgrenze nicht aus der Quelle erkannt oder vollständig zugeordnet werden, bleibt die Voraussetzung mit einem Prüfhinweis auf nicht aktiv. Ergänzen oder korrigieren Sie die Quelle beziehungsweise die benötigten Fragen und erzeugen Sie danach die Regel erneut.
Decision-IR und JavaScript-Regel im Regelbereich
Bei neuen KI-Vorschlägen erzeugt AIA3 einen gemeinsamen Entscheidungsgraphen. Eine einfache atomare Ja/Nein-, Gleichheits- oder Schwellenprüfung mit wörtlichem Quellenbeleg wird direkt aus dem extrahierten Beleg aufgebaut; dafür ist kein zusätzlicher freier Regelvorschlag nötig. Unsichere, komplexe oder unvollständig belegte Fälle bleiben im bisherigen KI- und Prüfpfad. Aus dem gültigen Graphen werden Fragenfolge, Sprünge, automatische Testfälle und die im Regelbereich sichtbare JavaScript-Funktion gemeinsam abgeleitet. Platzhalterwerte sind nicht zulässig. Fehlende Grenzwerte müssen fachlich aus den Quellen geklärt werden. Bleibt der Graph oder seine Quellenprüfung ungültig, wird die Voraussetzung auf nicht aktiv gesetzt. Eine technisch ausführbare Regel hebt einen Quellen- oder Fachfehler nicht auf. Prüfen Sie auch bei formal gültigem Code, ob Staffel, Bedingungen und Ausnahmen richtig umgesetzt sind.
Bei Ja/Nein-Fragen bezieht sich die erwartete Antwort immer auf den sichtbaren Fragetext: Ja entspricht true, Nein entspricht false – auch bei einer Frage wie „Bestehen keine Rückstände?“. AIA3 dreht diesen Wert nicht nochmals wegen Wörtern wie „kein“ oder „nicht“ in Parameter-ID, Beschreibung oder Quelle um. Widersprüchliche Angaben bleiben als Review nötig inaktiv.
Wenn ein neuer Kandidatensatz weiterhin belegte Bestandsbedingungen verlieren würde, wird er nicht sofort gespeichert. AIA3 prüft nach Rollenfilterung und Dublettenzusammenführung die fachlichen Dimensionen jeder alten Bedingung und versucht höchstens eine gezielte Coverage-Reparatur. Bleibt beispielsweise ein eigenständiger Vertrag oder eine Antragstellergruppe weiterhin belegt, muss sie im neuen Satz semantisch erhalten sein. Andernfalls bleibt der bisherige Bestand vollständig bestehen.
Zusammengesetzte Einkommensbegriffe wie Haushaltseinkommen und passende kundenspezifische Erkennungsbegriffe aus der aktiven Fachprofil-Kategorie Einkommen werden bei dieser Prüfung berücksichtigt. Das Fachprofil ergänzt nur die Begriffserkennung; es legt keine Anspruchsregel fest und aktiviert keine Voraussetzung. Muss AIA3 eine weiterhin belegte Bedingung ergänzen, wird nur diese Lücke an den Reparatur-Prompt übergeben und nicht der bereits gültige Kandidatensatz neu erzeugt. Dabei bleiben alle für die Bedingung benötigten Rohdatenfragen erhalten: Eine Einkommensstaffel mit Haushaltsgröße wird beispielsweise nicht auf die Einkommensfrage allein verkürzt.
Vorläufig ähnliche Vorschläge werden nach der deterministischen Zusammenführung erneut geprüft. Unabhängige UND-Bedingungen ohne interne Weiterleitung werden zuvor in eigenständige Voraussetzungen zerlegt. Deckt eine zeitlich und räumlich spezifischere Wohnsitzfrage eine allgemeinere Frage bei gleicher Polarität vollständig ab, bleibt nur die spezifischere Frage erhalten und die Zusammenführung wird protokolliert. Der Vergleich berücksichtigt auch Teilfragen bereits vorhandener Sammel-Voraussetzungen. Ein alter Sammel-Eintrag wird nur ersetzt, wenn valide neue Kandidaten gemeinsam alle seine Teilfragen abdecken; bei einer Teilerkennung bleibt er unverändert. Wirklich unterschiedliche oder weiterhin uneindeutige Bedingungen bleiben dagegen auf Review nötig.
Für den Vergleich mit dem Altbestand zählt eine Ja-/Nein-Polarität nur, wenn die erwartete Antwort ausdrücklich strukturiert vorhanden ist. Wörter wie „nicht“ in einer Grenzwertformulierung werden nicht mit einer fehlenden erwarteten Antwort gleichgesetzt. Ein echter Konflikt zwischen ausdrücklich Ja und Nein bleibt dagegen ein blockierender Prüfpunkt.
Scheitert ein Reparaturversuch dennoch technisch, wird der bestehende Bestand nicht durch ein unvollständiges Ergebnis ersetzt. Eine Bestandsprüfung kann sichere Metadaten ergänzen oder fachlich unsichere Einträge auf Review nötig und inaktiv setzen. Der Hinweis beim manuellen KI→-Aufruf nennt zusätzlich die letzte technische Ursache, etwa eine leere oder am Antwortlimit abgeschnittene Modellantwort. Der Refresh Wizard verwendet dieselbe Prüfung und dieselben Diagnoseinformationen.
Status, Regel, Validierung und Reviewkennzeichen werden nicht aus der KI-Antwort übernommen, sondern erst serverseitig aus Quelle und Kandidat berechnet. Dadurch kann eine formal plausible Modellantwort weder eine erfolgreiche Prüfung vortäuschen noch einen unbelegten Reviewhinweis dauerhaft festschreiben.
Reine Berechnungs- und Bemessungsaussagen, Förderbeträge, Nachweislisten, Verfahrenshinweise und Informationen erzeugen keine Voraussetzung und keine Regel. Eine echte Anspruchsgrenze oder zwingende Mitwirkung bleibt dagegen prüfbar. Die Rollenentscheidung wird in den Harvest-Diagnosen festgehalten.
Bei erhaltenem Altbestand kann AIA3 eine fehlende erwartete Ja/Nein-Antwort ergänzen, wenn Decision-IR, Testfälle, Entscheidungsbeleg und aktuelle Quelle konsistent denselben Wert ergeben. Ein Widerspruch oder fehlender Beleg führt weiterhin zu Review nötig; AIA3 rät keine Polarität.
Fragen und Regeln werden im kombinierten KI→- oder Wizard-Lauf als zusammengehörige Kette behandelt. Für einen vollständig validierten neuen Kandidaten kompiliert AIA3 die Regel deterministisch aus derselben Decision-IR; ein zweiter freier Regel-KI-Aufruf ist dafür nicht nötig. Im manuellen Lauf werden vollständige Ergebnisse nach dem globalen Parameterabgleich bei aktueller, konfliktfreier Quellenbasis kandidatenweise aktiviert. Fachlich offene Geschwisterkandidaten blockieren diese sicheren Voraussetzungen nicht: Mit brauchbaren Fragen und Parametern werden sie inaktiv zur manuellen Korrektur angelegt, ohne editierbare Struktur bleiben sie nur im Protokoll. Im Wizard steuert weiterhin die Option zur Sofortaktivierung diesen Schritt; inaktive Korrekturentwürfe gehören nie zur Aktivierungsmenge. Bleibt wegen eines Harvest- oder Qualitätsfehlers der Altbestand erhalten, wird die Regelphase übersprungen; alte Regeln werden nicht als neue Ergebnisse ausgegeben. Ein verworfener Regressionskandidat, ein Paralleländerungskonflikt oder eine wegen geänderter Quellenbasis veraltete Regel zählt nicht als Neuerstellung. Die separate Wizard-Aufgabe Voraussetzungs-Regeln bleibt für einen bereits vorhandenen Bestand verfügbar.
Bei Zahlenregeln speichert AIA3 zusätzlich, ob ein Wert direkt aus der Quelle, als Grenzwert, als Tabellenwert oder als exakt nachrechenbare Ableitung stammt. Vollständig belegte Staffeln werden zeilengetreu nachgeschlagen. Aus zwei benachbarten Tabellenwerten wird nicht automatisch ein Zuschlag abgeleitet. Eine ausdrücklich belegte Regel wie „für jede weitere Person“ darf dagegen als kontrollierte Fortschreibung verwendet werden.
Tabellenzeilen verwenden die tatsächlichen Werte aus der Quelle: Eine Zeile für ein Kind bleibt Kinderzahl 1 und wird nicht als Position 0 behandelt. Bei einem Stufensystem trennt AIA3 Anspruch und Förderhöhe. Wenn die Quelle eindeutig sagt, dass Einkommen bis zur höchsten Stufe noch förderfähig ist, dient diese äußere Stufengrenze der Ja-/Nein-Anspruchsprüfung; niedrigere Stufen bestimmen nur die Förderhöhe. Automatische Grenzfälle prüfen zusätzlich jede belegte Zeile sowie mehrere aufeinanderfolgende Zuschläge für weitere Erwachsene oder Kinder und deren Kombinationen.
Erkannte Verwechslungen von Teilleistung, Förderhöchstbetrag und Anspruchsgrenze bleiben als fachlicher Prüfpunkt inaktiv. Ebenso müssen fehlende oder widersprüchliche Einkommensperioden und uneindeutige Stufensysteme zuerst geklärt werden. Klären Sie die Entscheidungsgrundlage und erzeugen Sie anschließend die betroffene Regel neu.
Ein offener Quellenverweis betrifft nur die zugehörige Voraussetzung: Fehlende Einkommensgrenzen sperren beispielsweise keine unabhängige Wohnsitzfrage. Unklare Zuordnungen bleiben zur Prüfung offen. Dafür werden keine wiederholten Reparaturen am Regelcode gestartet. Bei automatisch gescheiterten Pflichtprüfungen bestätigt der Chat keine vollständige Förderberechtigung.
Bei rein technischen Fehlern repariert AIA3 nicht mehr den gesamten Entscheidungsgraphen neu. Die KI darf nur kleine, vorab erlaubte Felder in vorhandenen Knoten oder Bedingungen als JSON-Patch ändern. Parameter-IDs, Datentypen, belegte Zahlen, Quellenbezüge und bekannte positive, negative oder frühe Abschlussfälle bleiben geschützt. Erst ein vollständig geprüfter Patch wird übernommen; nach einem ungültigen Versuch bleibt der bisherige Graph unverändert.
Die abgeleitete Funktion hat weiterhin den Vertrag function evaluate(params) { ... }. Sie liest die gebundenen Parameter aus params und gibt genau einen der Werte true, false oder null zurück. Sind alle auf dem Pfad benötigten Angaben vorhanden und richtig typisiert, muss das Ergebnis immer true oder false sein. null ist ausschließlich für eine tatsächlich fehlende oder typfalsche benötigte Angabe zulässig. Bestehende Voraussetzungen ohne Decision-IR verwenden diesen bisherigen Regelpfad weiter.
Bei einer Folgeaktion Abschluss erfüllt oder Abschluss nicht erfüllt darf die Entscheidung keine danach übersprungene Frage mehr verlangen. Die automatische Prüfung erzeugt für jeden frühen Abschluss einen Fall ohne die späteren Parameter und vergleicht Entscheidungsgraph und JavaScript. Bei null oder einem abweichenden Wahrheitswert bleibt die Voraussetzung ungültig.
true: Die Voraussetzung ist erfüllt, der Chat prüft die nächste Voraussetzung.false: Die Voraussetzung ist nicht erfüllt, der Chat wechselt in den Nicht-erfüllt-Pfad.null: Ein benötigterparams-Wert fehlt noch. Wenn die fehlende Parameter-ID bekannt ist, fragt der Chat diesen Wert nach; ohne bekannten fehlenden Parameter gilt dies als Regelproblem.
Beispiel für eine Ja/Nein-Voraussetzung:
function evaluate(params) {
const hauptwohnsitz = params["hauptwohnsitz_bundesland"];
if (typeof hauptwohnsitz === "undefined") return null;
return hauptwohnsitz === true;
}
Verwenden Sie exakt die Parameter-IDs aus den Fragen. Wenn ein Parameterdatentyp geändert wurde, Regel mit KI→ neu erzeugen oder den Code manuell an den aktuellen Datentyp anpassen.
Referenz: wichtige Felder
1
2
3
4
| Marker | Element | Bedeutung |
|---|---|---|
| 1 | Overlay-Titel | Zeigt, dass die Parametersuche geöffnet ist. |
| 2 | Suchfeld | Findet Parameter über ID, Alias oder Beschreibung. |
| 3 | Trefferliste | Vergleicht mögliche Parameterkandidaten. |
| 4 | Übernehmen | Ordnet den ausgewählten Parameter der Voraussetzung zu. |
Abb. X-02 zeigt den Detaildialog zur Parametersuche vor der Feldreferenz. Nutzen Sie ihn, wenn eine Voraussetzung mit einem vorhandenen globalen Parameter verbunden werden soll.
| Feld | Sicht | Bedeutung |
|---|---|---|
| Titel | Wissen | kurzer Name der Wissenskarte |
| Kategorie | Wissen | fachliche Einordnung, zum Beispiel Nachweise oder Fristen |
| Schlüsselwörter | Wissen | Such- und Matching-Hinweise für freie Fragen |
| Antwort | Wissen | geprüfter Antworttext für die Startberatung |
| Typ | Wissen & Rechnen | legt fest, ob der Eintrag eine normale Wissenskarte oder eine Berechnung ist |
| Berechnung | Wissen & Rechnen | strukturierte Rechenlogik mit Eingaben, Rechenschritten, Ergebnis und Testfall; Aktivierung ist nur mit gültiger Prüfrechnung möglich |
| Frage | Voraussetzung | Text, den der Chat stellt |
| Antworttyp | Voraussetzung | steuert, wie Antworten ausgewertet werden |
| Parameter-ID | Voraussetzung | verbindet Antwort, Regel und Chat-Kontext |
| Folgeaktion | Voraussetzung | steuert den nächsten Dialogschritt |
| Regelbereich | Voraussetzung | prüft komplexere fachliche Bedingungen |
Status und Aktivierung
- neu: Entwurf oder KI-Vorschlag.
- nicht_aktiv: gespeichert, aber im Chat nicht wirksam.
- aktiv: fachlich geprüft und für Beratung nutzbar.
- Wissenskarten sollten erst aktiviert werden, wenn Antworttext, Kategorie und Schlüsselwörter fachlich geprüft sind.
- In den Sichten Wissen & Rechnen und Voraussetzung können mehrere gefilterte Einträge gleichzeitig markiert und über das Status-Select auf neu, aktiv oder nicht_aktiv gesetzt werden.
- Berechnungen können nur aktiviert werden, wenn die strukturierte Rechenlogik vollständig ist und die hinterlegte Prüfrechnung erfolgreich durchläuft. Automatisch erzeugte Berechnungen bleiben bis zur fachlichen Kontrolle Entwürfe.
- Offene Prüfpunkte zum Zeitraum des Einkommens, zu mehreren Förderstufen oder zur Bedeutung eines Quellenbelegs verhindern auch die Sofortaktivierung. Eine einzelne erfolgreiche Prüfrechnung bestätigt nicht die vollständige Staffel. Korrigieren und speichern Sie zuerst Quelle, Antwort oder Berechnung. Bleibt der geklärte Hinweis bestehen, schließen Sie die Prüfung mit einer Begründung an der einzelnen Karte ab.
- Der Abschluss gilt nur, solange Inhalt und Quellen der geprüften Karte unverändert bleiben. Jede inhaltliche oder quellenbezogene Änderung erfordert eine neue Prüfung. Ein unvollständiges Berechnungsschema muss immer korrigiert werden.
- Gesammelte Statusänderungen sind nur sinnvoll, wenn die aktuelle Suche, der Kategorie-Filter und die Markierung genau die fachlich geprüften Einträge enthalten.
- Der Aktivierungs-Guard verhindert unvollständige oder widersprüchliche Voraussetzungen.
- Wenn Frage oder Regel unabhängig von einem vorhandenen Decision-IR geändert werden, wird die Voraussetzung inaktiv und prüfpflichtig. Speichern Sie diese Änderung nur, wenn die gesamte Entscheidungslogik danach neu erzeugt und geprüft wird.
- Review nötig bedeutet, dass die Regelstruktur lesbar ist, aber eine fachliche Entscheidungsgrundlage wie Grenzwert oder Bezugsperiode fehlt. Der Wert wird nicht geraten, die Voraussetzung bleibt inaktiv und der Hinweis nennt die zu prüfende Quelle.
- Ist die fachliche Regel trotz fehlendem automatischen Quellenbeleg eindeutig bestätigt, kann sie im Detailbereich mit einer Begründung von mindestens zehn Zeichen über Ohne Quellenbeleg fachlich freigeben bestätigt werden. Der Status bleibt sichtbar als manuell freigegeben gekennzeichnet. Technische Fehler lassen sich nicht übersteuern; Änderungen an Fragen, Parametern, Regel oder Quellenstand machen die Freigabe ungültig.
Häufige Probleme
| Problem | Vorgehen |
|---|---|
| Freie Frage wird nicht beantwortet. | Wissenskarte, Schlüsselwörter und Status prüfen; anschließend QS-Startberatung erneut starten. |
| Voraussetzung wird doppelt gefragt. | Fragen bündeln und Parameterbindung prüfen. |
| Antwort wird falsch bewertet. | Bedingungen, kanonische Werte in Global und Regelbereich prüfen. |
| Wissens- oder Berechnungskarte lässt sich nicht aktivieren. | Den roten Prüfbereich der Karte lesen: Er nennt Grund, Beleg und den nächsten Schritt in verständlicher Sprache. Inhalt beziehungsweise Quelle korrigieren und speichern. Bleibt der Hinweis nach der Prüfung bestehen, eine Begründung eingeben und Prüfung abschließen und Karte freigeben wählen. Der grüne Bereich zeigt danach die eingegebene Begründung. Fehlende Angaben im Berechnungsschema oder fehlgeschlagene Testfälle müssen korrigiert werden. |
| Voraussetzung lässt sich nicht aktivieren. | Hinweisdialog lesen. Bei Review nötig zuerst fehlenden Grenzwert, Zeitraum oder Quellenbeleg fachlich klären. Ist die fachliche Regel eindeutig bestätigt, im Detailbereich eine Begründung eingeben und Ohne Quellenbeleg fachlich freigeben wählen. Technische Fehler, fehlende Parameter oder strukturell ungültige Regeln müssen korrigiert werden. |