Business Rule Extractor

Turn undocumented legacy logic into a written rule inventory so a rewrite preserves behavior instead of silently changing it. The source code is the spec, and most of it is accidental - your job is to surface what it actually does, not what it should do.

Workflow

1. Scope the extraction target. Identify the exact module, files, and entry points to be rewritten. List every external system, shared table, global, and session state the logic touches - a rule split across files is the one most likely to break on rewrite.
2. Mine rules from conditionals and constants. For each branch, guard, magic number, string literal, and validation, ask "what business reality does this encode?" amount > 10000 is a large-transaction threshold; a hardcoded date is a regulation start; a branch on one customer ID is a negotiated exception. Magic numbers are almost always undocumented policy. Treat any constant that appears in two or more places as a single rule with duplication risk - note every occurrence, because a rewrite that updates one copy and misses the other creates a divergence bug.
3. Record order and interaction. Capture precedence (which discount wins when two apply), short-circuits, fall-through defaults, and exact boundary handling of null, empty, negative, and > vs >=. Evaluation order is itself a rule; note every place an input path forks.
4. Separate intended rules from bug-as-features. Code alone cannot tell you which behaviors are deliberate. Flag each questionable behavior and confirm against domain experts, support tickets, or production data - aim for at least two independent sources (e.g. one expert plus production evidence) before labeling a behavior intended. Document bug-as-features explicitly so the rewrite team decides consciously, not in an incident.
5. Capture each rule as input-to-output examples. For every rule, record concrete cases from real data, especially at boundaries - a minimum of 3 cases per rule (below, at, and above each boundary), and 10+ for rules with interacting conditions. A table of cases removes the ambiguity that "applies a tiered discount" leaves behind.
6. Hand off open questions. Before declaring a path dead, check production logs or traffic over a window that covers the business cycle - 90 days is a practical floor, a full year for anything with annual/seasonal triggers. Mark provably dead paths as dead rather than reverse-engineering intent. List behaviors you could not classify as explicit questions for domain owners.

Deliverable

Produce a rule inventory document containing: (a) a numbered rule table - trigger condition, action, source location(s), the "why" if discoverable, and status (intended / bug-as-feature / open question / dead); (b) an input-to-output example table per rule, drawn from real data with boundary cases marked; (c) a precedence-and-interaction section describing evaluation order where rules overlap; and (d) an open-questions list addressed to named domain owners. This document is the handoff artifact to characterization-test-writer and the rewrite team.

Quality bar