Woher das Modell weiß, was ein Defect ist

Ein Missverständnis, das sich nicht wie eines anfühlt

Wer schon einmal zwischen zwei Unternehmen gewechselt hat, kennt den kleinen Kulturschock: Was hier „Defect" heißt, hieß dort „Bug", und was dort als „Change Request" durchging, wäre hier als eigener Vorgangstyp undenkbar gewesen. Menschen lernen solche Unterschiede meist innerhalb weniger Wochen, oft ohne dass es ihnen bewusst auffällt — sie fragen nach, sie beobachten, wie Kolleginnen die Begriffe verwenden, und passen sich an.

Ein generisches Sprachmodell hat diese Lerngelegenheit nicht. Es kennt die allgemeine Bedeutung von „Defect" aus seinen Trainingsdaten, aber nicht die spezifische Definition, die ausgerechnet in diesem einen Jira-Projekt gilt — und anders als bei einem Menschen fällt ein solches Missverständnis nicht unbedingt auf. Ein selbstsicher formulierter Vorschlag, der auf der falschen Bedeutung eines Fachbegriffs beruht, liest sich am Ende oft genauso überzeugend wie ein korrekter.

Ein Glossar, das aus echten Daten entsteht statt erfunden zu werden

JiCo begegnet diesem Problem, indem es ein Glossar nicht von Hand erfinden lässt, sondern aus den tatsächlichen Metadaten des angebundenen Jira aufbaut — Vorgangstypen, Feldwerte, Auswahllisten, so wie sie in der konkreten Installation wirklich vorkommen, nicht als generische Vorlage. Ein vollständiger Eintrag trägt dabei mehr als nur einen Begriff: den bevorzugten Ausdruck, erlaubte Abkürzungen, Synonyme samt veralteter Schreibweisen, die automatisch aufgelöst und ersetzt werden, Gegenbegriffe und eine kurze Erläuterung.

Besonders wirksam sind dabei die ausdrücklichen Abgrenzungen — Einträge der Form „Defect NICHT: Änderungsantrag". Diese Formulierung klingt unscheinbar, trifft aber genau den Kern des ursprünglichen Problems: Ein Modell, das nur weiß, was ein Begriff bedeutet, kann trotzdem daneben liegen, wenn es nicht auch weiß, was er ausdrücklich nicht bedeutet — gerade an den Stellen, an denen zwei Begriffe im Alltag leicht verwechselt werden.

Wenn eine Frage mehrdeutig bleibt, wird das gesagt

Nicht jede Unklarheit lässt sich vorab durch ein Glossar auflösen. Deshalb führt JiCo zusätzlich ein eigenes Abfrage-Vokabular, das festhält, wie ein Alltagsbegriff in eine konkrete Jira-Abfrage übersetzt wird — und ob diese Übersetzung eindeutig ist oder auf einer Annahme beruht. Bleibt eine Anfrage mehrdeutig, weil zum Beispiel unklar ist, welches von zwei ähnlich klingenden Feldern gemeint war, taucht dieser Hinweis direkt in der Antwort auf, statt stillschweigend eine Annahme zu treffen und sie als vermeintlich sichere Antwort zu präsentieren.

(Nachtrag 2026-10-10: Die hier beschriebenen sechs deterministischen Schnellfragen ganz ohne Modell gehörten zum eigenen Chat und sind mit ihm ausgebaut, JICO-D-1969. Auch den Hinweis auf eine Annahme hängt JiCo nicht mehr selbst an die Antwort — dafür müsste es die Antwort sehen, und die bleibt beim KI-Client. Das Abfrage-Vokabular selbst ist geblieben: es steht im Modellkontext und bittet das Modell, die verwendete Einschränkung zu nennen.)

Konventionen, die nicht im Code, sondern in einem Repository liegen

Neben dem reinen Vokabular kennt JiCo auch fachliche Konventionen — Regeln der Form „wird ein Ticket auf 'erledigt' gesetzt, muss auch das Feld X gepflegt sein". Diese Regeln liegen bewusst nicht fest im Programmcode, sondern in einer austauschbaren Datei aus einem Repository: entweder aus dem öffentlichen Standard-Repository, das für den allgemeinen Fall vorkonfiguriert ist, oder aus einem eigenen, unternehmensspezifischen. Diese eine Datei wird streng geprüft, täglich automatisch nachgezogen, und jeder Wechsel wird im Audit-Trail festgehalten.

Das hat einen praktischen Vorteil, der sich erst im Alltag zeigt: Ändert sich eine fachliche Regel, weil ein Team seinen Prozess anpasst, muss niemand JiCo selbst verändern oder ein Update abwarten — die eine Konventionsdatei wird angepasst, und der nächste automatische Abgleich übernimmt die neue Regel von selbst. Regeln lassen sich dabei sogar auf einzelne Projekte begrenzen, wenn unterschiedliche Teams unterschiedliche Konventionen pflegen.

Auch eigene Felder bleiben nicht anonym

Dasselbe Prinzip gilt auch für die vielen unternehmenseigenen Zusatzfelder, mit denen fast jede reale Jira-Installation über die Standardfelder hinausgeht. JiCo führt dafür einen eigenen Feldkatalog, der zu jedem technischen Feldnamen den passenden JQL-Namen, den tatsächlichen Typ und — bei Auswahlfeldern — die exakt gültigen Werte samt ihrer Abkürzungen kennt. Fragt jemand nach einem Wert, der in Wahrheit nicht existiert, weist JiCo die Suche mit den tatsächlich gültigen Werten zurück, statt eine Abfrage loszuschicken, die leer bliebe, ohne dass jemand verstünde, warum. Bewusst außen vor bleiben dabei Freitext- und Personenfelder — für sie gilt weiterhin die PII-Schleuse, nicht der Feldkatalog, weil ein freies Textfeld sich nicht auf eine feste Werteliste reduzieren lässt.

Der eigentliche Nutzen liegt vor der Antwort, nicht in ihr

Der entscheidende Effekt all dieser Bausteine zeigt sich nicht darin, dass Antworten am Ende schöner formuliert wären, sondern darin, wo im Ablauf sie ansetzen: Begriffe werden bereits im Modellkontext selbst vereinheitlicht — bevor ein Vorschlag überhaupt entsteht — und ein zweites Mal direkt im Schreibvorschlag, bevor er einem Menschen zur Freigabe vorgelegt wird. Ein Missverständnis über einen Fachbegriff soll damit möglichst gar nicht erst in einen fertig formulierten Vorschlag einfließen, statt hinterher mühsam entdeckt werden zu müssen.