Why recover business rules from code instead of from documentation or people?

Because the code is the only source that is guaranteed current — it is what's actually running the business right now. Documentation has usually drifted, and memory is incomplete and walking out the door. The code can't tell you why a rule exists, so you still validate against people and intent where you can. But for the question of what the system actually does today, the executing code is the authoritative answer and everything else is a claim to check against it.

What makes extracting business rules from legacy code hard?

The rules are not labeled. A genuine business rule sits in the same code as input validation, error handling, logging, and database plumbing, with nothing marking which is which. The logic is often spread across many files and layers, duplicated inconsistently, and interleaved with dead branches that no longer fire. The work isn't reading one function — it's separating decision from mechanism across an entire codebase and telling the live rules from the fossils.

Does AI extract business rules reliably on its own?

It accelerates the work dramatically but does not finish it alone. AI can read the whole codebase and draft candidate rules far faster than manual review, which is exactly the bottleneck. But a drafted rule is a hypothesis: it can misread intent, include a dead branch, or miss the why. So every captured rule passes human review, and the behavior is ultimately proven against the running system through parity validation. AI does the reading at scale; people and evidence decide what's true.

Capturing Business Rules from Legacy Code

ModernLift ·June 25, 2026 ·11 min read

Part 5 of 8

Capturing business rules from legacy code means recovering the decisions a system makes — the eligibility checks, pricing logic, validations, and edge-case handling — and writing them down as reviewable specifications, separate from the technical plumbing they're tangled with. The code is the source of truth because it is the one place the rules are still executing exactly as the business depends on. AI-accelerated discovery reads the codebase and drafts these rules at a scale manual review can't reach; senior engineers and remaining domain experts then validate them. The output is a set of business rules the team owns, independent of who remembers them.

Part 4 made the case for recovering a system’s behavior from the code and validating it with the people who remain. This part goes one level deeper, to the most valuable thing inside that code: the business rules — the decisions the system makes that the company actually runs on. Recovering them cleanly is the difference between a modernization that preserves the business and one that quietly drops pieces of it.

What counts as a business rule

A business rule is a decision the system makes on the business’s behalf: who is eligible, what something costs, whether a transaction is allowed, how an exception is handled. “A customer over their credit limit can still place an order if they’ve been flagged as strategic.” “Orders from this region are taxed under a different schedule.” “A payment that arrives within the grace window is treated as on-time.” These are not technical details. They are the company’s policy, encoded — and in a legacy system, the code is often the only complete and current statement of that policy in existence.

That’s the realization that reframes the whole exercise. You’re not refactoring software. You’re recovering the operating logic of the business from the one place it’s been faithfully recorded, because every other record — the docs, the policy manuals, people’s memories — has drifted or has gaps.

Why they’re hard to find

If business rules were neatly labeled, this would be a clerical task. They aren’t. The difficulty is that a business rule and the plumbing around it look identical in code, and nothing marks the boundary.

A single function might check a date format (plumbing), look up a customer record (plumbing), apply a discount based on account tier (rule), log the result (plumbing), and handle a missing field by falling back to a default that some downstream process depends on (rule, disguised as error handling). The decision-that-matters is interleaved with the mechanism-that-doesn’t, in the same lines, by authors who had no reason to separate them. Recovering the rule means separating decision from mechanism — and doing it across an entire codebase.

Three things make that harder than reading one function:

Spread. A rule is rarely in one place. The eligibility logic touches a validation layer here, a service method there, a stored procedure in the database, a config flag set in a file nobody remembers. The full rule is the sum, and the sum isn’t written anywhere.
Duplication and inconsistency. The same rule is often implemented in several places that have drifted apart, so “the rule” is genuinely ambiguous — and which copy actually fires for a given input is itself a question.
Fossils. Dead branches that no longer execute sit beside live ones, indistinguishable by reading alone. Capture a fossil as a live rule and you’ll faithfully rebuild behavior the business abandoned years ago.

This is why rule extraction defeats casual effort. It’s not hard to understand any single rule. It’s hard to find them all, separate each from its plumbing, resolve the contradictions, and tell the living from the dead — at the scale of a system that’s accreted for fifteen years.

Recovering them: read everything, draft, then prove

The recovery has a shape, and the shape is dictated by the difficulties above.

Read the whole thing, not a sample. Because rules are spread and duplicated, partial reading produces partial rules — and a partial rule is often worse than none, because it looks complete. Comprehensive reading is the price of accuracy, and it’s exactly where manual review runs out of budget. This is the bottleneck an AI deep-read is built to break: reading the entire codebase, copybooks, stored procedures, and config together and drafting the candidate rules — turning an analysis that ran twelve weeks into about two.

Treat each drafted rule as a hypothesis. A recovered rule starts as a claim: here is a decision the code appears to make, here are the inputs, here is the branch, here is what it does. That claim then faces two checks. A senior engineer and, where available, the original author review it — confirming it’s a real rule, not a dead branch; correcting misread intent; supplying the why the code can’t. And the behavior is ultimately proven against the running system: in parity validation, the modernized slice runs on shadow traffic alongside the legacy, and any divergence is a recovered-rule error surfacing as a ticket, before a user ever feels it. Recovery proposes; review and evidence dispose.

The output of this is not a refactor. It’s a set of business rules stated plainly, each traceable to the code it came from and the reasoning behind it — a record the team owns and can read, independent of who remembers the system.

Recovery is the moment to decide, not just record

There’s a strategic payoff that pure documentation misses. Once a rule is surfaced and stated plainly, you can finally make a deliberate decision about it — something impossible while it was buried and invisible. For each rule: replicate it exactly, fix it, or drop it.

This is the “must replicate” versus “improve” distinction at the heart of disciplined modernization. A rule that’s load-bearing business policy gets preserved and held to strict parity. A rule that’s actually a long-standing bug, or a workaround for a problem you’re about to eliminate, goes on the list to fix or remove — deliberately, with the decision recorded, not carried forward by accident. You can only make that choice for rules you’ve surfaced. Everything still buried gets the default decision, which is “reproduce it blindly or lose it silently” — and you don’t get to pick which.

What the code can’t tell you

Recovering business rules from code has a hard limit worth stating plainly: the code tells you what, never why. It can show you that strategic-flagged customers bypass the credit-limit check; it cannot tell you whether that’s deliberate policy or a hack someone added under pressure in 2015 and forgot. That distinction decides whether the rule is sacred or disposable, and only a person who knows the history can supply it. Where that person is still around, capture the why while you can — it’s the most perishable part. Where they’re gone, you’re left with two honest options: preserve the behavior exactly because you can’t justify changing what you don’t understand, or prove through analysis that the rule is genuinely unreachable. What you must not do is guess at intent and act on the guess. Recovering the what is a solved problem at scale. Recovering the why is bounded by who’s still there to tell you.

Where this leads

This part kept pointing at the same enabling capability: reading an entire legacy codebase end to end, fast enough and completely enough to draft every rule. That used to be the immovable bottleneck. Part 6, AI Codebase Deep-Read & Reverse Engineering, opens up the mechanism — what an AI deep-read actually does, what it can and can’t conclude, and why human review is built into it rather than bolted on.

Frequently asked questions

Why recover business rules from code instead of from documentation or people?: Because the code is the only source that is guaranteed current — it is what's actually running the business right now. Documentation has usually drifted, and memory is incomplete and walking out the door. The code can't tell you why a rule exists, so you still validate against people and intent where you can. But for the question of what the system actually does today, the executing code is the authoritative answer and everything else is a claim to check against it.
What makes extracting business rules from legacy code hard?: The rules are not labeled. A genuine business rule sits in the same code as input validation, error handling, logging, and database plumbing, with nothing marking which is which. The logic is often spread across many files and layers, duplicated inconsistently, and interleaved with dead branches that no longer fire. The work isn't reading one function — it's separating decision from mechanism across an entire codebase and telling the live rules from the fossils.
Does AI extract business rules reliably on its own?: It accelerates the work dramatically but does not finish it alone. AI can read the whole codebase and draft candidate rules far faster than manual review, which is exactly the bottleneck. But a drafted rule is a hypothesis: it can misread intent, include a dead branch, or miss the why. So every captured rule passes human review, and the behavior is ultimately proven against the running system through parity validation. AI does the reading at scale; people and evidence decide what's true.

All 8 parts of Tribal Knowledge & Documentation Drift →