Decision-Lab Run Gallery

Dieser Master-Run ist als MVP-1.0-Referenz wertvoll. Er zeigt den lokalen Basisstand für die einfache Kernanforderung: Das Requirement wird fachlich richtig nicht freigegeben, weil Systemgrenzen, API-Einbindung, Datenverantwortung, Berechtigungen und Testbarkeit noch nicht ausreichend geklärt sind.

Das Hauptmanko liegt im fachlichen Klärungsbedarf. Maximale Anzahl, Standardadresse, Lösch- oder Deaktivierungsverhalten, Pflichtfelder, Datenverantwortung, Berechtigungen und Auswirkungen auf bestehende Rechnungsprozesse sind noch offen.

Dieser Slot bleibt bewusst ruhig als Master- und Vergleichsstand. Er ist nicht der Platz für eine Drift- oder Modellgrenzenbewertung; diese wird bei den komplexeren Vergleichsruns ausgewiesen.

Dieser Run soll als Baseline für MVP 1.0 verwendet werden. Er zeigt, wie die lokale IREB-Core-Simulation auf NAB9 mit qwen2.5:3b die einfache Kernanforderung bewertet.

Fachlich müssen Business Rules, Standardadresse, maximale Anzahl, Lösch- oder Deaktivierungsverhalten, Pflichtfelder, Datenverantwortung, Berechtigungen, Systemgrenzen und API-Folgen geklärt werden. Ohne diese Punkte bleibt der Change Request zu Recht blockiert.

Dieser Slot dient als Master-Referenz für den Vergleich mit komplexeren Runs. Die Bewertung von Drift, Modellgrenzen und Max-Load-Verhalten erfolgt in den nachfolgenden Slots.

Der Run ist fachlich brauchbar, aber nicht als stabile Umsetzungsfreigabe geeignet. Der Change Request wird korrekt blockiert, weil Ownership, Systemgrenzen und Verantwortung für Länder-, Steuer- und Validierungsregeln nicht geklärt sind.

Die Blockade kommt nicht aus einem einfachen Textproblem, sondern aus der fachlichen und architektonischen Unschärfe: Es ist offen, wer die Regeln verantwortet, wo sie systemisch gepflegt werden, wie sie bestehende Rechnungsprozesse beeinflussen und welche Validierungslogik verbindlich gilt.

Zusätzlich bleibt der Run als MVP-1.0-Auswertung beobachtungsbedürftig, weil Knowledge-Kontext, Domänentreue und Rollen-Governance pro Run weiterhin geprüft werden müssen. Genau darum gehört dieser Run in die Gallery: Er zeigt einen echten, nützlichen Blocker, aber auch die Grenzen des aktuellen lokalen MVP-Setups.

Fachlich müssen zuerst Ownership, Standardadresse, maximale Anzahl, Lösch- oder Deaktivierungsverhalten, Pflichtfelder, Länderlogik, Steuerlogik und Validierungsregeln geklärt werden. Ohne diese Entscheidungen bleibt die Story nicht delivery-ready.

Technisch sollten Knowledge Routing, Agent Output-Verträge und run-spezifische Guard-Checks weiter gehärtet werden, damit künftige Runs weniger Domänenvermischung, weniger Rollenwidersprüche und eindeutigere Evidence-Zuordnung zeigen.

Danach sind Vergleichsruns sinnvoll: zuerst qwen2.5:7b auf NAB9, später qwen2.5:3b und qwen2.5:7b auf der GPU-Cloud. So wird sichtbar, ob sich Qualität, Laufzeit, JSON-Stabilität und Governance-Plausibilität durch Modell und Hardware verbessern.

Dieser Run erweitert die Master-Anforderung um Länder-, Steuer- und Validierungsregeln pro Rechnungsadresse. Damit ist er komplexer als der Master Reference Run, aber noch kein vollständiger Compatibility-Stress-Run.

Die fachliche Richtung wurde erkannt und der Governance-Block ist plausibel. Gleichzeitig zeigt der Run erste Grenzen des lokalen qwen2.5:3b-Setups auf NAB9: Knowledge-Kontext, Domänentreue und Rollen-Governance müssen weiterhin pro Run geprüft werden.

Der Run ist deshalb als Regelkontext-Run brauchbar, aber nicht als Master-Referenz zu verstehen. Die stärkere Modellgrenzen- und Driftbewertung erfolgt im nachfolgenden Max-Load-Run 72cb.

Dieser Run ist als Max-Load- und Compatibility-Stress-Run verwertbar, aber nicht als Master Reference Run. Er kombiniert drei Belastungen gleichzeitig: mehrere Rechnungsadressen, eigene Länder-, Steuer- und Validierungsregeln je Adresse sowie die Rückwärtskompatibilität bestehender Rechnungsprozesse und API-Schnittstellen.

Das Hauptmanko liegt in der Architektur- und Ownership-Unschärfe. Der Solution Architect blockiert plausibel, weil Systemgrenzen, betroffene APIs, Datenflüsse, Integrationen und Verantwortung für Länder-, Steuer- und Validierungsregeln nicht ausreichend geklärt sind.

Zusätzlich zeigt der Run eine sichtbare Modell- und Kontextgrenze. Die fachliche Richtung wurde erkannt und JSON blieb stabil, aber die Purity-Prüfung meldet Domain Drift. Einzelne Rohformulierungen und Knowledge-Fragmente bleiben deshalb als Evidence sichtbar und dürfen nicht als glatte Referenzqualität gelesen werden.

Vor einer Umsetzung müssen Systemgrenzen, Ownership, betroffene API-Schnittstellen, betroffene Rechnungsprozesse, Datenflüsse, Integrationen, Regelverantwortung und Rückwärtskompatibilitätsgarantien explizit geklärt werden.

Für die nächste Vergleichsstufe sollte derselbe Change Request mit qwen2.5:7b auf NAB9 wiederholt werden. Wenn der Drift sinkt und die Rollenbeiträge stabiler werden, ist die Schwäche primär ein Modell- oder Kapazitätsthema.

Wenn ähnliche Drift-Muster bleiben, müssen Knowledge-Routing, Prompt-Verträge, Rollen-Output-Verträge, Guard-Checks und die Level-Logik im Code weiter gehärtet werden. Max-Load-Requirements sollten dann als eigener Belastungslevel behandelt werden und nicht mit normalen Referenzläufen vermischt werden.

Die Context-Purity-Prüfung meldet DOMAIN_DRIFT_DETECTED. Der Purity Score liegt bei 85. Gleichzeitig lieferten alle fünf Agents valides JSON. Das ist für diesen Max-Load-Run ein wichtiges Ergebnis: Die Struktur hält, aber die Kontextreinheit ist noch nicht stabil genug für eine unkritische Referenzqualität.

Der Run zeigt damit eine ehrliche Grenze des lokalen MVP-1.0-Setups mit qwen2.5:3b auf NAB9. Er ist gut als Belastungstest und Vergleichspunkt geeignet, aber nicht als sauberer Gold-Run.

Der Lauf verbessert die Governance-Auswertung deutlich gegenüber der MVP-1.0-Baseline. Aus BLOCKED_BY_VETO wird REQUIRES_REWORK, es gibt keine Vetorollen und keine kritischen Rollen. Trotzdem ist der Lauf nicht masterfähig.

Das Hauptmanko liegt nicht mehr primär in einer Veto-Blockade, sondern in der verbleibenden Qualität des Outputs. Domain Drift bleibt vorhanden, der Purity Score steigt nicht über 85 und der Tester-Output zeigt trotz formal gültigem JSON strukturelle Modellartefakte.

Der Lauf beweist damit nicht, dass qwen2.5:7b automatisch besser ist. Er zeigt, dass 7b bessere Governance-Werte liefern kann, aber weiterhin Tester Output Contract, Language Guard und eine klare Rollout-Grenze braucht.

Pro: Governance verbessert sich auf REQUIRES_REWORK. Keine Vetorolle. Keine kritischen Rollen. JSON-Stabilität bleibt bei 5 / 5. Der Report ist fachlich deutlich besser einordbar.

Contra: Domain Drift bleibt vorhanden. Purity bleibt bei 85. Der Tester-Output enthält Strukturartefakte. Die Laufzeit ist deutlich höher. Der NAB9 wird thermisch und lastseitig stark beansprucht.

Empfehlung: 5df0 als Post-MVP-1.1-7b-Kandidatenlauf dokumentieren. Nicht als neuen Master markieren. Kein blinder Rollout auf Silo 2 oder Silo 3. Zuerst Tester Output Contract und Language Guard prüfen.

qwen2.5:7b ist lokal auf dem NAB9 lauffähig, belastet die Hardware aber deutlich stärker als die 3b-Baseline.

Laufzeit: ca. 27:27 Minuten. CPU-Temperatur während des lokalen Laufs manuell beobachtet bei ca. 88 bis 89 °C. Systemlast zeitweise über 90 Prozent.

Die Laufzeit stammt aus dem Run-Artefakt. CPU-Temperatur und Systemlast sind manuell beobachtete Betriebswerte und nicht automatisch aus runtime_timing.json gemessen.

Massnahme: Keine Mehrfachläufe ohne Abkühlphase. Für längere Vergleichsreihen entweder stärkeres Runtime-Profil, GPU-System oder Cloud-Vergleich prüfen.

bd43 zeigt BLOCKED_BY_VETO und Release 30 wo 5df0 REQUIRES_REWORK und Release 65 zeigte. Das sieht auf den ersten Blick wie ein Rückschritt aus. Es ist keiner.

5df0 erreichte 65 Punkte, weil die Tester-Bedenken nicht governance-wirksam wurden: 0 von 42 kritischem Gewicht, kein Veto. bd43 erreicht 30 Punkte, weil dieselbe Rollenstrenge jetzt formal zählt: Tester-Veto, 17 von 42 kritischem Gewicht. Die Pipeline misst schärfer, nicht das System ist schlechter.

Purity stieg von 85 auf 100. Domain Drift von erkannt auf CLEAN. Tester-Output von unkontrolliert auf Contract ENFORCED_WITH_WARNINGS. Der niedrigere Score ist die Folge einer Governance die Rollenstrenge erstmals formal wirksam macht.

1. Tester Output Contract v1: Kontrollierte Strukturvorgabe für den Tester-Output. Status ENFORCED_WITH_WARNINGS.

2. Alias Mapping: Drei Alias-Varianten auf kanonische Felder abgebildet (acceptance_risks, missing_verification_evidence, test_data).

3. Controlled Variant Normalizer: Vier rollenfremde technische Einträge aktiv blockiert.

4. PO Governance Mapping: Fehlende PO-Governance-Felder werden sichtbar statt still durchgewunken.

5. Tester Governance Bridge: Drei Governance-Metadaten als Raw Evidence ausserhalb des Contracts gehalten.

6. Report Semantics Deduplication: Tester QA Decision Semantics genau einmal im Report.

7. No-Model Regression Tests: Contract, Normalizer, Mapping und Report-Semantik abgesichert ohne Modellläufe.

8. Knowledge SMART_ROUTING: Finaler Master-Lauf mit aktivem Knowledge-Routing.

bd43 lief trotz zusätzlicher Contract- und Normalizer-Arbeit rund 12.6 Prozent schneller als 5df0 (24:00 gegen 27:27 Minuten). Die 1.1-Anpassungen haben die Laufzeit auf dieser Hardware nicht verschlechtert.

Betriebswert während des Laufs (05:06, LHM CoreMax, NAB9 CRIT_OS): CPU 88 °C, Last 51 Prozent. Nachgereicht als Momentwert, nicht als Messung über den gesamten Lauf.

Der langsamste Agent war der Tester mit 425.08 s (29.5 Prozent der Gesamtzeit). Das passt zur Projektgeschichte: das Tester-Handling war der Kern der MVP-1.1-Arbeiten.

434c ist nicht deshalb Referenz, weil der Change Request freigegeben wäre. Der Lauf bleibt fachlich korrekt blockiert: Governance BLOCKED_BY_VETO, Release Readiness 30, Vetorolle Tester. Genau das ist für diese Minimalanforderung plausibel, weil Standardadresse, Mengengrenzen, fachliche Regeln, Datenmodell, Validierung, Fehlerfälle und Regression weiterhin offen sind.

Die Referenzqualität liegt in der Pipeline-Stabilität: JSON 5 / 5, Raw JSON 5 / 5, normalized 5 / 5, Context Purity OK, Purity 100 und keine Delivery-Freigabe durch die Hintertür. Der Lauf zeigt kontrollierte Strenge, nicht Umsetzungsreife.

bd43 bleibt der historische MVP-1.1-Master der ersten acht Anpassungen. 434c läuft mit demselben Minimal-Change-Request auf der weiter gehärteten Pipeline. Die Product-Owner-Governance ist in 434c sauber: po_decision PARTIALLY_APPROVABLE, risk_level MEDIUM, Quality Guard OK. Der Product Owner ist nicht mehr kritische Rolle.

Die kritischen Rollen verschieben sich auf Developer und Tester. Der Developer blockiert fachlich-technisch mit NOT_APPROVABLE und NOT_IMPLEMENTABLE, solange Datenmodell, Validierungen und Fehlerfälle offen sind. Der Tester bleibt mit REQUIRES_FIXES streng. Gleichzeitig ist der Tester-Output kontrolliert: sieben Alias-Zuordnungen, verschachtelte Struktur über controlled_nested_variant_normalizer_v1, keine blockierten Einträge, release_status und risk_level als Raw Evidence ausserhalb des kanonischen Tester-Outputs.

434c bleibt fachlich korrekt BLOCKED_BY_VETO. Release Readiness 30 und das Tester-Veto sind keine technische Instabilität, sondern eine kontrolliert strenge Governance-Entscheidung.

Die Referenzqualität liegt in Context Purity OK, Purity 100, stabiler JSON-Struktur und kontrolliertem Tester-Output.

434c nutzt weiterhin die acht bestehenden MVP-1.1-Anpassungen. Die späteren Härtungen sind Präzisierungen innerhalb dieser acht Punkte; es gibt keine neunte Anpassung und keine MVP 1.2.

434c lief 1559.41 Sekunden (25:59.4 Minuten). Der langsamste Agent war der Product Owner mit 365.54 Sekunden.

Der nachgereichte Betriebswert von CPU 90 °C und Load 53 % ist ein manueller Momentwert, kein Run-Artefakt, Durchschnitt oder Maximalwert.

Die aggregierten Governance-Werte bleiben gegenüber 434c unverändert: BLOCKED_BY_VETO, Release Readiness 30, kritisches Gewicht 17 / 42, kritische Rollen Developer und Tester sowie Tester als Vetorolle. Das ist ein Score-Plateau und kein Beleg dafür, dass der erweiterte Change Request gleich komplex wäre.

Die zusätzliche Komplexität wird in den Rollenoutputs sichtbar: Regelmodell, Gültigkeit, Versionierung, Rule Ownership, Source of Truth, Validierungsquelle, Fehlercodes, Datenmodell- und API-Auswirkungen sowie Default-Verhalten werden deutlich tiefer behandelt. Die Laufzeit steigt gegenüber 434c nur um 6.47 Sekunden beziehungsweise rund 0.41 Prozent.

dbf0 bleibt fachlich korrekt BLOCKED_BY_VETO. Der Tester entscheidet REQUIRES_FIXES, weil bestätigte Akzeptanzkriterien, Testvoraussetzungen und Regression weiterhin fehlen. Der Developer bewertet den Change Request als NOT_APPROVABLE und NOT_IMPLEMENTABLE, solange Regelmodell, Validierungen, Fehlerfälle und fachliche Regeln offen sind.

Die rote Governance-Ampel ist keine technische Pipeline-Instabilität. Context Purity ist OK, Purity liegt bei 100 und alle fünf Agenten liefern valides JSON. Der Run zeigt kontrollierte Strenge, nicht Umsetzungsreife.

Der Tester Output Contract v1 ist mit ENFORCED_WITH_WARNINGS aktiv. Fünf Alias-Zuordnungen werden kontrolliert verarbeitet. Dazu gehört erstmals die Trennung testfallartiger Inhalte aus test_scope nach test_cases über tester_scope_test_case_separation_v1.

Drei rollenfremde API-Annahmen werden blockiert. Regression, release_status und risk_level werden aus dem kanonischen Tester-Output entfernt, während der Raw Output erhalten bleibt. Das ist ein sichtbarer Wirkungsnachweis des Contracts und kein technischer Defekt.

Gegenüber 434c ist die kanonische Tester-Vollständigkeit schwächer: fünf statt sieben Zuordnungen und drei blockierte Einträge statt null. Diese Differenz ist ein Vergleichsergebnis und löst vor CR-Stufe 2 keine Codeänderung aus.

Die aggregierten Governance-Werte bleiben über alle drei Läufe identisch: BLOCKED_BY_VETO, Release Readiness 30, kritisches Gewicht 17 / 42, kritische Rollen Developer und Tester sowie Tester als Vetorolle. Das ist ein Score-Plateau und kein Beleg dafür, dass die drei Change Requests gleich komplex wären.

Die zusätzliche Komplexität von b6a0 wird in den Rollenoutputs sichtbar: Die verbindliche Rückwärtskompatibilität erzeugt Fragen zu API-Versionierung, möglichen Breaking Changes, Migration, Default-Verhalten bestehender Adressen, Kompatibilitätsgarantien und Regression. Die Pipeline bleibt technisch stabil, der aggregierte Score reagiert jedoch nicht weiter auf die steigende fachliche Komplexität.

In b6a0 ist die Rückwärtskompatibilität erstmals verbindlicher Bestandteil des Original-Change-Requests. Der Developer erkennt API-Versionierung, mögliche Breaking Changes und Migration als offene technische Themen. Der konsolidierte Report führt eine eigene Kategorie Kompatibilitätsanforderungen.

Eine technische Erfüllung ist damit noch nicht bewiesen. Die Aussage, Rückwärtskompatibilität werde sichergestellt, ist als Rollen-Overclaim zu lesen. Korrekt ist: Rückwärtskompatibilität ist eine verbindliche Anforderung; ihre fachliche und technische Erfüllung muss vor Delivery nachgewiesen werden.

Zusätzlich zeigt delivery_relevance.json einen Compatibility Propagation Gap: constraints und regression_hints bleiben leer, obwohl die Kompatibilitätsanforderung explizit im Change Request steht. Dieser Befund gehört in den Post-Staffelungs-Backlog und löst keine neue Run-Schleife aus.

Der Business Analyst enthält einen Cross-Field-Widerspruch: Seine Summary behauptet vollständig klare Regeln und Akzeptanzkriterien, während derselbe Output fehlende Business Rules und Akzeptanzkriterien aufführt.

Die formale Product-Owner-Governance bleibt sauber, im Raw Content verbleiben jedoch unbelegte Mengen-, Scope-, Abhängigkeits- und API-Aussagen. Sie sind keine finalen Produktentscheidungen.

Der Solution Architect reagiert im kanonischen Rollenoutput nicht tief genug auf die neue verbindliche Kompatibilitätsanforderung. Betroffene APIs, Versionierungsstrategie, Migration, Kompatibilitätsgarantien und Systemgrenzen bleiben zu wenig ausgearbeitet.

Der Tester Output Contract v1 bleibt mit ENFORCED_WITH_WARNINGS aktiv. b6a0 zeigt drei Alias-Zuordnungen und null blockierte Einträge. Weniger Zuordnungen sind jedoch keine automatische Qualitätsverbesserung: test_scope vermischt weiterhin Scope, Testfälle, Risiken und Prüfnachweise; test_cases und risks bleiben fachlich zu knapp.