Home › Use Cases › Does the monthly meal claim agree with the daily count sheets it was keyed from?
Use caseUC0296
🧪 Use-case kit · runnable

Does the monthly meal claim agree with the daily count sheets it was keyed from?

A small, forkable project that does one job end to end. Run twice for real over the same set, and every figure on these pages captured from those runs.

The business caseThe problem this solves

A school food-service site counts reimbursable meals at the point of service, every serving day, by eligibility category. At the end of the month a clerk keys those sheets into a monthly reimbursement claim: six lines, breakfast and lunch by free, reduced-price and paid. Nobody puts the two back together. The claim is submitted, and the box of sheets goes in a drawer against the possibility of a review. Re-adding fifteen to twenty count sheets by hand, six columns at a time, to find out whether a monthly claim line is supported — and reading each sheet's own correction notes while doing it.

Audience

The claim reviewer at a sponsor or a business office who has the box and the claim in front of them and has to decide, line by line, whether the second is supported by the first — and who needs to know which serving day to pull, not just that a number is out. Every number on these pages came from one real run of this code, not from a vendor page.

The inputThe actual claim months

The corpus is 62 claim months, 0.61 MB (json 4 · jsonl 1 · md 2 · txt 62). Because the messiness is the product. A monthly meal claim is six integers and the sheets behind it are columns, so the arithmetic half of this job is free — and the generator's whole purpose is the other half: a sheet whose own note corrects its printed figure, a note saying a category was rung on the wrong key, a day whose second meal service is on a continuation sheet with no date of its own, and a serving day the claim pays for that has no sheet at all. 50 of the 62 claim months carry exactly one of those shapes and 12 carry none. The two floors between them cover the corpus and neither gets past 68 pct, which is the measurement this corpus exists to make.

The corpus

  • The 62 claim monthsgenerated from a fixed seed, so no real record, person or institution appears in it.
  • Where each came fromwritten for this kit rather than collected — the corpus is generated in the kit's own repository, so there is no third-party data in it.

Swap this folder for your own material and the kit is pointed at your claim months. That is the whole change — there is no database to migrate.

One claim month, as the model receives itMCR-0001.txt · 1 of 62
==============================================================================
MONTHLY MEAL CLAIM RECONCILIATION PACKET                    MCR-0001
Sponsor: Cedar Hollow School District (invented)
Site: Site 03 - Harbor Ridge Elementary
Claim month: 2026-02        Days of operation: 18        Procedure: MCR-2026
==============================================================================

CLAIM AS SUBMITTED
  LINE                 MEAL TYPE   CATEGORY   MEALS CLAIMED   DAYS  ELIGIBLE ENROLLMENT
  BREAKFAST-FREE       breakfast   free                1670     18                  150
  BREAKFAST-REDUCED    breakfast   reduced              330     18                   40
  BREAKFAST-PAID       breakfast   paid                 117     18                   47
  LUNCH-FREE           lunch       free                2511     18                  150
  LUNCH-REDUCED        lunch       reduced              571     18                   40
  LUNCH-PAID           lunch       paid                 367     18                   47

DAILY TALLY AS KEYED BY THE SPONSOR
  The site clerk keyed these from the sheets. Each claim line above is a column total.
  DATE         BKFST-FREE BKFST-RED BKFST-PAID  LUNCH-FREE LUNCH-RED LUNCH-PAID
  2026-02-02           93        17          6         141        33         19
  2026-02-03           88        18          7         128        31         19
  2026-02-04           84        18          6         126        28         19
  2026-02-05           97        21          7         154        35         22
  2026-02-06           99        19          7         156        34         23
  2026-02-09          102        20          7         155        32         22
  2026-02-10           92        20          6         139        33         19

Abridged — the file continues.

The outcomeWhat a good result looks like

Six rows a reviewer can work: the count recomputed from the sheets, the difference in meals, one verdict, and the serving days whose sheet disagrees with the clerk's keyed tally, each with the sheet row quoted verbatim.

And when it cannot

A line reported MATCHES with one of its two disagreeing serving days named and the other not. That is the single miss in r001 — MCR-0060, LUNCH-FREE — and it is not a wrong verdict or a wrong count: both are exactly right. It is a reviewer who is told the month agrees and is not told that two days behind it do not.

Where it fitsWhat did work

Every line below is a measured result from this kit's own runs, with the figure that supports it. The headline above is not softened by any of them.

  • Your count sheets are one fixed layout and nobody ever writes on them — the free rules floor alone
    it is exactly right on all 12 clean claim months and all 24 where a number is simply wrong, for $0.00. On that shape the column parser is the product.
  • Your sheets carry corrections, re-allocations and continuation pages in prose — the paid call
    that is the entire margin: 20 of the 62 claim months, where the free floor scores 0 and the paid call scores 20 on both runs.
  • You want to know which serving day to pull, not just that a line is out — either arm, and read the cited days rather than the verdict
    the free floor names 30 of 30 cited days and invents 21; the paid call names 29 of 30 and invents 0 on r001, and 30 of 30 with 0 invented on r002.

And where nothing here is good enough:

  • Your claim carries monthly totals and no keyed daily tally — neither arm as shipped
    cites and the whole netting failure mode become unanswerable by anybody, because there is no per-day claim for a sheet to disagree with. The count and the verdict still work; the field that carries the finding does not.

At a glanceHow the whole thing runs

98–100%packet all correct pct · 2 runs, no ordering
78,367 msp50, end to end
$36.60per 1,000 claim months · Gemini 3 Flash

Run twice over the same set, for real, the last on 2026-09-03. Every figure on these pages was captured from those runs — nothing is written from intent.

14 steps, grouped by the question that sends you to them rather than by build order. Each tile carries the one figure that step is about, and opens the page behind it.

Should you use this?What you bring, where it stops, and when not to use it

Before you commit an afternoon to this, these are the answers that decide it. Each one is rendered from the record it lives in — and links the page that holds it in full.

What do I have to bring?Replace data/corpus/ with your own claim months in the same three panels — the claim as submitted, the clerk's keyed daily tally, and the sheets — and data/sites.json with one register row per claim: the operating calendar, the eligible enrollment by category and the six line totals as filed. Every number this kit publishes is measured on a generated corpus with one fixed sheet layout, one messiness shape per claim month, and messiness announced in one of three sentence templates. Corpus lens →
When is this the wrong choice?Avoid: Believing 42 of 62 transfers to a box of sheets people write on. That is the case against the best-fitting scenario (“Your count sheets are one fixed layout and nobody ever writes on them”). 4 scenarios scored in all, each with its own. Eval lens →
Where does it stop working?A sheet in a layout the strict parser was not written against — a scan, a photograph, a spreadsheet export or a second pre-printed form. Every sheet here is one fixed layout, which is the single biggest thing flattering the free floor. 7 recorded failure modes, each from a run rather than a guess. Corpus lens →
What was never verified?A third scored run, or a second tier. Two identical passes were bought and both are published as runs; any margin under two claim months should be read as unresolved. 8 items this kit says it could not check. Eval lens →
Can I run this on a model I control?Yes — any OpenAI-compatible endpoint, including one on your own hardware. The shipped adapter takes its host from BASE_URL and its model from MODEL, so nothing in src/ changes. The published figures come from 1 model on the fast tier, one provider, one key. Prompt lens →
And if it fits — what do I stand up?7 artifacts with a stated home and a stated egress, and 3 decisions each with what you provision past its ceiling — plus what was not measured. That is the next page, not this one. step 14 — Run it in your environment →

Not asked of this kit — 2 questions: clone (a fresh clone of this kit runs with nothing fetched); judge (nothing here is graded by a model).

Last verified 2026-09-03 — r001-meal-claim-recon. Every figure on these pages was captured from that run.

Run itHow this reaches your data

Every result on this page was produced by pure code over checked-in files, with no API key — which is why you can read the numbers before anyone spends anything.

Run this on your own data

  • The pipeline, its eval harness and the runs behind every numberdeployed inside your environment, on your own model endpoints, against your own documents.
  • The corpus above is the shape, not the limitit is a folder swap, and there is no database to migrate.

Talk to us →

Checked before this shipped — A clean checkout with no key configured rebuilds all 62 packets byte-identically from the seed, re-derives the whole answer key independently, scores both free floors and runs the stub end to end in 1.06 seconds, and the local board renders every panel and replays the committed scored run for $0.00. Measured on the capture machine on 2026-09-03. requirements.txt names no package.

A living map of modern AI — kept current every morning