Example 1: Legacy Banking Rule Extraction

Domain: Credit approval logic in a 40-year-old COBOL core banking system
Stakes: Regulatory compliance, incorrect approvals or denials at scale, audit exposure
Context: Phoenix Runtime pipeline being prepared to modernize the legacy system

Illustrative example. The domain details are accurate; the engagement is constructed to be representative.

The Situation

A bank is preparing to run Project Phoenix on their loan origination system. Approximately 180,000 lines of COBOL. The original authors have retired. The business analysts who know the domain learned it from the code — not from documentation that preceded it.

The instinct is to start Phoenix immediately. Extract the business logic, rebuild from zero. The code is the source of truth.

GDD says: not yet.

The ICR Cycle

FORMALIZE — stated assumptions

[1] We believe a loan is approved when DTI ratio is below 43%.
[2] We believe credit score threshold is 680 for standard approval.
[3] We believe employment is verified by a flag in the APPLICANT table.
[4] We believe the approval path handles self-employed applicants.
[5] We believe joint applications combine incomes for DTI calculation.
[6] We believe the 43% DTI threshold is a fixed regulatory requirement.
[7] We believe declined applications are logged with a reason code.
[8] We believe the COBOL branches identically for all loan types.

STRESS — what breaks each

[1] breaks if: DTI is calculated differently for revolving vs installment debt
              the threshold varies by loan type or loan amount

[2] breaks if: score thresholds differ by product (mortgage vs personal)
              manual override paths exist that bypass the threshold

[3] breaks if: the flag can be set by the system without a document on file
              self-employed applicants have no flag — they fall through

[4] breaks if: self-employed applicants hit a code branch that was never
              updated — producing approvals or denials based on 1987 logic

[6] breaks if: 43% is a policy threshold the bank set — adjustable by
              executive decision — not a regulatory hard floor

[7] breaks if: reason codes are mapped to a table not updated since 2011
              and no longer matches current regulations

CHECK — internal consistency

Three conflicts surface:

[CONFLICT A] Statement [6] assumes regulatory fixed floor.
             Statement [1] uses 43% as if it is policy-adjustable.
             Different governance implications — cannot both be true.

[CONFLICT B] Statement [3] assumes the flag covers all applicants.
             Statement [4] assumes self-employed are handled.
             If self-employed have no flag path, [4] cannot be true.

[CONFLICT C] Statement [8] assumes unified approval path.
             Stress test on [2] suggests product-specific thresholds exist.
             If thresholds differ by product, the path is not unified.

SURFACE — unresolvable residue

ITEM 1: Is the 43% DTI threshold regulatory or policy?
  Cannot resolve from: COBOL code (encodes the number, not its origin)
  Decision required from: Chief Compliance Officer
  Consequence if wrong: regulatory breach vs unnecessary constraint
  Deadline: before Phoenix agent pass 1

ITEM 2: What is the self-employed applicant path?
  Cannot resolve from: COBOL code (branch references a 1987 product
                       that no longer exists)
  Decision required from: Head of Loan Origination + Compliance
  Options: replicate existing behaviour, define a new path,
           exclude self-employed from initial migration scope
  Deadline: before Phoenix agent pass 1

ITEM 3: Are reason codes current?
  Cannot resolve from: COBOL code (codes are hardcoded integers)
  Decision required from: Operations + Compliance
  Deadline: before Phoenix agent pass 2 (validation stage)

GATE

Three decisions made before Phoenix runs:

1. CCO confirms: 43% is regulatory — a hard floor, not adjustable
2. Head of Loan Origination decides: self-employed applicants are out of scope for initial migration — separate workstream
3. Operations agrees to map reason codes — assigned owner, two-week timeline

What Changed

Phoenix ran against a constraint set that had been stress-tested. The migration produced Java that correctly treated the 43% threshold as immutable — not as a configurable policy value. The self-employed branch was not migrated and not accidentally replicated with broken logic. Reason codes were mapped before go-live, not discovered missing during a compliance audit.

The GDD cycle took four hours across two working sessions with five people.

The alternative — discovering the self-employed branch ambiguity in production — would have triggered a regulatory notification, a rollback, and a forensic investigation of how many self-employed applicants were incorrectly processed during the migration window.

The unresolvable residue was the most valuable output Phoenix produced — and it was produced before Phoenix ran a single line.

---

Next example: Multi-Agent Procurement →