The rule is larger than the code
A transfer eligibility check may inspect an account attribute, yet the product rules that give that attribute meaning can live in a separate configuration store. A developer tracing only the application can explain the branch and still miss which products qualify, when a setting changed, or who approved an exception. That is the verifiability gap in practical terms: the team can read an implementation without being able to prove the business behavior it represents.
Start with a rule inventory, not a translation inventory. For each flow, identify the code path, the configuration it reads, relevant interface contracts, tests, operational evidence, and the person who can explain the intended policy.
Draft a map that can be challenged
AI can help trace calls, outline data flows, and draft a sequence diagram. Those outputs are useful because they give experts something concrete to inspect. They should show their supporting files and configuration references, and separate observed behavior from an inference about intent. A diagram that hides its evidence can make a mistaken interpretation look settled.
The review should follow a complete request across boundaries: where the decision starts, which configuration is consulted, what downstream services receive, and how failure is handled. The resulting document is a working hypothesis until a business specialist and technical lead reconcile it with real rules and independent checks.
Treat dormant paths as open questions
Older systems often retain branches for products that have changed or disappeared. No recent call, weak test coverage, or an old runbook may suggest that a path is dormant. None of those clues alone proves it can be removed. A rarely used exception may be exactly the behavior a migration must preserve.
Mark the path with its evidence and uncertainty. Ask an accountable domain owner whether the rule is active, intentionally retired, or unresolved. If the answer remains unclear, keep it as a named assumption with a follow-up trigger. That is safer than letting an AI score or a search result silently decide the target behavior.
Make approval a controlled baseline
The verified rule document should say what the rule means, where the evidence came from, who reviewed it, which scope the decision covers, and what remains uncertain. When sources disagree, record the disagreement and its resolution. The business specialist owns the rule's meaning; the architect or technical lead owns its implications for the system design.
This baseline is valuable because later teams can trace a design choice or a failed test back to the decision that shaped it. It is still a versioned account of the current understanding, not a claim that every historical behavior is known forever. Changes in configuration or policy need another review.
Let rules drive the slices
Once a rule is approved, link it to the target design, a bounded implementation task, and acceptance scenarios. A slice might cover one eligibility decision and its failure cases rather than an entire transfer domain. The smaller scope makes it easier to ask whether the new service preserves the approved behavior, and easier to locate the source of a difference.
Tests should include ordinary cases, boundary cases, and exceptions discovered during analysis. Where the legacy system behaves unexpectedly, the team must decide whether that behavior is required, an accepted change, or a defect to correct. Coding should follow that decision, not create it by accident.
Use discrepancies to improve the map
Comparison against the old system will expose differences that a document review missed. A failed scenario might reflect a coding error, stale configuration, mismatched test data, or a rule that was never fully understood. Give each difference an owner and a disposition before expanding the migration.
The loop should reach backward as well as forward. Correct the rule record when its evidence changes; update the design or tests when the original interpretation was incomplete. That way, the next slice starts from better knowledge. The enduring deliverable is not merely a list of legacy conditions. It is a chain from source evidence to an approved business decision and a testable replacement.