The business caseThe problem this solves
A merchant is approved on one pricing schedule and then SET UP on another. The approval is written by underwriting; the boarding is keyed by a different person into a different system, from a different document, often days later. A tier is picked from the wrong dropdown, an interchange-plus markup is entered as a flat rate because that screen was already open, a fee the approval waived is left at its default, a volume discount never gets boarded at all. Nobody finds out until the merchant reads their first statement — and by then the money has moved and the conversation is a refund, not a correction. the line-by-line read a boarding analyst does against the approval before a new merchant's first statement, on the accounts there is time for
Audience
The boarding analyst who works the exception queue, and the operations lead deciding whether a model call per merchant is worth buying over the comparison they could write in code. On this corpus the honest answer is no, and the report says so in its first sentence. Every number on these pages came from one real run of this code, not from a vendor page.
The inputThe actual merchant boarding packets
The corpus is 40 merchant boarding packets, 0.09 MB (json 3 · jsonl 1 · md 1 · txt 40). ⚠︎ EVERY BYTE OF IT IS INVENTED, AND THAT IS STATED BEFORE ANY NUMBER. NBPS-2026 is a fictional merchant pricing catalogue written for this kit. It is not a card-network rule, not an interchange table and not any real processor's fee schedule; the processor, every merchant, every MID and every approval reference is generated. It was generated rather than found because the measurement needs an answer key at the element level — and, more importantly, because THE CORPUS IS THE EXPERIMENT. 20 packets state the approval as a STRUCTURED RECORD with the element key printed, and 20 state the same pricing as APPROVAL PROSE, with the same exception rates from the same generator. That is the only way to ask the question this kit exists for: where does a field diff stop being enough? The prose half is shaped against the shortcut — values spelled in words with no digit, a fee in cents against a record keyed in dollars, waivers as sentences that each carry a number which is not the fee, and a volume threshold sitting beside the discount as the larger and more eye-catching of two numbers. 39 of the 293 boarded lines are DISTRACTORS the approval never mentions, so 'every boarded line answers an approved element' is wrong by construction.
The corpus
- The 40 merchant boarding packetsgenerated 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 merchant boarding packets. That is the whole change — there is no database to migrate.
MERCHANT BOARDING RECONCILIATION PACKET — PKT-0001
Processor: Northbay Payment Systems (fictional) · pricing catalogue NBPS-2026 (fictional)
Merchant: Cedar Lane Provisions · MID 747621801
Approval reference AP-34215 · effective 2026-01-25 · approval format NARRATIVE
PART A — PRICING AS APPROVED (underwriting approval record)
Northbay Payment Systems has approved Cedar Lane Provisions (MID 747621801) under approval reference AP-34215, effective 2026-01-25. The account is priced on an interchange-plus basis. The merchant is charged a markup of thirty basis points over interchange. Boarding is to include a per-authorisation fee of fifteen cents. The schedule provides for a PCI programme fee of USD 9.95 per month. Boarding is to include an early termination fee of USD 195.00. The schedule provides for a gateway access fee of USD 15.00 per month. The merchant is charged a monthly service fee of USD 19.95. Boarding is to include a monthly statement fee of USD 5.95. Funds settle on a two (2) business day cycle. This approval supersedes any earlier quotation and is the pricing the account is to be boarded on.
PART B — PRICING AS BOARDED (processing system extract, MID 747621801)
CODE BASIS VALUE AS KEYED
STMT.FEE.MO USD_PER_MONTH 5.95
SVC.FEE.MO USD_PER_MONTH 19.96
GWY.FEE.MO USD_PER_MONTH 15.00
AUTH.FEE.USD USD_PER_AUTH 0.150
PCI.PROG.MO USD_PER_MONTH 99.50
DISC.MODEL MODEL INTERCHANGE_PLUS
ETF.USD USD_PER_CONTRACT 195.01
SETUP NOTES: (none recorded)
PART C — ELEMENTS TO RECONCILE (every element PART A approves)Abridged — the file continues.
The outcomeWhat a good result looks like
Every approved pricing element gets one of five verdicts and, where the boarded record carries a line for it, the line and the approval's own words printed side by side — so an analyst reads a difference rather than a claim about one.
And when it cannot
It over-flags rather than under-flags, but not by much: 5 of its 26 errors raise an exception that is not there and 7 wave a real exception through as MATCH. Its single worst confusion is between MISSING and MODEL_MISMATCH — 7 elements boarded on the WRONG BASIS that it reported as simply absent, and 2 absent elements it reported as boarded on the wrong basis. Both still reach the analyst as exceptions; the label is wrong, not the alarm.
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 approval records are STRUCTURED — a table, a form, an export — the schema-aware diff in evals/baseline.py, on its own
it scores 160 of 160 on that half of this corpus, against the paid call's 150, for $0.00 and no network. A field-by-field numeric comparison is what code is for - you only need a QUEUE — which elements need working, not what is wrong with them — either arm; take the free one
on the binary question the two are 308 and 314 of 320, p = 0.237885. This corpus cannot separate them - your approvals are PROSE and your catalogue is small and stable — the anchor-lexicon extractor in evals/baseline.py, then measure
on this corpus it reaches 154 of 160 and the paid call reaches 144, p = 0.052479 — a null result. A lexicon of twelve anchors is a morning's work and it is free - your approvals are prose and your catalogue is large, or changes often — measure the call before deciding, on your own labelled packets
an anchor lexicon needs one line per element and someone to maintain it; a call needs neither. This kit did not measure that trade — its catalogue is twelve fixed elements
At a glanceHow the whole thing runs
Run once, for real, on 2026-09-11. Every figure on these pages was captured from that run — 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/catalog.json with your own pricing catalogue — element keys, your processing system's boarded codes, the basis each element is priced on and the alternate basis a mis-boarding would use — and drop your boarding packets into data/corpus/ in the three-part shape tools/build_corpus.py emits. THE MEASURED RESULT DOES NOT TRAVEL WITH YOUR CORPUS, AND ON THIS KIT THAT CUTS BOTH WAYS. Corpus lens → |
| When is this the wrong choice? | Avoid: Buying a call per merchant for this. On this corpus it is measurably worse. That is the case against the best-fitting scenario (“your approval records are STRUCTURED — a table, a form, an export”). 4 scenarios scored in all, each with its own. Eval lens → |
| Where does it stop working? | an approval that prices an element BY REFERENCE to a rate sheet not in the packet — the correct answer is then 'cannot be determined from this packet' and the schema has no verdict for it. 5 recorded failure modes, each from a run rather than a guess. Corpus lens → |
| What was never verified? | whether the paid call would beat the floor on a prose corpus that is NOT built from twelve sentence templates. This is the biggest open question on the page and the corpus cannot answer it. 5 items this kit says it could not check. Eval lens → |
| Can I run this on a model I control? | The shipped adapter is the runtime provider is not named on this page; the Prompt lens states what swapping it costs. The published figures come from 1 model on the fast tier. Prompt lens → |
| And if it fits — what do I stand up? | 5 artifacts with a stated home and a stated egress, and 4 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-11 — r001-boarded-pricing. 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.
Checked before this shipped — A clean checkout with no key configured renders the whole board — the corpus, the answer key, the committed run and all four free floors — and scores every floor offline in pure Python. Shot as kits/UC0390-boarded-pricing/docs/shots/boarded-pricing-empty.png against a server started with API_KEY blanked in its own environment, not against a banner drawn to look like one.
