Skip to main content

​
Credit-repair reasons attach to cards + term loan only; file veto deleted

Status: accepted Date: 2026-07-09 Phase 9 deletes the file-level credit-repair hard stop and attaches credit-repair as a per-product reason. This ADR locks which Funding Products receive that reason in Phase 9, and what is explicitly deferred.

​
Decision

  1. Delete hasCreditRepairHardStop (and any equivalent file-level short-circuit in deriveWorkflow) so a credit-repair-class outcome can never set primaryPaths: ["decline"] before other products are considered. This restores locked cross-track non-exclusivity (docs/design/underwriting.md §9 decision #5).
  2. Attach credit-repair-class reasons to card_stacking and term_loan Product Decisions only. MCA, SBA, and BLOC do not inherit cards-side credit-repair reasons; they keep only their own evaluator reasons.
  3. Keep existing creditRepairFlag / credit_repair (and related) coaching nextActions for Phase 9 — do not remove recommendation cards in this phase.
  4. Defer (follow-up initiative, not Phase 9): eliminate credit-repair recommendations from the coaching layer; add an operator settings switch to inject a credit-repair referral link into decline email/SMS templates.
  5. Park a spike (before or alongside 9c TL wiring): audit whether term-loan evaluator gates already imply credit-repair-class declines, or whether TL must explicitly share cards’ repair reason codes so we do not under- or over-decline TL relative to operator reality (“if cards need repair, TL usually fails too”).

​
Context

Today hasCreditRepairHardStop in deriveWorkflow.ts can veto the whole file — contradicting the 2026-04-27 non-exclusivity lock. The roadmap’s prior recommendation attached repair reasons to card_stacking + sba only and treated TL as “has its own gates.” Product direction rejects sparing TL on that basis, and rejects attaching repair to SBA (SBA is questionnaire-gated per ADR-0003, not a repair-referral surface). Longer-term, credit-repair coaching should leave the engine UX entirely in favor of an opt-in referral link in decline templates — that is a messaging/settings project, not a prerequisite for deleting the file veto.

​
Considered options

  • A — Phase 9: cards + TL reasons; keep coaching; defer settings referral (accepted).
  • B — Also strip credit-repair nextActions in Phase 9 — rejected for this ADR; larger coaching delta, can ship after the veto is gone.
  • C — Full cutover including settings + decline-template link in Phase 9 — rejected; pulls settings/messaging into the underwriting roadmap.
  • D — Cards only; TL waits on spike — rejected as the Phase 9 attachment rule; the spike still runs to validate how TL shares reason codes, but the locked target is cards + TL, not cards alone.
  • Roadmap default (cards + SBA) — superseded; SBA is not a repair-reason product under ADR-0003.

​
Consequences

  • Phase 9c persona delta table must expect: credit-repair-class files can show card_stacking (+ often term_loan) declined with repair reasons while MCA/BLOC remain independently qualified when their evaluators pass.
  • Do not re-introduce any router-level gate that mutates Product Decisions (VISION.md Locked Decision on FUND-1964 / routing gates still applies — reasons are projections/attachments per evaluator, not a second pass that overwrites unrelated products).
  • creditRepairFlag persistence and coaching emission stay until the follow-up initiative; operators may still see repair recommendation cards in Phase 9.
  • Glossary: CONTEXT.md → “Credit-repair reason attachment”. System reference: docs/design/underwriting.md §7 / §10 gap #1.
  • Follow-up to ticket separately: CR recommendation removal + settings referral link; TL gates spike findings may amend how TL reason codes are sourced but not which products are in the attachment set without a new ADR.