Agent Swarm Intelligence
DECISION-LAB
MVP 1.0 · Reference Run: runs/run_2026-06-11_17-51-05_a48f
Vom einfachen Requirement zur geprüften Entscheidungsgrundlage
Ein einfacher Change Request wird durch mehrere Rollen geprüft, als Requirement präzisiert, in einen Epic-Vorschlag und eine User Story übersetzt, auf Risiken und Governance bewertet und anschliessend auf Delivery-Readiness geprüft.
Ein einzelner Change Request ist der Ausgangspunkt der gesamten Analyse. Alles, was in den folgenden Intelligence-Schichten entsteht, wird aus diesem Input abgeleitet.
Originaler Change Request
Ein Kunde soll mehrere Rechnungsadressen speichern können.
Dieser Satz ist die Quelle der gesamten Simulation.
Die folgenden Abschnitte zeigen, wie Decision-Lab diesen Input klassifiziert, rollenbasiert bewertet, fachlich präzisiert und zu einer Entscheidungsgrundlage verdichtet.
Simulationskontext
GRUPPETEST — IREB Core Group
STATUSCLARIFICATION_REQUIRED
ANFORDERUNGSTYPFunktionale Systemfähigkeit Das Requirement beschreibt eine fachliche Fähigkeit, die das System bereitstellen soll. · Technischer Simulationswert: FUNCTIONAL
RES-v1NO_MEANINGFUL_IMPROVEMENT
KNOWLEDGEaktiviert (j, SMART_ROUTING)
LLMqwen2.5:3b
HARDWARENAB9 · Intel i9-12900HK Intel Iris Xe Graphics, keine dedizierte GPU
ROLLENBusiness Analyst · Product Owner · Developer · Solution Architect · Tester
Die fachliche Präzisierung, Rollenbewertung, Governance-Prüfung, Story-Ableitung und Umsetzungsentscheidung entstehen erst in den folgenden Abschnitten.
Vom Input zur Architektur-Begründung
01 Input Intelligence→02 Warum dieser Weg
Der ursprüngliche Change Request ist erfasst. Bevor die Analyse beginnt, erklärt Decision-Lab, warum der Input nicht direkt beantwortet, sondern strukturiert verarbeitet wird.
Architektur-Rationale
Warum dieser aufwendige Weg?
Lokales 3B-Modell. Kompakte Hardware. Kontrollierte Entscheidungslogik statt blindem Vertrauen in eine Einzelantwort.
Lokales LLM
qwen2.5:3b
NAB9
Intel i9-12900HK
Intel Iris Xe Graphics 96 EU
Halluzinationsrisiko sichtbar machen
Full Evidence
Decision-Lab wurde bewusst nicht als einfache Chatbot-Antwort gebaut. Ein einzelnes LLM kann überzeugend formulieren, aber bei Requirements, Architektur, Governance und Delivery-Entscheiden fachliche Regeln erfinden, technische Annahmen vermischen oder wichtige Risiken übersehen.
Deshalb zerlegt Decision-Lab den Change Request in mehrere Intelligence-Schichten. Jede Schicht hat eine begrenzte Aufgabe. Jede Rolle bewertet denselben Input aus ihrer eigenen Verantwortung. Die Ergebnisse werden geprüft, normalisiert, konsolidiert und als vollständige Evidenz sichtbar gemacht.
Diese Architektur ist besonders wichtig, weil der MVP lokal läuft. Das System arbeitet mit einem kleinen 3B-Modell auf kompakter Hardware. Qualität entsteht hier nicht durch rohe Modellgrösse, sondern durch klare Rollen, kontrollierte Verarbeitungsschritte, Governance-Regeln und vollständige Nachvollziehbarkeit.
Warum diese Architektur notwendig ist
▼
Decision-Lab nutzt den Agent Swarm Intelligence Stack nicht als technische Spielerei. Der Stack ist eine bewusste Antwort auf die Grenzen eines lokalen MVP-Setups.
Das Modell qwen2.5:3b läuft lokal auf einem NAB9 mit Intel i9-12900HK und Intel Iris Xe Graphics (96 EU). Diese Umgebung ist kompakt, unabhängig und gut nachvollziehbar, aber sie ersetzt keine grosse GPU-Infrastruktur und kein grosses Cloud-LLM.
Darum darf das System nicht darauf vertrauen, dass eine einzelne Modellantwort alles richtig macht. Stattdessen wird der Entscheidungsprozess strukturiert.
Der ursprüngliche Change Request wird zuerst unverändert übernommen. Danach wird er klassifiziert, mit Knowledge-Kontext angereichert, in Rollenperspektiven übersetzt, durch Agents bewertet, auf Struktur geprüft, normalisiert und zu einem Governance-Entscheid konsolidiert.
Diese Struktur reduziert Halluzinationsrisiken. Nicht, weil das Modell plötzlich unfehlbar wird. Sondern weil die Antwort nicht mehr unkontrolliert als ein einziger Text entsteht. Fachliche Analyse, Produktbewertung, technische Prüfung, Architekturperspektive, Testbarkeit, Governance, Pattern-Empfehlungen, Lösungsskizze und Entscheidungslogik werden getrennt betrachtet und anschliessend nachvollziehbar zusammengeführt.
Wenn ein Agent unsauber antwortet, wenn ein Output nicht als JSON erkannt wird oder wenn Knowledge-Kontext in eine falsche Richtung zeigt, wird das nicht versteckt. Es bleibt im Full-Evidence-Bereich sichtbar. Das ist Teil des Konzepts.
Decision-Lab soll nicht nur schöne Antworten erzeugen. Es soll prüfbare Entscheidungswege zeigen. Gerade mit einem kleinen lokalen Modell ist Transparenz wichtiger als perfekte Oberfläche.
Der Nutzen liegt deshalb nicht darin, dass jeder einzelne Agent immer perfekt antwortet. Der Nutzen liegt darin, dass der gesamte Entscheidungsweg sichtbar wird. Aus einem einfachen Requirement entsteht eine nachvollziehbare Entscheidungsgrundlage. Nicht durch eine einzelne KI-Antwort. Sondern durch einen strukturierten, lokalen und überprüfbaren Agent-Swarm-Prozess.
Problem
Grenze des Einzelprompts
Eine einzelne LLM-Antwort kann fachlich überzeugend klingen, aber Requirements, Architektur, Governance und Delivery-Aspekte vermischen.
Problem
Grenze des kleinen lokalen Modells
Ein kompaktes lokales 3B-Modell muss stärker geführt werden als ein grosses Cloud-Modell. Qualität entsteht hier nicht durch Modellgrösse, sondern durch Prozessstruktur.
Problem
Halluzinationsrisiko
Nicht belegte Business Rules, falsche technische Annahmen oder domänenfremde Knowledge-Fragmente müssen sichtbar und überprüfbar bleiben.
Struktur ersetzt blinde Modellgläubigkeit
Lösung
Rollen trennen Verantwortung
Business Analyst, Product Owner, Developer, Solution Architect und Tester prüfen denselben Input aus klar getrennten Verantwortungen.
Lösung
Governance prüft Entscheidung
Risiken, Vetos, Blocker und Release Readiness werden konsolidiert, statt in einer einzelnen Antwort unterzugehen.
Lösung
Evidence macht alles prüfbar
Konsolidierter Report, Agentenberichte, Normalisierung und Rohdaten bleiben vollständig sichtbar.
Von der Begründung zum Intelligence Stack
02 Warum dieser Weg→03 Agent Swarm Intelligence Stack
Die Architekturentscheidung ist begründet. Jetzt zeigt der Stack, welche sechs Intelligence-Schichten den Change Request konkret verarbeiten.
Decision-Lab bewertet einen Change Request nicht als einzelne KI-Antwort. Der Input durchläuft mehrere Intelligence-Schichten. Fachliche Rollen, Governance, Patterns, Lösungsskizzen, Architektur-Blueprints und Entscheidungslogik greifen ineinander. Dadurch entsteht eine nachvollziehbare Entscheidungsgrundlage mit vollständiger Evidenz.
Die Simulation erzeugt rollenbasierte Agentenoutputs, prüft deren Struktur, normalisiert Ergebnisse, konsolidiert Risiken und Governance-Status und exportiert die vollständige Evidenz. Die Hauptseite zeigt die kuratierte Entscheidungslogik. Der Full-Evidence-Bereich zeigt die vollständigen Rohdaten.
1Role
→
2Governance
→
3Pattern
→
4Solution
→
5Architecture
Blueprint
→
6Decision
Der Agent Swarm Intelligence Stack zeigt die innere Verarbeitungslogik der Simulation. Die folgenden Abschnitte 04 bis 13 zeigen die daraus entstehenden Ergebnisräume in einer lesbaren Reihenfolge.
Orientierung: Stack-Schichten und Ergebnisbereiche
Innere Verarbeitung versus sichtbare Homepage-Struktur
1 Role→04 Role Intelligence
2 Governance→06 Governance Intelligence
3 Pattern→07 Pattern Intelligence
4 Solution→09 Solution Intelligence
5 Blueprint→10 Architecture Blueprint Intelligence
6 Decision→11 Decision Intelligence
Abgeleitete Ergebnisbereiche
05 Requirement Intelligence entsteht aus Rollenoutputs, RES-v1 und IREB-Präzisierung.
08 Story Intelligence entsteht aus Requirement Intelligence, Governance und Rollenbeiträgen.
12 Delivery Readiness entsteht aus Story Boundary und Decision Intelligence.
13 Evidence Intelligence sammelt kuratierte Ergebnisse und vollständige Rohdaten.
Die folgenden Intelligence-Schichten zeigen, wie Decision-Lab den ursprünglichen Change Request verarbeitet. Jede Schicht ergänzt eine eigene Perspektive. Erst aus dem Zusammenspiel entsteht der konsolidierte Entscheidungsreport.
1Role Intelligence
Mehrere spezialisierte Rollen bewerten denselben Change Request parallel aus ihrer jeweiligen Verantwortung. Dadurch werden fachliche Lücken, Produktfragen, technische Auswirkungen, Architekturgrenzen und Testbarkeit sichtbar.
Business Analyst, Product Owner, Developer, Solution Architect und Tester betrachten denselben Input aus unterschiedlichen Blickwinkeln. Dadurch werden fachliche Lücken, Produktfragen, technische Auswirkungen, Architekturgrenzen und Testbarkeit sichtbar.
WichtigKonflikte zwischen Rollen werden nicht versteckt. Sie werden bewusst sichtbar gemacht, weil sie für eine echte Entscheidungsgrundlage wichtig sind.
Ergebnisbezug: Diese Schicht liefert Role Insights und Konflikte.
▼Details anzeigen
2Governance Intelligence
Risiken, Vetos und Entscheidungsfähigkeit werden früh bewertet. Ein Change Request kann fachlich sinnvoll sein und trotzdem blockiert werden, wenn Business Rules, Architektur, Testbarkeit oder Governance fehlen.
Die Simulation prüft, ob ein Change Request freigegeben, mit Auflagen versehen oder blockiert werden muss. Governance Intelligence bewertet Risiko-Level, Vetorollen, kritische Rollen, Governance Severity, Governance Status und Release Readiness Score.
WichtigEin Change Request kann fachlich sinnvoll sein und trotzdem blockiert werden, wenn Business Rules, Architektur, Testbarkeit oder Governance fehlen.
Ergebnisbezug: Diese Schicht liefert Governance Status, Entscheidungsstatus, Blocker und Freigabehinweise.
▼Details anzeigen
3Pattern Intelligence
Die Anforderung wird gegen wiederkehrende Lösungs- und Strukturmuster geprüft. Patterns sind Empfehlungen und helfen, Lösungsrichtungen sichtbar zu machen.
Pattern Intelligence erkennt, welche bekannten Enterprise Patterns zum Change Request passen könnten. Dazu gehören beispielsweise RBAC and Ownership Pattern, Audit Trail Pattern oder andere Architektur- und Governance-Muster.
WichtigPatterns sind Empfehlungen, keine fertige Umsetzung. Sie helfen, Lösungsrichtungen strukturiert sichtbar zu machen.
Ergebnisbezug: Diese Schicht liefert Pattern-Empfehlungen und sinnvolle Pattern-Kombinationen.
▼Details anzeigen
4Solution Intelligence
Aus Rollenperspektiven und Mustern entsteht eine erste Lösungsskizze. Sie zeigt Optionen und Klärungsbedarf, ist aber keine Umsetzungsfreigabe.
Solution Intelligence verdichtet die fachlichen, technischen und governance-orientierten Hinweise zu einer möglichen Lösungsrichtung. Dabei werden Optionen, Abhängigkeiten und notwendige Klärungen sichtbar, ohne bereits eine finale technische Umsetzung festzulegen.
WichtigDie Lösungsskizze ist eine Entscheidungsgrundlage. Sie ist keine Umsetzungsfreigabe und kein fertiges technisches Design.
Ergebnisbezug: Diese Schicht liefert Lösungsskizze, Handlungsoptionen und empfohlene nächste Konkretisierungsschritte.
▼Details anzeigen
5Architecture Blueprint Intelligence
Eine fachlich-technische Zielstruktur wird sichtbar gemacht. Verantwortungsbereiche wie API, Security, Governance, Audit und Speicher können getrennt betrachtet werden.
Architecture Blueprint Intelligence ordnet die Lösung in Architekturbereiche ein. Frontend, API, Security, Governance, Audit, Speicher, Datenhoheit und Integrationsgrenzen können dadurch getrennt betrachtet werden.
WichtigDer Architektur-Blueprint ist high-level. Er zeigt Verantwortungsbereiche und Struktur, ersetzt aber keine technische Spezifikation.
Ergebnisbezug: Diese Schicht liefert Architektur-Blueprint, Layer-Struktur und Verantwortungsbereiche.
▼Details anzeigen
6Decision Intelligence
Alle Vorschichten werden zu einer Entscheidungsgrundlage verdichtet. Der Entscheidungsreport zeigt nicht nur, was möglich wäre, sondern ob die Umsetzung aktuell verantwortbar ist.
Decision Intelligence verbindet Rollenbeiträge, Risiken, Governance, Patterns, Lösungsskizze, Architekturhinweise und offene Fragen zu einem konsolidierten Entscheidungsreport.
WichtigDer Entscheidungsreport zeigt nicht nur, was gemacht werden könnte, sondern ob die Umsetzung in der aktuellen Form verantwortbar ist.
Ergebnisbezug: Diese Schicht liefert Empfehlung, Entscheidungsstatus, Risiken, Gegenmassnahmen und nächste Schritte.
▼Details anzeigen
Was aus dem Stack entsteht
Aus dieser Sequenz entsteht ein Entscheidungsreport mit mehreren strukturierten Komponenten. Die Farbe einer Komponente verweist auf die Quell-Schicht in der Grafik.
Governance Status
Freigegeben, mit Auflagen oder abgelehnt, jeweils mit nachvollziehbarer Begründung.
Governance Intelligence · Decision Intelligence
Role Insights und Konflikte
Kerninformationen, Spannungsfelder und Konflikte aus allen Rollenperspektiven.
Role Intelligence
Risiken und Gegenmassnahmen
Identifizierte Risiken, Risikokategorien, Schweregrade und empfohlene Massnahmen.
Governance · Role · Decision Intelligence
Pattern-Empfehlungen
Anwendbare Enterprise Patterns und sinnvolle Pattern-Kombinationen.
Pattern Intelligence
Architecture Blueprint
High-Level-Struktur, Layer, Verantwortungsbereiche und Architekturgrenzen.
Architecture Blueprint Intelligence
Nächste Schritte
Klare Handlungsoptionen und Klärungspunkte für Fachbereich, Product Owner, Architektur, Entwicklung, Testing und Delivery.
Decision · Delivery Readiness Intelligence
Vom Stack zur Rollen-Auswertung
03 Agent Swarm Intelligence Stack→04 Role Intelligence
Der Intelligence Stack übergibt den ursprünglichen Change Request an spezialisierte Rollenagenten. Jeder Agent erhält denselben Input, aber einen eigenen Auftrag, Kontext und Output-Vertrag.
Wie ein Agentenresultat entsteht
Von der Rollenperspektive zur prüfbaren Evidenz
Jeder Agent erhält denselben Change Request, aber einen eigenen fachlichen Auftrag. Aus Rolle, Knowledge-Kontext und Analysefokus entsteht ein rollenbezogener Prompt. Das lokale LLM erzeugt daraus eine Antwort. Decision-Lab prüft danach, ob diese Antwort als strukturierter JSON-Output verwendbar ist. Valide Outputs werden normalisiert und konsolidiert. Nicht valide Outputs werden nicht versteckt, sondern als Fallback markiert und im Full-Evidence-Bereich sichtbar gemacht.
1Rolle und Auftrag
→
2Prompt-Kontext
→
3LLM-Antwort
→
4JSON-Prüfung
→
5Normalisierung oder Fallback
→
6Konsolidierung
→
7Full Evidence
Die sieben Schritte erklärt▼
1. Rolle und Auftrag — Jeder Agent analysiert denselben Change Request aus einer klar definierten Verantwortung.
2. Prompt-Kontext — Rolle, Analyseauftrag, Knowledge-Kontext und Output-Erwartung werden zu einem Agentenprompt zusammengeführt.
3. LLM-Antwort — Das lokale Modell erzeugt die Antwort des jeweiligen Agents.
4. JSON-Prüfung — Decision-Lab prüft, ob die Antwort als strukturierter JSON-Output erkannt werden kann.
5. Normalisierung oder Fallback — Valide JSON-Ergebnisse werden normalisiert. Nicht valide Antworten werden als strukturierter Fallback gekennzeichnet.
6. Konsolidierung — Die verwertbaren Rollenbeiträge fliessen in Risiken, Governance, Story, Entscheidung und nächste Schritte ein.
7. Full Evidence — Alle Agentenoutputs, Normalisierungen, Fallbacks und Rohdaten bleiben vollständig sichtbar.
Fachlicher Agent
Ein Agent repräsentiert eine Rolle mit fachlicher Verantwortung. Business Analyst, Product Owner, Developer, Solution Architect und Tester prüfen denselben Input aus unterschiedlichen Blickwinkeln.
Technischer Output
Die Agentenantwort wird nicht einfach übernommen. Decision-Lab erwartet strukturierte Outputs, prüft JSON-Erkennung und markiert Abweichungen transparent.
Evidenz statt Glättung
Auch nicht perfekte Outputs bleiben sichtbar. Fallbacks, Normalisierungen und Rohdaten werden im Full-Evidence-Bereich offengelegt.
Technische Agentenlogik anzeigen▼
Ein Decision-Lab Agent besteht aus mehreren Ebenen.
Fachlich besitzt der Agent eine Rolle. Diese Rolle bestimmt, worauf der Agent achtet. Der Business Analyst sucht fachliche Lücken, fehlende Business Rules und offene Fragen. Der Product Owner bewertet Business Value, MVP-Scope und Priorität. Der Developer betrachtet Datenmodell, Validierungen, Fehlerfälle und technische Auswirkungen. Der Solution Architect prüft Systemgrenzen, Integration, Ownership und Rückwärtskompatibilität. Der Tester bewertet Testbarkeit, Akzeptanzkriterien, Fehlerfälle und Regression.
Technisch erhält jeder Agent einen Prompt. Dieser Prompt kombiniert den ursprünglichen Change Request, die Rollenbeschreibung, den Analyseauftrag, gegebenenfalls Knowledge-Kontext und die erwartete Output-Struktur.
Das LLM erzeugt daraus eine Antwort. Diese Antwort ist zunächst ein Rohoutput des Modells. Danach prüft Decision-Lab, ob die Antwort als JSON erkannt werden kann.
Wenn JSON erkannt wird, kann das Ergebnis strukturiert weiterverarbeitet werden. Wenn JSON nicht erkannt wird, wird die Antwort nicht verworfen. Sie wird als strukturierter Fallback markiert. Dadurch bleibt sichtbar, dass ein Agent geantwortet hat, aber der Output nicht vollständig maschinell auswertbar war. Ein Fallback ist ein Transparenzmechanismus, kein Systemabbruch.
Anschliessend werden Agentenoutputs normalisiert. Bekannte sprachliche Unschärfen, technische Rohwerte oder Strukturabweichungen können markiert und für den konsolidierten Report vorbereitet werden.
Erst danach fliessen die Rollenbeiträge in die weiteren Ebenen ein: Requirement Intelligence, Governance Intelligence, Pattern Intelligence, Story Intelligence, Solution Intelligence, Decision Intelligence und Full Evidence.
Diese Verarbeitung ist wichtig, weil Decision-Lab nicht blind einer einzelnen LLM-Antwort vertraut. Die Simulation macht sichtbar, welche Agenten strukturiert geantwortet haben, wo Fallbacks entstanden sind und welche Rohdaten der Entscheidung zugrunde liegen.
Knowledge-Kontext als Zusatzschicht
Was bedeutet Knowledge-Kontext?
Rollenbezogener Zusatzkontext, nicht freie Erfindung
Knowledge-Kontext bedeutet, dass ein Agent nicht nur den Change Request sieht, sondern zusätzlich ausgewählte Hintergrundinformationen erhält. Diese Informationen werden rollenbezogen zugesteuert. Im aktuellen MVP ist Knowledge-Kontext ein statischer, kategorisierter Textkontext. Er unterstützt die Rollenanalyse, ist aber noch keine Live-Auswertung einer echten Datenbank, keiner echten OpenAPI-Spezifikation und keiner echten UI-zu-API-zu-DB-Abbildung.
Knowledge: aktiviert
Modus: SMART_ROUTING
Grenze: keine Live-Introspektion
Zielbild: echte Systemquellen
Was Knowledge heute ist
Ein rollenbezogen gerouteter Zusatzkontext aus statischen Wissensdateien und Kategorien.
Was Knowledge heute nicht ist
Keine Live-Datenbankanalyse, keine echte OpenAPI-Introspektion, keine automatische Prüfung realer Endpunkte und kein vollständiges UI-zu-API-zu-DB-Tracing.
Wofür Knowledge später gedacht ist
Später soll Knowledge auf echte technische Quellen zugreifen können, darunter Datenbankschema, Tabellen, Spalten, Keys, Constraints, REST-Endpunkte, OpenAPI-Spezifikation, Berechtigungen, UI-Flows und API-zu-DB-Mapping.
Knowledge-Kontext im Detail anzeigen▼
1Knowledge Registry
→
2Smart Routing
→
3Rollenprompt
→
4Agentenantwort
→
5Normalisierung
→
6Full Evidence
Im aktuellen MVP unterstützt Knowledge die Rollenanalyse durch gerouteten Kontext. Es ist aber noch keine echte Live-Systemanalyse. Künftige Versionen sollen Knowledge direkt aus Datenbankstruktur, OpenAPI-Spezifikation, REST-Endpunkten, UI-Flows und API-zu-DB-Mapping speisen.
Der Knowledge-Kontext ist im aktuellen MVP eine strukturierte Zusatzbasis für die Agenten.
Das System entscheidet nicht blind, jedem Agenten alles zu geben. Stattdessen wird Knowledge rollenbezogen geroutet. Ein Business Analyst benötigt vor allem fachliche Regeln, Prozesshinweise und Governance-Fragen. Ein Developer benötigt eher Datenmodell-, Validierungs-, Fehlerfall- und Integrationshinweise. Ein Solution Architect benötigt Architektur-, API-, Ownership-, Security- und Integrationskontext. Ein Tester benötigt Testbarkeit, Akzeptanzkriterien, Fehlerfälle, Regression und Testdatenhinweise.
Im aktuellen MVP ist dieser Knowledge-Kontext statisch. Das bedeutet: Die Inhalte stammen aus vorbereiteten Kategorien und Textkontexten. Dazu gehören zum Beispiel Business Governance, Process Governance, API Governance, Data Model, Solution Patterns, Security, Compliance, Testing und Runtime-Kontext.
Diese Knowledge-Schicht hilft dem kleinen lokalen LLM, nicht völlig frei zu antworten. Sie gibt dem Agenten Struktur, Begriffe, typische Risiken und bekannte Pattern mit.
Gleichzeitig ist wichtig, diese Grenze ehrlich zu zeigen. Der aktuelle Knowledge-Kontext liest noch nicht live aus einer echten Projektdatenbank. Er analysiert noch nicht automatisch echte Tabellen, Spalten, Datentypen, Primary Keys, Foreign Keys, Constraints oder Indizes. Er prüft noch keine realen REST-Endpunkte und keine echte OpenAPI-Spezifikation. Er kennt auch noch keine vollständige Verbindung zwischen UI-Maske, API-Endpunkt, Service-Logik und Datenbanktabelle.
Darum kann der aktuelle Knowledge-Kontext helfen, bessere Fragen zu stellen und typische Risiken sichtbar zu machen. Er darf aber nicht als endgültige technische Wahrheit verstanden werden.
Wenn im Full-Evidence-Bereich domänenfremde oder generische Knowledge-Fragmente sichtbar werden, ist das kein Grund, diese zu verstecken. Es zeigt die aktuelle Grenze des MVP. Genau deshalb ist Full Evidence wichtig: Der Leser sieht nicht nur die kuratierte Hauptansicht, sondern auch, welche Rohdaten und Knowledge-Kontexte im Hintergrund mitgewirkt haben.
Zielbild für spätere Versionen: Knowledge soll künftig nicht nur aus statischen Textdateien bestehen, sondern aus echten, überprüfbaren Projektquellen gespeist werden. Dazu gehören: echtes Datenbankschema, Tabellen, Spalten, Datentypen, Primary Keys, Foreign Keys, Constraints, Indizes, reale REST-Endpunkte, OpenAPI-Spezifikation, Request- und Response-Strukturen, Statuscodes, Fehlermodelle, Berechtigungsmodell, RBAC- und Ownership-Regeln, Audit- und Compliance-Regeln, UI-Flows, Mapping von UI zu API zu Datenbank, bestehende Business Rules, bestehende Prozessmodelle und Schnittstellen zu Umsystemen.
Dann könnte ein Agent nicht nur allgemein sagen, dass ein Datenmodell geprüft werden muss. Er könnte konkret prüfen, ob eine Tabelle existiert, welche Felder fehlen, welche API betroffen ist, ob ein Endpoint bereits vorhanden ist, ob ein Breaking Change droht und ob die UI überhaupt eine passende Eingabestruktur hat. Damit wird aus Knowledge später eine echte technische Quellenbasis.
Agentenpipeline
Rollen-Auswertung
Fünf Rollenoutputs
Vom Agentenlauf zur Rollen-Auswertung
Jetzt werden die konkreten Outputs der fünf Rollen sichtbar.
Die vorherigen Verarbeitungsschichten erzeugen für jede Rolle einen eigenen Agentenoutput. Diese Rollenoutputs zeigen Fachfokus, Risiko, Governance-Wirkung, Strukturqualität und Detaildaten des Runs.
Output: JSONRisk: MEDIUM
Governance-Wirkung: Beitrag zur fachlichen Klärung
▼Details anzeigen
Fehlende Business Rules
- !Maximale Anzahl speicherbarer Rechnungsadressen pro Kunde ist nicht spezifiziert.
- !Regel zur Standard-Rechnungsadresse ist nicht spezifiziert.
- !Lösch- oder Deaktivierungsverhalten für Rechnungsadressen ist nicht spezifiziert.
- !Gültigkeits- und Validierungsregeln je Rechnungsadresse sind nicht spezifiziert.
- !Regel zur Verwendung einer Rechnungsadresse in bestehenden Rechnungsprozessen ist nicht spezifiziert.
Fehlende Akzeptanzkriterien
- ›Eine neue Rechnungsadresse kann einem Kundenkonto hinzugefügt werden.
- ›Eine bestehende Rechnungsadresse kann geändert werden.
- ›Eine bestehende Rechnungsadresse kann gelöscht oder deaktiviert werden, sofern fachlich erlaubt.
- ›Eine Rechnungsadresse kann als Standard-Rechnungsadresse festgelegt werden, sofern diese Regel fachlich vorgesehen ist.
- ›Bestehende Rechnungsprozesse bleiben nach der Erweiterung kompatibel.
Offene Fragen
- ?Gibt es eine maximale Anzahl von Rechnungsadressen pro Kunde?
- ?Muss genau eine Standard-Rechnungsadresse existieren?
- ?Welche Rechnungsadresse wird verwendet, wenn keine Standardadresse definiert ist?
- ?Welche Pflichtfelder und Validierungsregeln gelten je Rechnungsadresse?
- ?Was passiert mit bestehenden Rechnungen, wenn eine Rechnungsadresse geändert oder gelöscht wird?
Fachliche Business Rules, Akzeptanzkriterien und offene Fragen müssen vor Umsetzung geklärt werden.
Output: JSONRisk: MEDIUMGovernance: Critical Role
Governance-Wirkung: Kritische Rolle in der Governance-Bewertung (Rollenstatus, nicht das Risk Level des Outputs)
▼Details anzeigen
Business Value / MVP / Scope
- ›Mehrere Rechnungsadressen können den fachlichen Nutzen für Kunden mit unterschiedlichen Rechnungskontexten erhöhen.
- !MVP-Fit und Scope-Abgrenzung müssen fachlich bestätigt werden.
- !Keine expliziten Scope-Risiken aus dem Original ableitbar.
Offene Produktfragen
- ?Welcher fachliche Nutzen soll im MVP zuerst abgedeckt werden?
- ?Welche Regeln gehören zwingend in den MVP und welche können später folgen?
- ?Welche verbindliche Governance-Bewertung liefert der Product Owner für den Product-Owner-Governance-Entscheid?
Business Value, MVP-Scope und Priorisierung vor Umsetzung klären.
Output: JSONRisk: MEDIUM
Governance-Wirkung: Technische Umsetzbarkeit teilweise offen
▼Details anzeigen
Daten- & Validierungssicht
- !Das Datenmodell für mehrere Rechnungsadressen pro Kunde muss konkretisiert werden.
- !Pflichtfelder, Gültigkeitsregeln und zulässige Werte je Rechnungsadresse müssen geklärt werden.
- ✕Fehlerfälle für ungültige, unvollständige oder widersprüchliche Rechnungsadressen müssen definiert werden.
- ✕Das Verhalten bei fehlenden Pflichtangaben muss festgelegt werden.
Integrationsauswirkungen
- ✕Auswirkungen auf bestehende Rechnungsprozesse und Datenflüsse müssen geprüft werden.
Offene technische Fragen
- ?Welche Pflichtfelder gelten je Rechnungsadresse?
- ?Wie werden ungültige oder unvollständige Rechnungsadressen behandelt?
Datenmodell, Validierungslogik, Fehlerfälle und Auswirkungen auf bestehende Rechnungsprozesse müssen vor Umsetzung fachlich geklärt werden.
Output: JSONRisk: HIGHGovernance: Veto
Governance-Wirkung: Vetorolle in der Governance-Bewertung
▼Details anzeigen
Systemgrenzen & Ownership
- ✕Systemgrenzen für Verwaltung und Verwendung mehrerer Rechnungsadressen müssen geklärt werden.
- ✕Datenverantwortung für Rechnungsadressen und deren fachliche Regeln muss geklärt werden.
Rückwärtskompatibilität / Integration
- !Rückwärtskompatibilität bestehender Rechnungsprozesse und Integrationen muss bewertet werden.
Offene Architekturfragen
- ›Keine offenen Architekturfragen aus dem Original ableitbar — aber Systemgrenzen fehlen explizit.
Systemgrenzen, Datenverantwortung, Integrationen und Rückwärtskompatibilität vor Umsetzung absichern.
Output: TEXT-FALLBACKGovernance: VetoFallback: Non-JSON Output
Governance-Wirkung: Veto · Risiko nicht strukturiert bewertbar (Fallback-Quelle)
▼Details anzeigen
⚠ STRUCTURED FALLBACK — Tester output is not valid JSON and cannot be used for governance evaluation. Der Tester-Agent hat keinen validen JSON-Output erzeugt. Der Report verwendet einen strukturierten Fallback. Das ist kein versteckter Fehler, sondern Teil der Full-Evidence-Transparenz: Ein Fallback ist ein Transparenzmechanismus und zeigt, dass ein Agentenoutput vorhanden ist, aber nicht vollständig als strukturierter JSON-Output erkannt wurde.
Akzeptanzkriterien (aus konsolidiertem Report)
- !Akzeptanzkriterien für Erfassen, Ändern, Löschen und Festlegen einer Standard-Rechnungsadresse müssen definiert werden.
Positive Testfälle
- ✓Eine neue Rechnungsadresse kann einem Kundenkonto hinzugefügt werden.
Negative Testfälle / Fehlerfälle
- ✕Ungültige, unvollständige oder doppelte Rechnungsadressen werden geprüft.
Regression
- ✕Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.
Regression bestehender APIs und Rechnungsprozesse muss vor Release geprüft werden.
▼ Auf eine Rolle klicken für Details
Von Rollenoutputs zu Requirement Intelligence
04 Role Intelligence→05 Requirement Intelligence
Rollenoutputs→
Klärungsbedarf→
RES-v1→
IREB-Präzisierung→
Offene Fragen
Die Rollen-Auswertungen werden nun verdichtet. Aus fachlichen Lücken, offenen Fragen, Produkt- und Technikhinweisen entsteht die Requirement-Sicht mit Anforderungstyp, RES-v1 Bewertung, IREB-Präzisierung und offenen Klärungen.
Die Rollenoutputs aus 04 werden hier in eine Requirement-Sicht verdichtet. RES-v1 bleibt konservativ. Die IREB-Präzisierung macht den fachlichen Kern sichtbar, ohne neue Business Rules zu erfinden.
Original Change Request
Ein Kunde soll mehrere Rechnungsadressen speichern können.
RES-v1 Bewertung
NO_MEANINGFUL_IMPROVEMENT
RES-v1 verändert das Original nicht frei, wenn keine sicher ableitbare zusätzliche Business Rule vorliegt. Das verhindert Halluzinationen und schützt davor, nicht belegte Fachlichkeit in das Requirement einzubauen.
Die vollständige IREB-Anforderungskomposition wird im Abschnitt „IREB-Satzschablonen-Präzisierung und Rollenbeiträge" ausgewiesen.
Fachliche Kernanforderung
IREB-Präzisierung des ursprünglichen Change Requests
Das System muss dem Kunden die Möglichkeit bieten, mehrere Rechnungsadressen seinem Kundenkonto zuzuordnen, zu speichern, zu ändern und zu verwalten.
Diese Formulierung präzisiert den fachlichen Kern des ursprünglichen Change Requests. Sie ersetzt den Original-Change-Request nicht und erfindet keine zusätzlichen Business Rules.
Vollständigkeit und Randbedingungen
- RES-v1 erzeugt keinen freien alternativen Requirement-Vorschlag. Die IREB-Präzisierung macht den fachlichen Kern des vorhandenen Requirements sichtbar, ohne neue Business Rules zu erfinden.
- Die vollständige präzisierte Anforderung besteht aus Kernanforderung plus expliziten Randbedingungen aus dem Original.
- Die Kernanforderung allein ersetzt nicht den vollständigen Original-Change-Request.
- Keine zusätzlichen expliziten Randbedingungen wie Länder-, Steuer- oder Validierungsregeln sind im Original-Change-Request genannt.
MVP-2.0 · Geplanter Ausbaubereich
Qualitätsanforderungen (NFR) · Nicht im aktuellen Core-Report analysiert
Diese Qualitätsanforderungen sind als geplanter MVP-2.0-Ausbaubereich gekennzeichnet. Sie sind nicht als aktuelles Analyseergebnis dieses Core-Reports ausgewiesen und wurden noch nicht bewertet.
Offene Klärungen
Dedupliziert und normalisiert · Agent-Rohfragen im Detailbereich
- Welche Art und Weise sollen die zusätzlichen Rechnungsadressen gespeichert werden (z.B. separater Tab oder Eintrag pro Adresse)?
- Welche verbindliche Governance-Bewertung liefert der Product Owner für den Product-Owner-Governance-Entscheid?
- Wie sollte man die Verwendung und Identifikation von zusätzlichen Rechnungsadressen im System umsetzen?
- Wird die spezifische Struktur der Rechnungsadresse in den Anforderungen bereits erfasst?
Agent-Rohfragen anzeigen▼
Originale Agent-Rohfragen aus dem Run, unbereinigt. Sie überschneiden sich teilweise mit den normalisierten Klärungen oben.
- Welche Art und Weise sollen die zusätzlichen Rechnungsadressen gespeichert werden?Agent-Rohfrage
- Wird die spezifische Struktur der Rechnungsadresse in den Anforderungen bereits erfasst?Agent-Rohfrage
- Wie sollte man die Verwendung und Identifikation von zusätzlichen Rechnungsadressen im System umsetzen?Agent-Rohfrage
Von Requirement-Sicht zu Governance Gate
05 Requirement Intelligence→06 Governance Intelligence
Die präzisierte Requirement-Sicht wird nun auf Umsetzungsfähigkeit, Risiken und Governance geprüft.
Governance Gate
Das Gate vor der Umsetzung · IREB Core Group
BLOCKED_BY_VETO Governance Status
HIGH Governance Severity
CRITICAL Höchste Eskalation
26 / 42 Kritisches Gewicht
0.62 Kritischer Anteil
CRITICAL Governance Stability
RELEASE READINESS
24 / 100
Severity: HIGH
Eskalation: CRITICAL
Kritisches Gewicht: 26 / 42
Kritischer Anteil: 0.62
Stability: CRITICAL
Vetorollen: Solution Architect · Tester
→ Der Change Request darf in der aktuellen Form nicht umgesetzt werden.
Der Change Request ist fachlich nachvollziehbar, aber in der aktuellen Form nicht delivery-ready. Architektur, Testbarkeit, Business Rules und Governance müssen vor Umsetzung geklärt werden.
Aktivierte Governance-Regel: [HIGH] Architecture Instability Block → Architekturreview zwingend erforderlich.
Bewertungslogik und Herkunft anzeigen▼
Wie aus Agentenoutputs ein Governance Gate entsteht
Wer erzeugt die Governance-Bewertung?
Die finale Governance-Bewertung ist keine freie Einzelantwort des LLM. Die LLM-Agenten liefern rollenbezogene Analysen, Risiken, offene Fragen, Statushinweise und Begründungen. Danach werden diese Outputs durch Parser, Normalisierung und Governance-Konsolidierung ausgewertet.
KurzformDie KI liefert Rollenbeiträge. Die Governance-Logik konsolidiert daraus Status, Score, Veto und Release Readiness.
1LLM-Agenten
→
2Parser / JSON-Prüfung
→
3Normalisierung / Fallback
→
4Governance-Konsolidierung
→
5Release Readiness
→
6HTML-Report
Wie entsteht 24 / 100?
Der Release Readiness Score ist die verdichtete Umsetzungsreife dieses Runs. Er basiert auf den konsolidierten Rollenoutputs, kritischen Rollenbeiträgen, offenen Business Rules, Architektur- und Testbarkeitsrisiken, Vetorollen und Governance-Status.
Der Wert 24 / 100 bedeutet in dieser Darstellung: Der Change Request ist fachlich nachvollziehbar, aber aus Governance-Sicht aktuell deutlich nicht umsetzungsreif.
HerkunftDie Zahl stammt aus der Governance-Konsolidierung des Runs. Die HTML zeigt den im Run ausgewiesenen Release-Readiness-Wert und berechnet ihn nicht neu.
Was passiert, wenn andere Run-Daten verwendet werden?
Wenn ein anderer Run verwendet wird, werden andere Agentenoutputs, Risiken, Fallbacks, Rollenstatus und Governance-Bewertungen verarbeitet. Dadurch können sich Release Readiness, kritisches Gewicht, kritischer Anteil, Severity, Eskalation und Governance Status ändern.
Wenn weniger offene Business Rules auftreten, keine Vetorolle blockiert und die Architektur- und Testbarkeitssicht stabiler ist, kann der Release Readiness Score höher ausfallen. Wenn zusätzliche Vetos, Fallbacks oder kritische Risiken auftreten, kann der Score niedriger ausfallen oder der Status weiterhin blockiert bleiben.
KurzformDie HTML zeigt Werte aus dem konkreten Run. Sie darf Werte nicht frei erfinden.
Warum BLOCKED_BY_VETO?
BLOCKED_BY_VETO bedeutet, dass mindestens eine Vetorolle die Umsetzung blockiert. In diesem Run sind Solution Architect und Tester als Vetorollen ausgewiesen. Dadurch wird der Change Request nicht nur als riskant bewertet, sondern aktiv für die Umsetzung gesperrt.
Kritisches Gewicht 26 / 42Das kritische Gewicht fasst die gewichteten kritischen oder blockierenden Beiträge des Runs zusammen. 26 von 42 bedeutet, dass ein hoher Anteil der bewerteten Governance-Last kritisch ist.
Kritischer Anteil 0.620.62 entspricht 26 / 42. Damit liegen rund 62 Prozent der gewichteten Bewertung im kritischen Bereich.
Governance Severity HIGHDie Governance-Schwere wird als hoch bewertet.
Höchste Eskalation CRITICALMindestens ein konsolidierter Eskalationswert liegt auf kritischer Stufe.
Governance Stability CRITICALDie Governance-Lage ist nicht stabil genug für eine Freigabe.
Quelle, Logik und Darstellung
Die angezeigten Governance-Werte stammen aus dem konkreten Reference Run. Die HTML-Seite berechnet diese Werte nicht neu, sondern visualisiert und erklärt die im Run konsolidierten Ergebnisse.
LLM-Agentenliefern rollenbezogene Rohbeiträge, Risiken, offene Fragen und Begründungen.
Parser / JSON-Prüfungerkennen, ob ein Agentenoutput strukturiert verwertbar ist.
Normalisierung / Fallbackmarkieren verwertbare Outputs, Abweichungen und Non-JSON-Antworten.
Governance-Konsolidierungleitet daraus Status, Veto, kritisches Gewicht, kritischen Anteil, Severity, Eskalation und Release Readiness ab.
HTML-Reportstellt diese Werte lesbar dar und erklärt ihre Bedeutung für den Leser.
KurzformDie KI liefert Rollenbeiträge. Die Runtime prüft und konsolidiert. Der Report zeigt und erklärt die Run-Ergebnisse.
Fazit der Bewertungsherkunft
Die Bewertung entsteht aus dem konkreten Run. Die LLM-Agenten liefern Rollenanalysen. Die Governance-Konsolidierung leitet daraus Status, Score, Gewichtung, Veto und Release Readiness ab. Bei anderen Run-Daten können sich diese Werte ändern.
Diese Erklärung beschreibt die Herkunft und Interpretation der vorhandenen Governance-Werte. Sie ersetzt keine vollständige technische Scoring-Dokumentation.
Der Change Request kann fachlich sinnvoll sein und trotzdem nicht delivery-ready sein. Governance Intelligence bewertet Risiko-Level, Vetorollen, kritische Rollen, Governance Severity, Governance Status und Release Readiness Score.
Von Governance zu Pattern Intelligence
06 Governance Intelligence→07 Pattern Intelligence
Die Governance-Bewertung zeigt Risiken und Blocker. Pattern Intelligence macht mögliche Strukturmuster sichtbar, ohne eine Umsetzung freizugeben.
Patterns helfen, die Lösung nicht frei zu erfinden, sondern an bekannten Strukturmustern auszurichten. Sie sind Empfehlungen, keine fertige Umsetzung.
Enterprise Pattern · Empfehlung
RBAC and Ownership Pattern
Rollenbasierte Zugriffskontrolle kombiniert mit klarer Daten-Ownership. Adressiert die offenen Fragen zu Berechtigungen, Systemgrenzen und Datenhoheit aus der Architektur-Bewertung.
Enterprise Pattern · Empfehlung
Audit Trail Pattern
Revisionssichere Protokollierung relevanter Änderungen an Rechnungsadressen. Unterstützt Compliance-, Governance- und Nachvollziehbarkeitsanforderungen.
Empfohlene Komposition
RBAC and Ownership Pattern + Audit Trail Pattern
Keine Pattern-Empfehlung bedeutet eine freigegebene technische Lösung. Patterns machen Lösungsrichtungen strukturiert sichtbar, die Umsetzungsentscheidung bleibt beim Governance Gate und der Delivery Pipeline.
Von Pattern Intelligence zu Story Intelligence
07 Pattern Intelligence→08 Story Intelligence
Aus Requirement, Rollenbeiträgen, Governance und Patterns entsteht nun ein agiler Story-Kandidat mit klarer Abgrenzung zur Delivery Pipeline.
Aus Requirement Intelligence, Governance-Bewertung und Rollenbeiträgen entsteht ein fachlich abgeleiteter agiler Story-Kandidat. Dieser Bereich zeigt Epic-Vorschlag, User Story 1, Akzeptanzkriterien, offene Business Rules, DoR-Entwurf, DoD-Entwurf und Testhinweise. Die Story ist fachlich abgeleitet, aber noch nicht delivery-ready.
Epic-Vorschlag
User Story 1
Fachlich abgeleitet
Nicht delivery-ready
BLOCKED_BY_VETO
Kein freigegebenes Jira-Artefakt
EPICVorschlag · Container für den Story-Kandidaten
Rechnungsadressverwaltung für Kundenkonten
Business Outcome
Das System soll Kunden ermöglichen, mehrere Rechnungsadressen im Kundenkonto zu verwalten und für unterschiedliche Rechnungssituationen die passende Rechnungsadresse zu verwenden.
Status
Fachlich abgeleitet, aber nicht delivery-ready.
Boundary
Kein freigegebenes Jira-Epic.
Fachlich abgeleitet · nicht delivery-ready
Zentrales agiles Artefakt
User Story 1
Fachlich abgeleiteter Story-Kandidat
Epic: Rechnungsadressverwaltung für Kundenkonten
BLOCKED_BY_VETO
AlsKunde
möchte ichmehrere Rechnungsadressen in meinem Kundenkonto verwalten können
damitich für unterschiedliche Rechnungssituationen die passende Rechnungsadresse verwenden kann.
Fachlich abgeleitet
Nicht delivery-ready
BLOCKED_BY_VETO
Kein Jira-ready Artefakt
Als Kunde möchte ich mehrere Rechnungsadressen in meinem Kundenkonto verwalten können, damit ich für unterschiedliche Rechnungssituationen die passende Rechnungsadresse verwenden kann.
Diese User Story beschreibt Nutzerziel und fachlichen Nutzen, ist aber noch nicht zur Umsetzung freigegeben.
Story Readiness Board
Prüf- und Readiness-Bereich: Warum der Story-Kandidat noch nicht delivery-ready ist
Akzeptanzkriterien-Vorschlag
Vorschlag · nicht final · fachlich zu bestätigen
AC VorschlagEine neue Rechnungsadresse kann einem Kundenkonto hinzugefügt werden.
AC VorschlagEine bestehende Rechnungsadresse kann geändert werden.
AC VorschlagEine bestehende Rechnungsadresse kann gelöscht oder deaktiviert werden, sofern fachlich erlaubt.
AC VorschlagEine Rechnungsadresse kann als Standard-Rechnungsadresse festgelegt werden, sofern diese Regel fachlich vorgesehen ist.
AC VorschlagBestehende Rechnungsprozesse bleiben nach der Erweiterung kompatibel.
Offene Business Rules vor Delivery-Readiness
BR offenMaximale Anzahl speicherbarer Rechnungsadressen pro Kunde ist nicht spezifiziert.
BR offenRegel zur Standard-Rechnungsadresse ist nicht spezifiziert.
BR offenLösch- oder Deaktivierungsverhalten für Rechnungsadressen ist nicht spezifiziert.
BR offenPflichtfelder und Validierungsregeln je Rechnungsadresse müssen geklärt werden.
BR offenRegel zur Verwendung einer Rechnungsadresse in bestehenden Rechnungsprozessen ist nicht spezifiziert.
Diese offenen Business Rules verhindern Delivery-Readiness.
Definition of Ready · EntwurfDraft · not approved
- ›Fachlicher Scope ist geklärt.
- ›Offene Business Rules sind entschieden.
- ›Akzeptanzkriterien sind fachlich bestätigt.
- ›Datenmodell-Auswirkungen sind grob verstanden.
- ›API- und Prozessauswirkungen sind bewertet.
- ›Testdaten und Testfälle sind ableitbar.
- ›Governance-Blocker sind geklärt oder bewusst akzeptiert.
Definition of Done · EntwurfDraft · not approved
- ✓Die Funktion erfüllt die bestätigten Akzeptanzkriterien.
- ✓Positive Testfälle sind erfolgreich durchgeführt.
- ✓Negative Testfälle und Fehlerfälle sind geprüft.
- ✓Regression bestehender Rechnungsprozesse und relevanter APIs ist geprüft.
- ✓Relevante fachliche und technische Dokumentation ist aktualisiert.
- ✓Keine offenen Blocker aus Architektur, Testing oder Governance bestehen.
Test- und Regression-Hinweise
✓ Positive Testfälle
- ✓Neue Rechnungsadresse kann hinzugefügt werden.
- ✓Bestehende Rechnungsadresse kann geändert werden.
! Negativ / Fehlerfälle
- !Ungültige, unvollständige oder doppelte Rechnungsadressen werden geprüft.
✕ Regression / Release-Risiko
- ✕Regression bestehender APIs und Rechnungsprozesse muss geprüft werden.
Testhinweise sind aus der Story ableitbar, aber Testfälle und Testdaten müssen vor Delivery konkretisiert werden.
Delivery Boundary
Diese Story ist nicht release-ready und nicht delivery-ready. Offene Business Rules sind noch nicht final entschieden. Die User Story ist noch keine freigegebene Jira- oder Delivery-Story. Finale Akzeptanzkriterien, finale Definition of Done und technische Tasks entstehen weiterhin über die Delivery Pipeline.
Core Analysis
erzeugt Story-Kandidat
→
Delivery Pipeline
erzeugt finale Delivery-Artefakte
Von Story Intelligence zu Solution Intelligence
08 Story Intelligence→09 Solution Intelligence
Der Story-Kandidat zeigt fachliches Ziel, offene Business Rules und Delivery-Grenzen. Solution Intelligence verdichtet daraus eine erste fachlich-technische Lösungsrichtung, ohne eine Umsetzung freizugeben.
Aus Requirement, Governance, Pattern und Story entsteht hier keine fertige Lösung, sondern ein Lösungskorridor. Solution Intelligence zeigt, welche fachlich-technischen Richtungen plausibel sind und welche Entscheidungen vor Umsetzung noch offen bleiben.
Lösungskorridor
Die Lösung muss mehrere Rechnungsadressen pro Kundenkonto fachlich abbilden und bestehende Rechnungsprozesse kompatibel halten.
Berechtigung und Ownership
Berechtigungsmodell, Rollenrechte und Datenverantwortung müssen konkretisiert werden. Das empfohlene RBAC and Ownership Pattern liefert eine Strukturidee, aber keine fertige Umsetzung.
API- und Prozessauswirkungen
Bestehende Rechnungsprozesse, Datenflüsse und mögliche API-Auswirkungen müssen geprüft werden. Unklare Auswirkungen bleiben ein Umsetzungsrisiko.
Offene Lösungsentscheidungen
Maximale Anzahl, Standardadresse, Lösch- oder Deaktivierungsverhalten, Pflichtfelder, Validierungsregeln und Verwendung in bestehenden Rechnungsprozessen müssen vor Umsetzung entschieden werden.
Die Lösungsskizze ist eine Entscheidungsgrundlage. Sie ist keine technische Spezifikation und keine Umsetzungsfreigabe. Sie definiert keine finale API und kein finales Datenmodell.
Agent-Rohbeiträge anzeigen▼
Originale Lösungshinweise aus den Agentenläufen, teilweise mit unsauberen Formulierungen. Sie bleiben als Evidenz sichtbar.
- !Berechtigungsmodell konkretisieren: Rollenzugriffssteigerungen für die Anforderung müssen in der Governance-Struktur bestätigt werden. Agent-Rohbeitrag
- !API-Auswirkung berücksichtigen: Wenn eine existierende Rechnungsadressen-Zugehörigkeit geändert wird, sind die Nachfolge-APIs nicht vollständig bewertet. Agent-Rohbeitrag
Von Solution Intelligence zu Architecture Blueprint
09 Solution Intelligence→10 Architecture Blueprint Intelligence
Die Lösungsskizze wird nun in technische und fachliche Zielbereiche eingeordnet. Der Blueprint zeigt Verantwortungsbereiche und Architekturgrenzen, ersetzt aber kein technisches Design.
Architecture Blueprint Intelligence ordnet die Lösungsskizze in technische und fachliche Zielbereiche ein. Die Layer zeigen, wo Verantwortung, Prüfung und spätere Spezifikation notwendig sind. Der Blueprint ist high-level und bleibt bewusst unterhalb einer technischen Detailarchitektur.
Security LayerBerechtigungen, Rollenrechte und Zugriff auf Rechnungsadressen müssen geregelt werden.
Governance LayerGovernance-, Security- und Compliance-Regeln werden zentral bewertet und dürfen nicht in Einzelentscheidungen verschwinden.
Audit LayerRelevante Änderungen an Rechnungsadressen müssen nachvollziehbar protokollierbar sein.
API LayerAPI-Auswirkungen und mögliche neue oder geänderte Endpunkte müssen geprüft werden. Aktuell ist noch keine finale API-Spezifikation vorhanden.
Data / Storage LayerDatenmodell, Tabellenstruktur, Pflichtfelder, Schlüssel, Historisierung und Validierungslogik müssen konkretisiert werden. Aktuell ist noch keine echte Datenbank-Introspektion angebunden.
Integration BoundaryAuswirkungen auf bestehende Rechnungsprozesse, Umsysteme und Rückwärtskompatibilität müssen geprüft werden.
Der Blueprint ist high-level. Er zeigt Zielstruktur, Verantwortungsbereiche und offene Architekturfragen. Er ersetzt kein technisches Design, keine OpenAPI-Spezifikation und kein Datenbankschema und basiert aktuell nicht auf echter Live-Datenbank- oder API-Introspektion.
Vom Blueprint zur Entscheidung
10 Architecture Blueprint Intelligence→11 Decision Intelligence
Die Architektur- und Lösungshinweise werden mit Governance, Risiken, Rollenbeiträgen und offenen Fragen zusammengeführt. Daraus entsteht der konsolidierte Entscheid.
Aus Rollenoutputs, Governance-Bewertung, Patterns und Story-Ableitung entsteht der konsolidierte Entscheid. Die Hauptansicht ist kuratiert, die originalen Agentenrisiken bleiben im Detailbereich erhalten.
Konsolidierter Entscheid
Der Change Request darf in der aktuellen Form nicht umgesetzt werden.
24 / 100
Release Readiness
CRITICAL
Höchste Eskalation
Begründung: Der Change Request ist fachlich nachvollziehbar, aber Architektur, Testbarkeit, Business Rules, Datenmodell, API-Auswirkungen und Governance sind noch nicht ausreichend geklärt.
Risikocluster 1
Architektur und Integration
Systemgrenzen, Datenhoheit, API-Auswirkungen und Rückwärtskompatibilität sind nicht ausreichend geklärt.
Risikocluster 2
Security und Governance
Berechtigungen, Ownership, RBAC, Governance-Regeln und mögliche Rollenzugriffe sind nicht final entschieden.
Risikocluster 3
Testing und Delivery Readiness
Akzeptanzkriterien, Testdaten, Fehlerfälle, Regression und Release-Kriterien sind noch nicht ausreichend konkretisiert.
Konflikte zwischen Rollen
Product Ownerschützt MVP, Scope und Business Value
Solution Architectblockiert wegen Architektur- und Integrationsrisiken
Testerblockiert wegen fehlender Testbarkeit und fehlender Release-Kriterien
Agent-Risiken aus Rohdaten anzeigen▼
Die folgenden Einträge sind originale Risikoformulierungen aus den Agentenläufen. Einzelne Formulierungen können roh oder sprachlich unsauber sein. Sie bleiben als Evidenz sichtbar, dominieren aber nicht die kuratierte Entscheidung.
Critical · Security
Der Server sollte fachliche und technische Rollenübersichtsmechanismen in Betracht ziehen.Agent-Rohbeitrag
Ein unbekanntes oder nicht offizielles RBAC-System könnte zu einer Verschlechterung der Sicherheitsstrategie führen.Agent-Rohbeitrag
Rollenzugriffssteigerungen für Umsetzung nicht festgelegt.Agent-Rohbeitrag
High · Architecture
Definiere klare Systemgrenzen für die neue API.Agent-Rohbeitrag
High · API
Es fehlen klare Definitionen der neuen API-Schnittstellen.Agent-Rohbeitrag
Medium · Business
DATENREGEL ZWEISCHRITTENVERIFIED-ZUSATZ / Prozessbeeinträchtigung möglich.Agent-Rohbeitrag
Medium · Testing
Tester output is not valid JSON.Agent-Rohbeitrag
Low · Governance
5 Governance-Risiken, vollständig im Evidence-Bereich (Sektion 13) ausgewiesen.Agent-Rohbeitrag
Nächste Klärungsschritte
Was vor einer möglichen Umsetzung geklärt werden muss
- 01Fehlende Business Rules, Datenregeln und Akzeptanzkriterien definieren.
- 02Business Value, MVP-Relevanz, Scope und Priorisierung klären.
- 03Datenmodell, Validierungen, technische Auswirkungen und Umsetzungsoptionen konkretisieren.
- 04Systemgrenzen, Datenhoheit, Storage-Verantwortung und Integrationsfolgen klären.
- 05Testdaten, Positivtests, Negativtests, Berechtigungstests und Regressionstests definieren.
Von Decision Intelligence zu Delivery Readiness
11 Decision Intelligence→12 Delivery Readiness Intelligence
Der Entscheid blockiert die Umsetzung in der aktuellen Form. Delivery Readiness zeigt, welche Artefakte und Klärungen vor einer echten Umsetzung noch fehlen.
⚠
Keine Umsetzungsfreigabe
Der Change Request ist durch Vetorollen blockiert und nicht delivery-ready.
Keine freigegebene Delivery Story
Nicht freigegeben
Die User Story aus 08 ist fachlich abgeleitet, aber keine freigegebene Jira- oder Delivery-Story.
Finale Akzeptanzkriterien fehlen
Nicht erzeugt
Die Akzeptanzkriterien aus 08 sind Vorschläge. Finale Delivery-Akzeptanzkriterien entstehen erst in der Delivery Pipeline.
Finale Definition of Done fehlt
Nicht erzeugt
Der DoD-Entwurf aus 08 ist nicht final. Die finale Definition of Done entsteht in der Delivery Pipeline.
Technische Tasks fehlen
Nicht erzeugt
Technische Tasks werden in diesem Core-Gruppenlauf nicht erzeugt. Sie entstehen sinnvoll erst über die Delivery Pipeline.
Core Analysis
erzeugt Story-Kandidat, Risiken, Entscheid und Klärungsbedarf
→
Delivery Pipeline
erzeugt finale Delivery-Artefakte, technische Tasks, finale Akzeptanzkriterien und finale Definition of Done
Delivery Readiness ist nicht die Wiederholung von Story Intelligence. Dieser Abschnitt trennt bewusst fachliche Ableitung von echter Umsetzungsfreigabe. Die Core Analysis erzeugt eine Entscheidungsgrundlage. Die Delivery Pipeline erzeugt erst danach die umsetzbaren Artefakte.
Von Delivery Readiness zu Evidence Intelligence
12 Delivery Readiness Intelligence→13 Evidence Intelligence
Nach Entscheidung und Delivery-Abgrenzung zeigt Evidence Intelligence, worauf die kuratierte Hauptansicht basiert und welche Rohdaten als Nachvollziehbarkeit erhalten bleiben.
Evidence Intelligence macht nachvollziehbar, worauf die kuratierte Entscheidung basiert. Die Hauptseite zeigt eine lesbare Entscheidungslogik. Der Evidence-Bereich hält Reportdaten, Agentenoutputs, Normalisierungen, Fallbacks und Rohdaten als prüfbare Grundlage bereit.
Die kuratierte Hauptansicht zeigt die Entscheidung.
Evidence Intelligence zeigt, worauf diese Entscheidung basiert.
Die Rohdaten werden nicht versteckt.
Fallbacks, Normalisierungen und historische Rohbausteine bleiben nachvollziehbar.
Diese HTML-Version zeigt den vollständigen konsolidierten Reportauszug aus full_evidence_report.md. Vollständige Agentenberichte und JSON-Rohdaten sind Teil des Full-Evidence-Konzepts und sollen als eigene Evidence-Akkordeons ergänzt werden.
Full-Evidence-Ausbau
Welche Evidenzbereiche künftig getrennt sichtbar werden sollen
Aktuell sichtbarKonsolidierter Entscheidungsreport
Konzeptuell vorgesehenVollständige Agentenberichte
Konzeptuell vorgesehenNormalisierung und Fallbacks
Konzeptuell vorgesehenAgent Results JSON
Konzeptuell vorgesehenOriginale Rohdaten
Konsolidierter Reportauszug
▼
Rohdaten-Hinweis
Dieser Bereich zeigt den konsolidierten Reportauszug aus dem aktuellen Evidence-Paket. Historische Fallback-Bausteine und rohe Agentenformulierungen bleiben als Evidenz sichtbar. Rohdaten können historische Fallback-, Encoding- oder Agenten-Artefakte enthalten. Die kuratierte Hauptansicht trennt fachliche Interpretation und Rohdaten.
DECISION-LAB / AGENT SWARM INTELLIGENCE
Run: runs/run_2026-06-11_17-51-05_a48f
Gruppe: TEST - IREB Core Group
Change Request: Ein Kunde soll mehrere Rechnungsadressen speichern können.
─────────────────────────────────────────────────────────
REQUIREMENT EVOLUTION
─────────────────────────────────────────────────────────
Status: CLARIFICATION_REQUIRED
Requirement Type: FUNCTIONAL
Original: Ein Kunde soll mehrere Rechnungsadressen speichern können.
RES-v1: NO_MEANINGFUL_IMPROVEMENT
RES-v1 verändert das Original nicht frei, wenn keine sicher ableitbare zusätzliche Business Rule vorliegt.
Offene Klärungen:
- Welche Art und Weise sollen die zusätzlichen Rechnungsadressen gespeichert werden?
- Welche verbindliche Governance-Bewertung liefert Product Owner für: Product-Owner-Governance-Entscheid?
- Wie sollte man die Verwendung und Identifikation von zusätzlichen Rechnungsadressen im System umsetzen?
- Wird die spezifische Struktur der Rechnungsadresse in den Anforderungen bereits erfasst?
─────────────────────────────────────────────────────────
IREB-SATZSCHABLONEN-PRÄZISIERUNG
─────────────────────────────────────────────────────────
Kernanforderung:
Das System muss dem Kunden die Möglichkeit bieten, mehrere Rechnungsadressen seinem Kundenkonto zuzuordnen, zu speichern, zu ändern und zu verwalten.
Vollständigkeitshinweis:
- Die vollständige präzisierte Anforderung besteht aus Kernanforderung plus expliziten Randbedingungen aus dem Original.
- Die Kernanforderung allein ersetzt nicht den vollständigen Original-Change-Request.
─────────────────────────────────────────────────────────
USER STORY PAKET
─────────────────────────────────────────────────────────
Epic-Vorschlag: Rechnungsadressverwaltung für Kundenkonten
Das System soll Kunden ermöglichen, mehrere Rechnungsadressen im Kundenkonto zu verwalten und für unterschiedliche Rechnungssituationen die passende Rechnungsadresse zu verwenden.
Status: Fachlich abgeleitet, aber nicht delivery-ready.
User Story 1:
Status: Fachlich abgeleitet, aber nicht delivery-ready.
Governance: BLOCKED_BY_VETO
Story: Als Kunde möchte ich mehrere Rechnungsadressen in meinem Kundenkonto verwalten können, damit ich für unterschiedliche Rechnungssituationen die passende Rechnungsadresse verwenden kann.
Akzeptanzkriterien-Vorschlag:
- Eine neue Rechnungsadresse kann einem Kundenkonto hinzugefügt werden.
- Eine bestehende Rechnungsadresse kann geändert werden.
- Eine bestehende Rechnungsadresse kann gelöscht oder deaktiviert werden, sofern fachlich erlaubt.
- Eine Rechnungsadresse kann als Standard-Rechnungsadresse festgelegt werden, sofern diese Regel fachlich vorgesehen ist.
- Bestehende Rechnungsprozesse bleiben nach der Erweiterung kompatibel.
─────────────────────────────────────────────────────────
1. KURZFAZIT
─────────────────────────────────────────────────────────
Gruppe: TEST - IREB Core Group
Beteiligte Rollen: Business Analyst, Product Owner, Developer, Software - Solution Architect, Tester
Kritische Rollen: Product Owner, Software - Solution Architect, Tester
Vetorollen: Software - Solution Architect, Tester
Governance Severity: HIGH
Governance Status: BLOCKED_BY_VETO
Höchste Eskalation: CRITICAL
Der Change Request ist durch mindestens eine Vetorolle blockiert.
2. ENTSCHEIDUNGSSTATUS
- Kritisches Gewicht: 26 von 42
- Kritischer Anteil: 0.62
- Release Readiness Score: 24 von 100
- Governance Stability: CRITICAL
3. ZENTRALE BLOCKER
- Definiere klare Systemgrenzen für die neue API, um mögliche Konflikte mit existierenden APIs zu vermeiden.
4. WICHTIGSTE RISIKEN
CRITICAL – SECURITY:
- Der Server sollte fachliche und technische Rollenübersichtsmechanismen in Betracht ziehen.
- Ein unbekanntes oder nicht offizielles RBAC-System könnte zu einer Verschlechterung der Sicherheitsstrategie führen.
- Rollenzugriffssteigerungen für Umsetzung nicht festgelegt.
HIGH – ARCHITECTURE: Definiere klare Systemgrenzen für die neue API.
HIGH – API: Es fehlen klare Definitionen der neuen API-Schnittstellen.
MEDIUM – BUSINESS: DATENREGEL ZWEISCHRITTENVERIFIED-ZUSATZ / Prozessbeeinträchtigung möglich.
MEDIUM – TESTING: Tester output is not valid JSON.
LOW – GOVERNANCE: [5 Risiken - siehe vollständiges File]
5. OFFENE FRAGEN
- Welche Art und Weise sollen die zusätzlichen Rechnungsadressen gespeichert werden?
- Welche verbindliche Governance-Bewertung liefert der Product Owner?
- Wie sollte man die Verwendung und Identifikation umsetzen?
- Wird die spezifische Struktur der Rechnungsadresse bereits erfasst?
6. KONFLIKTE
- Product Owner ↔ Software - Solution Architect
- Software - Solution Architect ↔ Product Owner
8. GOVERNANCE BEWERTUNG
- [HIGH] Architecture Instability Block → Architekturreview zwingend erforderlich.
- Governance Status: BLOCKED_BY_VETO · Höchste Eskalationsstufe: CRITICAL
9. EMPFEHLUNG
- Der Change Request darf in der aktuellen Form nicht umgesetzt werden.
10. LÖSUNGSSKIZZE
- Berechtigungsmodell konkretisieren
- API-Auswirkung berücksichtigen
- Empfohlenes Pattern: RBAC and Ownership Pattern + Audit Trail Pattern
10A. ARCHITEKTUR-BLUEPRINT
- Security Layer: Berechtigungen und Ownership zentral erzwingen.
- Governance Layer: Governance-, Security- und Compliance-Regeln zentral bündeln.
- Audit Layer: Alle relevanten Entscheidungen revisionssicher protokollieren.
11. NÄCHSTE SCHRITTE
- Fehlende Business Rules, Datenregeln und Akzeptanzkriterien definieren.
- Business Value, MVP-Relevanz, Scope und Priorisierung klären.
- Datenmodell, Validierungen, technische Auswirkungen und Umsetzungsoptionen konkretisieren.
- Systemgrenzen, Datenhoheit, Storage-Verantwortung und Integrationsfolgen klären.
- Testdaten, Positivtests, Negativtests, Berechtigungstests und Regressionstests definieren.