EduLoans reviewer workspace

I chose deterministic lender gates for the first version and deferred machine-learning scoring until outcome data existed. The alternative would have made a plausible score easier to display while leaving the underlying eligibility uncertain. Relationship-manager confirmation, backed by a policy screenshot, was required before the five affected lenders could be released.

The model keeps each lender’s conditions visible: eligibility gates first, then a score bounded at 0–100 and five result tiers. Premium-university income exceptions, course factors and urgency adjustments remain policy inputs rather than reasons to improvise an answer. The same verified facts and rule version should produce the same result.

I separated policy exploration from interface scaffolding so each could be inspected independently. AI-assisted building describes how the working artifacts were produced; it does not mean the captured interface runs a live document model or makes a lender’s credit decision. The original role screens use sample data and scripted responses.

A document can be recognized without its contents being reliable. The design separates classification, validation and verification. For example, an uncertain regional marksheet or scanned tax return must go to a KAM—an account manager reviewing the case—rather than silently becoming verified information. This is the intended handling of the documented example types, not an executed document-quality evaluation.

The role views explore different actions against one case model. A student supplies information; a partner submits and manages cases in bulk with payout context; a KAM inspects risk and service-level signals, checks evidence and resolves exceptions. The scripted screenshots show those jobs individually; they are not a recording of one case completing the full journey.

That choice adds a review step instead of maximizing apparent automation. It also makes unfinished work visible. The archived backlog includes rule-source consistency, a specified Punjab pincode rejection not yet wired into the application, 32 unsecured lender–applicant checklist combinations and a separate operational dashboard. None is presented as subsequently completed.

Before release, I would require approved lender fixtures, verification that cannot be bypassed and matching policy versions across builds. These are proposed gates. Document quality, permissions, score boundaries and recovery need their own evaluation; a software-test pass count cannot establish those results.