Operator overrides stay cards + term loan only
Status: accepted Date: 2026-07-09 Phase 9d does not extendoperatorOverrides to MCA / SBA / BLOC. Manual revise remains the cards + term-loan surface it is today.
Decision
- Override set =
card_stacking+term_loanonly. Schema,reviseUnderwriting, andReviseUnderwritingDialogkeep (and continue to use) override code mirrors for cards and TL. Do not add per-product override codes or revise UI formca,sba, orblocin Phase 9. - Effective resolution for cards/TL stays
override ?? engine. For MCA / SBA / BLOC, effective = engine Product Decision only (SBA later: questionnaire enrichment per ADR-0003 — still not an operator override). - This supersedes the roadmap’s prior recommendation that “all 5 products [be] operator-revisable” in 9d.
Context
Operators need to correct cards and TL verdicts when the engine is wrong or incomplete. Established / revenue-based products are gate- and (for SBA) questionnaire-driven; building revise symmetry for them was ceremony without an operator workflow. ADR-0003 already blocks Confirming SBA until a questionnaire ships — adding an SBA override would create a back door around that gate.Considered options
- Roadmap default — all five products revisable in 9d — rejected.
- Confirmable-only overrides (cards/TL/MCA/BLOC; SBA later) — rejected; MCA/BLOC also do not need manual override.
- Schema for all five, UI only for Confirmable — rejected; unused override fields are debt.
- Cards + TL only (accepted).
Consequences
- Phase 9d shrinks: no Established override schema/UI work. 9d may be a thin confirmation that cards/TL override code mirrors still resolve correctly against
products[], or fold into 9e if there is nothing left to ship. - Persona / QA: no “operator revises MCA/BLOC/SBA” cases in Phase 9.
- Glossary: CONTEXT.md → “Operator product override”. System reference:
docs/design/underwriting.md§7 decision 5. - Rename of the “Established Funding” UX label to “Revenue Based” → ADR-0007.

