Blaze NexGen 2.0
Evolution from a Java/React legacy code modernization platform (Spring Boot 3.4.5, 7-step workflow, AWS ECS Fargate) to an agentic SDLC platform (78 agents, 4-phase governance, EKS). Feature-by-feature comparison of every Blaze 1.0 capability against its 2.0 counterpart.
Architecture Shift: UI Tool → Agentic Platform
Blaze 1.0 is a multi-module Java/React monorepo (Spring Boot 3.4.5 + React 19 + Python FastAPI) deployed on AWS ECS Fargate that guides consultants through a 7-step legacy code modernization workflow. Blaze 2.0 replaces the entire interaction model with 78 specialized AI agents orchestrated through a 4-phase SDLC workflow.
Blaze 1.0 Architecture — Multi-Module Monorepo
| Module | Technology | Purpose |
|---|---|---|
modules/core | Java 21, Spring Boot 3.4.5 | REST API, JPA/PostgreSQL, AI orchestration |
modules/ui | React 19, TypeScript 5.8, Vite 6 | Single-page application (shadcn/ui, @xyflow/react) |
modules/file-index | Spring Boot | Standalone hybrid search microservice |
modules/assistant | Python, FastAPI, LlamaIndex | RAG-powered AI assistant service |
modules/agents/* | Python, tree-sitter, Agno AI | AST parsing, code summarization, story generation |
terraform/aws/ | HCL | AWS ECS/Fargate, RDS, EFS, ALB |
Blaze 1.0 — 7-Step Workflow
Blaze 2.0
Feature-by-Feature Scorecard
Every Blaze 1.0 capability mapped to its 2.0 counterpart with coverage assessment.
| 1.0 Feature | 1.0 Approach | 2.0 Approach | Verdict |
|---|---|---|---|
| Legacy Code Understanding | Tree-sitter AST parsing (PL/SQL, SAS, COBOL, Java, C, Alteryx) → PostgreSQL graph with PGVector 1536-dim embeddings; interactive @xyflow/react knowledge graph with hybrid semantic+keyword search | codebase-mapper agent + Legacy Modernization Mode (5-dimension analysis) + Neo4j knowledge graph |
Exceeds |
| Current/Target State Mapping | UI-driven target stack definition (Spring Boot, Quarkus, PySpark, etc.) with hierarchical module decomposition and legacy→modern artifact mapping via AI-assisted discovery | bpmn-specialist + dmn-decision-architect + process-simulator — executable BPMN 2.0/DMN 1.3 with PM4Py simulation |
Exceeds |
| Requirements Generation | AI-generated requirement specs, design specs, and user stories per target module via story-generator agent; file export to Jira/ADO |
prd-generator with mandatory BDD Gherkin + live PM integration via ado-manager, jira-manager, github-issues-manager |
Exceeds |
| Code Generation | OpenCode agent generates modernized code per target module using accumulated AST graph + embedding context; batch output as project structure | TDD-governed generation in isolated git worktrees with code-integrity rules (no stubs, no TODOs, no mocks) |
Exceeds |
| Testing & Remediation | Execute generated test cases, identify compilation/testing failures, AI-assisted remediation before making code available; summary report with key metrics | 6-gate testing protocol + playwright-e2e-tester + JSON evidence capture + CI enforcement (6 jobs) |
Exceeds |
| Data Lineage | Graph-centric data model (CALL_GRAPH, LINEAGE_GRAPH, UI_INTERACTION_FLOW) with interactive @xyflow/react visualization and JSONB metadata | Neo4j graph + legacy modernization data analysis dimension (programmatic, no visual UI) | Meets |
| Data/Analytic Pipeline | Data and analytic pipeline orchestration via capability registry pattern; Docker-backed processing tools with @Async event-driven execution | CI/CD pipeline focus only — no dedicated ETL/data pipeline agent | Gap |
| Integration Refactoring | Integration refactoring via legacy→modern mapping (Step 4) with AI-assisted artifact linking and dependency graph analysis | Legacy Modernization Dim 4 (integration analysis) + deviation-rules API governance |
Meets |
| Model Conversion | Data model conversion between technologies via target architecture design (Step 3) and code generation (Step 6); supports Spring Boot, Quarkus, PySpark targets | BPMN/DMN process model conversion covered; generic data model conversion is partial | Partial |
| Low Code / No Code | 7-step guided workflow via React 19 SPA (shadcn/ui, Radix UI); visual graph exploration + form-driven target architecture design + AI code generation | Natural language → full SDLC via 78 agents (beyond low-code) | Reimagined |
| Mainframe Modernization | COBOL/JCL-aware ingestion via tree-sitter AST parsing (Step 1); mainframe source treated as first-class input alongside PL/SQL, SAS, Java, C, Alteryx | General-purpose legacy framework (5-dimension) + mainframe extensions; not mainframe-specific tooling | Partial |
| Built-in Knowledge System | LlamaIndex RAG assistant (FastAPI + Python) with conversational interface over full knowledge base; AWS Bedrock Cohere embeddings + PGVector hybrid search | Multi-layer: AI reasoning + memory-bank + Neo4j graph + Context7 real-time docs |
Exceeds |
| Guard Rails | Configurable processing tool guard rails via capability registry pattern; Docker-backed policy enforcement with application.yml configuration |
Multi-layer enforcement: Python engines + 40 rule files + git hooks + 4-category deviation protocol + trust enforcer | Exceeds |
| Jira/ADO Export | AI-generated user stories per target module via story-generator agent; export as files for manual upload to Jira/ADO |
Live bidirectional API integration — agents create work items directly | Exceeds |
| Cloud-Native Transformation | Target architecture design (Step 3) generates cloud-native output; deployed on AWS ECS/Fargate + RDS PostgreSQL 16 + ALB + OAuth2 Proxy (Azure Entra ID) | Production EKS/K8s (74 manifests) + 5 Cloudflare Workers (OTP auth) + Prometheus/Loki/OTEL observability built-in | Exceeds |
Guard Rails: Configurable vs Multi-Layer Enforcement
This is where 2.0 most dramatically exceeds 1.0. Instead of user-configurable policies, 2.0 has a layered enforcement architecture that makes non-compliance structurally impossible.
Blaze 1.0 Configurable Guard Rails
- Capability registry pattern — processing tools (preprocessors, doc generators) registered by name in
application.yml - Each capability backed by a Docker image; executed via Podman/Python runtimes
- Configurable policies and architecture principles applied through UI forms
- Guidelines displayed as advisory warnings during code generation
- Post-hoc review catches violations after generation completes
Blaze 2.0 Multi-Layer Enforcement
- Layer 1: Python enforcement engines —
compliance-monitor.py,workflow-validator.py,industry_rule_engine.py - Layer 2: 40 rule files across 10 categories (agents, security, testing, workflow, etc.)
- Layer 3: Git hooks —
pre-commitandpre-pushblock invalid commits - Layer 4: 4-category deviation protocol (Auto-fix / Ask First / Stop / Never Do)
- Layer 5: Code integrity rules — 6 blocking patterns (no stubs, no TODOs, no mocks in prod)
- Layer 6: Trust enforcer agent prevents unauthorized operations
- Layer 7: Industry rule engine supports 7 verticals (HIPAA, SOC2, PCI-DSS, etc.)
Enforcement Comparison
| Aspect | 1.0 | 2.0 |
|---|---|---|
| Enforcement timing | During generation — advisory warnings + post-hoc review | Pre-commit, pre-merge, real-time |
| Bypass possible? | Yes — advisory; user can override | No — blocking quality gates |
| Industry-specific | Configurable per-capability via application.yml | 7 industry verticals with specific controls |
| Evidence collection | Manual (no structured evidence format) | Automated CDD with Merkle tree integrity |
| Compliance scoring | N/A | 4-dimension composite score, 90% gate |
Code Generation: Batch Output vs TDD-Governed
1.0 generates a project as a deliverable. 2.0 generates code within a governed development lifecycle where tests are written first and code must pass 6 integrity checks before it can proceed.
Blaze 1.0 Context-Driven Code Generation
- OpenCode agent uses accumulated AST graph + PGVector embedding context per target module
- Core API prepares context files in shared directory, posts to OpenCode HTTP API over internal service endpoint
- Generates modernized source code, unit tests, and config files per module
- Output as batch project structure for manual integration
- Event-driven async processing — @Async + lifecycle hooks (onStart/onSuccess/onFailure)
- No enforcement of test-code relationship or TDD cycle
Blaze 2.0 TDD-Governed Generation
- Red: Write failing tests from BDD scenarios first
- Green: Generate minimum code to pass tests
- Refactor: Clean up while maintaining green tests
- Isolated git worktrees prevent cross-branch contamination
- 6 code integrity rules block stubs, TODOs, mocks, empty bodies, commented-out code
- TypeScript strict mode and Python type hints enforced
Generation Workflow Comparison
1.0 Flow (7 Steps)
2.0 Flow
Testing: Run & Remediate vs 6-Gate Protocol
1.0 runs tests and reports failures. 2.0 enforces 6 independent quality gates, captures results as machine-readable evidence, and blocks progression until all gates pass.
Blaze 1.0 Test & Remediate
- Execute generated test cases against modernized code output
- Identify compilation errors and testing failures per module
- AI-assisted remediation — OpenCode agent fixes failures before making code available
- Summary report with key metrics (pass/fail counts, compilation status)
- Single pass: run, AI-fix, done — no multi-gate enforcement or evidence capture
Blaze 2.0 6-Gate Protocol
- Gate 1: Every new file has corresponding test file
- Gate 2: Coverage ≥ 50% project / 80% new code
- Gate 3: Integration tests for external dependencies
- Gate 4: No skipped tests without justification + work item
- Gate 5: Tests must assert real outcomes (not just execute)
- Gate 6: Edge cases and error paths covered
Evidence Capture Comparison
| Aspect | 1.0 | 2.0 |
|---|---|---|
| Output format | Summary report (pass/fail counts, compilation status) | JSON evidence (machine-readable + human-readable) |
| Work item linking | Manual (stories exported as files) | Automatic — every test result linked to work item |
| BDD mapping | Not enforced | Scenario-to-test mapping captured as evidence |
| CI enforcement | mvn test (Testcontainers) + frontend npm run build | 6-job CI: python-tests, python-audit, js-tests, js-audit, coverage, worker-tests |
| Compliance integration | None | Test evidence feeds CDD compliance scoring |
Capabilities With No 1.0 Equivalent
These 15 capabilities exist in Blaze 2.0 but have no counterpart in the 1.0 product.
Multi-AI Consensus Review
4-model PR review pipeline (Claude Sonnet + Claude Opus + Gemini + GPT-4o) with consensus synthesis via multi-ai-reviewer.
CDD (Compliance-Driven Development)
Evidence collection at every SDLC phase with Merkle tree integrity chains for tamper-proof audit trails.
4-Phase SDLC Orchestration
Automated Phase 1→4 workflow with quality gates blocking progression between phases.
78-Agent Hierarchy
3-tier agent system: Primary (2), Visible (12), Hidden (64) — each specialized for a specific concern.
BDD Enforcement
Mandatory Gherkin scenarios (Given/When/Then) before any coding begins. Phase 1→2 quality gate.
Security Scanning
OWASP Top 10 analysis, secrets detection, supply chain security via security-reviewer + dependency-checker.
Process Simulation
PM4Py-based what-if analysis and Monte Carlo simulation on BPMN process models.
Cost Optimization
Multi-cloud cost analysis via aws-cost-reporter and multi-dimensional banking cost allocation.
Banking Operations
Tier 1 banking: AML transaction analysis, market risk calculation, trading desk orchestration.
Hypothesis-Driven Reasoning
Formal ADI cycle with WLNK evidence assessment and bounded validity on all architectural decisions.
Session Continuity
Memory Bank + activeContext.md enables cross-session handoff with checkpoint recovery.
Multi-Tenant Architecture
Organization & tenant isolation with Descope SSO, per-tenant K8s namespaces, and solution registry.
Canonical Artifact Registry
186 artifacts defined once, auto-published to OpenCode & Claude Code via publish-artifacts.sh with zero-touch automation.
K8s Operations Console
Full Kubernetes dashboard with pod management, deployment controls, and multi-cloud provider support (AWS, Azure, GCP).
Operations Dashboard
Real-time platform metrics, compliance gauges, agent analytics, ROI tracking, and AI governance monitoring.
Areas Where 2.0 Has Partial Coverage or Gaps
Three areas where Blaze 1.0 capabilities are not fully matched. Remediation plans created as ADO work items.
data-pipeline-orchestrator agent created. Supports pipeline definition, execution monitoring, data quality checks, and Neo4j lineage tracking. ADO work item filed.model-converter agent created supporting 8 source formats and 12 target formats with field mapping documentation. ADO work item filed.Summary
Coverage Assessment
Strongest Advantages (2.0 over 1.0)
| Guard Rails | 7-layer enforcement vs configurable policies |
| Testing | 6-gate protocol vs run-and-report |
| Code Generation | TDD-governed vs batch output |
| PM Integration | Live bidirectional API vs file export |
| Cloud-Native | Production infrastructure built-in vs transformation advice |
Gaps Addressed
| Data Pipelines | Agent Created data-pipeline-orchestrator.md |
| Mainframe | Extensions Created MAINFRAME_MODERNIZATION_EXTENSIONS.md |
| Model Conversion | Agent Created model-converter.md |
| All 3 gaps have ADO work items for tracking and future implementation | |
Key Insight
Blaze 1.0 and 2.0 are fundamentally different architectures addressing the same outcomes. 1.0 is a multi-module Java/React monorepo (Spring Boot 3.4.5, React 19, FastAPI) on AWS ECS Fargate that guides consultants through a 7-step legacy modernization workflow with AI-assisted code generation. 2.0 is an agentic platform with 78 specialized agents that performs the work autonomously under 4-phase governance. The comparison is less about feature parity and more about paradigm evolution — from AI-assisted modernization tool to agent-orchestrated SDLC platform.