The full repository is private. These are its outputs: the SFR/DSCR origination-intake tool running on a real application, the product spec it was built from, and the standard operating procedure that runs it. This is the day-one deliverable the role describes, in the client's own asset class.
Standard-library Python, no dependencies. The process exit code mirrors the credit decision (0 on PASS, 1 on FAIL), so it composes inside a larger origination pipeline or a CI gate. Below is the real output from python dscr_intake.py sample_input.json.
$ python dscr_intake.py sample_input.json ==================================================================== ORIGINATION INTAKE, DSCR UNDERWRITE ==================================================================== Loan ID SFR-DSCR-2026-0142 Product DSCR rental (SFR bridge-to-rent with rehab) Total project cost $220,000 INCOME Gross annual rent $28,200 Vacancy loss ($1,410) Effective gross income $26,790 Operating expense ($4,920) Net operating income $21,870 DEBT SERVICE COVERAGE Annual debt service $17,580 DSCR 1.244 Minimum DSCR 1.20 DSCR test PASS POLICY CHECKS LTV to ARV 0.6610 (max 0.7500) PASS Loan to cost 0.8864 (max 0.9000) PASS DECISION PASS ==================================================================== CONSTRUCTION DRAW SCHEDULE ==================================================================== Rehab budget $48,000 Construction rate 8.25% Interest treatment capitalized Mo Draw Amount Interest Balance ------------------------------------------------------------------- 1 Draw 1, demo and rough-in $14,400 $0 $14,400 2 Draw 2, mechanicals $12,000 $99 $26,499 3 Draw 3, finishes $14,400 $182 $41,081 4 Draw 4, punch and CO $7,200 $282 $48,564 ------------------------------------------------------------------- Capitalized interest $564 Fully funded balance $48,564 ====================================================================
How to read it: rent of $2,350 per month against $195k of debt at 8.25 percent on a 30-year amortization clears the 1.20 minimum DSCR at 1.244. The loan sits at 66.1 percent of ARV and 88.6 percent of total cost, inside both policy caps. The rehab holdback funds across four monthly draws, and the $564 of construction interest is capitalized into a fully funded balance of $48,564 rather than billed during the rehab. Raise the requested loan above 90 percent of cost, or cut the rent, and the checks flip to FAIL and the exit code returns 1.
Deliberately small, so a reviewer reads it in one sitting and sees the shape of a production spec: problem, goal, non-goals, users, inputs, outputs, functional requirements, policy thresholds, and acceptance criteria.
An origination desk takes SFR/DSCR rental-loan applications one at a time, each with a property, a rent assumption, a requested loan, and a rehab plan. Today an analyst keys the inputs into a spreadsheet, recomputes DSCR and leverage by hand, and builds the draw schedule from a template. It is slow, the policy thresholds live in the analyst's head, and the draw-interest math drifts between deals. The result is inconsistent underwrites and a screen that does not scale past the analyst.
One tool that takes a single application as structured input and returns a consistent, policy-checked underwrite plus a draw schedule, every time, with the same thresholds. It turns one analyst's judgment into a repeatable system the desk can run at volume and a dashboard can read. It is not a pricing engine, not a valuation model, not a system of record, and it does no model training or inference infrastructure.
One application as JSON: borrower; property (as-is value, ARV, purchase price); rent (gross monthly rent, vacancy, operating expenses); loan (amount, note rate, amortization, interest-only flag, term, points); rehab (budget and draws by month and percent); and an underwriting policy block (minimum DSCR, max LTV-to-ARV, max LTC, construction rate, capitalize-interest flag).
--json mode for machine consumers.Defaults in the sample: minimum DSCR 1.20, max LTV-to-ARV 0.75, max loan-to-cost 0.90, construction interest at the note rate capitalized during rehab. The thresholds live in the input, not the code, so the credit lead changes policy without a code change. Acceptance: the sample returns PASS at DSCR 1.244 / LTV-to-ARV 0.661 / LTC 0.886 with exit 0; raising the loan above 90 percent of cost flips the decision to FAIL with exit 1; the capitalized interest is $564 and the fully funded balance $48,564; --json emits a structured object a dashboard reads without scraping text.
The standard operating procedure that pairs with the spec. Audience: an origination analyst on the desk.
python dscr_intake.py SFR-DSCR-2026-0142.json. Read the DECISION line, the DSCR against the minimum, and both policy checks.--json to the deal file. In a script, branch on the exit code rather than parsing the text.Confirm the policy block matches the current thresholds, the draw percentages sum to 100 percent, and the report's total project cost equals purchase price plus rehab. Threshold changes come from the credit lead and are versioned in the policy record. Tool changes follow the SDLC: scope, requirement, test against the acceptance criteria, deploy, and note the change. Re-run the sample after any change and confirm it still meets the acceptance criteria before using the new version on live deals.