Portal Architecture: Tasks, Documents & Messages

The Borrower Portal Drives Post-Application Fulfillment

Authenticated surface where borrowers complete tasks, upload documents, and communicate with lenders.

Routing & Auth

Auth guard · load · render

Task System

Task dispatch per product type

Docs & Messages

S3 uploads, on-demand refresh, threads

Backend Loop

Decision re-eval lifecycle

Every Portal Route Is Auth-Guarded and Pre-Loaded

Session check before render, parallel data fetch on entry.

Auth Guard

Verify session before any render

Parallel Loader

Fetch loan + tasks simultaneously

Portal Page

Tasks Messages Documents

Task Detail

Handler dispatched per product type

guards non-actionable

ℹ️

Cached & parallel — loan and task data load together on entry, then every child route reads from cache.

Source Files

Guard→src/routes/_auth.tsx

Auth Client→src/lib/auth-client.ts

Session→src/lib/auth-session.ts

Loader→src/tasks/loader.ts

Portal Page→src/tasks/portal-page.tsx

Task Route→src/routes/_auth.tasks.$taskId.tsx

Statuses→src/lib/tasks.api.ts:80

Task Dispatch by Product Type

Each handler owns its UI, from file uploads to embedded vendor SDKs.

Identity

ID verificationOCR

Income

documentsauto-verify

Property

photosGPS validated

Employment

vendor SDK

Liabilities

vendor SDK

Other Docs

catch-all

S3 Upload Pipeline

Select Files

Handler UI

Get Upload URL

Presigned from backend

Upload to S3

Direct to bucket

Confirm

Backend processes

Source Files

Identity→src/tasks/government-id/

Income→src/tasks/income-documents/

Property→src/tasks/instant-pcr/

Employment→src/tasks/voie/voie.tsx

Liabilities→src/tasks/method/index.tsx

Dispatcher→src/tasks/task-detail.tsx

Upload→src/tasks/use-multiple-submit.ts

Presign→borrower_tasks/s3.py

Submit→borrower/views/document.py

Dispatch→borrower_tasks/tasks.py

Documents and Messages

No realtime connection. Messages poll; documents refresh on demand.

Lender-Shared Files

grouped by name unread indicators download & preview

Threaded Chat

10s polling auto-mark-read co-borrower shared

ℹ️

Messages poll every 10s — documents refresh after user actions (upload, delete). No realtime connection needed.

Source Files

Documents UI→src/documents/document-list.tsx

Documents API→src/lib/documents.api.ts

Documents Backend→borrower/views/shared_documents.py

Messages UI→src/messages/message-thread.tsx

Messages API→src/lib/messages.api.ts

Messages Backend→borrower/views/file_chat.py

Unread→src/tasks/portal-page.tsx:50-54

End-to-End Lifecycle Across Three Systems

A task flows from lender order to decision re-evaluation.

Lender Orders

Cortex places task request

Task Created

Backend creates task record

Borrower Fulfills

Upload files or complete SDK flow

Backend Processes

Verify, OCR, approve or reject

Decision Re-Eval

Loan may advance to next stage

ℹ️

Feedback loop — on task close, the portal invalidates cached loan + task data so the UI reflects the updated decision state immediately.

Source Files

Routes→lc/app/borrower/routes.py

Auth→lc/app/borrower/decorator.py

Tasks→lc/app/borrower/views/tasks.py

Endpoints→src/lib/endpoints.ts

Invalidate→src/tasks/task-detail.tsx:45-53

S3 + Textract→borrower_tasks/s3.py

Borrower UI - Application

Lender UI Overview

Cognito Auth

Portal Architecture at a Glance

How the borrower portal is structured.

Auth-First

Every route is guarded — session verified before any data loads or renders.

Handler per Product

One dispatcher routes each task to a specialized handler with its own upload or SDK flow.

No Realtime Connection

Messages and unread counts poll every 10s. Documents refresh on demand after user actions.

Navigation

Next: Cortex Overview

Borrower UI - Application

TOE Series Hub

The Borrower Portal Drives Post-Application Fulfillment

Every Portal Route Is Auth-Guarded and Pre-Loaded

Task Dispatch by Product Type

Documents and Messages

End-to-End Lifecycle Across Three Systems

Portal Architecture at a Glance

Keyboard Shortcuts