A woman applies for a loan and is denied. Under federal law, she now has a right the architecture diagram never mentions: the right to be told why — specifically, accurately, and in terms of the actual principal reasons the decision went against her.
That right is fifty years old. The Equal Credit Opportunity Act and Regulation B require an adverse-action notice with the specific reasons for denial; the Fair Credit Reporting Act adds its own notice duties when a consumer report was involved. And in a pair of circulars, the Consumer Financial Protection Bureau closed the door most AI teams were hoping to walk through: there is no complexity exemption. If your model is too sophisticated to produce specific and accurate reasons, the Bureau’s position is not “then a vague reason will do.” It is then you may not use that model to decide.
Sit with that sentence, because it is an architecture review conducted by statute. Most of this series has been about wrapping models in enforcement. This article is about the rarer and more uncomfortable case: a legal requirement that reaches through the wrapper and disqualifies the model’s position in the system itself.
What “specific and accurate” actually demands
The legal standard sounds mild until you translate it into engineering acceptance criteria. The reasons on the notice must be specific — “insufficient income relative to obligations,” not “did not meet our credit standards.” They must be accurate — they must be the reasons that actually drove this decision, not plausible reasons a decision like this might have. And they must be individually correct — reasons drawn from the applicant’s actual data, not from the model’s general behavior.
Turn that into a test and it reads: for any denied applicant, the system must emit the principal factors that caused the denial, such that changing those factors would have changed the outcome, and the emitted factors must be stable — ask twice, get the same answer.
Now hold a generative model up against that test.
Why a sampled explanation is not a reason
The instinct everyone has first: keep the powerful model, add an explanation step. Ask the model why it decided. Or run the decision, then have a second pass generate the rationale for the notice.
The problem is not that the generated explanation reads badly. It reads beautifully. The problem is what it is: a sample from a distribution over plausible rationales, produced by a system whose actual decision process is a forward pass no narrative faithfully describes. The model is not reporting its reasons; it is writing a story about a decision, in the confident voice of something that knows. Ask it twice and you can get two different, equally fluent stories — which fails the stability test on its face. Perturb the applicant’s data in ways the story says were decisive and the decision sometimes doesn’t change — which fails the accuracy test, measurably.
In an unregulated product, this gap between decision and narrative is a philosophical curiosity. On an adverse-action notice it is a false statement of reasons, delivered to the exact person the statute was written to protect, and preserved in writing for the examiner. Part 1 argued a hallucinated APR is a violation, not a bug. A hallucinated reason for denial is the same species, aimed at a more protected moment.
And note that this failure is not fixable by the tools that fixed everything else in this series. You cannot negative-test your way out of it; the eval suite can detect that explanations are unstable, but no gate can make a sampled narrative become a cause. The enforcement layer can stop a bad action; it cannot make a story true.
The forbidden architecture, named plainly
So here is the line, and it’s worth stating without hedges: in a credit decision path, a generative model may not be the thing that decides, and may not be the thing that explains. Not because generative models are bad — the rest of this series exists because they’re valuable — but because this specific legal duty demands a property (faithful, stable, individually-causal reasons) that sampling does not have and cannot be wrapped into having.
That eliminates the end-to-end agentic underwriter that demos so well. It also eliminates the subtler version: deterministic decisioning with an LLM “summarizing” the reasons onto the notice, unconstrained — because an unconstrained rephrase can drift from the reason codes it’s supposedly conveying, and the notice is the legal artifact.
The compliant shape: code decides, code explains, the model translates
What remains is a clean division of labor, and it’s the same one this series keeps arriving at from different directions — the LLM interprets; the code computes.
The decision core is deterministic and interpretable by construction. Scorecards, constrained and monotonic models, rule structures — systems where the principal reasons for an outcome are computable, not narrated. Reason codes fall out of the decision itself: the factors are the arithmetic, not a story about it. Ask twice, get the same answer, because nothing is sampled.
The explanation is bound to the reason codes. The notice content comes from the codes through governed templates. If a generative model participates at all, it participates as a translator — rendering the bound content in plain language, at a reading level, in the customer’s language — under a constraint the enforcement layer can actually check: every rendered notice is validated, deterministically, against the codes it must express, and a rendering that adds, drops, or reweights a reason fails closed. The model may change the words. It may not change the reasons.
Fairness testing gates the release. Bias evaluation across protected classes is a blocking eval on the decision core — same machinery as Part 1’s term-accuracy gates, pointed at disparate outcomes. One currency note, held loosely because this ground is moving: 2026 rulemaking pulled back the federal disparate-impact emphasis, but several states run effects-based fair-lending regimes of their own, so the testing obligation survives federally-shaped arguments about it. Let compliance characterize the legal theory; engineering’s job is that the measurement exists, runs, and blocks.
And everything upstream of the decision still gets to be modern. Document intake, income-statement normalization, application assembly, fraud signals, customer communication before and after the decision — generative models are fine there, governed by everything this series already built, because none of it is the decision. The line isn’t “no LLMs in lending.” The line is: no sampling where the statute demands a cause.
The design input nobody budgets for
The practical failure I’ve seen is not teams refusing this analysis. It’s teams encountering it late — after the impressive end-to-end prototype, after the roadmap commitment, when the compliant redesign reads as a loss instead of a requirement. The adverse-action constraint is a design input, and it belongs in the first architecture conversation, in writing, in the decision record — because it changes what you prototype, what you promise, and which vendors you shortlist. A vendor pitching a generative underwriting agent has not solved this problem. They have not met this problem.
There’s a version of this article for every regulated decision, not just credit: employment screening, insurance rating, housing. The statutes differ; the shape repeats. Wherever the law grants a person the right to the true reasons for a decision about them, sampling is disqualified from making or explaining that decision — and the honest architecture puts the model where it excels and is permitted: at the edges, translating, never deciding.
Next in this series: the datasets you built to test all of this — golden sets, traces, labeling queues — and why the Safeguards Rule considers them regulated assets, not internal tooling.