Headroom
Cash-flow planning & AI benchmarking
- Next.js
- React
- TypeScript
Headroom helps small businesses answer a practical question: can we take on this job and still cover payroll, suppliers and other bills? It brings together company books, reviewed contract terms and supporting evidence to model when money comes in and goes out. When a job creates a cash shortfall, it shows why and finds the smallest supported payment-timing change within the allowed options, such as moving part of the final payment into an upfront deposit without changing the contract total. AI helps interpret evidence; a deterministic engine calculates the cash scenarios, and proposed terms remain subject to owner review. The demo uses synthetic books and constructed scenarios.
My contribution
I worked on the benchmarking for Headroom.
A closer look
- Trace cash shortfalls to dated commitments and payment terms across collection scenarios.
- Explore deposit and installment adjustments while preserving the total contract value.
- Flag missing or conflicting evidence instead of treating unknown information as cash in the bank.
- Benchmark evidence-checking changes against a fixed evaluator, comparing correctness, model requests, tokens and request time.
Contract extraction and evidence
The team fine-tuned Qwen through Veri to propose structured payment rules, including amount references, AND/OR conditions and invoice timing. Schema, reference and business-rule checks precede owner review. TypeSafe's Jev evaluates whether supporting evidence satisfies a prerequisite, leaves it unknown or conflicts with it.
Deterministic cash-flow engine
A TypeScript engine models dated obligations using integer cents, conservative ordering for same-day events and bounded joint scenarios. Invoice eligibility, invoice issuance, payment due dates and bank settlement are separate events. Proposed timing adjustments preserve the contract total and are checked against every declared scenario.
Benchmarking approach
The MetaHarness uses Claude to propose bounded changes to evidence selection, batching and dependency-aware caching. A separate fixed evaluator checks correctness and useful coverage before accepting a candidate. Candidates cannot change the expected answers, financial rules or pass criteria. Recorded experiments compare model requests, token usage and request time alongside answer quality.
Quality gates and limitations
The extraction evaluation compares models on the same untouched synthetic clauses, prompts, schema and decoding settings. The V5 candidate improved some measures but failed the fixed promotion gate, so the cash demo retains reviewed inputs. The public app replays recorded provider experiments; visitors do not launch training jobs or spend model credits.
Recorded benchmark results
The recorded Jev 1.14 component test covered seven simulated updates and 21 scored evidence checks.
| Metric | Baseline | Optimized |
|---|---|---|
| Evidence checks scored correct | 20 / 21 | 20 / 21 |
| Model requests | 18 | 6 |
| Input tokens | 12,666 | 3,998 |
| Summed model-request time | 2,771 ms | 832 ms |
One error remained in each run. These are recorded component results, not end-to-end app latency, customer savings or general model accuracy.