I propose adding an AI-Powered Business Rule Change Simulation and Golden-Behavior Validation capability for IBM i applications to help development teams verify that application changes preserve intended business behavior while enabling controlled modernization.
IBM i applications often contain long-lived business processes implemented across RPG, SQL, CL, database objects, APIs, service programs, and other interconnected application components. Understanding technical dependencies is important, but developers also need to understand whether a proposed change alters the business behavior that existing users, processes, integrations, and downstream applications depend on.
The proposed capability would allow IBM i development teams to define and maintain approved “Golden Behavior” scenarios representing important business processes and expected application outcomes.
Developers could select an existing approved scenario and execute it against both the current application version and a proposed application version. IBM i would compare the resulting behavior and identify meaningful differences across application outputs, database changes, business-rule decisions, messages, API responses, transaction results, and other observable outcomes.
An AI-assisted analysis layer could then explain the behavioral difference in developer-friendly language and connect the difference back to the relevant RPG, SQL, program, procedure, database, API, or business-logic path that contributed to the changed behavior.
For example, if a change to an RPG pricing procedure causes a different customer discount or invoice calculation, the capability could identify the previous and proposed outcomes, highlight the affected business rule, identify the relevant application components, and explain why the behavior changed.
I also propose a developer review workflow allowing each detected difference to be classified as either an Expected Change or Potential Regression. Expected changes could be intentionally approved and incorporated into the Golden Behavior baseline, while unexpected differences could remain as validation findings requiring further investigation.
A proposed workflow could be:
Discover Business Scenario → Capture Approved Behavior → Create Golden Baseline → Develop Change → Replay Scenario → Compare Current and Proposed Behavior → Explain Differences → Review → Approve or Investigate → Update Baseline
The capability could provide a Business Behavior Validation Report containing the tested scenario, previous behavior, proposed behavior, detected differences, affected business rules, related application components, database or API effects, AI-generated explanation, developer review status, and final validation decision.
From my perspective, this enhancement could help IBM i development teams modernize and evolve mission-critical applications while maintaining greater confidence that important business behavior remains correct. It could also help organizations preserve institutional business knowledge by turning important application behavior into explicit, reviewable and reusable validation scenarios.
This capability could be particularly valuable for RPG developers, application architects, modernization teams, QA engineers, DevOps teams, and organizations maintaining large IBM i application estates. It could help reduce regression risk, improve modernization confidence, strengthen application testing, preserve business knowledge, and make behavioral validation a more integrated part of the IBM i application development lifecycle.
