> ## Documentation Index
> Fetch the complete documentation index at: https://docs.myfundingmachine.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 0001 underwriting whatif override seam

# Underwriting multiplier constants are tunable via an optional what-if override seam

Status: accepted

The Underwriting Review Console (`app/admin/internal/underwriting-review/`) lets staff preview the effect of changing a **constant knob** — a hardcoded multiplier magnitude or band boundary that is *not* a field on `ResolvedThresholds` (`SCORE_MULT_BANDS`, `NEW_CARD_MULT`, `THIN_MULT_CONFIG`, the `0.65^n` old-BK penalty, the business-tier cutoffs, the `760/710/680/650` score-band boundaries). To preview these live we thread an **optional what-if override** into `computeCreditMetrics` / `runUnderwriting` that defaults to the current constants, so a Decision is byte-identical when no override is passed (no behavior change, no ruleset-version bump). Production never passes overrides; only the review tool does, and only to compute an ephemeral what-if — a chosen change is applied to the actual constants via a generated Cursor prompt, never persisted from the browser.

## Considered options

* **Prompt-only (rejected):** keep the constants truly constant; the review tool specifies a desired change as text and previews nothing. Smaller engine surface, but defeats the tool's core promise — seeing a multiplier tweak's effect across the review batch *before* committing to it.
* **Persisted config (rejected for now):** promote these constants to operator `customValues` so tweaks take effect without a code edit. Rejected because these are global engine calibration, not per-operator config, and persisting them silently mutates the ruleset outside the version-bump + golden-snapshot discipline.

## Consequences

* `computeCreditMetrics` / `runUnderwriting` accept an optional override param that **production code never passes**. This is deliberate — do not "clean it up." The seam exists solely for the review tool's what-if preview.
* The override must **never** be wired into a production decision path. Doing so would change Decisions outside the `RULESET_CODE_VERSION` bump + golden-snapshot discipline that guards the orchestrator's transitive surface (see CONTEXT.md → "Ruleset version").
* The override seam in code must carry a comment pointing back to this ADR (`docs/adr/0001`), so an engineer editing it is routed here before changing it. Glossary cross-reference: CONTEXT.md → "What-if override".