← Zur Framework-Seite 01 Input Intelligence 02 Warum dieser Weg 03 Agent Swarm Intelligence Stack 04 Role Intelligence 05 Requirement Intelligence 06 Governance Intelligence 07 Pattern Intelligence 08 Story Intelligence 09 Solution Intelligence 10 Architecture Blueprint Intelligence 11 Decision Intelligence 12 Delivery Readiness Intelligence 13 Evidence Intelligence
Agent Swarm Intelligence

DECISION-LAB

MVP 2.0 · Silo 1 · RunPod · CR 3 / Stage 2 · Run 44d5 · qwen2.5:7b · runs/run_2026-07-20_16-13-28_44d5
Original Run Evidence unverändert · Execution Context separat bestätigt · Post-Run-Audit kuratiert
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.
← Zur Framework-Seite Report lesen
Original Run Evidence
Unveränderte Werte und Inhalte aus den zehn Run-Artefakten. Diese Ebene bleibt historische Evidence.
Execution Context
Separat bestätigte Angaben zu RunPod, GPU, Runtime, Modell und Git. Nicht Teil des ursprünglichen Run-Pakets.
Post-Run Audit
Spätere Prüfung von Konsistenz, Provenienz und Verbesserungsbedarf. Auditstand: 21. Juli 2026. Keine nachträgliche Veränderung des Runs.
Run-Status
VALID_MVP2_RUNPOD_STAGE2_EVIDENCE
  • Run 44d5 · CR-Stufe 2 · dritter Lauf der Serie
  • qwen2.5:7b · SMART_ROUTING
  • 20,79 s · fünf Rollen
  • JSON 5/5 · Purity 100 · Context Purity OK
Governance
BLOCKED_BY_VETO
  • Release Readiness 30/100
  • Severity HIGH · Stability CRITICAL
  • Vetorolle: Tester
  • Kritische Rollen: Developer, Tester
  • Aktivierte Regel: Testing Release Block
Execution Context
RunPod RTX 3090
  • 24 GB VRAM · Ollama 0.32.1 · Warm Model
  • qwen2.5:7b · Q4_K_M
  • Branch: mvp2/runpod-7b-cr-series-comparison-v1
  • HEAD: 93f49ce · identisch mit Lauf 5e63
  • Quelle: separater Live-Audit, nicht im Run-Paket
Serienentscheidung
MVP2_7B_THREE_RUN_BASELINE_SERIES_COMPLETE
  • 1ee4, 5e63 und 44d5 liegen vollständig vor
  • 44d5 unverändert als Evidence erhalten
  • Gemeinsame Bewertung der drei Läufe steht an
  • Erst danach systematische Verbesserungen
Post-Run-Audit und bekannte Limitationen
  • Der Tester liefert zum dritten Mal keine verwertbare fachliche QA-Evidence; der Contract blockiert fail-closed mit no_usable_tester_content_after_enforcement. Das Fail-Closed-Verhalten ist richtig, die Testerleistung selbst ist ein Ausfall.
  • Der Tester-Raw-Output-Hash f4cb9f6b…c918 ist in 1ee4, 5e63 und 44d5 identisch, also über drei unterschiedliche Change Requests hinweg. Aus dem Einzelbefund ist ein reproduzierbares Serienmuster geworden. Es deutet auf Prompt Collapse, starres Fallback-Verhalten oder Response-Wiederverwendung hin, beweist allein aber weiterhin keinen Cache-Fehler.
  • Der kanonische Wert qa_decision = BLOCKED verschärft den Rohwert REQUIRES_FIXES, obwohl qa_decision_normalized auf false steht. Diese Konstellation ist als Contract-Telemetry-Ambiguität zu behandeln: Der kanonische BLOCKED-Wert kann aus dem Enforcement stammen, während qa_decision_normalized nur die Alias- oder Variant-Normalisierung beschreibt. Die genaue Contract-Semantik ist noch zu prüfen.
  • Der Solution Architect liefert einen feldidentischen Rollenoutput wie im Basislauf 1ee4, obwohl der Change Request zwei Erweiterungsstufen weiter ist. Der CR-Complexity-Sensitivity-Gap ist damit belegt und nicht mehr nur vermutet.
  • Die Business-Analyst-Summary behauptet vollständig beschriebene Business Rules und Akzeptanzkriterien und weist im selben Output drei fehlende Business Rules und zwei fehlende Akzeptanzkriterien aus. Der Quality Guard meldet dennoch OK.
  • Der Product Owner verwendet erneut den von 5e63 bekannten abweichenden Feldsatz. Sein business_value ist diesmal ausformuliert, erreicht die Delivery-Ableitung aber nicht, business_value_hints bleibt leer.
  • regression_hints und constraints bleiben leer, obwohl der Change Request die Rückwärtskompatibilität ausdrücklich verlangt und Developer wie Product Owner sie behandeln. Der Compatibility Propagation Gap ist damit in beiden Umgebungen belegt.
  • Die Developer-Summary ist leer, obwohl dieser Lauf den fachlich reichhaltigsten Developer-Output der Serie enthält.
  • Der historische Raw-Report meldet Keine zentralen Blocker erkannt, obwohl Governance BLOCKED_BY_VETO ausweist. Die Reportsektion erklärt zudem statisch REQUIRES_FIXES statt BLOCKED.
01
Input Intelligence
Der Auftrag an die Simulation

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. Pro Rechnungsadresse sollen eigene Länder-, Steuer- und Validierungsregeln unterstützt werden. Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.
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
Original Run EvidenceExecution Context
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:7b AUSFÜHRUNGSUMGEBUNGRunPod · NVIDIA GeForce RTX 3090 · 24 GB VRAM Quelle: separater Execution Context, nicht Bestandteil des Run-PaketsRUNTIMEOllama 0.32.1MODELLqwen2.5:7b · 7.6B · Q4_K_MMODELLKAPAZITÄT32768 Tokens laut separat geprüftem Ollama-ModellmanifestRUNTIME NUM_CTXFür Run 44d5 im Run-Paket nicht separat ausgewiesenGITBranch: mvp2/runpod-7b-cr-series-comparison-v1
HEAD: 93f49ce6e9ed05f00527421ddc1e6d5e05593d98 ROLLENBusiness Analyst · Product Owner · Developer · Software - Solution Architect · Tester

Die fachliche Präzisierung, Rollenbewertung, Governance-Prüfung, Story-Ableitung und Umsetzungsentscheidung entstehen erst in den folgenden Abschnitten.

Runtime State · Separate Execution Context
RUNTIME STATEWARM MODEL METHODISCHE GRENZEDas Modell war unmittelbar vor 44d5 bereits vollständig auf der GPU geladen. Die 20,79 Sekunden enthalten deshalb keinen vollständigen Cold-Load-Anteil und dürfen nicht als Cold-Start-Laufzeit interpretiert werden. MODELLKAPAZITÄT32768 Tokens laut separat geprüftem Ollama-Modellmanifest RUNTIME NUM_CTXFür Run 44d5 im Run-Paket nicht separat ausgewiesen; keine automatische Gleichsetzung mit der Modellkapazität RUN CREATED AT20. Juli 2026 · 16:13:28 EXECUTION CONTEXTUnmittelbar vor dem Run separat geprüft; exakter Capture-Zeitpunkt nicht im Run-Paket gespeichert POST-RUN AUDITAktualisiert am 21. Juli 2026 SERIES STATUSAktualisiert am 21. Juli 2026
Rolle Laufzeit
Business Analyst5,36 s
Product Owner4,62 s
Developer4,63 s
Solution Architect3,07 s
Tester3,09 s
Gesamt20,79 s
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.

02
Warum dieser Weg
Die Begründung für den Agent Swarm Intelligence Stack
Architektur-Rationale
Warum dieser aufwendige Weg?
Modell-Kontext. Die MVP-1.0-Baseline lief mit qwen2.5:3b, die MVP-1.1-Kette mit dem festen Vergleichsmodell qwen2.5:7b, beide lokal auf NAB9; 434c bleibt die Referenz dieser lokalen Kette. Dieser Lauf 44d5 ist der dritte und letzte Lauf der MVP-2.0-Serie, welche die nominell unveränderte Pipeline auf einer RunPod-Cloud-GPU ausführt (1ee4 Basis-CR, 5e63 CR-Stufe 1, 44d5 CR-Stufe 2, Knowledge SMART_ROUTING). Instanz-, GPU- und Versionsangaben folgen aus dem separaten Execution Context und werden hier nicht behauptet. Daraus folgt keine allgemeine Modellpromotion.
Kompaktes Modell, kontrollierte Entscheidungslogik statt blindem Vertrauen in eine Einzelantwort, unabhängig davon, ob lokal oder auf einer Cloud-GPU ausgeführt wird.
Historische lokale Basis MVP 2.0: ausschliesslich qwen2.5:7b Historische MVP-1.x-Basis: NAB9 Aktueller Run: RTX 3090 24 GB VRAM 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 entstand im lokalen MVP-1.x-Setup und wird in MVP 2.0 auf RunPod weitergeführt. Das System entstand als lokale Pipeline auf kompakter Hardware (MVP 1.0 und MVP 1.1 auf NAB9). Dieser Lauf gehört zur MVP-2.0-Serie, welche dieselbe, nominell unveränderte Pipeline auf einer RunPod-Cloud-GPU ausführt; Instanz- und Versionsangaben folgen aus dem separaten Execution Context. 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.

Die MVP-1.0-Baseline qwen2.5:3b und das MVP-1.1-Vergleichsmodell qwen2.5:7b liefen lokal auf einem NAB9 mit Intel i9-12900HK und Intel Iris Xe Graphics (96 EU). Dieser Lauf gehört zur MVP-2.0-Serie auf RunPod; die lokale NAB9-Umgebung bleibt die Referenzumgebung der MVP-1.1-Kette.

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 in einem selbst gehosteten Setup 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, selbst gehosteten 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 Modellbetriebs
Ein kompaktes Modell benötigt eine klar geführte Pipeline; das gilt unabhängig davon, ob die Ausführung lokal oder auf einer Cloud-GPU erfolgt. Qualität entsteht hier nicht durch Modellgrösse oder Hardware, 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.

03
Agent Swarm Intelligence Stack
Wie aus einem einfachen Requirement eine Entscheidungsgrundlage entsteht

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.

04
Role Intelligence
Fünf Perspektiven prüfen denselben Change Request
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 für diesen Run ausgewählte 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 für diesen Run ausgewählte, selbst gehostete 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 führt das eingesetzte 7B-Modell durch zusätzlichen rollenbezogenen Kontext. 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.

Rollen-Auswertungen des Runs
Fünf Perspektiven auf denselben Change Request

Jede Rolle bewertet denselben Change Request aus ihrer eigenen Verantwortung. Dadurch entsteht ein mehrperspektivisches Bild aus Fachlichkeit, Produkt, Technik, Architektur und Qualitätssicherung.

BA
Business Analyst
Fachlicher Kern · Business Rules · Akzeptanzkriterien
▼
Output: JSONRisk: MEDIUMGovernance: Kein Veto, nicht kritisch
Raw OutputNormalization Marker vorhandenCurated Synthesis
Governance-Wirkung: Der Business Analyst benennt drei fehlende Business Rules, zwei fehlende Akzeptanzkriterien und die Prozessauswirkung der Rückwärtskompatibilität. Seine Summary behauptet im selben Output, die Anforderungen seien präzise formuliert, entscheidungsreif und vollständig beschrieben. Dieser Cross-Field-Widerspruch bleibt bei grünem Quality Guard unentdeckt; massgeblich sind die ausgewiesenen Lücken, nicht die Summary.
▼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.
  • ›Für jede Rechnungsadresse werden die im Original genannten Länder-, Steuer- und Validierungsregeln geprüft.
  • ›Ungültige Kombinationen aus Land, Steuerregel und Validierungsregel werden abgelehnt.
  • ›Bestehende Rechnungsprozesse bleiben nach der Erweiterung kompatibel.
  • ›Bestehende API-Schnittstellen werden nicht inkompatibel verändert.
  • ›Prüfhinweis: Die Rückwärtskompatibilität ist verbindlich gefordert, ihre technische Erfüllung ist im Lauf nicht nachgewiesen.
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.
PO
Product Owner
Business Value · MVP · Scope
▼
Output: JSONRisk: MEDIUMGovernance: Kein Veto, nicht kritisch
Raw OutputNormalization Marker vorhandenCurated Synthesis
Governance-Wirkung: Der Product Owner liefert eine formale Governance-Bewertung (po_decision PARTIALLY_APPROVABLE, risk_level MEDIUM, Quality Guard OK). Sein Rohoutput verwendet erneut den von 5e63 bekannten abweichenden Feldsatz (user_story, business_value, acceptance_criteria, business_rules, risks als Objekte); ob das einen Contract-Verstoss darstellt, wird erst nach Prüfung des tatsächlichen PO-Contracts entschieden. Der business_value ist in diesem Lauf ausformuliert, erreicht die Delivery-Ableitung aber nicht, business_value_hints bleibt leer. Inhalte sind keine finalen Produktentscheidungen.
▼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.
  • !Adressbezogene Länder-, Steuer- und Validierungsregeln sowie die verbindliche Rückwärtskompatibilität erhöhen Scope-, Delivery- und Release-Risiken. MVP-Abgrenzung und Priorisierung müssen bestätigt werden.
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?
Business Value, MVP-Scope und Priorisierung vor Umsetzung klären.
PO Governance Mapping aktiv: Der Product Owner liefert in diesem Lauf eine formale Governance-Bewertung: po_decision PARTIALLY_APPROVABLE, risk_level MEDIUM, quality_guard_status OK. Konservatives Mapping aus dem MVP-1.1-Hardening; daraus wird keine automatische Freigabe abgeleitet, der Umsetzungsentscheid bleibt beim Governance-Gate (Tester-Veto). Hinweis zur Abgrenzung: Der PO-Rohoutput verwendet erneut den abweichenden Feldsatz aus 5e63. Der ausformulierte business_value zu Nutzerfreundlichkeit und Kontrolle über Lieferländer bleibt eine Hypothese und erreicht die Delivery-Ableitung nicht, business_value_hints bleibt leer. Diese Inhalte sind keine finalen Produktentscheidungen, keine Scope-Freigabe und keine Delivery-Grundlage.
DEV
Developer
Datenmodell · Validierung · API
▼
Output: JSONRisk: HIGHGovernance: Critical Role
Raw OutputNormalization Marker vorhandenCurated Synthesis
Governance-Wirkung: Kritische Rolle dieses Runs: technical_decision NOT_APPROVABLE, implementation_status NOT_IMPLEMENTABLE, risk_level HIGH, solange Regelinhalte, Validierungen und Fehlercodes offen sind. Dieser Lauf enthält den fachlich reichhaltigsten Developer-Output der Serie mit Regelmodell, Gültigkeitszeiträumen, Versionierung, Rule Ownership, Validierungsquelle, Fehlercodes, Default-Verhalten, Migrations- und Kompatibilitätsnotizen. Die Developer-Summary ist dennoch leer, der Quality Guard meldet OK; das ist Teil der dokumentierten Defektliste. Strenge technische Rollenposition, keine Aussage über die Pipeline-Stabilität.
▼Details anzeigen
Darstellung: Kuratierte Neuordnung des Original-Developer-Outputs. Die Inhalte stammen aus dem Run; Reihenfolge und Überschriften wurden für die Stage-2-Lesbarkeit strukturiert.
Regelmodell und Regelkontext
  • ›Länder-, Steuer- und Validierungsregeln müssen je Rechnungsadresse eindeutig modelliert werden.
  • !Gültigkeitszeiträume, Versionierung und Regelstatus sind fachlich und technisch zu entscheiden.
  • !Rule Ownership, Pflegeverantwortung und Source of Truth sind offen.
  • !Validierungsquelle und Validierungsort je Rechnungsadresse sind nicht abschliessend entschieden.
API- und Kompatibilitätsfolgen
  • ✕Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.
  • !Versionierungs-, Übergangs- und Migrationsstrategie für bestehende Integrationen sind offen.
  • !Das Verhalten bestehender Adressen ohne Regelkontext muss definiert werden.
Fehlercodes und Default-Verhalten
  • !Fehlercodes und fachliche Fehlermeldungen für ungültige oder widersprüchliche Regelkombinationen fehlen.
  • !Default-Regeln und Ausnahmefälle je Rechnungsadresse sind offen.
  • !Migration bestehender Rechnungsadressen auf Regelkontext oder Standardregeln ist nicht entschieden.
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.
SA
Solution Architect
Systemgrenzen · Ownership · Integration
▼
Output: JSONRisk: MEDIUMGovernance: Kein Veto, nicht kritisch
Raw OutputNormalization Marker vorhandenCurated Architecture Synthesis
Governance-Wirkung: Formal stabil (architecture_decision PASS_WITH_WARNINGS, PARTIALLY_STABLE). Post-Run-Vergleichsbefund: Der sichtbare kanonische Rollenoutput entspricht in Feldsatz und Inhalt dem Basislauf 1ee4, obwohl der Change Request zwei Erweiterungsstufen weiter ist. Der Run-Report enthält dafür keinen separaten Rollenhash; der Befund bleibt deshalb eine dokumentierte Vergleichsaussage und keine allein aus 44d5 beweisbare Run-Evidence. Weder die Regelkontexte noch die verbindliche Rückwärtskompatibilität schlagen sich im Rollenoutput nieder.
▼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
  • ?Konsolidierte Architekturfrage: Wo werden Länder-, Steuer- und Validierungsregeln fachlich verantwortet, versioniert und systemisch bereitgestellt?Quelle: Developer-Beitrag und Report-Synthese; nicht aus dem Raw-Solution-Architect-Output abgeleitet.
  • ?Konsolidierte Architekturfrage: Welche bestehenden APIs sind betroffen und mit welcher Versionierungs-, Migrations- und Übergangsstrategie bleibt die geforderte Rückwärtskompatibilität gewährleistet?Quelle: Developer-Beitrag (api_notes, backwards_compatibility_notes, migration_notes) und Report-Synthese; nicht aus dem Raw-Solution-Architect-Output abgeleitet.
Systemgrenzen, Datenverantwortung, Integrationen und Rückwärtskompatibilität vor Umsetzung absichern.
QA
Tester
Akzeptanzkriterien · Testfälle · Regression
▼
Output: JSONQA: BLOCKEDGovernance: Veto
Raw Output: fachlich leerNormalized: BLOCKEDCurated QA Synthesis
Governance-Wirkung: Vetorolle dieses Runs mit kanonischer qa_decision BLOCKED. Der Output Contract blockiert vollständig (no_usable_tester_content_after_enforcement): alle kanonischen Felder leer nachgefüllt, alle fachlichen Raw-Evidence-Felder leer, Raw-Statuswerte REQUIRES_FIXES und PARTIALLY_RELEASEABLE bleiben als Governance-Metadaten erhalten. Der Raw-Output-Hash ist identisch mit 1ee4 und 5e63; die im historischen Raw-Report sichtbaren Tester-Inhalte sind ohne transparente Provenienz. Mit diesem dritten Lauf ist der Befund seriell belegt und für die gemeinsame Bewertung entscheidungsreif.
▼Details anzeigen
Tester-Evidence: Der Tester liefert in diesem Run keine verwertbare fachliche QA-Evidence. Der Tester Output Contract blockiert deshalb fail-closed mit no_usable_tester_content_after_enforcement. Die nachfolgend dargestellten Test- und Regression-Hinweise sind kuratierte QA-Vorschläge aus anderen Rollen beziehungsweise aus der Reportlogik. Sie stammen nicht aus dem kanonischen oder dem Raw-Tester-Output. Der identische Raw-Output-Hash in 1ee4, 5e63 und 44d5 ist ein reproduzierbares Serienmuster über drei unterschiedliche Change Requests und bleibt kausal ungeklärt.
Kuratierte QA-Synthese · Akzeptanzkriterien
  • !Akzeptanzkriterien für Erfassen, Ändern, Löschen und Festlegen einer Standard-Rechnungsadresse müssen definiert werden.
Kuratierte QA-Synthese · Positive Testfall-Vorschläge
  • ›Eine neue Rechnungsadresse kann einem Kundenkonto hinzugefügt werden.
Kuratierte QA-Synthese · Negativ- und Fehlerfälle
  • ✕Ungültige, unvollständige oder doppelte Rechnungsadressen werden geprüft.
  • ✕Ungültige Länder-, Steuer- oder Validierungsregeln pro Rechnungsadresse werden abgelehnt.
Kuratierte QA-Synthese · 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.

05
Requirement Intelligence
RES-v1 Bewertung, IREB-Präzisierung und Qualitätsanforderungen

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. Pro Rechnungsadresse sollen eigene Länder-, Steuer- und Validierungsregeln unterstützt werden. Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.
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 soll einem Kunden ermöglichen, mehrere Rechnungsadressen zu speichern. Pro Rechnungsadresse sollen eigene Länder-, Steuer- und Validierungsregeln unterstützt werden. Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.
Diese Formulierung bildet den ausdrücklich genannten fachlichen Kern sowie die beiden expliziten Randbedingungen des Change Requests ab, die Regelkontexte je Rechnungsadresse und die verbindliche Rückwärtskompatibilität. Zusätzliche Lifecycle-Funktionen bleiben Hypothesen und müssen fachlich bestätigt werden.
Mögliche Lifecycle-Erweiterungen · fachlich noch zu bestätigen
  • Rechnungsadresse ändern
  • Rechnungsadresse deaktivieren oder löschen
  • Standard-Rechnungsadresse festlegen
  • Rechnungsadresse einem Verwendungskontext zuordnen
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.
  • Der Original-Change-Request nennt zwei explizite Randbedingungen: pro Rechnungsadresse müssen eigene Länder-, Steuer- und Validierungsregeln berücksichtigt werden, und bestehende Rechnungsprozesse sowie API-Schnittstellen müssen rückwärtskompatibel bleiben.
  • Die Rückwärtskompatibilität ist eine verbindliche Anforderung. Ihre technische Erfüllung ist in diesem Lauf nicht nachgewiesen.
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.

Performanz
MVP 2.0
Zuverlässigkeit
MVP 2.0
Benutzbarkeit
MVP 2.0
Sicherheit
MVP 2.0
Wartbarkeit
MVP 2.0
Übertragbarkeit
MVP 2.0
Offene Klärungen
Dedupliziert und normalisiert · Agent-Rohfragen im Detailbereich
  • Offene technische Option: Ob und wie Schnittstellen für Rechnungsadressen und Regelkontext angepasst werden, ist technisch zu klären.
  • Welche Länderregeln und welche Steuerregeln gelten je Rechnungsadresse?
  • Welche Validierungsregeln und Validierungsstrategien für die Rechnungsadressen müssen definiert werden?
  • Welche Validierungsregeln, Default-Regeln und Ausnahmefälle gelten je Rechnungsadresse?
Agent-Rohfragen anzeigen▼

Originale Agent-Rohfragen aus dem Run, unbereinigt. Sie überschneiden sich teilweise mit den normalisierten Klärungen oben.

  • Offene technische Option: Ob und wie Schnittstellen für Rechnungsadressen und Regelkontext angepasst werden, ist technisch zu klären.Agent-Rohfrage
  • Welche Länderregeln gelten je Rechnungsadresse?Agent-Rohfrage
  • Welche Steuerregeln gelten je Rechnungsadresse?Agent-Rohfrage
  • Welche Validierungsregeln und -strategien für die Rechnungsadressen müssen definiert werden?Agent-Rohfrage
  • Welche Validierungsregeln, Default-Regeln und Ausnahmefälle gelten je Rechnungsadresse?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.

06
Governance Intelligence
Das Governance Gate: Status, Severity, Vetorollen und Release Readiness
Governance Gate
Das Gate vor der Umsetzung · IREB Core Group
BLOCKED_BY_VETO Governance Status
HIGH Governance Severity
HIGH Höchste Eskalation
17 / 42 Kritisches Gewicht
0.4 Kritischer Anteil
CRITICAL Governance Stability
30
Release Readiness
BLOCKED_BY_VETO
RELEASE READINESS
30 / 100
Severity: HIGH Eskalation: HIGH Kritisches Gewicht: 17 / 42 Kritischer Anteil: 0.4 Stability: CRITICAL Vetorollen: 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] Testing Release Block. Keine weitere zusätzliche Governance-Regel über diesen Block hinaus aktiviert.
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 30 / 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 30 / 100 bedeutet in dieser Darstellung, dass der Change Request aus Governance-Sicht aktuell deutlich nicht umsetzungsreif ist.
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 ist die folgende Vetorolle ausgewiesen: Tester. Dadurch wird der Change Request nicht nur als riskant bewertet, sondern aktiv für die Umsetzung gesperrt.
Kritisches Gewicht 17 / 42Das kritische Gewicht fasst die gewichteten kritischen oder blockierenden Beiträge des Runs zusammen. 17 von 42 bedeutet, dass ein wesentlicher Anteil der bewerteten Governance-Last als kritisch gewichtet ist.
Kritischer Anteil 0.40.4 entspricht 17 / 42. Damit liegen rund 40 Prozent der gewichteten Bewertung im kritischen Bereich.
Governance Severity HIGHDie Governance-Schwere wird als hoch bewertet.
Höchste Eskalation HIGHDer höchste konsolidierte Eskalationswert liegt auf hoher 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 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.

07
Pattern Intelligence
Wiederkehrende Lösungs- und Strukturmuster

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 mit klarer Daten-Ownership für Rechnungsadressen und die je Adresse zugeordneten Länder-, Steuer- und Validierungsregeln. Adressiert offene Fragen zu Berechtigungen, Regelpflege, Verantwortlichkeiten und Standard-Rechnungsadresse.
Enterprise Pattern · Empfehlung
Audit Trail Pattern
Falls Änderungen, Regelversionierung oder Auditpflicht fachlich bestätigt werden, kann ein Audit Trail die Nachvollziehbarkeit von Rechnungsadressen und Regelkontexten unterstützen. Eine konkrete Auditpflicht ist im Change Request nicht festgelegt.
Empfohlene Komposition RBAC and Ownership Pattern + Audit Trail Pattern
Quelle: Kuratierte Synthese aus Run-Report und Rollenbeiträgen. Die Auslegung der Patterns ist nicht vollständig Bestandteil des Raw-Outputs.
Pattern-Empfehlungen sind keine Umsetzungsfreigabe. Sie machen Lösungsrichtungen strukturiert sichtbar; die Entscheidung 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.

08
Story Intelligence
Vom Requirement zum agilen Story-Kandidaten

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
Mehrere Rechnungsadressen mit adressbezogenen Regeln
Business Outcome Das System soll Kunden ermöglichen, mehrere Rechnungsadressen zu speichern und pro Rechnungsadresse die ausdrücklich genannten Länder-, Steuer- und Validierungsregeln zu unterstützen, ohne bestehende Rechnungsprozesse oder API-Schnittstellen inkompatibel zu verändern. 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: Mehrere Rechnungsadressen mit adressbezogenen Regeln
BLOCKED_BY_VETO
AlsKunde
möchte ichmehrere Rechnungsadressen speichern können
damitpro Rechnungsadresse die im Change Request genannten Länder-, Steuer- und Validierungsregeln unterstützt werden können.
Fachlich abgeleitet Nicht delivery-ready BLOCKED_BY_VETO Kein Jira-ready Artefakt
Als Kunde möchte ich mehrere Rechnungsadressen speichern können, damit pro Rechnungsadresse die im Change Request genannten Länder-, Steuer- und Validierungsregeln unterstützt werden können.

Status: abgeleiteter Story-Kandidat. Die Nutzenannahme ist noch nicht durch Nutzer- oder Business-Evidence bestätigt; die Story ist weder delivery-ready noch freigegeben.

Verbindliche Kompatibilitätsbedingung
Die Erweiterung darf bestehende Rechnungsprozesse und bestehende API-Schnittstellen nicht inkompatibel verändern. Diese Bedingung stammt direkt aus dem Original-Change-Request und ist keine kuratierte Hypothese.
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.
Lifecycle-HypotheseEine bestehende Rechnungsadresse kann geändert werden.
Lifecycle-HypotheseEine bestehende Rechnungsadresse kann gelöscht oder deaktiviert werden, sofern fachlich erlaubt.
Lifecycle-HypotheseEine Rechnungsadresse kann als Standard-Rechnungsadresse festgelegt werden, sofern diese Regel fachlich vorgesehen ist.
AC VorschlagFür jede Rechnungsadresse werden die im Original genannten Länder-, Steuer- und Validierungsregeln geprüft.
AC VorschlagUngültige Kombinationen aus Land, Steuerregel und Validierungsregel werden abgelehnt.
AC VorschlagBestehende Rechnungsprozesse bleiben nach der Erweiterung kompatibel.
AC VorschlagBestehende API-Schnittstellen werden nicht inkompatibel verändert.
PrüfhinweisDie Rückwärtskompatibilität ist in diesem Change Request verbindlich gefordert. Ihre technische Erfüllung ist im Lauf nicht nachgewiesen und vor Delivery zu klären.
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 offenLänder-, Steuer- und Validierungsregeln je Rechnungsadresse müssen fachlich eindeutig definiert werden.
BR offenRegel zur Verwendung einer Rechnungsadresse in bestehenden Rechnungsprozessen ist nicht spezifiziert.
Diese offenen Business Rules verhindern Delivery-Readiness.
Readiness Checks
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.
Kuratierte QA-Synthese · Test- und Regression-Hinweise
Quelle: Business Analyst, Developer und Report-Konsolidierung. Nicht aus dem Raw- oder kanonischen Tester-Output abgeleitet. Nicht ausgeführt und nicht fachlich bestätigt.
Vorschläge · Positive Testfälle
  • ›Neue Rechnungsadresse kann hinzugefügt werden.
  • ›Bestehende Rechnungsadresse kann geändert werden, sofern diese Lifecycle-Hypothese fachlich bestätigt wird.
! 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.
Diese Vorschläge sind aus anderen Rollen und der Story-Ableitung hergeleitet. Sie ersetzen keine Tester-Evidence und müssen vor Delivery fachlich bestätigt, konkretisiert und ausgeführt 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.

09
Solution Intelligence
Lösungsskizze, Optionen und offene Lösungsentscheidungen

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 und deren Regelkontexte abbilden und die verbindliche Randbedingung der Rückwärtskompatibilität bestehender Rechnungsprozesse und API-Schnittstellen erfüllen. Ob diese Erfüllung erreicht wird, ist im Lauf nicht nachgewiesen.
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, die fachlichen Inhalte und die Pflege der Länder-, Steuer- und Validierungsregeln je Rechnungsadresse sowie die Verwendung in bestehenden Rechnungsprozessen müssen vor Umsetzung entschieden werden.
Developer Technical Options · nicht entschieden
  • ›Getrennte Routen für Rechnungsadressen und Regelkontext.
  • ›PATCH-Methoden für Teiländerungen.
  • ›Definiertes Default-Verhalten für Bestandsadressen ohne Regelkontext.
Status: Technische Optionen aus dem Developer-Beitrag. Nicht entschieden, nicht spezifiziert und nicht freigegeben.
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.

  • !API-Auswirkung berücksichtigen: Schnittstellen müssen Regelkontext je Rechnungsadresse anzeigen oder ändern können, falls fachlich vorgesehen. Agent-Rohbeitrag
  • !Empfohlene Pattern-Komposition: RBAC and Ownership Pattern + Audit Trail Pattern. Agent-Rohbeitrag
  • !Architektur-Blueprint, Security Layer: Berechtigungen und Ownership zentral erzwingen. Agent-Rohbeitrag
  • !Architektur-Blueprint, Governance Layer: Governance-, Security- und Compliance-Regeln zentral bündeln. Agent-Rohbeitrag
  • !Architektur-Blueprint, Audit Layer: Alle relevanten Entscheidungen revisionssicher protokollieren. 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.

10
Architecture Blueprint Intelligence
Fachlich-technische Zielstruktur und Verantwortungsbereiche

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 LayerZu prüfen ist, ob ein explizites Berechtigungs- und Ownership-Modell für Rechnungsadressen und Regelpflege erforderlich ist.
Governance LayerGovernance-, Security- und Compliance-Regeln werden zentral bewertet und dürfen nicht in Einzelentscheidungen verschwinden.
Audit LayerFalls Änderungen, Löschungen oder Regelversionierung fachlich bestätigt werden, ist Auditierbarkeit beziehungsweise Historisierung zu bewerten.
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 und Validierungslogik müssen konkretisiert werden; Historisierung ist nur bei bestätigter Lifecycle- oder Auditpflicht zu bewerten. Aktuell ist noch keine echte Datenbank-Introspektion angebunden.
Integration BoundaryAuswirkungen auf bestehende Rechnungsprozesse, Umsysteme und Rückwärtskompatibilität müssen geprüft werden.
Quelle: Kuratierte Architektur-Synthese. API-, Data-/Storage- und Integration-Layer erweitern die knappe Raw-Architektur um eine transparente Review-Sicht.
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.

11
Decision Intelligence
Konsolidierter Entscheid, Begründung, Risiken und nächste Schritte

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.
BLOCKED_BY_VETO
Status
30 / 100
Release Readiness
HIGH
Governance Severity
HIGH
Höchste Eskalation
Tester
Vetorolle
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
Regelmodell und fachliche Regelinhalte
Die fachlichen Inhalte der Länder-, Steuer- und Validierungsregeln je Rechnungsadresse fehlen; Validierungsstrategien, Default-Regeln und Ausnahmefälle sind offen. Konkrete Regeln dürfen nicht erfunden werden.
Risikocluster 2
Fachliche Produktentscheidungen
Standard-Rechnungsadresse, Mindest- und Maximalanzahl sowie Regelpflege sind offene Produktentscheidungen und dürfen nicht als finale Business Rules behandelt werden. Ohne definierte Regel- und Akzeptanzkriterien bleibt die Anforderung nur teilweise entscheidungsreif.
Risikocluster 3
Technische Umsetzbarkeit und Schnittstellen
Fehlercodes für ungültige, doppelte oder fehlende Rechnungsadressen sind nicht definiert (High API), Fragen zur Rückwärtskompatibilität bei Änderungen der Adressvalidierung sind offen (High Architecture), und ob und wie Schnittstellen für Rechnungsadressen und Regelkontext angepasst werden, ist eine offene technische Option.
Risikocluster 4
Test- und Releasefähigkeit
Akzeptanzkriterien und Testvoraussetzungen sind nicht bestätigt. In diesem Lauf kommt hinzu, dass der kanonische Tester-Kanon leer ist und die im konsolidierten Report sichtbaren Testinhalte ohne transparente Provenienz sind; die Testevidence dieses Laufs stammt nicht aus dem Tester-Output. Das Tester-Veto blockiert die Umsetzung.
Risikocluster 5
Governance-Metadaten als Raw Evidence
release_status PARTIALLY_RELEASEABLE und risk_level MEDIUM aus dem Tester-Rohoutput bleiben ausserhalb des kanonischen Contracts (Governance Bridge) und dürfen nicht als Delivery-Freigabe gelesen werden; die kanonische Verschärfung auf BLOCKED ist als Contract-Telemetry-Ambiguität dokumentiert und vor einer Defektklassifikation semantisch zu prüfen.
Konflikte zwischen Rollen
DeveloperKritische technische Rollenentscheidung: Der Developer stuft den Change Request als NOT_APPROVABLE und NOT_IMPLEMENTABLE ein. Er ist keine formale Vetorolle.
TesterTester blockiert, weil keine verwertbare kanonische QA-Evidence vorliegt. Eine konkrete testfachliche Begründung ist im Tester-Output dieses Runs nicht enthalten.
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.

High · Kompatibilität und API
Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben, was Zeit für Implementierung und Test verlängern kann.Agent-Rohbeitrag · Product Owner
Keine spezifischen Fehlerbehandlungen für ungültige, doppelte oder fehlende Rechnungsadressen definiert.Agent-Rohbeitrag
Migration bestehender Rechnungsadressen auf Regelkontext oder Standardregeln ist offen.Agent-Rohbeitrag
High · Regelmodell
Fachliche Inhalte der Länder-, Steuer- und Validierungsregeln je Rechnungsadresse sind nicht vollständig definiert.Agent-Rohbeitrag
Gültigkeit, Versionierung, Ownership und Validierungsquelle der Regeln müssen fachlich entschieden werden.Agent-Rohbeitrag
Default-Verhalten bei fehlendem Regelkontext je Rechnungsadresse ist offen.Agent-Rohbeitrag
Medium · Testing und Fehlerfälle
Fehlerbehandlung für widersprüchliche Länder-, Steuer- und Validierungsregeln je Rechnungsadresse ist offen.Agent-Rohbeitrag
Fehlercodes oder fachliche Fehlermeldungen für Regelverletzungen sind als offene Anforderung zu klären.Agent-Rohbeitrag
Konkrete Länder-, Steuer- und Validierungsregeln dürfen nicht erfunden werden und bleiben offene Anforderungen.Agent-Rohbeitrag
Medium · Fachliche Entscheidungsreife
Ohne definierte Regel- und Akzeptanzkriterien ist die Anforderung fachlich nur teilweise entscheidungsreif.Agent-Rohbeitrag
Die maximal unterstützte Anzahl Rechnungsadressen sollte zur Scope-Begrenzung definiert werden.Agent-Rohbeitrag · Product Owner
Low · Governance-Metadaten
Tester governance metadata is preserved as raw evidence outside the canonical Tester contract: release_status, Governance-Risikostufe.Agent-Rohbeitrag
Nächste Klärungsschritte
Was vor einer möglichen Umsetzung geklärt werden muss
  1. 01Fehlende Business Rules, Datenregeln und Akzeptanzkriterien definieren.
  2. 02Business Value, MVP-Relevanz, Scope und Priorisierung klären.
  3. 03Datenmodell, Validierungen, technische Auswirkungen und Umsetzungsoptionen konkretisieren.
  4. 04Systemgrenzen, Datenhoheit, Storage-Verantwortung und Integrationsfolgen klären.
  5. 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.

12
Delivery Readiness Intelligence
Was vor Umsetzung noch fehlt
⚠
Keine Umsetzungsfreigabe
Der Change Request ist durch die formale Vetorolle Tester 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.

13
Evidence Intelligence
Kuratierte Hauptansicht und vollständige Nachvollziehbarkeit

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.

Freigegebene Vergleichsrolle: Run 44d5 ist die unveränderte Silo-1-RunPod-CR3-/Stage-2-Evidence VALID_MVP2_RUNPOD_STAGE2_EVIDENCE. Die Drei-Run-Serie trägt den Status MVP2_7B_THREE_RUN_BASELINE_SERIES_COMPLETE. Runtimevergleiche müssen den Warm-Model-Zustand von 44d5 ausdrücklich berücksichtigen.
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.
Original Run Evidence · Artefakt-Manifest

Die zehn Artefakte des Run-Pakets mit Dateigrösse und SHA-256-Pruefsumme. Sie belegen, auf welchen unveränderten Rohdaten dieser Report beruht. Der Execution Context ist nicht Teil dieses Pakets und stammt aus dem separaten Live-Audit.

Artefakt Pfad Grösse SHA-256 Quelle Zeitpunkt
agent_results.jsonruns/run_2026-07-20_16-13-28_44d5/agent_results.json14'696 B26b8e3e8c4d43e618721948e3f9b1132890068b805d4a51dfea45f5104253b1cOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
context_purity.jsonruns/run_2026-07-20_16-13-28_44d5/context_purity.json397 B9aa9bf4b7f08a8e10735329b44e4fb9a8b12877df004d0225d41053fb5bea96aOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
delivery_relevance.jsonruns/run_2026-07-20_16-13-28_44d5/delivery_relevance.json2'480 B218a7065b52878142e3581c777b6cb009c546ea5d0b5b5f748b32684460fa33aOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
full_evidence_report.mdruns/run_2026-07-20_16-13-28_44d5/full_evidence_report.md57'944 B7af4aac342a6ab5261da0599a2afadc912992e8d24257b188af6b4ad9bf154edOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
metadata.jsonruns/run_2026-07-20_16-13-28_44d5/metadata.json2'968 Bb1a18b72e43c2ffbb40fc1458454619babb74c71e8fccc4a03b304aeb001df08Original Run Evidence20. Juli 2026 · Run-Erzeugung
purity_score.jsonruns/run_2026-07-20_16-13-28_44d5/purity_score.json45 B9b2a37ab2dcb4a88df8cf0318a0dde16f9b24ba29e54dd3e92fe97a71be5fc61Original Run Evidence20. Juli 2026 · Run-Erzeugung
report.mdruns/run_2026-07-20_16-13-28_44d5/report.md31'807 B977533509cf092a27ab82ee20facfcdea335b05c8b27b86313da6a58229e070dOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
run_score.jsonruns/run_2026-07-20_16-13-28_44d5/run_score.json78 B9e2f5bd54e42f3d2553ff8e0e1165fe25c6e9f776f255374f912890b571bad2aOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
run_summary.jsonruns/run_2026-07-20_16-13-28_44d5/run_summary.json2'488 B4d6b6170a8b9d4068c91fd89eaf2be0e5921a14d8579307d78c46c6b1300026fOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
runtime_timing.jsonruns/run_2026-07-20_16-13-28_44d5/runtime_timing.json989 B6c3450833bcfd82329f114b410c912076049bdd523525d0ba8e98a1b20620f8aOriginal Run Evidence20. Juli 2026 · Run-Erzeugung
Separate Provenienzartefakte: Für Execution Context und Post-Run Audit wurde kein eigenständiges, gehashtes Sidecar-Artefakt mitgeliefert. Diese Angaben bleiben deshalb sichtbar getrennt, aber als aktuelle Evidence-Lücke markiert.
MVP-1.1-Hardening und Wirkung in 44d5
  1. Tester Output Contract v1: blockiert den inhaltsleeren Tester fail-closed; Raw Output bleibt erhalten.
  2. Alias Mapping: erkennt fünf Tester-Feldzuordnungen, kann wegen leerer Quellfelder aber keine QA-Evidence übertragen.
  3. Controlled Variant Normalizer: aktiv, in 44d5 ohne sichtbare inhaltliche Wirkung.
  4. PO Governance Mapping: übernimmt PARTIALLY_APPROVABLE und MEDIUM trotz abweichendem Feldsatz.
  5. Tester Governance Bridge: bewahrt Raw-Metadaten, ohne daraus eine Delivery-Freigabe abzuleiten.
  6. Report Semantics Deduplication: verhindert Duplikate, deckt aber lauftreue Tester-Semantik und Provenienz noch nicht vollständig ab.
  7. No-Model Regression Tests: bilden die Basis für die spätere Report- und Provenienz-Härtung.
  8. Knowledge SMART_ROUTING: in 44d5 aktiv; Context Purity bleibt OK.

Quelle: Post-Run Audit. Die acht historischen MVP-1.1-Anpassungen bleiben unverändert; diese Darstellung bewertet nur ihre sichtbare Wirkung in 44d5.

Diese HTML-Version ist die kuratierte Reportansicht dieses Laufs. Die vollständige Evidence bleibt in den Run-Artefakten erhalten und ist die massgebliche Referenz: full_evidence_report.md, agent_results.json, metadata.json, runtime_timing.json, run_summary.json, purity_score.json, context_purity.json, run_score.json und delivery_relevance.json. Die zusätzlichen Evidence-Akkordeons im HTML sind konzeptuell vorgesehen.
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 ▼
Unveränderte historische Evidence
Dieser Bereich zeigt den ursprünglichen konsolidierten Raw-Report unverändert. Er enthält bekannte bestätigte Reportfehler, darunter „Keine zentralen Blocker erkannt“ trotz BLOCKED_BY_VETO, statische REQUIRES_FIXES-Semantik trotz kanonischem BLOCKED sowie Tester-Inhalte ohne belegte Tester-Provenienz. Diese Aussagen bleiben als historische Evidence erhalten und gelten nicht als korrigierte Interpretation des Runs. 
Run: runs/run_2026-07-20_16-13-28_44d5

# DECISION-LAB / AGENT SWARM INTELLIGENCE

## Entscheidungsreport

## Gruppe
TEST - IREB Core Group

## Change Request
Ein Kunde soll mehrere Rechnungsadressen speichern können. Pro Rechnungsadresse sollen eigene Länder-, Steuer- und Validierungsregeln unterstützt werden. Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.

## Knowledge-Kontext
aktiviert (j, SMART_ROUTING)

## Report
######################################################################
KONSOLIDIERTER ENTSCHEIDUNGSREPORT
######################################################################


## Requirement Evolution
- Hinweis: Requirement Recommendation nach RES-v1, IREB-Satzschablonen-orientiert.
- Status: CLARIFICATION_REQUIRED
- Requirement Type: FUNCTIONAL

### Original
- Ein Kunde soll mehrere Rechnungsadressen speichern können. Pro Rechnungsadresse sollen eigene Länder-, Steuer- und Validierungsregeln unterstützt werden. Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.

### RES-v1 Bewertung
- Hinweis: Die vollständige IREB-Anforderungskomposition wird im Abschnitt „IREB-Satzschablonen-Präzisierung und Rollenbeiträge“ ausgewiesen.
- Die konservative RES-v1-Bewertung erzeugt keinen separaten alternativen Requirement-Vorschlag.
- Begründung: RES-v1 verändert das Original nicht frei, wenn keine sicher ableitbare zusätzliche Business Rule vorliegt. Die vollständige IREB-Anforderungskomposition wird im Abschnitt „IREB-Satzschablonen-Präzisierung und Rollenbeiträge“ ausgewiesen.
- Status: NO_MEANINGFUL_IMPROVEMENT

### Offene Klärungen
- Offene Anforderung: Validierungsort und Validierungsquelle je Rechnungsadresse sind fachlich und technisch zu klären; serverseitige oder interne Prüfung ist nicht final entschieden.
- Welche Länderregeln gelten je Rechnungsadresse?
- Welche Steuerregeln gelten je Rechnungsadresse?
- Welche Validierungsregeln, Default-Regeln und Ausnahmefälle gelten je Rechnungsadresse?
- Wie sollen bestehende Rechnungsprozesse mit neuen Funktionen interagieren?


## Verbesserter Requirement-Vorschlag

Status: Nicht ableitbar.

Ein verbesserter Requirement-Vorschlag kann nicht stabil abgeleitet werden, weil keine stabile IREB-Kernanforderung im Report vorhanden ist.

### Ergänzende Business Rules für Delivery-Readiness

- Keine ergänzenden Business Rules aus dem aktuellen Report ableitbar.

### Akzeptanzkriterien-Vorschlag

- Keine finalen Akzeptanzkriterien aus dem aktuellen Report ableitbar.

### Abgrenzung

- Keine Business Rules wurden erfunden oder finalisiert.
- Keine freigegebene Delivery-/Jira-Story.
- Finale Akzeptanzkriterien, Definition of Done und technische Tasks bleiben Aufgabe der Delivery Pipeline.


## IREB-Satzschablonen-Präzisierung und Rollenbeiträge

Dieser Abschnitt ist getrennt von der konservativen RES-v1 Requirement Recommendation.
RES-v1 darf NO_MEANINGFUL_IMPROVEMENT liefern. Die IREB-Satzschablonen-Sicht präzisiert den fachlichen Kern und macht explizite Randbedingungen aus dem Original sichtbar, ohne neue Business Rules zu erfinden.

### Original

- Ein Kunde soll mehrere Rechnungsadressen speichern können. Pro Rechnungsadresse sollen eigene Länder-, Steuer- und Validierungsregeln unterstützt werden. Bestehende Rechnungsprozesse und API-Schnittstellen müssen rückwärtskompatibel bleiben.

### Vollständige IREB-Anforderungskomposition

**Kernanforderung**

- Das System muss dem Kunden die Möglichkeit bieten, mehrere Rechnungsadressen seinem Kundenkonto zuzuordnen, zu speichern, zu ändern und zu verwalten.

**Fachliche Randbedingungen**

- Das System muss pro Rechnungsadresse eigene Länder-, Steuer- und Validierungsregeln berücksichtigen.

**Kompatibilitätsanforderungen**

- Das System muss bestehende APIs und bestehende Rechnungsprozesse rückwärtskompatibel halten.

**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.

### Rollenbeiträge

### Business Analyst

**Fachliche Lücken und Klärungsbedarf**

**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.
- Länder-, Steuer- und Validierungsregeln je Rechnungsadresse müssen fachlich eindeutig definiert werden.
- Rückwärtskompatibilität bestehender APIs muss als verbindliche Randbedingung geklärt werden.
- Rückwärtskompatibilität bestehender Rechnungsprozesse muss als verbindliche Randbedingung geklärt werden.

**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.
- Für jede Rechnungsadresse werden Länder-, Steuer- und Validierungsregeln geprüft.
- Ungültige Kombinationen aus Land, Steuerregel und Validierungsregel werden abgelehnt.
- Die Erweiterung darf bestehende APIs nicht inkompatibel verändern.
- Die Erweiterung darf bestehende Rechnungsprozesse nicht inkompatibel verändern.

**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?
- Welche Länder-, Steuer- und Validierungsregeln gelten pro Rechnungsadresse?
- Welche Regeln gelten bei widersprüchlichen Länder-, Steuer- oder Validierungsangaben?
- Welche bestehenden APIs sind von mehreren Rechnungsadressen betroffen?
- Welche bestehenden Rechnungsprozesse dürfen durch die Erweiterung nicht verändert werden?

**Empfehlung**

- Fachliche Business Rules, Akzeptanzkriterien und offene Fragen müssen vor Umsetzung geklärt werden.

### Product Owner

**Business Value / MVP / Scope Sicht**

- Mehrere Rechnungsadressen können den fachlichen Nutzen für Kunden mit unterschiedlichen Rechnungskontexten erhöhen.

**MVP-Fit / Scope**

- MVP-Fit und Scope-Abgrenzung müssen fachlich bestätigt werden.

**Scope- oder Delivery-Risiken**

- Länder-, Steuer- und Validierungsregeln erhöhen den fachlichen Scope und müssen priorisiert werden.
- Kompatibilität bestehender APIs oder Rechnungsprozesse kann Auswirkungen auf MVP-Scope und Releaseplanung haben.

**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?

**Empfehlung**

- Business Value, MVP-Scope und Priorisierung vor Umsetzung klären.

### Developer

**Daten-, Validierungs- und Fehlerfallsicht**

- 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.
- Länder-, Steuer- und Validierungsregeln müssen je Rechnungsadresse eindeutig modelliert und geprüft werden.

**Fehlerfälle**

- 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**

- Bestehende APIs müssen auf Rückwärtskompatibilität geprüft werden.
- 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?
- Welche Länder-, Steuer- und Validierungsregeln gelten pro Rechnungsadresse?

**Empfehlung**

- Datenmodell, Validierungslogik, Fehlerfälle und Auswirkungen auf bestehende Rechnungsprozesse müssen vor Umsetzung fachlich geklärt werden.

### Software - Solution Architect

**Systemgrenzen, Ownership und Rückwärtskompatibilität**

- Systemgrenzen für Verwaltung und Verwendung mehrerer Rechnungsadressen müssen geklärt werden.
- Verantwortung für Länder-, Steuer- und Validierungsregeln muss fachlich und systemisch abgegrenzt werden.

**Ownership / Datenflüsse**

- Datenverantwortung für Rechnungsadressen und deren fachliche Regeln muss geklärt werden.

**Rückwärtskompatibilität / Integration**

- Bestehende APIs müssen rückwärtskompatibel bleiben.
- Bestehende Rechnungsprozesse dürfen nicht inkompatibel verändert werden.

**Offene Architekturfragen**

- Wo werden Länder-, Steuer- und Validierungsregeln fachlich verantwortet?
- Welche bestehenden APIs sind betroffen und welche Kompatibilitätsgarantien gelten?
- Welche bestehenden Rechnungsprozesse sind betroffen?

**Empfehlung**

- Systemgrenzen, Datenverantwortung, Integrationen und Rückwärtskompatibilität vor Umsetzung absichern.

### Tester

**Testbarkeit, Akzeptanzkriterien und Regression**

- Akzeptanzkriterien für Erfassen, Ändern, Löschen und Festlegen einer Standard-Rechnungsadresse müssen definiert werden.
- Länder-, Steuer- und Validierungsregeln werden je Rechnungsadresse geprüft.
- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.
- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft 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.
- Ungültige Länder-, Steuer- oder Validierungsregeln pro Rechnungsadresse werden abgelehnt.

**Regression**

- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.
- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.
- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.

**Offene QA-Fragen**

- Welche Testdaten werden für Länder-, Steuer- und Validierungsregeln benötigt?

**Empfehlung**

- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.
######################################################################
DELIVERY-ARTEFAKTE
######################################################################


## User Story Paket

Hinweis: Der aktuelle Core-Report leitet aus dem aktuellen Change Request genau eine fachliche User Story ab. Spätere Entwicklungsstufen können mehrere User Stories aus längeren Inputs ableiten.

### Epic-Vorschlag

Mehrere Rechnungsadressen mit regelbasierter Rechnungsverarbeitung

Das System soll Kunden ermöglichen, mehrere Rechnungsadressen im Kundenkonto zu verwalten und pro Rechnungsadresse relevante Länder-, Steuer- und Validierungsregeln zu berücksichtigen.

Status: Fachlich abgeleitet, aber nicht delivery-ready.

### User Story 1

Status: Fachlich abgeleitet, aber nicht delivery-ready.

Governance: BLOCKED_BY_VETO

Release Readiness Score: siehe Abschnitt Entscheidungsstatus

Diese User Story wurde aus dem Requirement und der IREB-Präzisierung abgeleitet. Sie beschreibt Nutzerziel und fachlichen Nutzen, ist aber noch nicht zur Umsetzung freigegeben.

Hinweis: Echte Delivery-Artefakte, Jira-ready User Stories und Technical Tasks entstehen weiterhin über die Delivery Pipeline.

#### Story

Als Kunde möchte ich mehrere Rechnungsadressen in meinem Kundenkonto verwalten können, damit Rechnungen je nach Land, Steuerregel und Rechnungskontext korrekt verarbeitet werden können.

#### Explizite Randbedingungen

- Pro Rechnungsadresse müssen die im Original genannten Länder-, Steuer- und Validierungsregeln berücksichtigt werden.

#### 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.
- Für jede Rechnungsadresse werden die im Original genannten Länder-, Steuer- und Validierungsregeln geprüft.
- Ungültige Kombinationen aus Land, Steuerregel und Validierungsregel werden abgelehnt.

#### Offene Business Rules vor Delivery-Readiness

- 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.
- Pflichtfelder und Validierungsregeln je Rechnungsadresse müssen geklärt werden.
- Regel zur Verwendung einer Rechnungsadresse in bestehenden Rechnungsprozessen ist nicht spezifiziert.
- Länder-, Steuer- und Validierungsregeln je Rechnungsadresse müssen fachlich eindeutig definiert werden.

#### Definition of Ready Entwurf

- 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 Entwurf

- 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:
- Eine neue Rechnungsadresse kann einem Kundenkonto hinzugefügt werden.
- Eine bestehende Rechnungsadresse kann geändert werden.

Negative Testfälle und Fehlerfälle:
- Ungültige, unvollständige oder doppelte Rechnungsadressen werden geprüft.
- Ungültige Länder-, Steuer- oder Validierungsregeln pro Rechnungsadresse werden abgelehnt.

Regression:
- Regression bestehender APIs und bestehender Rechnungsprozesse muss geprüft werden.

## Delivery-Readiness und Umsetzungsfreigabe

### Umsetzungsfreigabe
- Keine freigegebene Delivery-/Jira-Story.
- In diesem Core-Gruppenlauf wurden keine echten Delivery-Artefakte erzeugt.
- Finale Akzeptanzkriterien, Definition of Done und technische Tasks entstehen weiterhin über die Delivery Pipeline.
- Die aktuelle Auswertung fokussiert auf fachliche Ableitung, Governance, Risiken und Klärungsbedarf.

### Finale Akzeptanzkriterien
- Status: Finale Delivery-Akzeptanzkriterien werden in diesem Core-Gruppenlauf nicht erzeugt.
- Der Akzeptanzkriterien-Vorschlag ist im Abschnitt User Story Paket ausgewiesen.
- Finale Kriterien entstehen über die Delivery Pipeline.

### Finale Definition of Done
- Status: Eine finale Definition of Done wird in diesem Core-Gruppenlauf nicht erzeugt.
- Ein Definition-of-Done-Entwurf ist im Abschnitt User Story Paket ausgewiesen.
- Die finale Definition of Done entsteht über die Delivery Pipeline.

### Technische Tasks
- Status: In diesem Core-Gruppenlauf nicht erzeugt.
- Grund: Technische Tasks entstehen sinnvoll über die Delivery Pipeline.
- Hinweis: Der Core-Report liefert fachliche Ableitung, Risiken, Vorschläge und Entwürfe. Konkrete Tasks bleiben Delivery-Artefakte.

## 1. Kurzfazit
- Gruppe: TEST - IREB Core Group
- Beteiligte Rollen: Business Analyst, Product Owner, Developer, Software - Solution Architect, Tester
- Kritische Rollen: Developer, Tester
- Vetorollen: Tester
- Governance Severity: HIGH
- Governance Status: BLOCKED_BY_VETO
- Höchste Eskalation: HIGH
- Der Change Request ist durch mindestens eine Vetorolle blockiert.

## 2. Entscheidungsstatus
- Der Change Request ist durch mindestens eine Vetorolle blockiert.
- Kritisches Gewicht: 17 von 42
- Kritischer Anteil: 0.4
- Release Readiness Score: 30 von 100
- Governance Stability: CRITICAL

## 3. Zentrale Blocker
- Keine zentralen Blocker erkannt.

## 4. Wichtigste Risiken
### MEDIUM – TESTING
- Fehlerbehandlung für widersprüchliche Länder-, Steuer- und Validierungsregeln je Rechnungsadresse ist offen.
- Konkrete Länder-, Steuer- und Validierungsregeln dürfen nicht erfunden werden und bleiben offene Anforderungen.
- Mehrere Validierungsregeln pro Rechnungsadresse fehlen (Länder-, Steuer- und Validierungsregeln)
- Tester governance metadata is preserved as raw evidence outside the canonical Tester contract: release_status, Governance-Risikostufe.

### MEDIUM – BUSINESS
- Ohne definierte Regel- und Akzeptanzkriterien ist die Anforderung fachlich nur teilweise entscheidungsreif.

### LOW – OTHER
- Keine spezifischen Fehlerbehandlungen für ungültige, doppelte oder fehlende Rechnungsadressen definiert
- Unklare Standard-Rechnungsadresse kann zu falscher Rechnungserstellung führen.

## 5. Offene Fragen
- Offene Anforderung: Validierungsort und Validierungsquelle je Rechnungsadresse sind fachlich und technisch zu klären; serverseitige oder interne Prüfung ist nicht final entschieden.
- Welche Länderregeln gelten je Rechnungsadresse?
- Welche Steuerregeln gelten je Rechnungsadresse?
- Welche Validierungsregeln, Default-Regeln und Ausnahmefälle gelten je Rechnungsadresse?
- Wie sollen bestehende Rechnungsprozesse mit neuen Funktionen interagieren?

## 6. Konflikte zwischen Rollen
- Developer blockiert wegen technischer Umsetzbarkeit.
- Tester blockiert wegen fehlender Testbarkeit oder fehlender Release-Kriterien.

- Erkannte Konfliktpaare:
- Developer ↔ Tester
- Tester ↔ Developer

## 7. Qualitäts- und Umsetzungsaspekte
- Fachliche Entscheidungsreife, Business Rules und Akzeptanzkriterien müssen geklärt werden.
- MVP-Scope, Business Value und Priorisierung müssen bewertet werden.
- Technische Umsetzbarkeit, Datenmodell und Validierungen müssen geklärt werden.
- Architektur-, Integrations-, Systemgrenzen- und Datenhoheitsrisiken müssen bewertet werden.
- Test- und Releasefähigkeit müssen durch Akzeptanzkriterien, Testdaten und Regressionstests abgesichert werden.

## 8. Governance Bewertung
- Aktivierte Governance-Regeln:
- [HIGH] Testing Release Block → Testing blockiert wegen fehlender Releasefähigkeit.

- Mindestens eine Vetorolle blockiert den Change Request.
- Governance Severity: HIGH
- Governance Status: BLOCKED_BY_VETO
- Höchste Eskalationsstufe: HIGH

## 9. Empfehlung
- Der Change Request darf in der aktuellen Form nicht umgesetzt werden.

## 10. Lösungsskizze
- API-Auswirkung berücksichtigen: Schnittstellen müssen Regelkontext je Rechnungsadresse anzeigen oder ändern können, falls fachlich vorgesehen.
- Empfohlenes Enterprise Pattern: RBAC and Ownership Pattern
- Empfohlenes Enterprise Pattern: Audit Trail Pattern
- Empfohlene Pattern-Komposition: 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.
Run: runs/run_2026-07-20_16-13-28_44d5 · Gruppe: TEST - IREB Core Group · LLM: qwen2.5:7b
→ Change Request darf in aktueller Form nicht umgesetzt werden
← Framework-Seite Zum Report-Anfang