Which policy governed this loan? Answering the examiner's question

Sooner or later someone asks about a loan decided long ago. An examiner sampling files. An investor reviewing a repurchase demand. A borrower's counsel. The question almost always reduces to the same one: which policy governed this loan, and why did it decide what it decided?

Most operations answer it by reconstruction. Someone pulls the credit memo, finds the overlay document that was probably in force that month, and reasons backwards from the outcome. That works until the overlay changed mid-month, or the processor applied an exception nobody wrote down, or the answer depends on a threshold that lived in a spreadsheet that has since been edited.

A defensible answer has three parts, and each has to be captured when the decision is made rather than assembled when it is questioned.

The policy version. Not the policy as it reads today — the exact version that answered, identified in a way that cannot drift. A rule recorded by a fingerprint of its content cannot quietly become a different rule with the same name.

The inputs as they stood. The facts the policy was applied to, with their sources and their history. If a value was corrected later, the correction should supersede the original rather than overwrite it, so you can show both what was known then and what changed after.

The reasons that fired. Not a narrative written afterwards, but which conditions evaluated true and which branch that produced: eligible, ineligible for a named reason, or referred to a person.

With those three captured, the strongest answer stops being an explanation and becomes a demonstration: take the recorded inputs, run them through the recorded policy version, and show the same result. That only works when the decision logic is deterministic — rules and exact arithmetic, not a model's judgment — which is one more reason to keep the decision itself out of the model.

The record also has to be trustworthy on its face. A decision log in an ordinary database can be edited by anyone with access, which is exactly the objection opposing counsel will raise. A hash-chained trail, where each entry carries the fingerprint of the one before it, makes any alteration visible.

In Miji, credit overlays run as versioned rules or decision tables, and the version that answered is recorded by content fingerprint alongside the decision. Verified facts keep their sources, method and full history, with corrections superseding rather than overwriting. The DTI, LTV and payment calculations run with exact decimal arithmetic on the workflow engine. Every action, decision and approval is recorded against the run on a hash-chained audit trail you can verify on demand, and the inputs a run used are kept with it, so its numbers can be re-derived.

What is not there yet: decision notices generated directly from the decision record are in development, as is replaying a proposed policy against past loans before you publish it. Re-running a recorded decision and comparing the result with the original is also not a single button today. If you want to see the answer to 'which policy governed this loan' on a real file, that is what a first call is for: hello@mijios.ai.