Debt Term-Sheet Sizing & Loan Terms

Architecture

Key specifications

What it does for you

A borrower runs several projects through legal at once, and each period a new dated workbook is produced from one template as the deals move toward close. It lays the deals out side by side -- max loan amount, max loan-to-cost, the index-plus-spread rate build-up over a floor, the letter-of-credit and overdraft facilities, the origination / commitment / unused / admin fees, the term and its extension options, the recourse -- and the question is narrow and entirely arithmetic: do the numbers on the term sheet reconcile to the terms the term sheet states? A term sheet is a one-page summary re-keyed from a longer credit memo, and three failures hide inside it, none of which look wrong in a tidy grid. The loan is sized over the advance rate: the stated max loan creeps a cent or a million above max loan-to-cost times the cost basis, and the over-advance rides in the workbook while the cap sits in a cell nobody recomputed. A build-up figure is re-keyed rather than re-derived: the all-in rate typed as index plus spread when the floor actually governs, or a fee struck on the commitment where it should have been struck on the undrawn balance, so the amount is wrong against a rate that is right. And the rollup drifts from the deals: the total commitment, the total fees or the count of active deals is maintained beside the side-by-side rather than footed from it, and it drifts the first time a deal moves and nobody re-adds the column. None of these are judgment calls. They are equalities and comparisons -- a loan against a recomputed cap with exact <=, an all-in rate against max(index + spread, floor), a fee against the truncating basis-point product of its rate and its correct base, a stated total against its re-derivation -- which a deterministic control settles better than a template inherited by whoever maintains the workbook this period.

The seeded demo runs every control over every sizing file⁷. The CLI generates twenty-three fictional sizing files -- one clean baseline and one carrying each of the twenty-two planted defects -- then runs all twenty-one controls over each. The clean file returns PASS with no flags; every defect file returns REVIEW or FAIL and names the control it tripped along with the reason that control exists.

The advance-rate cap is met at the cent⁸. Deal DL-203 is seeded sized exactly at its advance-rate cap, so the cap is proved to be met rather than merely cleared. One defect file re-sizes DL-204 to one cent above max loan-to-cost times its cost basis and re-derives the rollup, so the only control that sees it is size_ltc_not_exceeded -- the over-advance is one cent, the finding is unambiguous, and nothing else in the file moves.

The floor is exercised, not assumed⁹. Deal DL-202's build-up lands below its floor -- index plus spread is 600 basis points against a 700 basis-point floor -- so the max in the all-in rate genuinely governs on the clean baseline. A defect file then contradicts DL-201's stated all-in rate without touching its build-up, and rate_all_in_recomputes rebuilds the rate from index, spread and floor and fails, proving the rate is recomputed rather than read back.

Functional block diagram

Instruction set

Benchmarks

Control characteristics

• Read-only: sizing files are parsed and never written back, so the engine cannot introduce the break it reports.
• The engine is the sizing tie-out, not the funding decision; it moves no money and advances no draw against a budget line.
• Integer cents and integer basis points throughout, compared with exact ==; there is no tolerance band, and a figure a cent or a basis point off the re-derivation is reported as a break.
• The advance-rate cap is recomputed with truncating basis-point math and compared with exact <=, so a loan one cent above the cap fails and a loan sized exactly at the cap passes.
• A figure that should be integer cents or integer basis points but is not produces an AMOUNT_INVALID finding contained to the one row it was read on, rather than being coerced into the number the engine is meant to audit.
• One term-sheet kernel: the controls and the generator share the re-derivation in sizing_engine.terms, so a determination cannot disagree with the data that produced it.
• Every expiry test is measured against the as_of pricing date carried in the file, never the system clock, so the same file returns the same verdict on any day.
• Deterministic and byte-stable: same inputs produce the same findings in the same order, with no timestamps or absolute paths in any output.
• Absent evidence is never a passing control; a missing artifact fails completeness rather than letting the controls that read it pass unread.

Operating limits

• The engine never sizes a loan, negotiates a term, advances a draw, moves a dollar, or writes to a source artifact. It reads the sizing file and stops.¹⁴
• It reads the seven artifacts the term-sheet workbook emits. It does not connect to a lender, a rate provider, a loan servicing system or a general ledger, and whether a draw is actually funded against a budget line is a separate engine's scope.¹⁵
• It proves the term sheet's arithmetic reconciles to the terms the term sheet states -- not that those terms are commercially appropriate, that credit approved them, or that the deal should close. That judgment is a credit officer's and a reviewer's.¹⁶
• It takes the index, spread, floor, cost basis and fee rates on file at face value and re-derives from them; it does not source or verify a reference rate, and every index name in the corpus is invented rather than a published benchmark.¹⁷
• It confirms the register, the schedules and the rollup foot and tie, not that a deal, a project or a cost basis exists. All shipped data is fictional and the workbook period is set in a fictional future.¹⁸

See it run

Integration

Distribution: public repository, MIT license.