Dhanesh Pottekula’s invoice-processing backend compares supplier invoices with purchase orders. Ordinary code handles the checks and arithmetic; Jev helps match invoice lines when wording makes the corresponding order line uncertain.
Keep the decision bounded
- The matcher asks an independent yes/no question for each uncertain invoice line and eligible order line, with invoice, order and code-matching context.
- By default, scores above 0.80 select a line; scores at or below 0.50 reject it. A score between those bounds leaves the invoice line unmatched for review.
- Missing, malformed, unavailable or timed-out model responses also leave uncertain lines unmatched. Code retains responsibility for quantities, balances and the final outcome.
- Without a TypeSafe key, recorded answers can replay for matching requests. The repository’s trigger tests use a fake model; they test routing, not Jev’s real-world accuracy.
What the boundaries leave open
The model request omits bank details and tax IDs, but it still includes supplier, invoice and order information. The README says the demo has no authentication and warns that multiple backend workers do not share locks. It is not ready to expose as a production payment system without additional controls.
The project’s thresholds are implementation choices, not evidence of calibrated accuracy. A typed answer can still match the wrong line. Verification: inspected the README, matching implementation and tests; neither the application nor live Jev was run, and this was not a security audit.