A coordination layer — not a repository for regulated paperwork
The most important constraint in this product is what it refuses to store. That refusal is enforced in code at the upload layer, because retrofitting it later is far harder than designing for it from the start.
Every document sorts itself into one of three lanes
Watch the third lane refuse its files. That rejection is the actual behaviour of the upload check, not an illustration of it.
Stored directly in the vault, auto-categorised.
- Ratified contract
- Inspection report
- Vendor invoice
- Title sheet
Status summary in-app; the file stays on the lender's system.
- Pre-approval letter
- Loan Estimate
- Closing Disclosure
Structurally impossible to upload, preview, or cache. No override.
- Bank statementBlocked
- Pay stubBlocked
- Tax returnBlocked
- Wire instructionsBlocked
- Loan application (1003)Blocked
This one is fraud liability, not paperwork
Business email compromise attacks work by intercepting a transaction and substituting the wiring details for a buyer's down payment. A portal that stores or previews wire instructions becomes one more surface where those numbers can be read or altered — and one more place a buyer might trust a tampered document.
So this product never holds them. Not as a hosted file, not as a preview, not as a cached link. The same applies to full loan applications, bank statements, pay stubs, tax returns, and credit reports — which carry financial-identity data that has no business sitting in a coordination tool.
This tiering is a working engineering framework, not a legal determination — a privacy attorney should review actual data flows before onboarding an institutional lender.
Four properties the upload layer holds
An agent and a lender uploading the same document type get the same answer. There's no per-role exception and no folder someone can drop a file into to sidestep the check.
The manual upload form and the email-forwarding intake both call the same function. A document emailed into a deal can't take a route around a rule that a dragged-and-dropped file has to obey.
HOST and LINK-OUT describe where a file lives. NEVER TOUCH describes a file that must not exist here at all — so there is deliberately no admin flag, support path, or force flag that admits one.
Stored files are served with a content type derived server-side from a validated extension allowlist, with a size ceiling — so an upload can't claim to be something the browser will then execute when someone opens it.
Next: the part that outlives the transaction
Everything that is safe to keep, stays keepable — which is the point of a record that doesn't switch off at closing.