Skip to content

Nunez & Fleischer

AI reads. A human confirms. Code writes. A document engine that takes a lender's terms and a title company's due-diligence bundle and returns the firm's complete loan closing set, ready to redline.

Loan Documents — loan summary
The review screen: each extracted value with its confidence and state, beside the paragraph of the source document it was read from

The review screen, on a synthetic deal — every value beside the words it was read from.

What it is

The firm acts as lender's counsel on private real-estate loans. Every closing meant reading the same facts out of a stack of PDFs — the loan terms, the borrower entity, the property, the title work, the insurance — and keying them into dozens of Word documents that all have to agree with each other. It was the kind of work that scales only by hiring, and the firm was turning deals away.

The engine takes the file in and hands the closing set back. What makes it safe to use isn't the model, it's the division of labor: the model reads and cites, and code writes. Claude proposes values with a citation and a confidence for each one, and then stops. Code canonicalizes them, computes everything derived, and fills the firm's own templates. The model never formats a number and never writes legal text.

How a package gets made

Five stages, and one of them is a person. The route from what the model read to a document that leaves the building runs through the review gate — there is no path around it, and the validator behind it can send a deal back.

Read, confirm, write — the gate is the only way through
  • 01

    The lender emails the loan terms; the title company sends the borrower and property paperwork — entity documents, title commitment, lien search, survey, insurance. All of it arrives as PDFs, in whatever shape it happens to be in.

  • 02

    One pass over the whole stack proposes about 70 fields. Every value carries a citation to the document and page it came from, a confidence, and a note where the model is unsure. It proposes and cites; it does nothing else.

  • 03

    Each value sits next to the words it was read from, and confirming happens on the row itself. Clicking a citation opens the source page with the quoted words highlighted. What the deal already answers is settled before the attorney arrives, so the questions that remain are the ones actually worth a person.

  • 04

    Deterministic rules run over the one canonical record: arithmetic, cross-document name and date consistency, entity authority, statutory limits. Findings carry a severity, and the serious ones send the deal back to a person.

  • 05

    Code fills the firm's own templates and hands back the closing set as .docx, ready to redline. The gate is absolute: zero unresolved tokens, or there is no package to download.

Designed for trust

An attorney signs their name to this paper. Every design decision below exists so that checking the machine is cheaper than doing the work by hand — because a tool that's expensive to verify just moves the labor somewhere less visible.

Provenance you can click

Every extracted value keeps its citation. Clicking one opens the source PDF at the right page with the quoted words highlighted — so checking the machine costs a click, not a hunt through a 300-page bundle.

Blanks that are visible

A fact nobody supplied renders as a closing-table blank you can see, not as an empty gap that reads like finished paper. The failure mode that matters here is silent, not loud.

Authority, reasoned

From the operating agreement or the articles: is the borrower an LLC or a corporation, who are its managers and members, and who can actually bind it. That answer drives every signature and notary block in the set. It is judgment, not transcription.

The arithmetic is code

Per-diem interest, documentary-stamp taxes, holdbacks, amounts spelled out in words — all computed and formatted by code from confirmed inputs. The model never formats a number and never fills a document.

Agreement, not just confidence

Two documents printing the same figure is corroboration, and the page each prints it on is one click away. Where they disagree, the competing reading opens its own document, highlighted at the words that differ — so the reviewer arbitrates between two sources instead of trusting a percentage.

A redline of what left

When an answer changes the shape of the deal, the draft shows the consequence both ways — what the change added, and what it struck out. A clause quietly disappearing is harder to catch than a clause appearing, so the diff refuses to be one-sided.

The gate

The largest module in the engine is the validator, not the extractor. It's the firm's own checking duties written as deterministic rules over one canonical record — arithmetic and comparison, run against confirmed values rather than model output. Every finding lands on a rung, and the rung decides what happens next.

Warning

noted, does not block

Something worth a second look — a name that differs slightly between two instruments, an unusual figure. Recorded against the deal and shown in review.

Attorney review

blocks until resolved

A person has to decide. Assembly stays shut until the finding is resolved or dismissed, and dismissing it is itself recorded.

Hard stop

refuses outright

A limit the paper cannot cross — a rate that breaches the statutory usury cap once fees are amortized in. The engine will not assemble around it, and the acknowledgement requires a written note.

Assembly has a gate of its own, and it isn't graded: zero unresolved placeholders across the whole set, or there is no package to download. A closing package that is 99% filled is not 99% useful — it is a document with a blank where a number belongs, and it has to be impossible to ship one by accident.

Two loans, one closing

The firm's deals started arriving in pairs — two separate loans to the same borrower, closing the same day, each secured by the other's property. Two files, two packages, and one story the paper on both sides has to tell identically. Handled as two unrelated deals, that is the same facts keyed twice and a cross-reference nobody checks.

Paired at intake, not stitched later

The coordinator knows on the call, so the new-deal form asks: is this loan half of a pair? Yes opens a second name and a second pile of documents, and one submit creates both deals already knowing about each other.

A fact settled once, on both sides

The borrower, the guarantors, the entity papers — the same in both files. Confirm one and it crosses to its sibling's empty row, with the citation it came from. One decision clears both halves of the pair.

Transcribed from both executed sides

Every cross-collateral clause in the layer exists as paper the firm already signed on both loans, so none of it is composed. Each side renders from its own record and is diffed against its own executed package.

Their spreadsheet, in the app

Alongside the drafting, the firm tracked every live closing on a shared spreadsheet — a row per loan, a column for each document they were still waiting to receive. The tool was already filing those documents; it just wasn't adding them up. Now that sheet is a view in the app, and it answers the question the spreadsheet was really for: which papers are we still missing, on which deal.

Received is derived from a document

A slot can be marked ordered or not-applicable, but nothing can be marked received except by a document actually landing. A third party's note that a paper is handled is evidence, never state — and so is a colleague's.

A file outranks a mark

If a slot was marked not-applicable and a document of that kind arrives, the document wins. Paper sitting on disk that the board reports as missing is the exact failure the board exists to prevent.

Late paper changes nothing on its own

The closing statement and the good-standing certificate routinely arrive after the package is drafted. Filing one stores it and schedules nothing — no re-extraction, no value rewritten under a reviewer who already checked it.

The folder files itself

The firm's shared folder syncs in on its own, and each document is sorted into the checklist column it belongs to. When the filename cannot say what something is, the model opens it and reads.

Not every blank is a question

The first real deals came back with dozens of rows waiting on a human, and almost all of them were empty — not unknown, just blank, because the answer was a lender's standing term, the firm's own policy of leaving that line alone, or a clause whose absence already decided it. An attorney was clicking through them two at a time. A review screen that asks about everything trains people to stop reading it.

So the facts that never appear in a bundle — which title agent is on the file, what a given lender's standard terms are — live in registries the firm maintains once, and print in the registry's own spelling. Rows the deal itself answers get resolved by code, each one marked with the reason it was safe to resolve and reopenable by a click. Nothing is hidden — it is signed for at the summary approval like every other value. What reaches a person is the set of questions that genuinely needed one.

The part nobody warns you about

Filling a Word document is its own problem. Word splits visually-contiguous text across many runs — an autocorrect, a spell-check pass, an edit made years ago — so a placeholder like [BORROWER NAME] often isn't a contiguous string anywhere in the file. Naive find-and-replace silently misses those, which is the worst possible failure: a document that looks finished and isn't.

So the filler works across run boundaries while preserving the formatting around each one, and it understands the structure it is writing into — repeating a signature block per guarantor, staying inside the table cell it started in, and choosing between a corporation's vocabulary and an LLC's throughout. Roughly 700 replacements a package, against templates the firm wrote and still owns.

Built with

Next.js 16TypeScriptPythonFastAPIMongoDBClaude OpusClaude Haikupython-docxPyMuPDFVercelRailway