# ADR-0003: Table `chargeback_cases` keeps its name; only the owning module moves

## Status

Accepted

## Context

As part of migrating chargeback code into `apps/dispute_core` (ADR-0001), the Elixir module `SettlementCore.ChargebackCase` is being renamed to `DisputeCore.Case` to fit its new home. The question is whether the underlying MySQL table (`chargeback_cases`) should be renamed to match (e.g. `dispute_cases`).

`risk_core` queries the `chargeback_cases` table directly via raw SQL for two risk rules (high-frequency chargeback merchant, high chargeback rate). Any table rename would require finding and updating every raw-SQL consumer across the umbrella, with no functional benefit — a table rename doesn't change behavior, only its label.

## Decision

Keep the physical table named `chargeback_cases`. Only the Elixir module moves and is renamed (`SettlementCore.ChargebackCase` → `DisputeCore.Case`, still `schema "chargeback_cases" do`).

## Alternatives considered

- **Rename the table to `dispute_cases` to match the new domain name.** Rejected — adds migration risk (every raw-SQL consumer needs updating, and a rename touching a table with financial/audit data warrants extra caution) for a purely cosmetic gain.

## Consequences

- The mismatch between table name (`chargeback_cases`) and module name (`DisputeCore.Case`) is intentional. It must be documented in `DisputeCore.Case`'s moduledoc so a future contributor doesn't "fix" it by renaming the table and inadvertently breaking `risk_core`'s raw SQL.
- If the table is ever renamed in the future for an unrelated reason, `risk_core`'s two raw-SQL queries must be updated in the same change.