The business caseThe problem this solves

Before a crop-protection product goes on a field, somebody has to decide whether the application somebody has planned sits inside the restrictions on that product's label — and if it does not, whether the answer is 'change it', 'wait', or 'nobody can say from this page'. It is eight comparisons in a fixed order, and the order matters: a hard restriction and a timing one are both breaches, and only one of them is cured by waiting. The page also puts two things next to the answer that look like evidence and are not: the agronomist's own free-text remark, and how many applications were made LAST season, when the label maximum is per season. Somebody opening a product label beside a proposed spray plan and working down it: is this crop on the label at all, is the partner in the tank prohibited, is the rate inside the maximum, has the season's allowance already been used, is the sprayer far enough from the ditch, has enough time passed since the last application, is harvest far enough away, and can people be kept out of the crop for long enough afterwards. It is a few minutes per plan and it is every plan, and the part that goes wrong is not the arithmetic: it is reading a near-neighbour crop as the crop, treating a maximum that has already been reached as a limit you may sit on, mixing up two day counts that run in opposite directions, and comparing an interval measured in hours against one measured in days.

The inputThe actual label extracts

The corpus is 52 label extracts, 0.05 MB (txt 52). Plain text, one format, invented rather than fetched — a real product label is a manufacturer's copyrighted document approved by a national authority, and a real spray plan names a real holding, a real parcel and a named adviser's own remark. There is no public corpus of (label, proposed application, correct verdict, correct deciding restriction) pairs. Generating it also makes both labels mechanical: gold's verdict and gold's deciding restriction are the walk of data/checks.json over the same twenty values the page states, never somebody's reading of the note.

Field
-----
FLD-WF-28935

Product and Registration
------------------------
Ravelquin 300 SC -- registration REG-2018-50379 -- active substance zemidral 100 g/L

Label Restrictions
------------------
permitted crops: protected lettuce, winter oilseed rape, field peas, spring wheat, winter wheat
maximum rate per application: 2.5 L/ha
maximum applications per season: 1
minimum re-treatment interval: 28 days
pre-harvest interval: 60 days
re-entry interval: 48 hours
minimum buffer to surface water: 20 m
tank mix prohibited with: Hollowmere 450 SC, Belquoran 120 WG

Proposed Application
--------------------
crop: winter oilseed rape
rate: 1.2 L/ha
applications already made this season: 0
days since the last application: no application made to this crop this season
days to harvest: 59
planned re-entry: 48 hours after application
distance to nearest surface water: 45 m
tank mix partner: none

Season History
--------------
applications made in the PREVIOUS season: 0

Application Status
------------------
planned

Agronomist Notes
----------------
Something looked off against the label; flagged for a second read before spraying.

The outcomeWhat a good result looks like

A twenty-two-field extracted record per case, plus TWO decisions taken afterwards in pure code: which of eight restrictions the case turns on, and one hold decision from two of those fields — an application that is not inside the label as it stands, whose product is already on the crop, is the one to look at today. The verdict carries the check set's own reasoning and names what it could not determine. Nothing here authorises an application, withdraws a crop, or contacts anybody.

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 season's proposed applications before an agronomy or assurance desk opens them — the fast tier — it was exact on every published figure on this corpus
  100 pct four-way verdict accuracy and 100 pct deciding-restriction accuracy against the free agronomist-note floor's 30.77 pct and 15.38 pct, and 0 unsafe clearances against the floor's 15 of 38.

And where nothing here is good enough:

• Deciding which model to run this on — nothing — this page cannot answer it
  ONE tier was run, ONCE. There is no second tier and no repeat, so nothing here compares two models, and nothing here even establishes that the perfect score is repeatable on the same model. What the numbers DO support is narrower and real: on this corpus the shipped prompt and check set produce exact answers, and a tone read of the note does not.
• Deciding whether this shape is worth buying at all, from these numbers — nothing yet — this corpus cannot answer it
  Every published figure is perfect, so nothing here separates any two configurations. What the numbers DO support: a tone read of an adviser's note is measurably unsafe on this shape of decision — it clears 15 of the 38 proposals that must be stopped and names a restriction on none of them — and a self-consistency check caught 36 of that shortcut's 44 answer errors with no labels at all.

At a glanceHow the whole thing runs

Run once, for real, on 2026-08-22. 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.

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-22 — r001-label-restrict. 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.

Checked before this shipped — Checked on a fresh checkout with API_KEY left blank: python -m src.app starts, the 52-case picker populates, the field table draws its twenty-two empty rows, the walk panel says nothing has been checked yet rather than printing eight blanks, and the shipped check set renders in full from data/checks.json; clicking Check returns the no-key sentence rather than a stack trace, and the hold row reads “not computed — one of the two values the rule needs was missing” rather than “no”. python -m evals.check_labels passes with no network access at all.

Step 01 of 14Business case

Written for: product manager · Measured during the eval run. Never estimated, never quoted from a vendor page.

In brief

What the clock covers. model call only, one per case, measured around the adapter call while twelve calls ran concurrently

Current processWhat it replaces

Somebody opening a product label beside a proposed spray plan and working down it: is this crop on the label at all, is the partner in the tank prohibited, is the rate inside the maximum, has the season's allowance already been used, is the sprayer far enough from the ditch, has enough time passed since the last application, is harvest far enough away, and can people be kept out of the crop for long enough afterwards. It is a few minutes per plan and it is every plan, and the part that goes wrong is not the arithmetic: it is reading a near-neighbour crop as the crop, treating a maximum that has already been reached as a limit you may sit on, mixing up two day counts that run in opposite directions, and comparing an interval measured in hours against one measured in days.

Step 02 of 14Architecture

Written for: solutions architect · Component map derived from the real code, not drawn from intent.

In brief

CorpusCorpusArchitectureArchitecturePromptPromptPromptPromptApp UIApp UIEvalsEvalsBusiness caseUnit cost

• 1stations numbered in run order
• txt
• 0 of 7 stations carry a recorded failure

scroll → 7 stations

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 swap seams

Components

Step 03 of 14App UI

Written for: anyone, in 5 seconds · Screenshots of the running app taken during the run.

SuccessesWhen it works

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.

Step 04 of 14Corpus

Written for: "can I point this at mine?" · Measured off the corpus the run actually used.

In brief

How it is cutWhat one section is

cut on underlined section headings, then anchored to the label LINE each field is stated on; a case with no headings falls back to one whole-document segment

SetupWhat the setup figure measured

There is no index. Preparation is segmentation only — 52 cases cut into 364 sections in well under a hundredth of a second, in process, with no model and no network.

LicenceLicence

MIT — this repository's own licence. Every product name, registration number, active substance, field reference and agronomist note is INVENTED and every crop is an ordinary generic crop noun; no manufacturer, distributor, assurance scheme, adviser or regulator is named. The check set this kit ships (data/checks.json) is ILLUSTRATIVE and is not an authority. It was written for this kit and reproduces no real product label, no manufacturer's use instructions, no registration, no approved-use database and no regulator's guidance.

Bring your ownBring your own label extracts

REPLACE data/checks.json FIRST. It is this kit's own construction, it resembles no real label, and everything downstream reads it: src/checks.py walks it, src/prompt.py renders it into every call, tools/build_corpus.py writes both gold answers with it, and src/app.py serves it to the page. Then replace data/corpus/*.txt, write your own data/fields.json — including the line key that anchors each field's span — and supply a gold record per case. SECTION_HINTS in src/select.py maps fields to section headings and will need editing for a different layout; when it does not match, selection falls back to the whole document — slower, more expensive, always correct. compute() in src/extract.py is this kit's own hold rule and is the second thing to replace.

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.

Token budgetWhere the tokens actually go

The system prompt (856 tokens, 24 pct), the check set (1201, 34 pct) and the field schema (1095, 31 pct) are byte-identical on every call; the case itself is 406 tokens (11 pct). The bill is the instructions and the eight checks, not the label — and the check set is the part that would grow without limit on a real label with per-crop rates and intervals.

AssemblyHow the prompt is assembled

This is the cost lesson as arithmetic: of the 3,558 tokens assembled, 1,607 are contexts — 45% 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 method on LBL-0032 — the same case the worked example above was captured on, so the four parts sum to exactly the 3558 input tokens that call actually reported. Four calls at max_tokens=1, each part's size the difference between two consecutive prompt_tokens counts the provider itself returned. kits/UC0051-label-restrict/results/tokens-p001-label-restrict.json. ⚠︎ THE MEASUREMENT WAS TAKEN ON ONE CASE ONLY, which is weaker than the sibling kit that repeated it on a second case to prove the fixed prefix really is fixed. The prefix is byte-identical by construction — src/prompt.py builds the system text, the check set and the schema from files that do not vary per case — but that is an argument from the code rather than a second measurement.

Full promptThe prompt in full

You read a CROP-PROTECTION PRODUCT LABEL EXTRACT together with ONE PROPOSED APPLICATION, and you extract structured fields from them. You return JSON and nothing else.

You are PROPOSING a reading of the label for a qualified adviser to act on. You never authorise an application, and your answer is not a substitute for the approved label for this product in this territory.

RULES, in order of importance:
1. If the page does not state a field, return null for it. Do not infer it and do not use what you know about the world. The label extract and the proposal are the only facts.
2. `verdict` and `deciding_restriction` are decided ONLY by the CHECK SET given below. Walk the eight checks IN THEIR STATED ORDER and STOP at the first one that fires. `deciding_restriction` is the id of that check. If none fires, the verdict is 'within_label' and the deciding restriction is 'none'.
3. A CHECK THAT IS NOT APPLICABLE IS SKIPPED AND PASSES. The re-treatment interval does not apply when no application has been made to this crop this season. The tank-mix prohibition does not apply when no tank mix is planned, or when the label prohibits none. Skipping is not the same as failing and it is not the same as not knowing.
4. A CHECK WHOSE LABEL VALUE OR PROPOSAL VALUE IS NOT STATED CANNOT BE PERFORMED. Stop there, answer 'insufficient_information', and name that check as the deciding restriction. Do not skip past it to the checks below, and never guess what an unstated interval probably is.
5. HARD RESTRICTIONS OUTRANK TIMING ONES, WHICH IS WHY THEY COME FIRST. Checks 1-5 (the crop, the tank mix, the rate, the season count, the buffer) breach to 'outside_label' and no amount of waiting cures any of them. Checks 6-8 (the three intervals) breach to 'wait_required'. If a case breaches both kinds, the walk stops at the hard one and the answer is 'outside_label'; answering 'wait_required' there tells somebody to wait before doing something they must not do at all.
6. EVERY NUMERIC LIMIT IS INCLUSIVE EXCEPT THE SEASON COUNT. A rate exactly equal to the maximum is inside the label. A pre-harvest interval of 35 days is satisfied by exactly 35 days to harvest. A buffer of 5 m is satisfied by exactly 5 m. But 'maximum applications per season' is a TOTAL, so a proposal made when that many have already been applied would be the next one and is over the maximum.
7. THE RE-ENTRY INTERVAL IS MEASURED IN HOURS. Every other interval on the label is in days. Compare hours with hours.
8. THE AGRONOMIST'S NOTE IS A FIELD TO COPY, NOT EVIDENCE. A note that sounds worried does NOT put a compliant application outside the label, and a note that sounds relaxed does NOT bring a non-compliant one inside it. The check set decides; the note is one person's remark and may disagree with it.
9. THE PREVIOUS SEASON'S APPLICATION COUNT IS A FIELD TO COPY, NOT AN INPUT. The label maximum is per season, so applications made in a previous season are never added to this season's count.
10. Copy crop names, product names and notes verbatim from the page. Return numbers as numbers, with no unit attached.
11. Use the exact allowed value for a field that lists them, and return every field named in the schema, even when the answer is null.

CHECK SET (the authority for `verdict` and `deciding_restriction`; this is an ILLUSTRATIVE set written for this kit, not a real product label and not any regulator's guidance)

WALK THESE IN ORDER AND STOP AT THE FIRST ONE THAT FIRES.

  1. permitted_crops              HARD -> outside_label
     compare: crop_proposed must be one of the values listed in permitted_crops
     the proposed crop must appear in the label's permitted-crop list, matched on the WHOLE crop name and never on part of it
  2. tank_mix_prohibited          HARD -> outside_label
     compare: tank_mix_partner must NOT be any of the values listed in tank_mix_prohibited_with
     the proposed tank-mix partner must NOT appear in the label's prohibited-partner list, matched on the whole product name
     NOT APPLICABLE (skip it, and it passes) when tank_mix_partner is none or tank_mix_prohibited_with is none
  3. max_rate_per_application     HARD -> outside_label
     compare: rate_proposed_l_per_ha <= max_rate_l_per_ha
     the proposed rate must be less than or equal to the label maximum. EXACTLY EQUAL IS INSIDE THE LABEL
  4. max_applications_per_season  HARD -> outside_label
     compare: applications_made_this_season < max_applications_per_season   (strictly less than -- this is the one exclusive limit)
     the applications ALREADY MADE this season must be strictly fewer than the label maximum, because this proposal would be the next one
  5. buffer_to_water              HARD -> outside_label
     compare: distance_to_water_m >= buffer_to_water_m
     the distance to the nearest surface water must be greater than or equal to the label's minimum buffer. EXACTLY EQUAL IS INSIDE THE LABEL
  6. min_retreatment_interval     TIMING -> wait_required
     compare: days_since_last_application >= min_retreatment_interval_days
     at least the label's minimum re-treatment interval must have elapsed since the last application to this crop. NOT APPLICABLE when no application has been made this season
     NOT APPLICABLE (skip it, and it passes) when applications_made_this_season is 0
  7. pre_harvest_interval         TIMING -> wait_required
     compare: days_to_harvest >= pre_harvest_interval_days
     the days remaining to harvest must be at least the label's pre-harvest interval. EXACTLY EQUAL IS INSIDE THE LABEL
  8. re_entry_interval            TIMING -> wait_required
     compare: planned_re_entry_hours >= re_entry_interval_hours
     the planned re-entry must be at least the label's re-entry interval. THIS ONE IS IN HOURS AND EVERY OTHER INTERVAL ON THE LABEL IS IN DAYS. EXACTLY EQUAL IS INSIDE THE LABEL

PRECEDENCE: The checks run in the order below and STOP at the first one that fires. Two things follow from that and both are load-bearing. First, a HARD restriction outranks a TIMING one: if the crop is not on the label, it does not matter that the pre-harvest interval has not elapsed either — the application must not be made at all, and 'wait a fortnight' is the wrong answer to it. Second, a check whose value is NOT STATED cannot be performed, and a check that cannot be performed stops the walk with `insufficient_information` — you cannot skip past a restriction you were unable to read.

SKIPPED IS NOT UNKNOWN: A SKIPPED CHECK AND AN UNREADABLE ONE ARE DIFFERENT THINGS AND ARE NEVER FOLDED TOGETHER. The re-treatment interval does not apply when no application has been made to this crop this season; the tank-mix prohibition does not apply when no tank mix is planned or when the label prohibits none. Those are checks that are NOT APPLICABLE, and they pass. A label that simply does not state its pre-harvest interval is a check that could not be performed, and it does not pass.

AT THE LIMIT: EVERY NUMERIC LIMIT HERE IS INCLUSIVE, and that is stated because it is the single most common way to read a label wrong. A rate exactly equal to the maximum is INSIDE the label. A pre-harvest interval of 35 days is satisfied by exactly 35 days to harvest. A buffer of 5 m is satisfied by exactly 5 m. The one check that is NOT inclusive is the season count, and it is not inclusive for a reason: `maximum applications per season: 3` means three in total, so a proposal made when three have ALREADY been applied would be the fourth.

WHAT EACH VERDICT MEANS
  within_label:              Every applicable restriction is satisfied. The proposal is inside the label as it stands.
  wait_required:             Every hard restriction is satisfied and the only thing standing in the way is an interval that has not yet elapsed. The application may be inside the label later; it is not inside it today.
  outside_label:             A restriction is breached that no waiting will cure — the crop, the tank mix, the rate, the season count or the buffer. Changing WHEN the application is made does not fix any of these.
  insufficient_information:  A restriction this proposal turns on is not stated — on the label, or in the proposal. The kit names which one rather than guessing a verdict.

Extract these fields:
- field_id (string) -- the field or parcel identifier this application is proposed for, verbatim
- permitted_crops (string) -- the label's permitted-crop list, copied verbatim and in full, comma-separated exactly as the label states it
- max_rate_l_per_ha (number) -- the label's maximum rate per application, in L/ha, as a number with no unit
- max_applications_per_season (number) -- the label's maximum number of applications per season, as a number
- min_retreatment_interval_days (number) -- the label's minimum interval between applications, in DAYS, as a number. When the label extract says it is not stated, return null
- pre_harvest_interval_days (number) -- the label's pre-harvest interval, in DAYS, as a number. When the label extract says it is not stated, return null
- re_entry_interval_hours (number) -- the label's re-entry interval, in HOURS -- this is the one interval on the label that is not in days -- as a number. When the label extract says it is not stated, return null
- buffer_to_water_m (number) -- the label's minimum buffer to surface water, in metres, as a number
- tank_mix_prohibited_with (string) -- the products the label prohibits mixing with, copied verbatim and comma-separated. When the label states none, return the word none
- crop_proposed (string) -- the crop this application is proposed for, verbatim and in the lower case the proposal states it
- rate_proposed_l_per_ha (number) -- the proposed rate, in L/ha, as a number with no unit
- applications_made_this_season (number) -- how many applications of this product have ALREADY been made to this crop THIS season, as a number. Do not add the previous season's count to it
- days_since_last_application (number) -- days elapsed since the last application to this crop this season, as a number. When the proposal says no application has been made to this crop this season, return null
- days_to_harvest (number) -- days remaining until the planned harvest, as a number. When the proposal says it is not stated, return null
- planned_re_entry_hours (number) -- how many HOURS after application re-entry to the treated area is planned, as a number
- distance_to_water_m (number) -- the distance from the proposed application to the nearest surface water, in metres, as a number
- tank_mix_partner (string) -- the product proposed as a tank-mix partner, copied verbatim. When the proposal states none, return the word none
- previous_season_applications (number) -- how many applications were made in the PREVIOUS season, as a number. Report it as stated -- the label maximum is per season, so it is NOT part of any check
- application_status (enum) one of: planned, applied -- has this application already been made, or is it still planned?
- agronomist_note (string) -- the agronomist's own free-text remark on this proposal, copied verbatim
- verdict (enum) one of: within_label, wait_required, outside_label, insufficient_information -- whether the proposed application sits inside the label's restrictions. Decide it STRICTLY from the eight restriction checks in the CHECK SET given to you, in their stated order, stopping at the first that fires -- never from the agronomist's note and never from the previous season's count. (1) A check whose label value or proposal value is NOT STATED cannot be performed: answer 'insufficient_information'. (2) A check that is NOT APPLICABLE is skipped and passes -- the re-treatment interval when no application has been made this season, the tank-mix prohibition when no mix is planned or the label prohibits none. (3) A breach of checks 1-5 (crop, tank mix, rate, season count, buffer) is 'outside_label'; no waiting cures any of them. (4) A breach of checks 6-8 (re-treatment interval, pre-harvest interval, re-entry interval) is 'wait_required'. (5) All applicable checks satisfied: 'within_label'. Every limit is inclusive EXCEPT the season count, which is strictly-less-than because this proposal would be the next application
- deciding_restriction (enum) one of: permitted_crops, tank_mix_prohibited, max_rate_per_application, max_applications_per_season, buffer_to_water, min_retreatment_interval, pre_harvest_interval, re_entry_interval, none -- the id of the FIRST check that fired -- the restriction that actually decided the verdict, whether it was breached or could not be read. Return 'none' if and only if the verdict is 'within_label'. A right verdict with the wrong restriction named is scored as a separate failure here, because a grower told to wait on the wrong interval is not helped by the verdict being right

Return a JSON object with exactly these keys: field_id, permitted_crops, max_rate_l_per_ha, max_applications_per_season, min_retreatment_interval_days, pre_harvest_interval_days, re_entry_interval_hours, buffer_to_water_m, tank_mix_prohibited_with, crop_proposed, rate_proposed_l_per_ha, applications_made_this_season, days_since_last_application, days_to_harvest, planned_re_entry_hours, distance_to_water_m, tank_mix_partner, previous_season_applications, application_status, agronomist_note, verdict, deciding_restriction
Use null for any field the page does not state.

LABEL EXTRACT AND PROPOSED APPLICATION
--------------------------------------
Field
-----
FLD-NP-20692

Label Restrictions
------------------
permitted crops: potatoes, carrots, winter barley, winter oilseed rape, field lettuce
maximum rate per application: 2.4 L/ha
maximum applications per season: 3
minimum re-treatment interval: 7 days
pre-harvest interval: 28 days
re-entry interval: 48 hours
minimum buffer to surface water: 6 m
tank mix prohibited with: Corvistel 275 SC, Trelmara 400 EC

Proposed Application
--------------------
crop: winter barley
rate: 0.6 L/ha
applications already made this season: 2
days since the last application: 14
days to harvest: 48
planned re-entry: 30 hours after application
distance to nearest surface water: 6 m
tank mix partner: none

Season History
--------------
applications made in the PREVIOUS season: 3

Application Status
------------------
applied

Agronomist Notes
----------------
Spray records for this parcel are disputed and are under manual audit this week.

Raw responseThe raw response

{
  "field_id": "FLD-NP-20692",
  "permitted_crops": "potatoes, carrots, winter barley, winter oilseed rape, field lettuce",
  "max_rate_l_per_ha": 2.4,
  "max_applications_per_season": 3,
  "min_retreatment_interval_days": 7,
  "pre_harvest_interval_days": 28,
  "re_entry_interval_hours": 48,
  "buffer_to_water_m": 6,
  "tank_mix_prohibited_with": "Corvistel 275 SC, Trelmara 400 EC",
  "crop_proposed": "winter barley",
  "rate_proposed_l_per_ha": 0.6,
  "applications_made_this_season": 2,
  "days_since_last_application": 14,
  "days_to_harvest": 48,
  "planned_re_entry_hours": 30,
  "distance_to_water_m": 6,
  "tank_mix_partner": "none",
  "previous_season_applications": 3,
  "application_status": "applied",
  "agronomist_note": "Spray records for this parcel are disputed and are under manual audit this week.",
  "verdict": "wait_required",
  "deciding_restriction": "re_entry_interval"
}

Step 06 of 14Evals

Written for: the skeptic · The harness output, with as_of / model version / dataset version / verified_by.

In brief

Check a farm's proposed spray against its label — 52 label extracts. One model answered, and every answer was then graded Four 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.

MeasurementsWhat was measured

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.

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.

Rates checked 2026-08-18. The provider that actually ran this 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 gradersFour ways to grade

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.

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.

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

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

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.

Answering vs gradingAnswering and grading are two separate bills

The agronomist-note floor (evals/baseline.py) and the scorer (evals/judge.py) are both pure code and cost $0.00 to run against any result set. The figure above is the scored run's own token counts (52 cases) priced at Google Gemini 3 Flash's published rate — the same basis cost_per_query_usd uses. ⚠︎ IT IS NOT WHAT BUILDING THIS KIT COST. Seven further paid calls sit outside it: four prompt-split calls at max_tokens=1 (results/tokens-p001-label-restrict.json), one worked example (results/example-LBL-0032.json) and two live UI screenshots — the second taken only because the first printed a hold sentence naming the wrong verdict. All 59 live calls together project to about $0.2733 on this card.

Cost driversWhat actually moves the bill

• The fixed prefix — system prompt (856 tokens), check set (1201) and field schema (1095) — is 3152 of 3558 tokens on the worked example, 89 pct, and is byte-identical on every one of the 52 calls. The case itself is 406 tokens. The bill is the instructions and the eight checks, not the document.
• Provider-side reasoning. 38017 of the run's 53462 output tokens (71.1 pct) were reasoning rather than the JSON record, on a twenty-two-key reply that is about 300 tokens of actual content. Reasoning was left at the provider's default and nothing here has measured what turning it off would cost in accuracy.
• Output length: the model returns a full twenty-two-key JSON record every call, including the permitted-crop list and the agronomist's note copied back verbatim, whatever the case says.

Your volumeWhat it costs at your volume

Linear in cases: each call is independent, carries the same fixed prefix and shares nothing with its neighbours, so 520 cases cost ten times 52 and take ten times as long in model time. Nothing amortises — there is no index and no cache. Wall clock is not linear at this size, because the harness runs twelve calls at once: 52 cases took 49.2 seconds of wall clock against about 432 seconds of summed model time. ⚠︎ AND THE CHECK SET DOES NOT SCALE LINEARLY, IT SCALES WORSE: it is sent whole in every call, so a label with per-crop rates and per-crop intervals multiplies the input side of every call at once. At that size the lookup has to move into code before the call, with only the relevant rows sent.

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.

The exact work behind every number on these pages: 52 label-restriction cases, one completion call each, on the fast tier. This kit ran ONE tier once; there is no second tier's run to record beside it.

The codeEvery file, and what it is for

Six 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.

Six 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 label extract and the proposed application into addressable sections, pure code — plus a line-level locator, because eight numeric restrictions share one section and a section-scoped span for the buffer would match the digit inside the rate two lines above it

# Cut a document into addressable sections, and locate a value inside one. Pure code.

def sections(text):
def _renderings(value):
def locate(text, value):
def locate_in_line(text, line_prefix, value):
def span_label(secs, start):

src/select.pyselect — a swap seam

pick which sections carry each field, pure code — the two decided fields are mapped to the two sections the checks actually read, never to the agronomist's note and never to the previous season's count, and the Product and Registration section is mapped by nothing and never sent

You change it to: map fields to your own layout's headings; unmatched falls back to the whole document

# Pick which sections plausibly carry each field. Pure code -- the last deterministic step before

SECTION_HINTS = {
def for_field(secs, field):
def plan(secs, fields):

src/checks.pychecks

the eight restriction checks, loaded from data/checks.json — their order, their hard-versus-timing class, their comparison operator and their not-applicable clauses. Data, not code, so a forker can open it and disagree with it

# THE RESTRICTION CHECKS, loaded from data/checks.json. Pure code, no model, no network.

HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
CHECKS_PATH = os.path.join(HERE, "data", "checks.json")
VERDICTS = ("within_label", "wait_required", "outside_label", "insufficient_information")
NO_RESTRICTION = "none"
def load(path=CHECKS_PATH):
C = load()
CHECKS = sorted(C["checks"], key=lambda c: c["order"])
BY_ID = {c["id"]: c for c in CHECKS}
RESTRICTIONS = tuple([c["id"] for c in CHECKS] + [NO_RESTRICTION])

src/prompt.pyprompt

assemble one call for all twenty-two fields, with the check set RENDERED into it from data/checks.json rather than restated in prose — a precedence walk the model has never been shown is not a precedence walk

# Assemble the label-restriction prompt. One prompt per case, all twenty-two fields in it.

SYSTEM = (
def check_block(c=None):
CHECK_TEXT = check_block()
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 business-condition check downstream: an application that is not inside the label, already made, is held

You change it to: the hold rule itself — this kit ships two values (not within_label AND already applied) and a real holding weighs which restriction was breached and by how much, whether the crop is for food or feed, and what the buyer's assurance scheme requires. It is deliberately NOT the same function as the check walk, so changing WHAT GETS HELD does not change WHAT IS INSIDE THE LABEL

# Extract one label-restriction case: 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 = 6000
def load_fields():
def load_doc(case_id):
def documents():
def decide(values):
def correct_verdict(values):

evals/judge.pyjudge

score field accuracy, the four-way verdict AND its collapse onto may-go-ahead, the DECIDING RESTRICTION on its own, and the hold flag, all separately, pure code

# Score a label-restriction run. PURE CODE -- gold is exact and the answer is one value per cell,

NUMERIC_FIELDS = set()
def norm(v):
def _as_number(v):
def equal(field, got, want):
def score(fields, records, golds):
def _matrix(rows, positive):
def score_verdicts(records, flags, golds):

Start hereThe shortest path into it

Every entry above is a file in this kit, listed in the order the pipeline runs it.

ScenariosWhat it costs at your volume

Everything below is computed from one measured base: 3553 input and 1028 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.

OperationsFour shapes of workload

The same arithmetic, at volumes worth naming. These are illustrations of scale, not measurements of anyone’s deployment.

Model follows the controls above.

What this ignoresWhere a real bill diverges

In one lineWhat this kit exposes

This run's cases are entirely synthetic (tools/build_corpus.py, seed 20260822): no real product, manufacturer, active substance, registration, holding, parcel, crop buyer or adviser exists in the corpus, and nothing was fetched from anywhere. Every product and active-substance name is coined and every crop is an ordinary generic crop noun. The only outbound traffic the kit makes is one chat-completion request per case to the configured provider, carrying the mapped sections of one case plus the fixed prompt and the shipped check set — the Product and Registration section is mapped by nothing and never leaves the machine. Nothing is written outside the kit directory, there is no database, no auth and no multi-tenancy, and the local UI binds 127.0.0.1 only.

Read from the shared .env or the real environment only, never committed, never logged and never rendered. .env is gitignored from the first commit. On an adapter error the app redacts the key and base URL out of the message before returning it, so a misconfigured endpoint cannot echo a credential into a browser — which matters more here than usual, because this kit deliberately surfaces transport errors that carry a URL.

The experimentWe did not attack it — and three of four boundaries hold

The three boundaries that hold were confirmed by reading the code, not by a run: no code path authorises an application, withdraws a crop or delays a harvest; the check walk and the hold rule read only enums, numbers and crop names, so the agronomist's note cannot reach either; and the key and base URL are redacted out of any error before it is returned. The fourth is open. An indirect prompt injection needs a field an outside party authored, and this kit has exactly one — the agronomist's note — which makes it the obvious place to attack and the reason the gap is named rather than glossed. Confirmed by reading the code, not by a run, on 2026-08-22 — no attack run was fired; see redteam.why.

The first three boundaries hold, confirmed by reading the code rather than by an attack run. The fourth is open and is named as open — an indirect prompt injection in the agronomist's note is exactly the attack this kit's shape invites, and nothing here has tried it, including the restriction-flip variant this kit's second guarded field makes possible.

The result0 attack trials, and three of four boundaries checked here hold on evidence. The one that does not is the one this kit's own shape invites: the agronomist's note is free text a third party wrote, and whether an instruction hidden in it could move the verdict — or, worse and specific to this kit, move only the NAMED RESTRICTION while the verdict stays right — is unmeasured.

This run's corpus is entirely generated (tools/build_corpus.py, seed 20260822), so no text in it came from an outside party and there was nothing adversarial to resist. The planted ambiguity is a REGISTER mismatch — a relaxed note on a proposal that must not be made — which measures whether a model walks the check set when the prose points the other way. It does not measure whether a model obeys an instruction hidden in the same field. Those are different failures and only one of them is measured here.

HonestyWhat this does not prove

• Whether an indirect prompt injection in the agronomist_note field could move the verdict or the deciding restriction. No attack run exists.
• Whether the kit behaves safely against a hostile provider — a response body crafted to break the JSON extraction in src/prompt.py::parse, or to return an enormous payload. parse() fails closed to an empty dict, which the harness records as a failed document, and nothing beyond that was tested.
• Whether a real holding's spray records would carry anything sensitive this kit mishandles. The corpus has no personal data by construction; a real record carries a named adviser, a named operator, a parcel that identifies a farm and a buyer's commercial requirements, and none of that path is exercised.

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.

needs_hold fires when the application is NOT inside the label as it stands AND the product has already gone on the crop — verdict != "within_label" and application_status == "applied". Both values come out of the same reply; the rule is run afterwards in pure code, over whatever the model returned, and never over gold. `insufficient_information` counts as not-inside, deliberately: product already on a crop under a restriction nobody could read is precisely a hold. `wait_required` counts too — an interval that has not elapsed is not a problem on a planned application and is one on a made one. A reply missing either value returns None rather than False — an unknown is not a pass.

src/extract.py::compute(), called by extract() on every case, by the local app on every click, and by evals/baseline.py on the free floor's own output so the two are routed by identical code. The restriction walk it reads lives in a SEPARATE module, src/checks.py::decide(), which is also what the corpus generator wrote both gold answers with, what src/prompt.py renders to the model, and what src/app.py serves to the page — one definition, four readers.

EvidenceDoes it hold?

The limitWhat a guardrail is not

• It is NOT an authorisation, a refusal, a harvest hold or a withdrawal. Nothing here stops an application, releases a crop, notifies anybody or writes to any system, and both decided fields are proposals with reasoning attached rather than decisions anybody is bound by. A qualified adviser decides, against the approved label.
• It is NOT a check on whether the extracted values are right. If the model misreads a number or a crop name and then walks the checks correctly from the misreading, the field is held (or not held) on a wrong fact and this rule cannot tell. The consistency diagnostic in evals/judge.py is the closest thing to that check, it is reported separately, and it is blind to exactly the same case.
• It is NOT anybody's real procedure. Not-inside-the-label-and-already-applied is this kit's own simplification, invented for this corpus. No manufacturer's guidance, assurance-scheme rule or regulation was consulted, and none is reproduced. A real holding weighs which restriction was breached and by how much, whether the crop is for food or feed, what the buyer's assurance scheme requires, and who has authority to decide.
• It is NOT a judgement about the check set. The flag reads the verdict the walk produced; if the check set is wrong, or its precedence order is wrong, the flag is confidently wrong with it. The shipped check set is illustrative and is not an authority.

WatchedWhat is watched, and why that one

The kit measures 12 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 run 5 need the model half

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.

all shared guards held between the recorded runs (documents 52, extraction_cells 1144, failures 0, refusal_cells 0) — 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.

HistoryRun history

3 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. They are split into 2 blocks because a free floor is a baseline rather than a peer, and a run of another kind measures another thing; a column in one block is never differenced against a column in another.

extraction · with the model in the path — 2 runs. Columns here are only ever compared with each other.

not a time series No two of these 2 runs measured the same system — they differ on provider, thinking, 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.

extraction · no model in the path — a baseline, not a peer column — 1 run. A floor is what the kit scores with no model in the path; it is the line the model runs have to beat, and it is never differenced against them.

one run A verdict is a comparison and one run has nothing to compare with, so the Verdict column is left off rather than filled with 7 chips that all say so.

DeviationsWhat deviated

0 breaches across 3 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.

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.

NextThe three you would add first

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 compute() in src/extract.py, on any change to data/checks.json (which moves the verdict the flag reads — including a pure REORDERING, which moves the deciding restriction on every case with two breaches), on any change to data/fields.json's allowed values for verdict or application_status, and on any corpus regeneration. Changing WHAT GETS HELD is a policy change and must be re-scored, even though it never changes what is inside the label.

In one lineNo framework, deliberately

No framework and no dependencies beyond the standard library. requirements.txt is empty on purpose: the corpus is generated in-process, the check set is a JSON file read with json, the provider is reached over urllib, and the UI is one HTML file with no build step. A forker runs this on whichever key they already hold, with one clone and no install.

The mappingSeam by seam, who owns what

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 case — segment, select, prompt, one call, parse, walk — with no branch, no loop and no agent. The only fan-out is the thread pool in the harness, which runs the same single path twelve times at once.

The other sideWhat a framework costs you

• Everything is hand-rolled, so everything is yours to maintain. The JSON extraction from a fenced reply, the backoff policy, the two section regexes, the numeric-aware comparison and the .env reader are all code somebody has to own — and a sibling kit's incomplete retry policy cost it two documents of a paid run, which is what a hypothetical maintenance bill looks like when it arrives.
• No framework means no framework's ecosystem — no tracing, no eval harness beyond the one in evals/, no prompt registry, no schema validation library. What ships is what is in the repository.
• The provider abstraction covers exactly two wire formats. A third provider is one function and one dict entry, and until somebody writes it the kit runs on two shapes.

In one lineWhat one run of this kit actually cost, in time and tokens

Measured on r001-label-restrict on the fast tier, 2026-08-22. 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

No movement column. Not one of the 2 earlier runs 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

No drift chart. Only one run has recorded a call latency; the other 2 runs on record made no model call at all — a rules-only floor stores 0, which is an absence, not a zero-millisecond answer. One timed run is a reading, not a trend, and it is in the table above. A chart appears the day a second run times itself.

The other sideWhat this does not tell you

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.

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

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

The wireWhat crosses it, and when

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 shapeHow it ships, and what you add

The ladderEach decision, and what you provision past its ceiling

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

The knobsThe config surface, enumerated

Environment variables: API_KEY, BASE_URL, EMBED_MODEL, EVAL_WORKERS, MAX_CALLS_PER_DAY, MODEL, PORT, PROVIDER.

The other sideWhat this page does not claim

The corpus licence, from the Data lens: MIT — this repository's own licence. Every product name, registration number, active substance, field reference and agronomist note is INVENTED and every crop is an ordinary generic crop noun; no manufacturer, distributor, assurance scheme, adviser or regulator is named. The check set this kit ships (data/checks.json) is ILLUSTRATIVE and is not an authority. It was written for this kit and reproduces no real product label, no manufacturer's use instructions, no registration, no approved-use database and no regulator's guidance. Your corpus’s licence is yours to verify, and the labels you write are about your documents.

In one linePer-field exact match, numeric-aware

Does the model's value for each field match gold? String fields are exact after trimming whitespace and punctuation; the fourteen NUMBER fields are compared as numbers, so 3 and 3.0 and “2.5 L/ha” all read as the value the page states. Five fields are legitimately null — three label intervals an extract does not state, the days since an application that was never made, and a days-to-harvest the proposal omits — so a null there is a hit, not a miss, when gold agrees.

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 floor is scored by — a floor and a real run scored by two different scorers cannot be compared honestly.

Every grader on these pages scored the same 52 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.

The inputOne real row, seen by every grader

The formulaWhat it computes

The analysisWhat it actually did

In operationWhat to monitor

Reference standard: tools/build_corpus.py's gold, read back off the same values the page states; evals/check_labels.py asserts every non-nullable field is populated on every row, that days_since_last_application's nullness agrees with a zero season count in BOTH directions, and that each of the five hard cases clears its own floor, before any run is allowed to spend.

How tight can the band be? There is no tolerance band on the string fields — exact match after trimming. The number fields compare with a 1e-9 epsilon, which is a float-equality guard and not a scoring tolerance.

Cadence: Re-score on any change to data/checks.json, src/prompt.py, data/fields.json or tools/build_corpus.py — the first three change what is asked, the fourth 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

In one lineThe verdict, four-way and collapsed onto may-go-ahead

Two questions at once. Four-way: did the run land on the same verdict the check-set walk produces — within_label, wait_required, outside_label or insufficient_information? And the one that decides whether a sprayer goes out: OF EVERY PROPOSAL THAT MUST NOT BE MADE AS IT STANDS, HOW MANY DID THE RUN STOP? not within_label is the positive class, and the expensive direction — a proposal the check set would have stopped that the run cleared — is counted and named on its own as unsafe_clearance, never averaged into an accuracy figure where it disappears.

MethodHow the test was run

evals/judge.py::score_verdicts, in-process, no key and no model.

Every grader on these pages scored the same 52 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.

The inputOne real row, seen by every grader

The formulaWhat it computes

The analysisWhat it actually did

In operationWhat to monitor

Reference standard: Gold's verdict is re-derived inside the grader by the same walk the kit publishes — src/checks.py::decide(), reading data/checks.json — so the truth this matrix grades against can never be a separately-typed label that drifted from the rule.

How tight can the band be? No threshold — the verdict is one of four allowed values, and a reply returning none of them is counted as unanswered rather than folded into a correct cell. On a label check that distinction is the whole difference between a proposal nobody cleared and one somebody cleared.

Cadence: Re-run whenever data/checks.json or src/checks.py changes, whenever the corpus is regenerated, and on any provider or model change.

The decisionWhen to reach for it

In one lineThe deciding restriction — and right verdict, wrong restriction

Did the run name the SAME restriction the walk stopped at? This is the grader this kit exists for. A verdict is one of four words; a deciding restriction is the actual answer to “so what do I do”. wait_required naming the pre-harvest interval on a case that turns on the re-entry interval is right on the grader above and useless in the field — the grower waits the wrong number of the wrong unit from the wrong date. That case is counted on its own as right_verdict_wrong_reason, over the cases that HAVE a restriction to name, and never averaged into the verdict figure.

MethodHow the test was run

evals/judge.py::score_verdicts, in-process, no key and no model.

Every grader on these pages scored the same 52 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.

The inputOne real row, seen by every grader

The formulaWhat it computes

The analysisWhat it actually did

In operationWhat to monitor

Reference standard: Gold's deciding restriction is re-derived inside the grader by the same walk — src/checks.py::decide() returns the verdict and the restriction from one pass, so the two truths cannot disagree with each other either.

How tight can the band be? No threshold — the restriction is one of nine allowed ids and gold is exact.

Cadence: Re-run whenever the ORDER of data/checks.json changes, even if no check's content does. Reordering the walk moves this grader's truth on every case with more than one breach while leaving the verdict grader untouched on most of them.

The decisionWhen to reach for it

In one lineneeds_hold against the same rule run over gold

Does the pure-code hold decision — not inside the label AND already applied — land on the same fields it would land on if both values had been read perfectly? It is a BUSINESS CONDITION, so unlike a self-consistency check it genuinely needs labels, and saying so is half of what makes the number believable.

MethodHow the test was run

evals/judge.py::score_verdicts, in-process, no key and no model.

Every grader on these pages scored the same 52 already-recorded answers. Nothing was re-generated, so this compares rulers and not models.

The inputOne real row, seen by every grader

The formulaWhat it computes

The analysisWhat it actually did

In operationWhat to monitor

Reference standard: src/extract.py::compute(), the same function the run uses, applied to GOLD's verdict and application_status. One rule, two inputs, so a change to the rule moves both sides together and the grader cannot silently grade an old policy.

How tight can the band be? No threshold — two values and a comparison.

Cadence: Re-run whenever compute() changes. Changing WHAT GETS HELD is a policy change and must be re-scored, even though it never changes what is inside the label.

The decisionWhen to reach for it