EduLoans reviewer workspace

Thirteen lender thresholds were missing. A polished interface could still produce a convincing match, but it could not supply the policy evidence behind that answer. I treated those gaps as restrictions on affected-lender release rather than letting the prototype guess.

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.

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.

What exists is a documented policy model and original interaction prototype for three roles. The model records 62 rules across eight lender configurations and 23 workflow states; these are scope counts, not correctness scores. Archived software tests cover UI/utilities and locally defined rule helpers, not deployed lender-function correctness or document-model quality. Closure of the recorded release restrictions is not established.

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.

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.

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.

The written student journey has fourteen turns; V1.03 shows a thirteen-step counter. Partners explore bulk submission and payout context. KAMs inspect a queue and verify evidence before rule-engine results. The screenshots are separate scripted role views, not a demonstrated end-to-end execution.

The 23 states describe a workflow state machine, not geography. Lender-by-applicant checklists link document requirements to policy. Uncertain regional marksheets, scanned tax returns and joint statements are documented examples for human review. Expanded coverage and a separate operational KAM dashboard remain archived roadmap items.

The policy/chat build supported rule and conversation review; the React, TypeScript and Supabase scaffold made the application structure tangible. The tool inventory records which work each build supported, not independent evidence of production quality.

Original V1.03 screenshots run with sample records and scripted responses, without a lender, backend or live model connection.

The archived policy model uses lender-specific gates, 0–100 bounded scores and five result tiers. Premium-university income exceptions, course factors and urgency adjustments are retained as explicit policy conditions; machine-learning scoring was deferred pending outcome data.

Thirteen thresholds across Auxilo, Gyandhan, PNB, Axis and ICICI required relationship-manager confirmation backed by policy evidence. The archived P0 restriction applied to those lenders. A Punjab pincode exclusion is specified as policy while its application wiring remains P1 backlog.

Status is the archived technical-portfolio account, reviewed 15 October 2026; later completion is not established. Threshold confirmation and consistency between the master rule source and builds restrict release. The proposed consistency options are master-to-Supabase sync with a checksum or a rules-administration flow.

Coverage work includes pincode rejection wiring and 32 unsecured checklist combinations. A proposed single-JWT OpenAPI contract has three scopes and asynchronous document/verification handling, with hard-reject closure. Later operational work includes separate KAM permissions, payout reconciliation and rule-engine re-runs.

Separate exploratory work considered mapping KAM work onto an NVIDIA NemoClaw agent graph in an Antigravity side project, and investigating Zapier MCP, Apify and Unipile for a LinkedIn-related connector gap. These are follow-on learning topics, not components delivered in the lending prototype.

Archived software tests cover UI/utilities and locally defined rule helpers. They do not establish deployed policy correctness or document-model quality. The Vitest JSON report records 145 passing assertions across ten files on 5 March 2026 at 06:51 UTC; the run was not freshly repeated for this case.

Rule-engine tests define helpers within the test file rather than importing the deployed suggest-lender function. Supabase and selected UI dependencies are mocked; document assertions cover status utilities. Earlier selector failures and an unidentified failed last-run marker also remain in the archive.

Proposed, not executed: approved lender fixtures, enforced verification and consistent rule versions are the three first release gates. The full matrix also covers score boundaries, uncertain documents, role permissions and incomplete-case recovery. Fixtures, acceptance thresholds and representative document data have not been supplied as executed model or end-to-end results.