RealityCheck

RealityCheck reads a credit agreement, extracts the assumptions it was written on, and uses Nemotron to flag when new reports break them, so lenders amend covenants before a default, not after.

Comment

Inspiration

Having dreams to work in finance, private credit definitely is an attractive option for me. I noticed how covenants and compliances were being monitored, but not on the basis of its underlying thesis (conditions) being subject to changes. The initial idea was to use less lagging indicators, but more leading indicators to determine when the borrowers may be lacking the capabilities to repay their obligations.

What it does

RealityCheck is a monitoring tool for private-credit analysts that keeps a loan's original underwriting assumptions attached to the loan and flags when new information means the covenant package may no longer fit.

The workflow is: upload origination documents → Nemotron builds a register of the assumptions the loan rests on, each with a quoted source and linked covenants → a new dated report arrives → Nemotron attributes it to those assumptions and covenant duties, and code withholds any finding whose quotation does not verify → Nemotron drafts a candidate package with and without the new evidence, and only the difference counts as drift → the analyst decides. A detection never changes terms, adopting an amendment is a separate step with full history preserved, and the system keeps an exposed assumption, a missed contractual duty and a formal default as three distinct outcomes

How we built it

RealityCheck is a single Python process that serves static HTML pages, stores state in SQLite, and calls NVIDIA-hosted Nemotron models. It has no web framework, no frontend build step and no cloud services.

  • Backend: Python 3 (developed on 3.14), using the standard library only. app.py is an http.server-based server that handles the pages and the JSON API. Run it with python app.py 8013.
  • Frontend: Four hand-written HTML files: index.html, b01.html, overview.html and benchmark.html. They use inline CSS and vanilla JavaScript with no external scripts or stylesheets. The pages poll the API for upload and analysis status.
  • Storage: SQLite holds companies, package versions, events and the work queue. JSON files hold seeds, fixtures, the lender guidelines (lender_guidelines.json) and every saved model response with its provenance.
  • Processing: A background worker thread in b01.py takes queued uploads and reports, calls Nemotron and saves the result. The main modules are:
    • uploads.py handles company onboarding.
    • parse.py extracts text from documents.
    • b01_model.py builds the assumption register and the event attributions.
    • attribution.py does validation and citation checks.
    • drift.py runs the candidate-package comparison.
  • Models: Nemotron 3 Super 120B does the reasoning and Nemotron Parse 2.0 does OCR on scanned pages. Both are called with urllib through the hosted NVIDIA NIM endpoint.
  • Optional dependencies: pymupdf for reading PDFs and Pillow for downscaling images. Both are imported lazily and only used by uploads.
  • Testing and evaluation: unittest suites run against temporary databases with a stubbed model, so they never touch the network. benchmark_blind.py and benchmark_evaluate.py run the hash-locked SEC replay, and real-credit-cases/ holds the fetch-and-build scripts for the filings. ## Challenges we ran into One of my biggest challenges was turning complex financial documents into a reliable, intuitive demo. On the technical side, I faced API timeouts, document-parsing issues, and upload limits that couldn’t accommodate full annual reports. At the same time, I needed to explain a specialized financial problem to people unfamiliar with lending covenants. I improved document handling and error recovery while refining the interface and pitch around a clear sequence: the original assumption, new evidence, the affected provision, and the analyst’s decision. ## Accomplishments that we're proud of It is the fact that I pulled this off alone. I was not able to meet someone that shared the same vision. I am from a non technical background, and the projects I have are at a surface level. I won't say that this one is an exception, but the fact that I created something in such a short span of time is what I am proud of. ## What we learned There are different parts to making an idea come to reality. Coding is not the only part, nor is envisioning. Having to do those alone was a valuable, but an excruciating experience. I will most definitely be looking for a team next time. There is great value in being able to communicate your ideas to someone. ## What's next for RealityCheck Next, I want to test RealityCheck with credit analysts on real review workflows. My priority is improving how it weighs conflicting evidence and reducing unnecessary alerts, while making document ingestion more reliable. I also want to make proposed covenant changes easier to inspect, compare, and approve. Longer term, I see applications in private equity, venture capital, and supply contracts—anywhere a decision depends on assumptions that can change. I’d start by proving its value in private credit, then adapt the framework to those other fields.

Built With

Share this project:

Updates

Submission history