Sort an asset manager's position breaks for supervisor review
Each day the firm's share counts and the custodian's disagree, and every break comes with a memo to read. This app reads each break, judges real mismatch or timing gap, and flags the old real ones for a supervisor.
PresenterOpens the private repo. Visible to admins only.
For the reconciliation deskCross-domain · Wealth & Asset Management
Why it matters
Today's manual process, and the same job with the app
A reconciliation desk at an asset manager or custodian bank, clearing position breaks before a supervisor reviews the queue.
✕Today's manual process
1Read every memo to tell a real mismatch from a trade that will settle on its own.
2Work out the gap between the custodian's count and the firm's, in a spreadsheet.
3Check the age of each break against the aging policy.
4One slip and a real break ages unseen, or a supervisor chases a timing gap.
Every memo read and checked manually
✓With the app
1Each memo is read, and the break is marked real or a timing gap.
2The gap is worked out from the two counts read off the record.
3The age is checked against the aging threshold, every time.
4Only old, real breaks go forward to the supervisor, who decides. Nothing is posted.
Supervisors see only old, real breaks
See it work
One real case, read by the app, step by step
Tobias Okafor's break PB-0020: the custodian shows 1,711 more shares, settlement passed unconfirmed, and it is 12 business days old.
Sort an asset manager's position breaks for supervisor reviewReference appBuilt to be shaped to your process
5
1The break record read into ten fields, each tied to the line it came from.
2The two counts 13,035 shares on the firm's books, 14,746 at the custodian.
3The memo settlement passed with no confirmation and no correction. Still unresolved.
4A real break not a timing gap that will clear on its own.
5Sent for review 1,711 shares apart and 12 business days old. A supervisor decides.
For engineers
How it is built, and how we measured it
All fourteen steps of the build are written up, from the business case to running it in your own environment.
Sort an asset manager's position breaks for supervisor review
A small, forkable project that does one job end to end. Run once for real, and every figure on these pages captured from that run.
PresenterOpens the private repo. Visible to admins only.
The business caseThe problem this solves
Reconciling a position break means reading the reconciling memo to judge whether it describes a genuine, unresolved discrepancy or a benign, self-resolving timing difference, then checking the break's age against an aging policy, before it goes to an operations supervisor. Someone manually reading each position break's reconciling memo to judge whether it describes a genuine unresolved discrepancy or a benign, self-resolving timing difference, then checking the break's age against an aging policy before it goes to an operations supervisor.
Audience
Operations and reconciliation analysts at an asset manager or custodian bank who triage position breaks before a supervisor reviews the queue, and the people who build tooling for them. Every number on these pages came from one real run of this code, not from a vendor page.
The inputThe actual records
The corpus is 55 records, 0.03 MB (txt 55). Plain text, one format, invented rather than fetched — a real reconciliation break cannot be published either (see SOURCES.md). Ten fields are chosen because the same ones matter to a position reconciliation review: who, what security, the two quantities, break age, and — the field this kit exists to test — whether the memo describes a genuine unresolved discrepancy or a benign explanation.
The corpus
The 55 recordsgenerated 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 records. That is the whole change — there is no database to migrate.
One record, as the model receives itPB-0001.txt · 1 of 55
Account
-------
ACCT-571716
Security
--------
QZ0000000096 -- Sunhaven Financial
As Of Date
----------
2026-05-09
Internal Quantity
-----------------
43508
Custodian Quantity
------------------
43124
Break Age (Business Days)
-------------------------
7
Assigned Analyst
----------------
Casey D. Rossi
Reconciling Memo
----------------
Mismatch flagged by overnight reconciliation. Investigation found the difference is a corporate action (2-for-1 split) processing lag; custodian confirms shares will post by settlement date. Fully accounted for.
The outcomeWhat a good result looks like
A ten-field extracted record per break, plus one pure-code computed flag folding two checks together — a genuine unresolved discrepancy, aged past a threshold — informational only, never an adjusting entry.
And when it cannot
This run found one field-level miss across both tiers and 1,100 combined cells — a security-name misread on a field the flag computation never touches — and zero review-flag errors on either tier. What the run did not test: a break that genuinely IS resolving but not yet confirmed, a memo mixing a true and an explainable element in the same account, or a second, corroborating custodian source — this kit reads one break at a time and never cross-references a related break on the same account. See Business.not_good_enough.
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.
Screening a reconciliation queue for which breaks need an operations supervisor to review before month-end close — either tier for the flag — they tie at 1.00 recall and precision measured here 100% review-flag recall on both tiers, against the free keyword-register floor's 80% recall (5 missed review flags, all genuine breaks whose memo still used settlement/timing language).
Deciding the two tiers on cost, speed or field-level precision — the fast tier Lower p50 latency (2,768 ms vs 4,462 ms), 11% fewer output tokens, and the one field-level miss of the night (a security-name misread) landed on the deliberating tier, not the fast one.
At a glanceHow the whole thing runs
100%extraction accuracy
2,768 msp50, end to end
$1.27per 1,000 records · Google Gemini 3 Flash
Run once, for real, on 2026-08-21. 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.
Sort an asset manager's position breaks for supervisor review14 steps · 4 questions · run once, for real · 2026-08-21
Every tile is a linkall 14 steps · no step without a page
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/*.txt, write data/fields.json, and supply a gold record per break. Corpus lens →
When is this the wrong choice?
Avoid: The keyword-register floor for the true/explainable judgment specifically — its fixed word list is exactly what the planted ambiguity is built to defeat. That is the case against the best-fitting scenario (“Screening a reconciliation queue for which breaks need an operations supervisor to review before month-end close”). 2 scenarios scored in all, each with its own.Eval lens →
Where does it stop working?
Scanned or image-only records — there is no OCR step. 3 recorded failure modes, each from a run rather than a guess.Corpus lens →
What was never verified?
Whether the model would still hit 100% flag recall on a larger, adversarially-constructed set of register-mismatched memos. This run's 20 ambiguous cases (of 55 records) all resolved correctly on both tiers for the flag, but 20 cases is not enough to rule out a harder register mismatch this corpus did not think to plant. 3 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 2 models on the fast tier and the deliberating tier, one provider, one key. Prompt lens →
And if it fits — what do I stand up?
4 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-08-21 — r001-position-reconcile. 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 — Verified from a cold clone with no key configured: 55 records segment into 440 sections in 0.009 seconds, and the assembled prompt for PB-0020 replays byte for byte — its three part sizes match what run r001 recorded.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
Step 01 of 14Business case
Written for: product manager · Measured during the eval run. Never estimated, never quoted from a vendor page.
In brief
100.0%rows answered
2,768 msp50, end to end
3,674 msp95
2 minclone to first result
What the clock covers. model call only, one per record
Current processWhat it replaces
Someone manually reading each position break's reconciling memo to judge whether it describes a genuine unresolved discrepancy or a benign, self-resolving timing difference, then checking the break's age against an aging policy before it goes to an operations supervisor.
Where it is not good enough
One field-level miss across both tiers and 1,100 combined cells: the deliberating tier misread a security name as "Novocore" instead of "Novacore" on one record (PB-0038) — a one-character slip on a field that plays no part in the review-flag computation. Both tiers hit 1.00 recall and precision on the flag itself. That is still a small sample for a rule this consequential, and it says nothing about the harder cases this corpus does not test: a break that genuinely IS resolving but not yet confirmed, a memo that mixes a true and an explainable element in the same account, or a non-English memo. It also reads one record at a time — see Data.breaks_on.
One question, end to end. Colour on the fan-in is the corpus format; a red hook marks every station with a recorded failure, and the words — every sub line, failure and report field — are in the ledger beneath. Every station is a link — click one to jump to its row, and each row links to the lens that explains it.
The free keyword-register floor (evals/baseline.py, classifies by five fixed benign-sounding words) scores 98.91 pct extraction accuracy but 80.0 pct flag recall — 5 missed review flags, every one a genuine break whose memo still used settlement or timing language — against 100 pct flag recall and precision on both tiers here, with only one field-level miss across both tiers and zero flag errors of any kind. No red-team run exists for this kit — this footer names that absence rather than a resistance rate it does not have.
The swap seams
Seam
File
What changes
SECTION_HINTS
src/select.py
map fields to your own record's headings; unmatched falls back to the whole document
PROVIDERS
src/adapters/__init__.py
any OpenAI-compatible host, or Anthropic's Messages API
AGING_THRESHOLD_DAYS
src/extract.py
this kit's own flat aging policy — replace with your actual firm's documented SLA and escalation routing before trusting the computed flag for anything real
the field schema
data/fields.json
a different set of fields entirely, with its own types and allowed values
Components
Component
File
Role
segment
src/segment.py
cut the record into addressable sections, pure code
select
src/select.py
pick which sections carry each field, pure code
prompt
src/prompt.py
assemble one call for all ten fields
extract
src/extract.py
the AI layer, one provider one key — plus the pure-code computation downstream: break quantity and the review-routing flag
judge
evals/judge.py
score field accuracy and the flag's recall/precision separately, pure code
Where it breaks at scale
One call per record, no concurrency and nothing shared between calls: 55 records took a few minutes wall clock on the fast tier. A stack of thousands needs batching and a rate-limit strategy this kit does not have. It also reads one break in isolation — a real reconciliation queue often carries related breaks across the same account that this kit never cross-references.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
Step 03 of 14App UI
Written for: anyone, in 5 seconds · Screenshots of the running app taken during the run.
SuccessesWhen it works
Before anything is asked of the model. Ten named fields with their own types and allowed values, plus a second panel for the two pure-code figures computed afterwards.successOpen full size →PB-0020, extracted live. A memo reading "Originally logged as trade pending T+2 settlement; settlement date has now passed with no confirmation from custodian and no correction submitted" correctly reads is_true_break: yes despite using settlement language, and the computed panel shows a 1,711-share break and routes it for review at 12 business days old.successOpen full size →
LimitsWhen it does not
A report showing only wins is an advert. This one is required, and the validator now refuses a kit that omits it.
The same button with no API_KEY configured. A calm 200 and a plain sentence, not a stack trace: nothing was called, nothing was spent, and the field table stays browsable.failureOpen full size →
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
Step 04 of 14Corpus
Written for: "can I point this at mine?" · Measured off the corpus the run actually used.
In brief
55records
0.03 MiBtxt 55
440sections · p50 48 chars
$0.00setup · 0.009s
How it is cutWhat one section is
cut on underlined section headings; a record with none falls back to one whole-document segment so a span still resolves
SetupWhat the setup figure measured
There is no index. Preparation is segmentation only — 55 records cut into 440 sections by src/segment.py, pure code, no model and no key.
LicenceLicence
MIT — this repository's own licence. Every account, security and memo is invented; a real reconciliation break cannot be published either — it names a real account and a real custodian relationship.
Bring your ownBring your own records
Replace data/corpus/*.txt, write data/fields.json, and supply a gold record per break. SECTION_HINTS in src/select.py maps fields to headings and will need editing for a different record layout; when it does not match, selection falls back to the whole document — slower, more expensive, always correct.
What breaks it
Scanned or image-only records — there is no OCR step.
A record whose sections are not headed — segment() falls back to one whole-document segment, so a span names "document" and locates nothing finer.
Related breaks across the same account are never cross-referenced — this kit reads one break record in isolation, whatever its own memo does or does not say.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
Step 05 of 14Prompt
Written for: engineer · Logged from the run, verbatim.
In brief
The assembled prompt in full, and its real decomposition. Every part below occurs in the prompt that was actually sent, and the token counts sum to the recorded input total — they were measured against the provider’s own counter, not apportioned by character share.
AssemblyHow the prompt is assembled
Part
Characters
Tokens
system
1,231
352
field schema
1,264
301
record sections
541
195
Total
848
This is the cost lesson as arithmetic: of the 848 tokens assembled, 352 are instructions — 42% of the prompt, the largest single part. A per-request bill follows whichever part is biggest, and on this kit that is the one named here.
Measured token-for-token via evals/prompt_tokens.py's nested-prefix subtraction against the provider's own tokenizer, not estimated from characters — see results/tokens-p001-position-reconcile.json.
Full promptThe prompt in full
The verbatim prompt, as sent
the prompt, as sent
You extract structured fields from a position reconciliation break record. You return JSON and nothing else.
RULES, in order of importance:
1. If the record does not state a field, return null for it. Do not infer it, do not compute it, and do not use what you know about the world.
2. `is_true_break` means the reconciling memo describes a GENUINE, unresolved discrepancy -- no explanation on file, custodian unresponsive, no correction submitted -- as opposed to a BENIGN, explainable and self-resolving timing difference (a trade pending settlement that is on track, a corporate action in process, a dividend timing difference). Judge by what the memo says ACTUALLY HAPPENED, not by which words it uses. A memo that still says 'pending settlement' after the settlement date has clearly passed with no confirmation is a true break despite using settlement language. A memo that opens with an alarming word ('URGENT', 'mismatch flagged') but is fully accounted for by its own end is not a true break. Read the whole memo before deciding.
3. Copy values verbatim from the record wherever possible.
4. Use the exact allowed value for a field that lists them.
5. Return every field named in the schema, even when the answer is null.
---
Extract these fields:
- account_id (string) -- the account identifier, verbatim
- security_id (string) -- the security identifier (CUSIP-style)
- security_name (string) -- the security's name
- as_of_date (string) -- the position date, YYYY-MM-DD
- internal_quantity (number) -- the firm's internal book quantity
- custodian_quantity (number) -- the custodian's reported quantity
- break_age_days (integer) -- how many business days the break has been open
- assigned_analyst (string) -- the analyst assigned to this break
- reconciling_memo (string) -- the reconciling memo, copied verbatim
- is_true_break (enum) one of: yes, no -- does the memo describe a GENUINE, unresolved discrepancy (no explanation on file, custodian unresponsive, no correction submitted), or a BENIGN, explainable and self-resolving timing difference (a trade pending settlement that is on track, a corporate action in process, a dividend timing difference)? Judge by what the memo says actually HAPPENED, not by which words it uses -- a memo that still says 'pending settlement' after the settlement date has passed with no confirmation is a true break despite using settlement language; a memo that opens with an alarming word ('URGENT', 'mismatch flagged') but is fully accounted for by its own end is not.
Return a JSON object with exactly these keys: account_id, security_id, security_name, as_of_date, internal_quantity, custodian_quantity, break_age_days, assigned_analyst, reconciling_memo, is_true_break
Use null for any field the record does not state.
BREAK RECORD
------------
Account
-------
ACCT-339453
Security
--------
QZ0000000013 -- Orchardline Common Stock A
As Of Date
----------
2026-03-22
Internal Quantity
-----------------
13035
Custodian Quantity
------------------
14746
Break Age (Business Days)
-------------------------
12
Assigned Analyst
----------------
Tobias F. Okafor
Reconciling Memo
----------------
Originally logged as trade pending T+2 settlement; settlement date has now passed with no confirmation from custodian and no correction submitted. Escalated to trade support, unresolved.
Raw responseThe raw response
The raw response, before any parsing
the response, unparsed
{
"account_id": "ACCT-339453",
"security_id": "QZ0000000013",
"security_name": "Orchardline Common Stock A",
"as_of_date": "2026-03-22",
"internal_quantity": 13035,
"custodian_quantity": 14746,
"break_age_days": 12,
"assigned_analyst": "Tobias F. Okafor",
"reconciling_memo": "Originally logged as trade pending T+2 settlement; settlement date has now passed with no confirmation from custodian and no correction submitted. Escalated to trade support, unresolved.",
"is_true_break": "yes"
}
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
Step 06 of 14Evals
Written for: the skeptic · The harness output, with as_of / model version / dataset version / verified_by.
In brief
Sort an asset manager's position breaks for supervisor review — 55 records. Two tiers of one model family answered, and every answer was then graded Two different ways — because the grade is a measurement too, and most of what went wrong on this kit went wrong in the ruler rather than the model.
55records
55source documents
2model tiers
110graded answers
2grading methods
MeasurementsWhat was measured
COUNTED550 · 549 / 550extraction accuracy — cellsDecided by == against a fixed gold value. No model graded this and it reproduces to the digit — which makes it checkable, not necessarily right: it is only as good as the gold behind it.
COUNTED25 · 25 / 25review-flag recall — records that should have been flaggedDecided by == against a fixed gold value. No model graded this and it reproduces to the digit — which makes it checkable, not necessarily right: it is only as good as the gold behind it.
NOT YET KNOWN—A person confirmed the gold is rightThe grader is == and needs no confirming. The gold does: it is machine-derived from the registry's structured modules, and every rate on this page rests on that derivation being faithful to what the prose actually says. Nobody has read a document against its gold record by hand.
Two words carry this page: Counted is deterministic and nobody's opinion and Not yet known is printed blank rather than filled with something plausible. There is no Judged row here and that is the point: nothing on this page is a model's opinion about another model. The row most worth having is currently the empty one.
How the method was validated
The scorer (evals/judge.py) is pure code, exact match with light normalisation against a mechanically-derived gold — there is no judgement to validate, only comparison. What WAS validated: tools/build_corpus.py's gold is read back off the same generated quantities and memo the document states, never carried over from a separate target, and evals/check_labels.py asserts every field is populated on every row before any run is allowed to spend. The TRUE review flag is derived by running the same pure-code compute() over gold's own values, never a separately-typed truth.
283.18output tokens · the fast tier · 2,768 ms p50
331.64output tokens · the deliberating tier · 4,462 ms p50
Two tiers, one API key
Not two vendors and not a vendor comparison — which is the whole reason the two-model rule could be met without signing up to a second provider. Both tiers send the same retrieved context; the slower one writes about twice as much back, waits 1.6× as long, and lands one row apart on 55. This set does not separate them on quality and no ranking should be read from it — which is not an opinion about the models but something the second run below demonstrated.
Grading costWhat it costs
Every dollar on these pages is a MEASURED token count multiplied by a named vendor's PUBLISHED rate — a projection onto a rate card, not a bill anyone paid.
Priced at
Per 1M in / out
One record
1,000 records
Share that is the prompt
Google Gemini 3 Flash the cheapest model Google publishes a rate for, and the card every kit in this series projects onto so the rows compare across use cases
$0.50 / $3.00
$0.001267
$1.27
33%
Same work, 1× the bill
The same records, the same tokens — only the rate card changed. And on that card about 33% of what you pay is the prompt this pipeline sends, not the answer it writes.
which tier is called — the two tiers tie on the review-flag figure that matters most, so the lever buys accuracy nothing measurable; the fast tier is both cheaper and faster with no measured tradeoff.
Rates checked 2026-08-18. The provider that actually ran r001 and r002 publishes no rate card this repo commits, so nothing here is what was actually paid — the real spend for this kit's build is recorded in the commit history and the shared call ledger, not on this page.
The gradersTwo ways to grade
Grader
Cost / 1k
Data leaves
Same answer twice
Result
Per-field exact match, light normalisation Does the model's value for each field match gold, after trimming whitespace/punctuation and treating numbers within half a cent as equal?
$0.00
no
yes
the fast tier 100.0% · the deliberating tier 99.8%
Review-flag confusion matrix Does the run's own pure-code needs_review (true break AND aged past threshold) match the same computation run over gold's own true values?
$0.00
no
yes
the fast tier 100.0% · the deliberating tier 100.0%
Every row opens its own page: how the test was run, the input on one real row, the prompt or formula with every iteration of it, and the analysis.
Why this set cannot separate them
Yes, between the models and the keyword-register floor, not meaningfully between the two model tiers. Both tiers hit 25/25 review flags identically and 1.00 recall/precision; the fast tier hit every field cell and the deliberating tier missed exactly one (a security-name spelling, unrelated to the flag). The floor is what separates cleanly: 80% recall against 100%, on exactly the register-mismatched memos this corpus was built to plant.
Choosing oneWhich one to use
The comparison is only useful if it ends in a choice. The answer is conditional — and it is not the grader with the best agreement score.
If your situation is
Use
Because
And avoid
Screening a reconciliation queue for which breaks need an operations supervisor to review before month-end close
either tier for the flag — they tie at 1.00 recall and precision measured here
100% review-flag recall on both tiers, against the free keyword-register floor's 80% recall (5 missed review flags, all genuine breaks whose memo still used settlement/timing language).
the keyword-register floor for the true/explainable judgment specifically — its fixed word list is exactly what the planted ambiguity is built to defeat.
Deciding the two tiers on cost, speed or field-level precision
the fast tier
Lower p50 latency (2,768 ms vs 4,462 ms), 11% fewer output tokens, and the one field-level miss of the night (a security-name misread) landed on the deliberating tier, not the fast one.
paying for the higher tier here — this run found nothing it bought.
This pipeline was also attacked, which is a different question from whether its answers are right: see Threat model for the injection experiment, its two gates and what it does not prove.
Failure causesHow it fails
Cause
What it means
Rows
A real example
security-name-misread
A one-character security-name misread, unrelated to the flag computation
1
PB-0038: gold security_name="Novacore Semiconductor"; the deliberating tier returned "Novocore Semiconductor" — a single-letter substitution. The fast tier extracted it correctly. Neither security_id, the quantities, nor is_true_break were affected, and…
What we could NOT verify
Whether the model would still hit 100% flag recall on a larger, adversarially-constructed set of register-mismatched memos. This run's 20 ambiguous cases (of 55 records) all resolved correctly on both tiers for the flag, but 20 cases is not enough to rule out a harder register mismatch this corpus did not think to plant.
Whether AGING_THRESHOLD_DAYS=3 matches any real firm's actual documented reconciliation SLA — it does not, by design (see README); this row's own facet sheet states no formal SLA exists today, and no real policy was consulted or reproduced.
How either tier performs on a real, messy reconciliation feed (a multi-account daily break report, custodian-specific formatting, a feed with dozens of breaks per account) — this corpus is one break per record, plain text, with a single consistent layout by construction.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
Step 07 of 14Unit cost
Written for: whoever signs off on the bill · Measured over the eval run, per model. Never quoted from a vendor page.
In brief
Tier
Input tokens
Output tokens
p50 latency
Google Gemini 3 Flash
the fast tier
835.02
283.18
2,768 ms
$0.001267
the deliberating tier
835.02
331.64
4,462 ms
$0.001412
The token counts are measured on a real run and belong to this pipeline — which sections are selected, the field schema, the prompt — so they hold wherever you run it. The dollars are those counts multiplied by each vendor's published rate, checked 2026-08-18. Nobody paid these particular bills; they are what the same work would cost you on a card you can sign up to today.
Identical work in both rows — the same query, the same tokens. Only the price list changed. Which is why the token count is the measurement and the dollar is arithmetic you can redo on your own card.
Answering vs gradingAnswering and grading are two separate bills
The keyword-register floor (evals/baseline.py) and the scorer (evals/judge.py) are both pure code and cost $0.00 to run against either result set. The figure above is both runs' own token counts (the fast-tier and deliberating-tier runs, 55 records each) priced at Google Gemini 3 Flash's published rate — the same basis cost_per_query_usd uses, not a second, larger spend.
Cost driversWhat actually moves the bill
The fixed system prompt and field schema (653 of 848 tokens on the example call, 77%) outweigh the record sections sent (195 tokens) on this example — the floor every call pays before a single quantity is read.
Output length: the model returns a full ten-key JSON record every call regardless of the memo's own length.
Your volumeWhat it costs at your volume
Linear in records: each call is independent and self-contained, with no shared context or index to amortise. This run's 55 records cost about $0.070 projected onto Gemini 3 Flash's rate, so ten times the set is about $0.70 on the same rate and the same prompt — arithmetic on the measured per-call rate, not a second run.
Where pricing changes shape
Your return, with your numbers
Volume
What it replaces
Time saved per item
We publish the inputs, not a return: a return depends on your labour cost and your volume. The ROI dashboard takes it from here, and AI Costing explains the math.
Other modelsOn other models
This is arithmetic, not a run. No model below was executed against the labelled set, and no accuracy is claimed for any of them. What transfers is the input volume: retrieval is model-independent, so every model would receive the same passages.
45,926input tokens · this run
15,575output tokens
—not priced — no committed card for the provider that ran it
The exact work behind every number on these pages: 55 position-break records extracted, each scored by pure code against a mechanically-derived gold set. This run (r001-position-reconcile, the fast tier) answered all 55 of 55 records with no truncation -- the row this table prices, the same one Cost.cost_by_model[0] uses.
Model
Provider
One eval pass
This whole run
Per 1,000 queries
Rates as of
gpt-5-6-luna
OpenAI
$0.028
$0.028
$0.51
2026-09-12
gemini-3-flash
Google
$0.070
$0.070
$1.27
2026-09-18
gemini-3-8-flash
Google
$0.093
$0.093
$1.69
2026-09-18
llama-5
Meta
$0.124
$0.124
$2.25
2026-09-18
claude-haiku-4-5
Anthropic
$0.124
$0.124
$2.25
2026-09-12
grok-4-5
xAI
$0.185
$0.185
$3.37
2026-09-18
grok-4-6
xAI
$0.185
$0.185
$3.37
2026-09-18
claude-sonnet-5
Anthropic
$0.248
$0.248
$4.50
2026-09-12
gemini-3-1-pro
Google
$0.279
$0.279
$5.07
2026-09-18
gpt-5-6-terra
OpenAI
$0.279
$0.279
$5.07
2026-09-12
gpt-5-6-sol
OpenAI
$0.495
$0.495
$9.00
2026-09-12
claude-opus-4-8
Anthropic
$0.619
$0.619
$11.25
2026-09-12
claude-opus-5
Anthropic
$0.619
$0.619
$11.25
2026-09-12
claude-fable-5
Anthropic
$1.238
$1.238
$22.51
2026-09-18
claude-fable-5-1
Anthropic
$1.238
$1.238
$22.51
2026-09-18
gpt-6-astra
OpenAI
$1.238
$1.238
$22.51
2026-09-17
Read this against the numbers above
Every row below prices the FAST TIER's own 55-call run (r001-position-reconcile) -- the deliberating tier's own token counts are on Cost.cost_by_model[1] and are not separately projected here.
Neither tier's registered run left anything to disable -- src/adapters/__init__.py's thinking parameter is only sent when a caller passes one, and this kit's own harness never does (see LLM.settings) -- so unlike several sibling kits, there is no reasoning-on/reasoning-off discrepancy to caveat here.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
The codeEvery file, and what it is for
Five modules, no framework, and almost no dependencies. The pipeline is stdlib Python, because a kit is meant to be read and changed by someone who cloned it ten minutes ago — every dependency is a thing they have to understand before they can touch the part they came for.
Four of these are swap seams: the points you edit to make the kit yours. Each is marked, and each block below is the module’s real shape, read out of the file rather than written here.
The files on this page are not in the public GitHub catalog.
src/segment.pysegment
cut the record into addressable sections, pure code
src/segment.py
# Cut a document into addressable sections. Pure code — no model, no network.
def sections(text):
def locate(text, value):
def span_label(secs, start):
src/select.pyselect — a swap seam
pick which sections carry each field, pure code
You change it to: map fields to your own record's headings; unmatched falls back to the whole document
src/select.py
# Pick which sections plausibly carry each field. Pure code -- the last deterministic step
SECTION_HINTS = {
def for_field(secs, field):
def plan(secs, fields):
src/prompt.pyprompt
assemble one call for all ten fields
src/prompt.py
# Assemble the extraction prompt. One prompt per break record, all ten fields in it.
SYSTEM = (
def field_schema(fields):
def build(doc_text, secs, fields, selector):
def parse(raw, fields):
src/extract.pyextract — a swap seam
the AI layer, one provider one key — plus the pure-code computation downstream: break quantity and the review-routing flag
You change it to: this kit's own flat aging policy — replace with your actual firm's documented SLA and escalation routing before trusting the computed flag for anything real
src/extract.py
# Extract one break record's fields: segment, select, prompt, one model call, then a pure-code
HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
FIELDS = os.path.join(HERE, "data", "fields.json")
CORPUS = os.path.join(HERE, "data", "corpus")
MAX_TOKENS = 4000
AGING_THRESHOLD_DAYS = 3
def load_fields():
def load_doc(stmt_id):
def documents():
def compute(values):
evals/judge.pyjudge
score field accuracy and the flag's recall/precision separately, pure code
evals/judge.py
# Score an extraction run. PURE CODE -- gold is exact and the answer is one value per cell, so
def norm(v):
def _num(v):
def equal(field, got, want):
def score(fields, records, golds):
def score_flags(flags, golds):
Start hereThe shortest path into it
src/segment.pycut the record into addressable sections, pure code
src/select.pypick which sections carry each field, pure code A swap seam.
src/prompt.pyassemble one call for all ten fields
src/extract.pythe AI layer, one provider one key — plus the pure-code computation downstream: break quantity and the review-routing flag A swap seam.
evals/judge.pyscore field accuracy and the flag's recall/precision separately, pure code
Every entry above is a file in this kit, listed in the order the pipeline runs it.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
ScenariosWhat it costs at your volume
Everything below is computed from one measured base: 835 input and 283 output tokens per query, all of it fixed — this kit sends the document's own selected sections, so there is no retrieval depth to turn. Change the volume and the bill scales linearly, because nothing here batches.
Grading really is free here, and that is a property of the ruler rather than a discount
This kit is graded by pure code — the grader makes no model call, needs no key and sends nothing anywhere, so the grading line above is zero at every sampling rate and the leak count stays at nought. What that buys is a ruler you can run on every row, every time, for nothing. What it costs is reach: a code grader can only check what is mechanically checkable.
OperationsFour shapes of workload
The same arithmetic, at volumes worth naming. These are illustrations of scale, not measurements of anyone’s deployment.
Shape
Querys/day
Per day
Per month
Per year
Model follows the controls above.
What this ignoresWhere a real bill diverges
Read before quoting any of it
Output length is assumed constant.A terser or more verbose model moves it, and output is priced above input everywhere.
No volume, committed-use, batch or cache discount is modelled.Each moves real enterprise pricing and none are on a public rate card.
Longer documents cost more and nothing here caps them.This kit selects the document’s own sections in pure Python, so there is no vector store to price — but a corpus of longer records raises the input tokens per query directly, and that is the very number every figure above multiplies.
Grading adds nothing to this bill, and would if you changed the ruler.A code grader is free and local; swapping in an LLM judge would cost more per row than the extraction itself and send every row to a vendor. The instrument is a cost decision, not a footnote.
Rates age.Every one carries the date it was read on the cost page.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one lineWhat this kit exposes
This run's records are entirely synthetic (tools/build_corpus.py) -- no untrusted party wrote any record text. In a real deployment a position-break record's reconciling memo is written by an operations analyst working the break, or arrives inside a custodian's own exception report -- exactly the kind of externally-authored input this kit's architecture reads verbatim and trusts, with no verification step before its text reaches the model. No attack has been tried against this kit; see redteam.why.
Read from the shared .env or the real environment only, never written into the repo, never requested from a reader on any surface. src/app.py's /api/extract handler strips api_key and base_url out of any exception message before it reaches the browser, so a misconfigured key cannot leak into a UI error.
The experimentWe did not attack it — and three of four boundaries hold
An indirect prompt injection needs a field an outside party controls that reaches the prompt. In THIS corpus every record is generated by tools/build_corpus.py, so there is no live untrusted text in the run this report measures -- but a real deployment's reconciling memos arrive from an operations analyst working the break or a custodian's own exception report, and that surface has not been attacked. The four gates below are boundaries confirmed by reading the code, not payloads run through it. Confirmed by reading the code, not by a run, on 2026-08-21 -- no attack run was fired; see redteam.why.
Boundary checked
What could go wrong
What the code guarantees
Does an extraction ever post an adjusting entry or trigger a downstream action?
An extraction could plausibly post a correcting entry, an approval or a denial.
No code path does. src/extract.py::extract() and src/app.py's /api/extract both return a record only; neither writes to any file or store -- confirmed by reading every call site.
Could a misconfigured provider key leak into a UI-visible error?
An exception raised from a bad key or base URL could echo the secret back to the browser.
src/app.py's /api/extract handler strips api_key and base_url out of any exception message before returning it -- confirmed by reading the handler (see key_handling).
Is the aging threshold, or the review-flag arithmetic, something a prompt or a reply can move?
A crafted reconciling memo could plausibly shift AGING_THRESHOLD_DAYS, or talk the arithmetic into a different answer.
No. AGING_THRESHOLD_DAYS in src/extract.py is a module-level constant, read once at import time -- nothing the model returns is consulted when computing it; needs_review is computed after the model call, in pure code (src/extract.py::compute()).
Could a crafted reconciling memo talk the model into a fabricated is_true_break='no' despite a real unresolved discrepancy being described?
A memo written to describe a genuine unresolved discrepancy in routine, self-resolving-sounding language could plausibly move is_true_break to 'no', clearing a break that should have been flagged.
Unmeasured -- no attack has been tried. is_true_break is an enum with no span at all (see Eval.scores.non_spannable_fields), unlike the copied-verbatim fields src/segment.py::locate() can check against the record text -- nothing stops the model from ASSERTING the break is benign when the underlying memo is not; see could_not_verify.
The first three boundaries hold, confirmed by reading the code, not by an attack trial. The fourth is the one this run has not tested: is_true_break is the field the whole guardrail depends on, and it is also the one field this kit's own span mechanism cannot check, because it is an enum, not a copied value -- no crafted input has ever been run against it.
The result0 attack trials, and three of four boundaries checked here hold in code: no write path exists, the aging threshold is a fixed constant the model cannot move, and a misconfigured key cannot leak into a UI error. The fourth -- whether a crafted reconciling memo could talk the model into a fabricated 'no' on a real unresolved discrepancy -- is unmeasured.
1externally-authored field a live deployment would carry (the reconciling memo text itself, from an operations analyst or a custodian's exception report) -- synthetic on this run's corpus
0 of 0attack trials run
n/adecision-flip resistance -- not measured
This run's corpus is entirely generated (tools/build_corpus.py) -- no record's text was authored by an outside party. A real deployment's reconciling memos arrive from an operations analyst working the break or a custodian's own exception report -- exactly the kind of externally-supplied text this kit's architecture reads verbatim and trusts, with no verification step. Whether a memo crafted to describe a genuine unresolved discrepancy in routine-sounding language could talk the model into a false is_true_break='no' is unmeasured for this kit.
Read this twice
The review flag is exactly as good as is_true_break. src/extract.py::compute() never re-derives that field from the reconciling memo text -- it trusts the model's own answer and only checks the age condition alongside it. On this run the fast tier scored a clean 100 pct extraction accuracy and both tiers scored 100 pct review-flag recall and precision, with only one field-level error across both tiers and zero flag errors of any kind across 55 records -- a near-clean run, and also a small one for a rule this consequential (see Business.not_good_enough). A future version should recompute is_true_break independently before trusting a live flag, and a red-team pass targeting exactly that field is the natural next measurement.
HonestyWhat this does not prove
Whether a reconciling memo crafted to describe a genuine unresolved discrepancy in routine, self-resolving-sounding language could talk the model into a false is_true_break='no' -- no red-team run exists for this kit.
Whether the live app's own /api/extract behaves identically to the registered run under an adversarial record -- both use the same src/extract.py::extract(), but neither has been tested against one.
Whether a code-level consistency check on is_true_break (re-deriving it from the memo text by pure code) would catch a model's fabricated 'no' in practice -- none has been built or exercised.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one lineThe guardrail is enforced in code
Not a prompt instruction the model can ignore — a comparison applied after the reply is parsed, before anything downstream sees it.
the guardrail, verbatim
A break is routed for review when the model's own is_true_break is 'yes' AND the stated break_age_days exceeds AGING_THRESHOLD_DAYS=3 — both computed in pure code from the model's own extracted fields, never asked of the model directly, never overridden by anything it returns.
src/extract.py::compute() -- AGING_THRESHOLD_DAYS is a module-level constant and pure code, read once at import time. Unlike a prompt instruction the model could ignore, this guardrail cannot be talked out of firing by anything in the reply text; it only depends on the model's own extracted is_true_break and break_age_days being right in the first place -- a DIFFERENT, prompt-level dependency the flag inherits (see is_not and could_not_verify).
EvidenceDoes it hold?
What
Measured
The review flag never misses a record that should have been flagged
25 of 25 records that should have been flagged were flagged, on both tiers (100 pct recall) -- see Eval.scores.
The review flag never fires on a record that should not be flagged
0 false positives among the 30 records that should not have been flagged, on both tiers (100 pct precision).
The aging threshold is not something a prompt or a reply can move
AGING_THRESHOLD_DAYS in src/extract.py is a module-level constant, read once at import time -- confirmed by reading compute(); nothing the model returns is consulted when computing it.
No code path posts an adjusting entry or a correction based on the flag
src/extract.py::extract() and src/app.py's /api/extract both return a record only; neither writes to any file or store -- confirmed by reading every call site.
The limitWhat a guardrail is not
IT IS NOT A CHECK ON is_true_break ITSELF. The flag trusts the model's own answer for that field completely -- nothing re-derives it from the reconciling memo text before computing the flag. This run found zero disagreements on that field across 55 records on both tiers (see Eval.scores), which is evidence the prompt's stated 'judge by what happened, not which words' rule held up on this corpus, not evidence the guardrail itself checked and cleared anything -- it never looks at the memo text at all.
It does not guarantee a reconciliation determination either way -- the flag is a routing signal for an operations supervisor, never itself an adjusting entry. See UI.shots and Data.breaks_on.
It has not been attacked. Whether a reconciling memo crafted to describe a real unresolved discrepancy in routine, self-resolving-sounding language could suppress is_true_break or needs_review is unmeasured -- see Security.could_not_verify.
WatchedWhat is watched, and why that one
2runs recorded
0 / 0deterministic metrics exact
+0.0%largest move — latency
0band breaches
—model half · needs provider URL
The kit measures 14 watched figures plus 8 comparability guards and 5 reference constants — three duties, not one list. 0 of the watched are grader rates, each on its own grader page; this board watches the ones that decide when to look again. Each square is one watched figure; filled means the latest run measured it.
7 measured by the latest run7 need the model half
Metric
Owner
Role
Why this one
field-exact-match-with-normalisation
Per-field exact match, light normalisation
alarm
extraction_accuracy specifically on is_true_break, since that is the one field this corpus is built to test — see taxonomy; the 550-of-550 clean-run rate on the fast tier, since a drop anywhere would mean something in the prompt or the corpus changed; span_rate on the nine spannable fields, since a value with no span is an assertion rather than a located citation — alarm on Any drop in extraction_accuracy below the measured figures on either tier — this run's near-clean result is the baseline, and any regression means the prompt, the corpus, or the provider changed.
flag-confusion-matrix
Review-flag confusion matrix
alarm
false_negative count specifically, since a missed true break aged past threshold is the failure mode an operations supervisor cares about most; whether recall stays at 1.00 as the corpus grows — this run's 25 positive cases is a small sample for a rule this consequential — alarm on Any false negative — a record gold says should route for review that the run's own computed flag did not catch.
GuardsBefore any comparison
Preconditions, not alarms. If one moves, the runs were not measuring the same system and nothing else on this board may be differenced.
Guard
Value
If it moves
corpus.doc_count
55
different corpus — nothing is comparable
corpus.bytes
26,216
records edited — the count held, the bytes did not
split.count
440
the sections count moved — a different set was scored
split.size_p50
48
the median size of one section moved
split.size_p95
152
the 95th-percentile size of one section moved
dataset.rows
55
the test set changed — every rate has a new denominator
tokens.context_limit
1,000,000
different model family
index.build_seconds
0.009
no index is built here — a change is in corpus preparation, not an index rebuild
all shared guards held between the recorded runs (documents 55, extraction_cells 550, failures 0, refusal_cells 0, thinking True) — which is why the history below is allowed to mean anything.
The reference constants — the null-grader baseline, the adjudication matrix, the negative count — are the third duty. They are never re-measured per run: a baseline that moves with the thing it measures is not a baseline.
BandsThe alarm bands
Derived from evidence, never picked: exact-match where two runs reproduced a metric to the digit, wider than the measured same-input drift for latency, one row of the negative class for any rate — denominator printed beside it.
Group
Band
Denominator
Where the band comes from
Extraction accuracy
exact match at 100 pct on the fast tier, 99.82 pct on the deliberating tier (one security-name misread, PB-0038)
550 cells
two independent tiers (r001-position-reconcile, r002-position-reconcile) -- one exact match, one near-exact on a field the flag never touches -- see Eval.taxonomy.
Review-flag recall/precision
exact match at 100 pct / 100 pct on both tiers
25 records that should be flagged, 30 that should not
two independent tiers reproduced the identical figures to the digit.
Hallucinations
exact match at 0 on both tiers
550 cells
two independent tiers reproduced zero to the digit.
Span rate
100 pct on the fast tier, 99.8 pct on the deliberating tier (494 of 495 spannable values located)
spannable extracted values (non-enum fields with a non-null answer)
two independent tiers -- the one gap on the deliberating tier is the same PB-0038 security-name misread, which locate() could not find verbatim.
Latency
2,768ms / 3,674ms p50/p95 on the fast tier, 4,462ms / 6,297ms p50/p95 on the deliberating tier -- roughly 60 pct higher, not same-input drift, because the two tiers are different models
55 calls per tier
measured directly on both tiers.
Token totals
45,926 input tokens on both tiers (identical prompt); 15,575 output on the fast tier vs 18,240 on the deliberating tier, about 17 pct more
55 calls per tier
measured directly on both tiers.
HistoryRun history
2 recorded runs. A dash is a metric that run did not measure, and a dash is never differenced: not measured is a third state, neither a value nor a zero, and reading it as zero is how a board reports an improvement on a run that never looked.
Metric
r001-position-reconcile 2026-08-21
r002-position-reconcile 2026-08-21
extraction accuracy
1.0000
0.9982
invented values
0
0
values with a span
1.000
0.998
input tokens, whole run
45926
45926
model latency p50 ms
2768.00
4462.00
model latency p95 ms
3674.00
6297.00
output tokens, whole run
15575
18240
not a time series No two of these 2 runs measured the same system — they differ on the model — so nothing here may be differenced and the Verdict column is left off. Read this block DOWN a column, as a comparison between those runs, not along a row as a history.
DeviationsWhat deviated
0 breaches across 2 runs
The day a band breaks, a row renders here carrying the metric, the two runs, the band it crossed and what changed between them — model, prompt, chunker or top_k, read off the run records’ guards. A deviation with no diff beside it is an alarm nobody can act on.
RippleThe ripple map
Which figures move together, so one alarm reads as a system. Every edge carries its basis: measured names the run that showed it; reasoning admits nothing has varied it yet.
Lever
What moves
Basis
Evidence
which tier is called (fast vs deliberating)
output tokens (+17 pct) and latency (roughly +60 pct) move together; review-flag recall/precision and hallucinations do not move at all; extraction accuracy and span rate move only very slightly, both on the same single security-name misread
measured
r001-position-reconcile vs r002-position-reconcile: 550/550 vs 549/550 cells, output tokens 15,575 -> 18,240, p50 latency 2,768ms -> 4,462ms.
a record with no genuine discrepancy, or a true break not yet aged past threshold
needs_review resolves false whenever either half of the rule fails -- a benign timing difference is never flagged regardless of age, and a true break under the 3-day threshold is never flagged regardless of severity
reasoning
src/extract.py::compute() only sets needs_review True when BOTH is_true_break=='yes' AND age>AGING_THRESHOLD_DAYS -- confirmed by reading the function; this run's 30 true-negative records all resolved to needs_review=false on both tiers.
FiresWhat fires when a band breaks
Where evals stop sitting beside the guardrail and start feeding it. Where the answer is nothing automatic, the row says so — hiding it would undo “What a guardrail is not” above.
Nothing fires yet. Not one of the 6 bands on this kit names a consequence, so there is no row to print. Which is the honest answer to the heading: a band that nothing is wired to is a number somebody has to notice, and this kit has only those. An empty table would have said the same thing while looking like a rendering failure.
NextThe three you would add first
Re-derive is_true_break from the reconciling memo text by pure code, and compare it to the model's own answer before trusting the flagthe flag's only real dependency is a field this guardrail currently takes on faith -- src/segment.py already does word-boundary text matching for spannable fields, and a similar pattern check could flag a disagreement rather than silently trusting the model, though it would need to be stricter than the free keyword-register floor this kit already ships (see Eval.baseline) to add anything.
Cross-reference a second, related break on the same account before trusting a clean recordthe flag is computed from one record's own memo alone today (see Architecture.breaks_at_scale); a real reconciliation queue is often checked against related breaks on the same account, and nothing here does that.
Replace the flat 3-business-day aging threshold with a real firm's published escalation SLAAGING_THRESHOLD_DAYS is this kit's own declared policy, not a real standard's guideline (see README/SOURCES.md) -- Data.breaks_on and could_not_verify both name this as unverified against anything real.
None of these is built here. They are named against the seam they sit on so they can be argued with.
CadenceWhen to re-run, and what it costs
Re-check the flag's evidence on any change to AGING_THRESHOLD_DAYS in src/extract.py, or to the is_true_break rule in src/prompt.py -- either changes what the flag is computed FROM. Re-run evals/run.py (paid) on any change to MAX_TOKENS or the provider/model.
What this cannot tell you
Whether the flag would still hold 100 pct recall and precision on a larger or harder set of register-mismatched memos -- this run's 20 ambiguous cases (of 55 records) all resolved correctly on both tiers for the flag, but 20 cases is not enough to rule out a harder confusable phrasing this corpus did not think to plant.
Whether a crafted reconciling memo could move is_true_break without the flag ever noticing -- no red-team run exists for this kit, see Security.could_not_verify.
Whether the 3-business-day aging threshold matches any real firm's actual documented reconciliation SLA -- it does not, by design; see README/SOURCES.md.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one lineNo framework, deliberately
No framework and no dependencies beyond the standard library -- requirements.txt is empty, with a comment explaining that the emptiness is load-bearing. The whole extraction decision is three files: src/segment.py, src/select.py and src/adapters/__init__.py.
The mappingSeam by seam, who owns what
Seam
File here
Framework equivalent
Note
the corpus
tools/build_corpus.py
none -- a seeded generator
55 position-break records, generated from a fixed seed, never fetched. Gold is read back off the same generated quantities and memo text the document states, never carried over from a separate target -- evals/check_labels.py asserts field completeness on every row before any run is allowed to spend; see data/SOURCES.md.
segmentation and selection
src/segment.py, src/select.py
text splitters / retrievers
a heading-based cut (src/segment.py) and a fixed field-to-heading map (SECTION_HINTS in src/select.py) -- no embeddings, no index, no ranking; a field absent from the map gets the whole document rather than nothing.
prompt assembly
src/prompt.py
prompt templates
the ten-field schema and the is_true_break rule are one declaration, and SYSTEM is built from it -- so the prompt can be published verbatim, which a template assembled two calls away cannot be.
the model
src/adapters/__init__.py
chat model wrappers / vendor SDKs
raw HTTP over urllib for every provider, so a forker runs this on whichever key they hold. This kit's own MAX_TOKENS=4000 (carried over from the sibling extraction kits' own experience on a similarly-shaped record) is a plain constant, not a client-library setting.
evaluation
evals/judge.py
eval harnesses
per-field exact match plus a separately-scored review-flag confusion matrix is a loop and a handful of counters, not a platform.
spend control
src/budget.py
none
an append-only ledger written BEFORE each call, shared by every kit under one .env so the cap is on the KEY rather than per kit.
The seams are the ones this kit already publishes, so the mapping cannot drift from the code.
GraphsWhere LangGraph changes the answer
Nothing here is a graph. The pipeline has one path per record -- segment, select, prompt, call, parse, compute -- with no branching and no state carried between records. A framework would add an orchestrator to a for-loop.
The other sideWhat a framework costs you
A different field schema (data/fields.json) or a different review rule needs its own gold set and its own evals/check_labels.py pass -- a framework's own schema layer would not remove that work, only relocate it.
SECTION_HINTS is a five-minute edit for a new record layout because it is a plain dict, not a configured retriever -- a framework's own chunking/retrieval abstraction would need its own re-tuning pass instead, with its own failure modes to learn.
Swapping providers is one function and one entry in PROVIDERS (src/adapters/__init__.py) -- a framework's own model abstraction would add a dependency and a version to track for the same one-line change this file already gives away free.
What we could NOT verify
Whether a framework's own retrieval or agent abstraction would resolve anything this kit does not already handle was not tested -- this run found one field-level error across both tiers and zero flag-level errors (see Business.not_good_enough), so there is very little observed weakness here for a framework to address.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one lineWhat one run of this kit actually cost, in time and tokens
Measured on r001-position-reconcile on the fast tier, 2026-08-21. This kit records telemetry measured per run — 4 of the 6 readings on this axis, 4 of them with a band the guardrail board can judge against.
The readingWhat the last run measured
Reading
Last run
Band
What fires
Model, median
2,768 ms
2,768ms / 3,674ms p50/p95 on the fast tier, 4,462ms / 6,297ms p50/p95 on the deliberating tier -- roughly 60 pct higher, not same-input drift, because the two tiers are different models
—
Model, p95
3,674 ms
2,768ms / 3,674ms p50/p95 on the fast tier, 4,462ms / 6,297ms p50/p95 on the deliberating tier -- roughly 60 pct higher, not same-input drift, because the two tiers are different models
—
Input tokens
45,926
45,926 input tokens on both tiers (identical prompt); 15,575 output on the fast tier vs 18,240 on the deliberating tier, about 17 pct more
—
Output tokens
15,575
45,926 input tokens on both tiers (identical prompt); 15,575 output on the fast tier vs 18,240 on the deliberating tier, about 17 pct more
—
No movement column. Not one of the 1 earlier run on record is comparable with this one — a different model tier, or a changed guard — and differencing across that measures two systems rather than one. Said once here rather than as a dash on every row.
Retrieval not shown. No run of this kit has ever recorded a retrieval timing, because the pipeline has no such stage. Those readings are left out rather than dashed: a dash says “this run did not measure it”, which promises a later run could.
DriftMedian call, run over run
r001-position-reconcile2,768 ms
r002-position-reconcile4,462 ms
Hatched bars are runs that are not comparable with the latest — a different model tier or a changed guard. They are drawn because hiding them would make the history look shorter than it is, and greyed because differencing across them would be measuring two systems.
The other sideWhat this does not tell you
What we could NOT verify
No stage-by-stage span tree. These are whole-call timings; which part of the pipeline spent the time is not recorded by this kit's harness.
Latency is a run-level median and p95. The spread between the fastest and slowest single call is not stored, so the distribution cannot be drawn.
No earlier run is comparable to this one (a different model tier or a changed guard), so nothing on this page is a trend yet.
One machine, one network, one region. Latency includes the provider round trip from a single location and will not transfer to yours.
The first of those is the one worth doing something about, and it is a solved problem: instrumenting a pipeline so each step reports its own duration is a couple of lines. Observability / tracing has the code, and what the result looks like once it is running.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one lineWhat you provision, honestly
Everything measured on this page says where it was measured; everything not measured says that — the same contract as the other thirteen pages. Where a retrieval index would be on other kits, this one has: no index — each document goes whole into one call.
The machineWhat this needs
Dependencies
nothing beyond the standard library — requirements.txt names no package
Configuration
7 environment variables — the full knob table is at the bottom of this page
Last verified run
2026-08-21, across 2 committed records
Enumerated from the kit’s own source by build/facts/envscan.py, committed, and drift-checked — never typed into this page.
Your dataWhere everything sits
Artifact
Where
Leaves your machine?
position-break records
data/corpus/*.txt — 55 files, generated once from a fixed seed (SEED = 20260821) by tools/build_corpus.py
read whole by src/segment.py and src/select.py; never modified after generation
gold labels
data/gold.jsonl — 55 rows, read back off the same generated quantities and reconciling memo the document states (never a target that seeded them), checked against the document text by tools/build_corpus.py's own _verify() pass
never — evals/judge.py is pure code, no model, no key
the field schema
data/fields.json — the ten-field record src/prompt.py assembles the user message from
read by src/prompt.py and src/extract.py only
the key
.env — never committed (see .gitignore)
only inside the Authorization header, to the configured BASE_URL (src/adapters/__init__.py)
The wireWhat crosses it, and when
Runtime call site
Destination
src/adapters/__init__.py line 55
the configured BASE_URL
Build-time (corpus tooling, run once)
Destination
none — this kit’s corpus is generated locally
Zero-egress topology: point BASE_URL at a local OpenAI-compatible server and nothing leaves the machine — statically true of the shipped adapter, whose only credential travels in the Authorization header.
The third state
What the provider retains, trains on or logs once a request arrives is not measured here — it is provider-dependent, and this page does not assert what no run of ours can verify.
The shapeHow it ships, and what you add
The key
Read from the shared .env or the real environment only, never written into the repo, never requested from a reader on any surface. src/app.py's /api/extract handler strips api_key and base_url out of any exception message before it reaches the browser, so a misconfigured key cannot leak into a UI error.
You add
your reverse proxy and your identity in front of one process — the kit deliberately ships neither, because identity belongs to your estate, not to a kit
Never ships
Docker, Helm, a queue, a database. The product is a folder of readable Python; what to run it under is this page’s job to state, not the kit’s job to impose
The ladderEach decision, and what you provision past its ceiling
Decision
The kit ships
Measured here
Past the ceiling
What stops being valid
model
one call per RECORD, carrying the selected sections plus the ten-field schema, behind src/adapters/__init__.py — OpenAI-compatible wire format over raw HTTP, so a forker runs this on whichever key they hold. MAX_TOKENS is fixed at 4000 (src/extract.py), set on the sibling extraction kits' own experience with a similarly-shaped JSON record rather than a ceiling this kit has ever hit — 0 of 55 calls truncated on either tier.
2,768ms p50 / 3,674ms p95 on the fast tier, 4,462ms p50 / 6,297ms p95 on the deliberating tier (the fast-tier and deliberating-tier runs, 2026-08-21 -- see Cost.cost_by_model)
one call per record, no concurrency and nothing shared between calls — see Architecture.breaks_at_scale. A stack of thousands needs batching and a rate-limit strategy this kit does not have; MAX_CALLS_PER_DAY in src/budget.py caps the shared key across every kit on this machine, not this kit's own throughput.
point src/adapters/__init__.py at a different provider or model and every published accuracy/cost/latency figure is void until re-run — this run's numbers are this model's numbers, not a property of the prompt.
corpus refresh
tools/build_corpus.py regenerates the whole corpus — 55 position-break records across a fixed roster of accounts, securities and reconciling memos — byte-identically from a fixed seed (SEED = 20260821) every time it is run. There is no incremental refresh; gold is derived from the same generated quantities and memo text the document states (never a target that seeded them) and the script's own _verify() pass checks every record's stated quantities and memo text appear verbatim in the document text before anything is scored.
under 0.05s wall time to regenerate all 55 files and their gold labels (measured directly, 2026-08-21 (python3 tools/build_corpus.py, timed) -- see Data.index for the separate segmentation figure, a different step)
a real deployment's break volume, account roster and memo vocabulary do not come from a fixed seed and grow without bound — how a genuinely varied set of real-world reconciliation feeds would change what src/segment.py (heading-based) and src/select.py (SECTION_HINTS) can resolve was not measured; see Architecture.breaks_at_scale and Data.breaks_on.
point tools/build_corpus.py at your own break records and account roster, and every published accuracy figure is void — they are this corpus's own planted ambiguity, not a property of the model.
labels
evals/check_labels.py asserts gold/document consistency (one gold row per document and vice versa, every enum value allowed by the schema) before evals/run.py is allowed to spend anything. Scoring (evals/judge.py) is per-(record,field) exact match with light normalisation, plus a separately-scored review-flag confusion matrix computed from the model's own extracted fields by pure code (src/extract.py::compute), never from a second model call.
550 of 550 possible (record, field) cells scored (55 records x 10 fields) plus 55 records carrying a review-flag verdict, scored separately (lenses.Eval.dataset, the fast-tier and deliberating-tier runs, 2026-08-21)
the gold set stops at 55 records and covers one planted ambiguity (a stale settlement-language true break vs. an alarming-opener explainable item) at a fixed 40 pct rate — a real reconciliation queue's mix of ambiguous phrasing is unmeasured, and a related break on the same account is never cross-referenced; see Data.breaks_on.
a different field schema (data/fields.json) or a different review rule needs its own gold set and its own evals/check_labels.py pass before any published figure can be trusted again.
Every threshold is a measurement with its provenance beside it, or says is_measured:false. A ceiling with no seam says so — it is the point the kit is outgrown, never a forced join.
When it failsFailure signatures
What you see
What it is
First move
is_true_break answered 'yes' on a memo that still uses settlement/pending-style language after the settlement date has clearly passed with no confirmation
the model read for what the memo actually says HAPPENED rather than being talked out of it by stale reassuring register in the same sentence — this is the corpus's planted ambiguity (AMBIGUOUS_FRACTION=0.40 in tools/build_corpus.py), and on this run both tiers got every one of these cases right (see Eval.taxonomy)
read the memo's own final sentence before assuming a 'yes' next to 'pending settlement' is a mistake — the prompt's own rule (see README) is that a memo still using settlement language after the date has passed is still a true break, and this run found zero cases where either tier applied the keyword-register shortcut instead of the stated rule (the fast-tier and deliberating-tier result files, both runs, 2026-08-21 -- see Eval.taxonomy and Eval.baseline for the same pattern's effect on the free keyword-register floor)
No machine symptom — this failure leaves no trace in any output.
no path in src/extract.py::compute() or src/app.py posts an adjusting entry, an approval, or any correction to a position — needs_review is returned to the caller as a field on the response record and nothing downstream of this kit acts on it. A flipped flag on a real deployment would show up only in whatever reconciliation system consumes this kit's output, which this kit does not have and does not simulate — so there is no committed artifact naming that failure, on purpose: it is out of this kit's boundary, not unmeasured.
Whether a 55-record, single-seed run's near-clean result generalises to a harder register-mismatched memo this corpus did not plant, or to a larger sample size, was not tested — see Eval.could_not_verify. Concurrency (every run in this series is one call at a time, sequential), AGING_THRESHOLD_DAYS=3 against any real firm's actual documented reconciliation SLA, and how either tier performs on a real, messy reconciliation feed (a multi-account daily break report, custodian-specific formatting, dozens of breaks per account) are all unmeasured — see Eval.could_not_verify and Data.breaks_on for the full list.
The corpus licence, from the Data lens: MIT — this repository's own licence. Every account, security and memo is invented; a real reconciliation break cannot be published either — it names a real account and a real custodian relationship. Your corpus’s licence is yours to verify, and the labels you write are about your documents.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one linePer-field exact match, light normalisation
Does the model's value for each field match gold, after trimming whitespace/punctuation and treating numbers within half a cent as equal?
$0.00per 1,000 records
nodata leaves your network
yessame answer every time
MethodHow the test was run
evals/judge.py::score, in-process, no key and no model. The same function evals/run.py calls after every call, and the same field-match logic the free baseline is scored by — a baseline and a real run scored by two different scorers cannot be compared honestly.
Every grader on these pages scored the same 110 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.
The inputOne real row, seen by every grader
doc
PB-0020
field
is_true_break
internal quantity
13035
custodian quantity
14746
break age days
12
is true break model
yes
gold is true break
yes
needs review
yes
break quantity
1711
Grader
Verdict
Why
Per-field exact match, light normalisation
correct
PB-0020's memo reads "Originally logged as trade pending T+2 settlement; settlement date has now passed with no confirmation from custodian and no correction submitted." Gold: is_true_break=yes, break_age_days=12, needs_review=true. Both tiers answered yes despite the settlement language, and the run's own pure code correctly computed a 1,711-share break and routed it for supervisor review.
Review-flag confusion matrix
correct
Gold needs_review=true (is_true_break=yes, break_age_days=12 > threshold 3). Both models' own extracted is_true_break=yes and break_age_days=12 fed src/extract.py::compute(), which correctly computed needs_review=true on both tiers and break_quantity=1711 — routed for operations supervisor review, as it should be.
The formulaWhat it computes
The analysisWhat it actually did
Model
Result
the fast tier
scored 100.0%
the deliberating tier
scored 99.8%
In operationWhat to monitor
Reference standard: tools/build_corpus.py's gold, read back off the same generated quantities and memo the document states (never a target that seeded them); evals/check_labels.py asserts every field is populated on every row before any run is allowed to spend.
These rates are UNKNOWN, on purpose
This grader IS the reference standard for field values — it cannot be scored against itself. What can go wrong is the corpus's own generation logic, which tools/build_corpus.py's own _verify() pass checks by confirming every record's stated quantities and memo text appear verbatim in the document.
Watch these
extraction_accuracy specifically on is_true_break, since that is the one field this corpus is built to test — see taxonomy
the 550-of-550 clean-run rate on the fast tier, since a drop anywhere would mean something in the prompt or the corpus changed
span_rate on the nine spannable fields, since a value with no span is an assertion rather than a located citation
Alarm on
Any drop in extraction_accuracy below the measured figures on either tier — this run's near-clean result is the baseline, and any regression means the prompt, the corpus, or the provider changed.
How tight can the band be? There is no tolerance band on the field grade itself — it is exact match after trimming whitespace/punctuation, and numbers within half a cent are treated as equal, never a continuous score to round.
Cadence: Re-score on any change to src/prompt.py, data/fields.json or tools/build_corpus.py — the first two change what is asked, the third changes what is asked about. Re-run evals/run.py (paid) on any change to MAX_TOKENS or the provider/model.
The decisionWhen to reach for it
Use it
Gold is derived from the same generated quantities and memo the document states, never from a separate target — true of every kit corpus, never true of a real reconciliation analyst's own break history.
Do not use it
The true field values are not known in advance — the normal state of a real reconciliation review, and the reason this corpus is generated rather than captured.
Sort an asset manager's position breaks for supervisor review
PresenterOpens the private repo. Visible to admins only.
In one lineReview-flag confusion matrix
Does the run's own pure-code needs_review (true break AND aged past threshold) match the same computation run over gold's own true values?
$0.00per 1,000 records
nodata leaves your network
yessame answer every time
MethodHow the test was run
evals/judge.py::score_flags, in-process, no key and no model. Runs src/extract.py::compute() over both the run's own extracted values and gold's own values, then compares the two booleans per record.
Every grader on these pages scored the same 110 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.
The inputOne real row, seen by every grader
doc
PB-0020
field
is_true_break
internal quantity
13035
custodian quantity
14746
break age days
12
is true break model
yes
gold is true break
yes
needs review
yes
break quantity
1711
Grader
Verdict
Why
Per-field exact match, light normalisation
correct
PB-0020's memo reads "Originally logged as trade pending T+2 settlement; settlement date has now passed with no confirmation from custodian and no correction submitted." Gold: is_true_break=yes, break_age_days=12, needs_review=true. Both tiers answered yes despite the settlement language, and the run's own pure code correctly computed a 1,711-share break and routed it for supervisor review.
Review-flag confusion matrix
correct
Gold needs_review=true (is_true_break=yes, break_age_days=12 > threshold 3). Both models' own extracted is_true_break=yes and break_age_days=12 fed src/extract.py::compute(), which correctly computed needs_review=true on both tiers and break_quantity=1711 — routed for operations supervisor review, as it should be.
The formulaWhat it computes
The analysisWhat it actually did
Model
Result
the fast tier
scored 100.0%
the deliberating tier
scored 100.0%
In operationWhat to monitor
Reference standard: The same pure-code compute() in src/extract.py, run over gold's own is_true_break and break_age_days values rather than the model's — the TRUE needs_review is never separately typed, only derived.
These rates are UNKNOWN, on purpose
Whether the flag generalises to breaks this corpus did not plant — the confusion matrix is exact against this run's 55 records, and says nothing about a register mismatch harder than the one built here. See Eval.could_not_verify.
Watch these
false_negative count specifically, since a missed true break aged past threshold is the failure mode an operations supervisor cares about most
whether recall stays at 1.00 as the corpus grows — this run's 25 positive cases is a small sample for a rule this consequential
Alarm on
Any false negative — a record gold says should route for review that the run's own computed flag did not catch.
How tight can the band be? No tolerance band — a binary flag either matches gold's derived flag or it does not, scored per record.
Cadence: Re-score on any change to AGING_THRESHOLD_DAYS, src/extract.py::compute, or the prompt's is_true_break instruction — all three change what the flag means.
The decisionWhen to reach for it
Use it
Gold's true needs_review is derived by running the same compute() the kit itself uses, over gold's own is_true_break and break_age_days — never a separately-typed truth that could drift from the rule the kit actually applies.
Do not use it
A real reconciliation queue's true review-worthiness is not known until an operations supervisor actually reads the break — this corpus's gold is a construction, not an observed outcome.
A living map of modern AI — kept current every morning