A credit agent recommends approving a loan. Its evidence check passes. Its policy check blocks the recommendation. For a lending reviewer, the important question is what those results actually mean: did the system verify a decision, or did it verify only the fields the agent chose to supply?
In Veriprajna's The Validation Firewall prototype, a retained model output on a synthetic application makes that distinction visible. The response recommends approval despite several failures against the configured credit policy. It also supplies an empty evidence list. The evidence check has nothing to compare and therefore passes. The separate policy check still evaluates the application record and blocks the recommendation.
We use this example to examine a practical requirement for credit decisioning validation: a reviewer should be able to identify the rule that controls the outcome, the information that rule inspected, and the gaps another green result leaves open.
The policy supplies the decision boundary
The prototype's authored Credit Policy CP-1, version 2026.1, defines six criteria. For this synthetic application, four comparisons are sufficient to explain the block. Its FICO credit score is 559 against a minimum of 620. Its debt-to-income ratio is 55% against a maximum of 43%. Its loan-to-value ratio is 98% against a maximum of 95%. It has three delinquencies in the preceding 24 months against a permitted count of zero.
These numbers matter because they show the relationship between the record and the recommendation. An approval contradicts the encoded policy even if its prose is coherent. The check does not ask the model to judge its own answer again. Plain-Python logic compares the record with the configured criteria outside the model.
The validation record displays the original approval alongside a BLOCK finding and the failed policy comparisons. That gives the reviewer a concrete reason to withhold acceptance of the recommendation within the demonstration. The displayed review destination is simulated; no loan system is updated and no borrower receives a message.
The retained model approval fails CP-1's configured criteria. The adjacent evidence pass checks supplied entries, not whether the response supplied enough evidence.
A passing check can cover an empty input
The same record exposes a coverage question that a dashboard colour cannot answer. The evidence check compares the field/value entries supplied by the agent with the application record. It does not require every relevant field to appear, and it does not independently verify every factual statement in the rationale. Here, the response supplies no evidence entries at all.
That means its passing result supports a narrower statement than a reader might assume. No supplied evidence entry failed comparison. It does not establish that the agent furnished a sufficient evidential basis for approval. The policy check catches this recommendation through a different input: the application record itself.
We would ask a validation owner to document both properties separately. Does a check reject mismatched supplied values? Does it reject missing required support? A design can implement the first without implementing the second. Treating them as one capability would leave a reviewer unable to distinguish correct evidence from absent evidence.
The prototype does not implement a general missing-evidence gate. Its value in this example is the visible separation of the checks, including a limitation that a production design would need to address explicitly.
The input contract deserves review too
The retained response's rationale says that no permitted denial-reason keys were provided, so a policy-compliant denial reason could not be issued. The source adapter supplies the policy criteria to the model but omits the permitted reason list that its prompt tells the model to use.
That is an integration defect relevant to interpreting this output. The case does not establish how the model would behave with a complete input contract, or provide a fair comparison of model capabilities. It does establish that the recommendation returned by this particular contract breaks the policy the independent gate evaluates.
Repairing the prompt and retaining the separate policy check serve different purposes. Supplying the missing reason list repairs information available to the model. Evaluating the returned recommendation against CP-1 checks whether this output satisfies the encoded boundary. We would require evidence for both before treating a revised workflow as ready for use.
The accompanying video also shows a policy-supported synthetic denial with no structured principal reason keys. That recommendation escalates for review rather than being blocked by the policy check. The rationale mentions credit factors, but the required reason-key list is empty. This reinforces the same distinction: an outcome, a narrative explanation and a complete structured response are separate things to inspect.
Make acceptance traceable to the check
For a model-risk or lending product review, the useful acceptance question is specific: which application values and policy version produced this gate result? The per-decision receipt retains the individual findings and rule references so the answer can be inspected alongside the recommendation.
These receipts cover selected encoded checks on synthetic data. They do not certify legal compliance or complete model validation. An AUTO-CLEAR label means the implemented individual checks passed; it can apply to a denial as well as an approval. It is not permission to release a production lending decision.
The full explainer shows the prototype and its boundaries. For a real review, we would require a green result to carry its coverage with it: what was examined, what could be omitted, and which independent rule actually determined acceptance. That makes a validation result usable without asking a reviewer to infer more than the check proved.