How Do I Extract Business Rules from My Old System with AI?

You extract the business rules from your old system in 3 steps: AI reads the code and writes each rule as a clear sentence linked to the line it came from, the person who owns the process reviews it and confirms or corrects it, and you compare it with what the system actually does on real invoices. A tool such as AWS Transform for mainframe writes rules as reviewable requirements, and in Thought Machine's announcement with Amazon on 29 September 2026 extraction runs through 4 stages ending in human sign-off. Write no new code until the rules are confirmed.

In part 3 you came out with an inventory and a provisional decision for each system. The systems you decided to rebuild or convert are the ones that need this step first.

Why business rules are the most valuable thing in your old system

A business rule is the way your company calculates or decides something: how a wholesale customer's discount is worked out, when a late fee is added, who approves a purchase order above a certain limit, how an installment amount is rounded. These rules built up over years of changes, and many of them were never written in any document.

• In the code: conditions and calculations a developer wrote years ago at the request of a manager who has since left.
• In the database: price tables, rates and limits someone edits by hand without knowing what depends on them.
• In people's heads: the exceptions the accountant handles by hand because the system does not.
• In spreadsheets: formulas that fill the gaps in the system, as we explained in which sheet is the system.

If you rebuild the system without these rules, you build a new system that calculates differently, and you only find out when a customer disputes an invoice. The rules are what must move; the old programming language is only the container.

How AI reads the code and writes the rules

Extracting rules used to be long manual work: a developer reading the code line by line and writing down what they understood. Today's tools read all of the code, follow where every number comes from and where it goes, then write what they find in plain language. One example: Amazon says on the AWS Transform for mainframe page that the service extracts every business rule from the source code and traces it to its origin, then generates development-ready requirements your team can review, each one traceable back to the code it came from. That is Amazon's description of its service, not a guaranteed result.

The format a rule is written in matters. One well-known format is EARS, the Easy Approach to Requirements Syntax, developed by Alistair Mavin and colleagues at Rolls-Royce and first published in 2009. The idea is that every rule is written in a fixed order: the state, then the trigger, then what the system must do. It has 5 basic patterns; here are illustrative business examples:

The value of this format is that the process owner can read and judge it without knowing how to program. One sentence per rule, and they answer yes, no or incomplete.

An example from banking: business intent, not line-by-line translation

The clearest recent example comes from banking, where interest, fee and repayment rules have lived in COBOL code on mainframes for decades. COBOL is an old programming language that still runs many systems in banking and insurance. In its announcement of 29 September 2026, Thought Machine, a banking technology company, said it is working with Amazon on a pipeline that does not translate code line by line but extracts pure business intent. According to the announcement, the pipeline runs through 4 stages:

1. Extraction: AWS Transform reads the legacy applications and extracts the business logic into specifications written in EARS.
2. Consolidation: hundreds of redundant variations of the same product are merged into lean, modern specifications.
3. Synthesis: AI agents generate the financial products and their tests in Python.
4. Validation: human review in which the bank's engineering and risk teams hold explicit sign-off authority.

Note the two lessons: consolidation shows that an old system carries many copies of the same rule, and the final stage is entirely human. These are the two companies' claims about their pipeline, and their example is a bank, but the method works for any company: extract, merge the duplicates, then build, and approve nothing before the decision owner signs off.

Why the process owner must confirm every rule

AI reads what the code does, not what the company wants. The gap between the two is where modernization mistakes happen:

• Dead code: it may extract a rule from a part that has not been used for years, making it look like a live rule.
• An old bug that became habit: the system rounds an amount the wrong way and staff fix it by hand. The extracted rule will carry the bug over unless someone says it is a bug.
• A rule outside the code: the exception the accountant handles by hand will never appear in the extraction.
• Conflicting rules: two versions of the discount calculation in two different places. Which one is right is a business decision, not a technical one.

So give every rule a business owner who signs it off: the sales manager for discount rules, the finance manager for late fees and approvals. Confirmed rules become the basis of the requirements brief for the new system, and we explained how to write one in our guide to writing a software requirements brief. Keep in mind that code and databases can hold customer or employee data, so any tool that reads them outside the Kingdom needs the review we covered in part 3, alongside the Saudi Data and AI Authority's guidance.

The Origami view

When we modernize an old system, we treat its business rules as the most important thing to carry over, not its code. We use AI tools to read the code and write the rules as clear sentences at a speed that was not possible before, but we do not treat a single rule as final until the process owner has read it and signed it off.

Then we test every confirmed rule against real data from the old system before we build the new one around it, so the new system calculates the way the company expects, not the way a tool guesses. If you want to see how we work, take a look at our services.

This week's exercise: one rule, three invoices

You do not need to wait for a tool to start. Pick one rule that causes frequent debate, such as a discount or a late fee, and follow these steps:

1. Ask the process owner to write the rule in one sentence, in the form: When..., the system shall...
2. Pull 3 real invoices from the system where the rule applied: an ordinary one, one at the limit, and one with an exception.
3. Calculate each invoice by hand using the written sentence, and compare the result with what the system produced.

If all three match, the rule is documented. If one differs, you have found a hidden rule or an old bug, and that is exactly what you need to know before any modernization.

Coming next

You now have confirmed rules for your system. Next comes the big decision: do you move the system as it is, convert its code to a modern platform, rebuild it around the rules you extracted, or replace it with a ready-made product and keep only the data? In part 5 we compare these paths in a table: when each fits, what it keeps, what it risks, and who must be involved.

Sources

• AWS Transform for mainframe: official page — business rule extraction traced to the original code, reviewable requirements and equivalence testing.
• Thought Machine and AWS: announcement of 29 September 2026 — the four stages: EARS extraction, consolidation, synthesis and human validation.
• EARS: the official guide by Alistair Mavin — the format, its five patterns and its first publication in 2009.
• SDAIA: Personal Data Protection.