Responsible AI-Driven Testing Strategy & Approach
Chakra Vyuha
Project
A responsible, human-in-the-loop pipeline for features/requirements extraction, documentation and scenarios/test cases generation — powered by dual AI agents, LLM reconciliation and a shared RAG knowledge base.
Chakra Vyuha · Seven-stage controlled lifecycle
From requirements to retained knowledge
Tap any card to open a simple explanation — what it is, why we do it, and its advantages.
Process Automation
Create validated manual test cases / scenarios
Tap to learn more →
Test Automation
Convert manual scenarios into executable automated tests
Tap to learn more →
CI Pipeline
Execute automated scenarios through quality gates
Tap to learn more →
Consolidated Test Results
Consolidate results and compare releases
Tap to learn more →
Continuous Deployment
Prepare environment and deploy validated build
Tap to learn more →
RTM
Trace requirements, tests and defects
Tap to learn more →
Documentation
Retain standards and project knowledge
Tap to learn more →
Responsible AI · Human in the Loop
AI proposes. Humans approve.
Every AI output passes two automated checks and two human gates before it is trusted downstream.
Human in the LoopHITL
AI drafts — people decide. No generated feature or test case moves downstream without human sign-off.
Transparency
Every artifact links back to its source file, build version and the LLM that produced it.
Triangulation
Two independent LLMs (Ornith · Nemotron) run in parallel; differences are surfaced, never hidden.
Grounded in evidence
RAG context keeps answers tied to real source code, DB schema and SRS — reducing hallucination.
Security & privacy
Static analysis against SonarQube and IMSAS guidelines; project data stays inside the controlled environment.
Honest confidence
Confidence % is assessed, not assumed. No speed or accuracy gains are claimed without measurement.
Sequential validation gates · AI first, humans decide
AI + RAG context validation
Outputs are checked against the retrieved source of truth.
Double-LLM delta validation
Gemma reconciles Ornith and Nemotron and flags every mismatch.
Manual validation
IV&V testers review every features/requirements .md and scenario/test case.
Stakeholder validation
Domain owners approve before automation, reporting and IBM ELM RTM.
Confidence Assessment / Confidence % — to be assessed. No measured gains are claimed.
Process automation · Two directions
Top-to-bottom & bottom-to-top
Start from the SRS when it exists — or reverse-engineer the code to build a synthetic SRS when it doesn't.
Top-to-Bottom
Use when a proper SRS (requirements document) exists.
- 1.Read the SRS and classify features: UI · REST API · Database · Integration
- 2.Write one features/requirements .md file for each classified feature
- 3.Read each .md file and generate Unit · REST API · UI · DB · Performance scenarios/test cases
- 4.Store .feature files in the respective layer folders
- 5.Nemotron 551B + Ornith 397B run in parallel → reconciliation → manual → stakeholder validation
Backward trace: Bug → Scenario → Feature → SRS
Bottom-to-Top
Use when no concrete SRS is available — derive a synthetic SRS from the code.
- 1.Read front-end / back-end source code and DB schema from RAG
- 2.Classify UI · REST API · Database · Integration features
- 3.Generate one features/requirements .md file per feature
- 4.Generate layered scenarios/test cases for every feature
- 5.Reconcile, validate manually and with stakeholders, then assemble the Synthetic SRS
Backward trace: Bug → Scenario → Feature → Synthetic SRS
Knowledge storage & retrieval
RAG design, sheet by sheet
Ingest, store, retrieve, return and reuse — switch sheets at the bottom of the workbook.
| A | B | C | D | E | |
|---|---|---|---|---|---|
| 1 | # | Artifact | Source | Used by | Purpose |
| 2 | 1 | Front-end source code | GitLab | Version · Vikram | UI feature extraction |
| 3 | 2 | Back-end source code | GitLab | Version · Vikram | REST API & integration features |
| 4 | 3 | DB schemas | GitLab | Vikram · Maya (Zara) | Database features & DB tests |
| 5 | 4 | SRS (when available) | GitLab / Docs | Vikram | Top-to-bottom generation |
| 6 | 5 | Commit ID / build version | GitLab | Agent Gen V | Version every artifact |
RAG Assistant · ask the knowledge base
Connected · previewHi, I'm the Chakra Vyuha RAG assistant. Ask me anything about the AIS features/requirements, .md files, scenarios/test cases or runs.
Process automation · System architecture
The pipeline, step by step
Every stage reads from and writes back to the RAG core. Press play, or pick a step on the wheel.
Agent Gen V · Version Agent
The process starts from the Gen V intake screen (UI). Gen V captures the source code / SRS, captures the committed ID, stores both in the RAG knowledge base and then triggers Agent Vikram for Step 2.
- Starts from
- Gen V UI — upload SRS or enter source code paths
- Activity
- Captures source + committed ID, stores in RAG
- Hand-off
- Sends trigger to Agent Vikram (Step 2)
Input
- Starts from the Gen V UI screen
- SRS document (uploaded), or
- Source code paths: front-end, back-end, DB schema diagram
- Any other supporting documents · GitLab branch
Output
- Captured committed ID
- Source code + SRS stored in RAG
- Trigger sent to Agent Vikram (Step 2)
Step 01 · Agent Gen V intake screen · the process starts here (preview)
Other documents (optional)
| Moduleby Vikram | Feature/Requirementby Vikram | features/requirements .mdby Vikram | Unitby Maya | APIby Maya | DBby Maya | UIby Maya | PFby Maya |
|---|---|---|---|---|---|---|---|
| AIS | Vessel Position Reporting | position_reporting.md | 14 | 9 | 5 | 6 | 3 |
| AIS | MMSI Identity Management | mmsi_identity.md | 11 | 7 | 6 | 4 | 2 |
| AIS | NMEA VDM Message Decoding | nmea_decoding.md | 18 | 6 | 3 | 2 | 4 |
| AIS | Target Tracking & CPA/TCPA | target_tracking.md | 16 | 8 | 4 | 7 | 5 |
| AIS | Collision Alerting | collision_alerting.md | 12 | 6 | 2 | 5 | 3 |
| AIS | Static & Voyage Data | voyage_data.md | 9 | 7 | 6 | 4 | 2 |
| AIS | Safety Message Broadcast | safety_messages.md | 8 | 5 | 3 | 3 | 2 |
Key design patterns
Triangulate, reconcile, then validate
Dual-Agent Validation
Ornith & Nemotron generate in parallel for cross-verification.
Reconciliation Loop
LLM (Gemma) reconciles outputs at every critical step.
Source Code Validation
Every artifact is checked against the source of truth.
Centralized RAG
One knowledge base shared across every stage.