AI Assisted Business Rule Extraction and Assurance for Enterprise Software

The problem

Greenfield software is the exception in enterprise environments. Many business-critical applications have been under development for 5, 10 or even 20 years. They contain tens or hundreds of thousands of lines of code and often operate as part of larger distributed systems involving databases, background services, file exchanges, application servers, APIs, scheduled jobs, configuration and other dependencies.

Over time, these systems pass through multiple development teams, architects, product owners and management structures. Most of the people who originally built them have been replaced. Large parts may not have been touched in years. The software works, but nobody fully understands all of the business rules it implements or where those rules are enforced.

This creates two expensive problems.

Modernisation is difficult and risky.

Companies want to consolidate applications around fewer technology stacks, migrate desktop applications to the web, replace obsolete frameworks, expose existing functionality to mobile workers, or restructure backends and APIs. The difficult part is not rewriting the software in a new technology stack; it is preserving the business behaviour accumulated across the existing system.

A rule may be implemented partly in application code, partly in a database, partly in a background process and partly through configuration or integration behaviour. Before an organisation can safely replace or restructure such a system, it needs to understand what business behaviour the existing environment actually enforces—including rules that are undocumented, duplicated, contradictory, obsolete or distributed across several technical components.

AI-assisted development creates a new assurance problem.

AI coding agents can dramatically reduce the cost of maintaining and modernising legacy applications, but they also increase the amount of software that can be changed faster than humans can safely review it. If an organisation does not have an independent baseline describing the business behaviour its systems currently enforce, how can it determine whether an AI coding agent has unintentionally changed that behaviour?

The product

BRE reconstructs business rules from the technical evidence distributed across an enterprise application landscape. and represents them in a canonical, human-readable form.

The objective is not to explain how the software is implemented. It is to establish what business rules the system enforces.

Source code is the initial and most important evidence source, but it is not the complete long-term scope of the product. In complex enterprise environments, relevant evidence may also be found in:

• Automated tests
• Stored procedures and database constraints
• Configuration
• Background and scheduled processes
• Service-to-service interactions
• APIs and message flows
• File-based exchanges
• Infrastructure and deployment dependencies
• Other technical artefacts that reveal or constrain business behaviour

BRE uses AI to identify, interpret and correlate this evidence in order to infer candidate business rules.

Each extracted rule retains provenance to the technical evidence from which it was derived and can be reviewed by a human and classified, for example, as Confirmed, Incorrect, Obsolete or Unknown. Equivalent or duplicate rules can be identified, contradictory implementations investigated, and supporting or conflicting evidence attached to the same canonical rule.

The resulting catalogue becomes a governed baseline of the business rules enforced by the application.

Because these rules are represented canonically rather than remaining implicit in implementation code, they can eventually become machine-consumable as well as human-readable. AI software agents could query BRE for the confirmed rules relevant to the part of the system they are modifying and use those rules as context and constraints while planning and implementing a change.

BRE can then evaluate subsequent software changes against that baseline. When a pull request, migration or AI-generated modification changes a previously confirmed business rule, BRE can flag the semantic change and require human review.

For example, if the established rule is:

BR-017: Orders above €5 000 require approval from a regional manager.

and a pull request changes the implementation to €50 000, BRE identifies that a confirmed business rule has changed. The reviewer no longer needs to discover that semantic change manually among hundreds of lines of modified code.

This makes BRE both business-rule intelligence and an AI assurance technology.

A phased product roadmap

BRE is intentionally designed around a layered roadmap. The long-term product vision is broad, but the initial implementation scope is deliberately constrained.

Phase 1 — Source-code extraction

The first version focuses on production source code.

The objective is to prove that BRE can reliably identify business-rule candidates in existing applications, convert them into canonical rules, preserve provenance and support human validation.

This phase prioritises a narrow set of languages, frameworks and application structures rather than attempting universal code understanding from the outset.

Automated tests and wider runtime dependencies are initially out of scope.

Phase 2 — Additional software evidence

Once source-code extraction is reliable, BRE expands the evidence model.

Automated tests become particularly valuable at this stage. They are not treated merely as additional code to document, but as independent evidence about expected behaviour.

For example, production code may imply that customers under 18 receive a 10% discount while an automated test explicitly verifies that behaviour. BRE can correlate both artefacts, strengthen confidence in the inferred rule and use the test to help locate relevant implementation code.

Other evidence sources can then be introduced progressively, including database logic, configuration, background jobs and service interfaces.

Phase 3 — System-level reconstruction

Large enterprise applications are frequently distributed systems rather than single repositories.

At this stage, BRE moves from analysing isolated codebases to reconstructing business behaviour across application boundaries.

A single business rule may require evidence from several components:

• An API validating a transaction
• A database enforcing an additional constraint
• A scheduled process applying the rule later
• Configuration selecting a threshold
• And another service determining an exception

BRE correlates these sources into a single canonical representation of the underlying business rule.

The target abstraction therefore becomes the enterprise system, not merely the repository.

Phase 4 — Continuous business-rule assurance

Once a validated baseline exists, BRE becomes a continuous assurance layer.

Changes to source code, configuration, tests, database logic or related system components can be evaluated against established business rules.

BRE can identify when a previously confirmed rule has:

• changed
• disappeared
• been duplicated
• been contradicted elsewhere
• or acquired new supporting or conflicting evidence

This allows organisations to review business-semantic changes rather than relying only on line-by-line code review.

Phase 5 — System of record for business rules

The long-term objective is for BRE to become the persistent control layer above implementation.

Source code can be rewritten. Technology stacks can be replaced. Applications can be decomposed into services. Tests can be regenerated. AI agents can change.

The business rules an organisation intends its software to enforce require a more durable representation.

At this stage, BRE becomes not only a system that humans can review and that independently validates software changes, but also a policy and context layer for AI software agents.

Before or during a software change, an authorised development agent could query BRE for the confirmed business rules relevant to the affected system, component or workflow. Those rules can be supplied as machine-readable context and constraints that the agent is expected to preserve unless a change to the rule itself has been explicitly authorised.

BRE then independently evaluates the resulting software change against the same governed baseline.

Why automated tests do not solve the problem

Tests determine whether the implementation behaves according to expectations encoded in the test suite. They do not provide a complete, human-readable inventory of the business rules implemented by a large application.

Many enterprise legacy applications only have a small set of automated tests and patchy coverage. Even where extensive tests exist, manually reconstructing hundreds of business rules from thousands of unit and integration tests merely shifts the code-comprehension problem to another technical artefact.

AI-assisted development introduces an additional problem: the same coding agent that changes production code can also change the tests validating that code.

If an agent incorrectly changes the €50 000 approval threshold to €75 000 and updates the corresponding test to expect €75 000, the test suite remains green. The implementation and tests are internally consistent, but the business behaviour is wrong.

BRE provides an independent semantic baseline. The code and tests may change together; a previously confirmed business rule does not change without BRE identifying the change for human review.

At the same time, automated tests become valuable evidence for BRE itself. Existing tests can support rule discovery, strengthen confidence in inferred rules, expose edge cases and help locate relevant implementation logic.

Tests are therefore neither a substitute for BRE nor irrelevant to it. They become one of the evidence sources from which BRE reconstructs and verifies business behaviour.

BRE can detect a system that is internally consistent but behaviourally wrong.

Why existing developer tools do not solve it

Code assistants help developers write, understand and maintain code. Code-wiki and code-documentation products primarily explain software architecture and implementation to technical users. Traditional static analysis identifies structural, quality and security properties of source code.

These tools are generally centred on the code artefact.

BRE operates at a different abstraction level.

Its primary artefact is a canonical inventory of business behaviour, derived from multiple technical evidence sources and understandable and reviewable by product owners and business analysts as well as software engineers.

Asking an LLM questions about a repository also does not create such a baseline. An answer to:

“What happens when an order exceeds €50 000?”

may be useful at that moment, but it does not establish a governed rule with provenance, confidence, supporting evidence, human confirmation, history and automated detection of subsequent changes.

Nor does repository-level analysis necessarily reveal rules whose implementation is distributed across databases, services, scheduled processes and configuration.

BRE therefore aims to move beyond code understanding toward business-behaviour reconstruction and assurance.

Initial use cases

1. Understand and govern existing software behaviour

BRE reconstructs the business rules implemented by an existing application and turns them into a canonical, reviewable and traceable inventory.

This allows application and programme teams to:

• extract undocumented business rules
• review and confirm the canonical rule inventory
• maintain a system of record for embedded business logic
• identify which confirmed rules are affected by proposed changes
• investigate contradictions, duplication and obsolete behaviour.

2. Change legacy software with an independent AI-coding guardrail

BRE compares proposed software changes against the confirmed business-rule baseline.

This allows engineering teams to:

• compare AI-generated changes against confirmed business rules
• flag pull requests that alter business behaviour
• require explicit human review of semantic changes
• preserve provenance and change history
• safely delegate more development work to AI coding agents.

3. Turn confirmed business rules into automated tests

Once business rules have been extracted and confirmed, BRE can help convert them into executable assurance.

This allows QA and engineering teams to:

• generate automated tests from confirmed business rules
• identify confirmed rules without corresponding test coverage
• recommend or regenerate tests when rules legitimately change
• validate implementations against the canonical rule set
• keep tests traceable to the business behaviour they protect.

4. Provide business-rule context to AI software agents

Once business rules have been extracted and confirmed, BRE can make the relevant rules available to AI development tools before and during software changes.

This allows engineering teams to:

• provide AI agents with the confirmed rules relevant to the code they are modifying
• use canonical business rules as machine-readable development context
• constrain agents to preserve established rules unless changes are explicitly authorised
• reduce reliance on agents reconstructing business intent independently from source code
• independently verify the resulting changes against the same confirmed rule baseline

From extracted rules to governed business knowledge

AI coding agents are changing the entire software-development lifecycle, from discovery and implementation through verification and deployment. Their productivity advantage becomes increasingly valuable as organisations allow agents to make larger and more autonomous changes.

But powerful development agents require both authoritative context before they make changes and independent assurance after those changes are made.

BRE starts with business-rule extraction from source code because that provides a practical and technically achievable entry point.

The resulting canonical business-rule model can then become the foundation for a broader control layer:

• human validation of business behaviour
• correlation of evidence across technical systems
• rule-change detection
• pull-request guardrails
• modernisation validation
• automated-test generation
• detection of contradictory implementations
• impact analysis
• machine-readable rule context for AI software agents
• policy constraints for AI-assisted development
• assurance of AI-generated software changes

The product therefore has a natural expansion path from repository analysis to enterprise-system understanding and from one-time extraction to continuous business-rule assurance.

Code can change. Technology stacks can change. Application boundaries can change. Development teams can change. AI agents can change.

The business rules that enterprise software is required to preserve need an independent system of record. As software development becomes increasingly agentic, that system of record can serve both humans and machines: providing authoritative context to the agents making changes and independently verifying the changes they produce.

BRE is intended to become that system.