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 and their recommendation cards. They are the operator’s in-app repair signal — including the caution-swap that warns of card-by-card denial risk on an otherwise qualified file — and they stay.
  4. Add an operator settings switch that injects a credit-repair referral link into the decline email/SMS templates. Ships separately from the underwriting roadmap.
  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). The client-facing side of repair referral belongs in decline messaging rather than the engine UX — an opt-in referral link operators configure in settings — but that is a messaging/settings project, not a prerequisite for deleting the file veto, and it does not displace the operator-facing coaching cards.

​
Considered options

  • A — Phase 9: cards + TL reasons; keep coaching; settings referral ships separately (accepted).
  • B — Also strip credit-repair nextActions — rejected. The coaching cards are not only a repair-partner pitch: the same emission drives the “Proceed with Caution — Card Stack” swap that sets denial-risk expectations on qualified files, so removing it would delete operator risk context along with the referral.
  • 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; operators continue to see repair recommendation cards.
  • Glossary: CONTEXT.md → “Credit-repair reason attachment”. System reference: docs/design/underwriting.md §7 / §10 gap #1.
  • The settings referral link ships separately: automationLocationConfig.creditRepairReferralLink plus the {{operator.creditRepairReferralLink}} merge variable in the declined_repair_referral templates. 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.