Parts 9 & 10 · for the dev team

How the pieces connect

The POS is the borrower’s front door. It is not the system of record — the LOS is, and the POS never invents loan status. Everything below hangs off that one rule.

CLEAR POSBorrower + LO + partner experience · multi-tenant from day one
CreditTri-merge, soft pullone reseller, soft + hard
VerificationVOA / VOI / VOETruv + Plaid
Doc AIClassify + extractOcrolus
DisclosuresTRID packagesDocMagic
eSign / eCloseRON, eNoteDocMagic · Snapdocs
Fraud / IDIdentity proofingPersona or Socure
AI cloneText + voiceClaude/GPT · ElevenLabs
LOS — LendingPad today, NachoLOS as it matures System of record for loan status. REST API + webhooks for status, milestone and document events.
CRM — GoHighLevel near-term Milestone campaigns and retention. Total Expert / Surefire if CLEAR standardizes later.
Cross-cutting: PPE (Optimal Blue / Polly) · AUS (DU / LPA) · MI · Flood · Title & valuation

The one integration that decides the project

// the POS→LOS contract, in one rule
POS owns: application data, borrower UX, documents in,
           consent, the AI conversation
LOS owns: loan status, conditions, underwriting,
           fees, the closing package

// therefore
status = await los.get(loanId) // never computed locally
needsList = los.conditions.map(toPlainLanguage)

// and every webhook is
idempotent · retried with backoff · reconciled nightly
Why this is the risk

A POS that computes its own status will eventually tell a borrower they are approved when they are not. Every status string the borrower sees must be traceable to an LOS value and a timestamp.

Adapter, not integration

LosAdapter is an interface with two implementations — LendingPad now (L2, P0), NachoLOS later (L3, P2). Written that way, moving to Nacho is a config change and a test suite, not a rewrite.

Reconciliation is a feature

Webhooks get dropped. A nightly diff of POS state against LOS truth, with an alert on drift, is L10 — and it is P0 for a reason.

⚠️ Credentials CLEAR must supply — not a dev task

These are long-lead items. They gate real testing, and this is the exact gap that stalled the Nacho build — 6 of the 15 open items there were credentials, not code. Source them now, in parallel with development.

DU + LPA access

Automated underwriting. Nothing realistic can be tested without it.

CLEAR
Credit reseller account

Soft pull for pre-qual, hard pull at application.

CLEAR
Truv / Plaid production keys

Sandbox keys are free; production is a contract and an underwriting review.

CLEAR
MERS org ID + eRegistry / eVault

Only needed for eNote (Phase 3) — but the setup takes months, so start it in Phase 1.

CLEAR
DocMagic / Docutech account

Disclosure packages and the eClose path.

CLEAR
PPE credentials

Optimal Blue or Polly, for anything rate-adjacent.

CLEAR
CRM keys · MI · flood accounts

The unglamorous long tail that blocks end-to-end tests.

CLEAR

Non-negotiables in the architecture

L1 · P0Multi-tenant from day one

Row-level scoping, per-tenant keys, no expressible cross-tenant join. Retrofitting isolation is a rewrite.

L11 · P0A real sandbox

Every vendor, in a non-production environment, before the first borrower. “We tested against mocks” is how launch weeks go wrong.

L12 · P0Instrumented by default

Completion rate, time-to-first-touch, drop-off by step. If it is not measured, the 68% abandonment problem is invisible.

10.4Autosave + offline tolerance

Mid-range Android on cellular is the target device, not a MacBook on office wifi.

10.3Versioned API

The POS will outlive its first LOS. Version the contract now.

10.6A QA script, not a demo

“Coded” is not “done.” Done means it passes its acceptance test on a real device, with its compliance controls tested.