Exception Keeper

Finds the spreadsheet cells that break the pattern, then asks NVIDIA Nemotron to tell a mistake from a documented exception, and drops any verdict it cannot back with a quote from the workbook.

Comment

The problem

A spreadsheet review usually goes wrong in one of two directions. Flag every cell that differs from its neighbours, and the real error gets lost among manual overrides, waived fees and agreed discounts. Trust a model to read the sheet and decide, and you get confident explanations that nobody can check against the workbook.

This matters to anyone who signs off a workbook they did not build: a club treasurer checking member fees, a small business owner reviewing a budget, an analyst inheriting a model. They need the few cells worth a second look, and they need to know which odd cells were changed on purpose.

Exception Keeper keeps the two jobs apart. Code finds and measures the unusual cells. NVIDIA Nemotron decides what each one means, and every decision has to point back at the workbook: a quote found at the cell it cites, or, for a formula that reads an empty input, that empty cell.

What it does

Upload an .xlsx file (up to 1 MB, nothing is stored) or open one of three sample workbooks. Exception Keeper returns a short list of findings, each with:

  • a verdict: error, documented exception, ask (a person should decide) or assumption to verify;
  • the engine's evidence: the formula, the majority pattern of its neighbours, the saved value and, where it can be computed, the impact;
  • the model's reason, with quotes from the workbook and the cell each quote comes from;
  • a suggested fix formula when one is supported, and a question to ask when it is not;
  • a cell map of each sheet with the findings marked, and a one-line summary with the single question worth asking first.

Findings can be copied as Markdown or downloaded as CSV.

How it works

  1. A deterministic engine finds candidates. Five detectors look for a formula that breaks its row or column pattern, a typed number inside a run of formulas, a total whose range skips cells, a formula that reads an empty input, and labelled constants that act as assumptions. The engine also computes the impact itself (for example, the signed sum of the saved values that a total leaves out). The model never computes numbers.
  2. Nemotron 3 Nano outlines the workbook: which sheets hold data, which hold rules, where the notes are.
  3. Nemotron 3 Super judges each candidate (up to 12 per workbook). It receives the candidate, its neighbours, the row note and the cell comment. Read-only tools to read a range, find notes, look up a rule or list cells with the same pattern are offered on every judgment; in the recorded runs Super answered without calling them.
  4. Every answer is grounded by code. A quoted piece of evidence must be found at the cell it cites. An "intended exception" must quote a note, a comment or a rule. A suggested fix must be a valid formula that only references existing sheets. If any check fails, the verdict is downgraded to ask, with the reason shown.
  5. Nemotron 3 Ultra orders the findings, names conflicts between them and writes the headline and the one question for the user.

All three models are called through the Nebius Token Factory API, with structured JSON output. The live API runs as a serverless function; a shared ledger caps spending per session, per day and in total, and when a cap is reached the app points to the recorded sample results instead.

Recorded results

The three sample workbooks are fictional and come with planted labels. The same judging code was run several times on each (live Nemotron calls on 2026-10-24):

Sample Planted cells Correct per run
club_membership_fees 5 4, 3, 4, 4, 4, 4, 3, 4, 4
small_business_budget 5 3, 3, 4, 4, 3, 3, 3, 1, 4
event_budget 2 1, 1, 1, 1, 1, 2

The sample results shown in the app are selected runs (the best run of each workbook), and the README lists every run. Across all runs, 33 of 102 verdicts on planted cells were wrong: 17 of those were "ask", which leaves the cell to a person, and 16 were confident mistakes, most often an ambiguous cell judged an error. A sample run costs between $0.002 and $0.016.

Challenges

  • Evidence addresses. Nemotron sometimes cited E5 instead of Event!E5. The grounding check now reads a bare address as the candidate's own sheet, as a spreadsheet formula would, and still requires the quote to be at that cell.
  • Reasoning inside the token budget. Super and Ultra report reasoning tokens separately, and the summary call once spent its whole 1,500-token budget on reasoning and returned no answer. Token limits were raised per stage.
  • Quotes in strict JSON mode. With reasoning on and a strict JSON schema, quoted formulas were cut at the first double quote (=IF(B14= for =IF(B14="Student",...)). The shortened quote still matches the start of the cell's formula, so the check passes, but it looks truncated on screen. We kept the strict schema because the looser JSON mode broke the answer format or ran out of tokens more often (7 of 12 correct against 9 of 12).
  • Variance. Verdicts differ between runs even though every call uses temperature 0. The engine's evidence and impact are deterministic; the verdicts are not, which is why every verdict carries its quotes and why the app prefers "ask" over guessing.

What's next

  • Corrected .xlsx export with the suggested fixes applied on a copy.
  • A larger labelled set of real-world spreadsheet patterns to measure verdict quality beyond three samples.
  • Letting the user answer the "ask" items and re-running the summary with those answers.

Built With

Share this project:

Updates

Submission history