Inspect the exact source clause, with evidence, human review, and third-party approval shown separately.
Synthetic cash-gap diagnostic: $400 in hypothetical extra cash covers all eight cases; one cent less fails. No funding is created.
Synthetic recovery plan: an approved payment shift raises the minimum balance from −$400 to $50, with $500 ending cash.
Separate synthetic example: one fixed resilient schedule preserves at least $49 across all three declared payday dates.
1. Follow source → clause → action → cash flow, and see exactly where a delayed paycheck breaks the nominal plan.

Inspiration

Financial emergencies are often not caused by a lack of information. They are caused by too much information scattered across documents that were never designed to work together.

Someone who loses their job might have a lease, phone contract, device financing agreement, utility bill, loan paperwork, employer benefits, and a payment-extension approval. Each document may contain rules that affect what they should do next, but those rules interact in ways that are hard to reason about.

For example, canceling a $60 phone plan may sound like an obvious way to save money. But if cancellation causes a $480 financed-device balance to become immediately due, it can actually make a short-term cash shortage much worse.

We wanted to build something beyond another financial chatbot or PDF summarizer. Our goal was to create a system that could turn financial agreements into an executable model of someone's situation, calculate the consequences of different actions, and determine which plans actually keep them financially safe.

That became ClauseGraph.

What it does

ClauseGraph is an evidence-backed financial planning engine for moments when cash timing and fine print matter.

Users provide their financial situation and upload documents such as contracts, bills, financing agreements, or approved payment arrangements. ClauseGraph extracts relevant information including:

payment amounts and dates
obligations and deadlines
conditions and eligibility requirements
actions the user may be able to take
dependencies between those actions
consequences triggered by cancellation, deferral, or other changes

Instead of leaving those facts as a list, ClauseGraph connects them into a dependency graph.

It then builds a day-by-day model of the user's cash flow and searches for valid combinations of actions that preserve essential expenses while improving the user's minimum cash balance.

A plan might look like:

Keep phone service, preserve rent and utilities, and move an already-approved $450 payment to a later date.

ClauseGraph can then show exactly why that plan helps:

the original payment date
the new payment date
the clause that permits the change
the effect on the user's daily balance
any future obligations that still remain

The system also supports scenario comparison. Users can ask questions such as:

What happens if my paycheck arrives five days late?
What if my payment extension is denied?
What if I cancel this service?
Which option leaves me with the strongest cash buffer?

Rather than asking a language model to estimate the answer, ClauseGraph recomputes the underlying financial model.

How we built it

ClauseGraph separates language understanding from financial reasoning.

NVIDIA Nemotron handles the unstructured side of the problem. It converts complicated financial documents into typed candidate rules: amounts, dates, conditions, obligations, and possible actions.

Those rules retain links to their original source text so users can inspect the evidence behind a recommendation. Model output does not automatically become financial truth; extracted information goes through validation and review before it can influence a confirmed plan.

Once the information has been structured, the language model steps out of the financial calculation.

The backend uses deterministic code to build the ledger and calculate every balance in integer cents. A dependency graph represents relationships such as:

requires
triggers
excludes
supersedes

We use constraint optimization to search over possible action combinations and execution dates while respecting deadlines, approvals, dependencies, essential services, and other restrictions.

Our optimization goal is roughly:

avoid a negative balance if possible,
maximize the user's minimum cash balance,
minimize fees and unnecessary actions.

This lets ClauseGraph distinguish between changes that actually save money and changes that merely move an obligation to another date.

For example, accelerating a $480 device balance is represented as the same debt moving earlier, not an additional $480 expense. Likewise, delaying a $450 payment improves short-term liquidity but is not reported as $450 of savings.

The application uses:

Next.js + TypeScript for the frontend
FastAPI + Python for the backend
NVIDIA Nemotron for structured contract understanding
OR-Tools CP-SAT for constrained planning
NetworkX for dependency reasoning
PostgreSQL / Tiger Data-compatible storage for versioned financial and scenario data
React Flow for interactive clause and dependency graphs
Recharts for cash-flow visualization
DigitalOcean-compatible deployment and private object storage
ElevenLabs for optional voice-based intake and accessible plan narration

A major design goal was making the entire reasoning chain visible:

source document → extracted rule → dependency → action → financial consequence

What we learned

One of our biggest lessons was that using a stronger language model does not eliminate the need for deterministic systems.

LLMs are extremely useful for understanding messy human language, but they should not be trusted to casually perform the final financial reasoning.

The most reliable architecture was to treat the model almost like a compiler front end. It translates natural-language agreements into a structured intermediate representation. Traditional algorithms then handle arithmetic, constraints, optimization, and simulation.

We also learned how important provenance is.

A recommendation such as "move this payment" is much more useful when the user can immediately answer:

Why is this allowed?

and see the exact document and clause supporting it.

Finally, we learned that financial planning is often less about total income versus total expenses and more about timing.

A person can finish a month with positive cash and still be unable to pay rent halfway through it. Modeling the balance day by day exposed problems that a traditional monthly budget would hide.

Challenges we faced

The hardest challenge was representing real-world contracts without allowing ambiguous model output to silently change someone's financial plan.

Contracts do not naturally look like code. A clause may reference another section, contain exceptions, require third-party approval, or describe a benefit without proving that the user actually qualifies for it.

We therefore had to distinguish between several states that might otherwise get collapsed together:

extracted versus verified
high-confidence versus evidence-backed
eligible versus unknown eligibility
approved versus pending
confirmed versus hypothetical

Another challenge was dealing with interactions between actions.

Optimizing each decision independently is not enough. Canceling one service might affect a financing agreement. Moving one obligation may interact with another deadline. Two actions may both attempt to modify the same payment.

We had to model the financial system as a connected set of constraints rather than a collection of independent recommendations.

We also spent significant effort making the output explainable. It is easy to build a solver that returns an answer; it is harder to show a user exactly why that answer was selected and how every dollar changed.

What's next

The next step for ClauseGraph is stronger plan verification.

Instead of only finding a good plan for one expected future, we want ClauseGraph to answer:

Does this plan still work across every bounded scenario the user says is possible?

For example, if a paycheck could arrive anywhere between September 20 and September 27, ClauseGraph should be able to test the plan across that entire range and either verify that it remains safe or produce a concrete counterexample:

If the paycheck arrives September 26, the balance reaches -$140 on September 24.

From there, the system can search for a more robust plan that survives all of the modeled cases.

Ultimately, we see ClauseGraph as a bridge between three areas that normally remain separate: AI document understanding, formal representations of contracts, and mathematical financial optimization.

Instead of asking AI to simply tell someone what their contracts mean, we want to turn those contracts into a system that can actually reason about what happens next.