Lender UI Overview

The Lender's Workspace for Working the File

Cortex covers the loan lifecycle from evaluate through review to fund.

Fast Track

Underwriting checklist

Rules & Actions

Inline editing & order placement

Borrower Tasks

Document collection & review

Funding

Close & disburse the loan

ℹ️

Frontend mounted on Marketplace

Mount point→src/file/left-nav.tsx

App entry→src/main.tsx

⚠️

Cortex is dead. The cortex-lender-checker-ui repo will be renamed soon — the patterns and architecture here still apply, but the branding is going away.

Fast Track Renders Decisions as an Interactive Checklist

The decision engine's output becomes a navigable hierarchy of stages, categories, and rules.

Apply

Borrower UI

Review

Lender UI

Fulfill

Borrower UI

Close

Lender UI

Decision Result

Overall pass/fail status

Stages

Underwriting phases

Bounded Domains Keep Each Concern Isolated

No cross-domain imports except through the shared API layer.

File Views

Layout shell + three product pages — Summary, Borrower Tasks, Funding

Order Display

Cross-cutting renderers for vendor reports and task results

Shared Components

Form primitives, inputs, and reusable UI patterns

API Layer

Queries, mutations, and endpoint definitions — the shared import boundary

Routes

Lazy-loaded file-based routing under a single base path

ℹ️

Everything lives under one file ID — all three views (Summary, Tasks, Funding) share the same loan context.

Source Files

Layout shell→src/file/index.tsx

Summary→src/file/summary/

Borrower Tasks→src/file/borrower-tasks/

Funding→src/file/funding-disbursement/

Products→src/orders/products/

Tasks→src/orders/tasks/

UI components→src/ui/

API layer→src/lib/

Routes→src/routes/

Every Rule Gets a Dedicated Component

Rules should map to data groups, not individual fields — but the legacy API currently maps 1:1.

Financial

DTI, CLTV, credit score, loan amount, income

Verification

Govt ID, employment, insurance, credit verified

Property

Type, residence, lien position, valuation, flood

Process

Intent to proceed, compliance workflow

Adaptive Polling

Orders In Flight

Exponential backoff (2s → 60s cap) — refreshes decisions, orders, and tasks

Idle

Polling stops once the stage has passed

Rule Card States

Success→Rule passed validation

Error→Rule failed — default fallback

Warning→Validation error on rule

Waiting→Execution in progress

Default→Initial neutral state

Source Files

DTI→src/file/summary/rules/dti.tsx

Credit score→src/file/summary/rules/credit-score.tsx

CLTV→src/file/summary/rules/cltv.tsx

Intent to proceed→src/file/summary/rules/intent-to-proceed.tsx

Polling hooks→src/file/summary/check-list-hooks.ts

State utils→src/file/summary/check-list-utils.ts

Rules map→src/file/summary/rules/index.tsx

⚠️

Legacy constraint: The current API maps each rule to a single field. A refactor is planned to align with the group-based model shown above.

Rule Cards Are Actionable, Not Just Informational

Inline edits and orders trigger live decision refreshes.

Edit in Drawer

Income, liabilities, liens

Save & Validate

Persist to backend, then invalidate

Decisions Refresh

Rules recalculate and update live

What Can a Rule Card Do?

Data Drawers

Edit income, liabilities, and liens with row-level forms

Order Placement

Trigger vendor reports directly from a rule card

Lender-Only Fields

Extra fields visible only to lenders — never exposed to borrowers

ℹ️

Edits cascade: entity data persists, then decisions recalculate — the UI picks up changes on the next action or poll cycle.

Source Files

DTI drawer→src/file/summary/rules/dti-drawer/

Lien drawer→src/file/summary/rules/lien-drawer/

Order mutation→src/lib/place-order.mutation.ts

Lenders Request, Borrowers Upload, Lenders Approve

The borrower tasks view connects lender orders to borrower fulfillment.

Waiting on Borrower

Order placed, email sent

Ready for Review

Borrower uploaded documents

Approved

Lender accepted or requested new

Specialized Task Types

Property Inspection

Photos, checklist, and final report

Identity Verification

Document extraction and comparison

Income Documents

Parsed data with issue flagging

Liability Payments

Payment approval tied to funding

Source Files

Tasks query→src/lib/borrower-tasks-list.query.ts

Endpoints→src/lib/endpoints.ts

Property Inspection→orders/tasks/instant-pcr/

Identity Verification→orders/tasks/government-id/

Income Documents→orders/tasks/income-docs.tsx

Liability Payments→orders/tasks/liability-payment/

Two Paths to Disburse

Institutional setup determines whether the lender or borrower drives the closing workflow.

Lender-Driven

Lender enters closing details, deposits, external payments, and fees — then validates and disburses

Borrower-Driven

Lender orders payment, borrower enters amounts in portal, lender reviews and approves — then disburses

Not Started

In Progress

Approved

Disbursed

Source Files

Core path→src/file/funding-disbursement/core/

Method path→src/file/funding-disbursement/method/

Status hook→src/file/funding-disbursement/use-disbursement.ts

Endpoints→src/lib/endpoints.ts

⚠️

Disbursement is irreversible — both paths require explicit confirmation before funds transfer.

The Feedback Loop That Drives the Loan

The Lender UI and Borrower UI share one API, split by audience.

Lender Acts

Place orders, edit data, approve tasks

Borrower Responds

Receive tasks, upload docs, enter payments

Engine Re-Evaluates

Decision rules recalculate on new data

Checklist Updates

Polling detects changes, rule cards refresh

Audience Access Levels

Full Access

Stages, rules, inline editing, order placement, lender-only fields

Scoped Access

Satisfy codes, task completion, document uploads — no lender fields

Source Files

Auth query→src/routes/__root.tsx

Nav routes→src/file/left-nav.tsx

Role guard (PCR)→orders/tasks/instant-pcr/index.tsx

Role guard (Income)→orders/tasks/income-docs.tsx

⚠️

Security boundary: Lender UI schemas include lender-only fields that must never appear in the borrower UI — always strip when adapting patterns.

The Lender UI Is a Live View of the Decision Engine

Three principles that define the lender's workspace.

Live, Not Static

Fast Track polls for changes and updates rule cards so the checklist stays current

Actionable Rules

Every rule card can trigger an edit, an order, or a task. Changes feed back into the engine on the next cycle.

Two UIs, One File

The Lender UI and Borrower UI are two views of the same loan data. Lender acts, borrower fulfills, engine re-evaluates.

Navigation

The Lender's Workspace for Working the File

Fast Track Renders Decisions as an Interactive Checklist

Bounded Domains Keep Each Concern Isolated

Every Rule Gets a Dedicated Component

Rule Cards Are Actionable, Not Just Informational

Lenders Request, Borrowers Upload, Lenders Approve

Two Paths to Disburse

The Feedback Loop That Drives the Loan

The Lender UI Is a Live View of the Decision Engine

Keyboard Shortcuts