The business caseThe problem this solves

An option on a property is a clock, and the clock is not written down anywhere. What is written down is a grant date, a term, a list of extensions with what each one needed and what the file says happened, and a status column somebody typed. Whether the option is still alive is arithmetic over those, in an order — and the register carries three things beside the answer that look like evidence and are not: the status column itself, the clerk's remark on the file, and an extension entry reading 'recorded: exercised' whose payment or notice never actually happened. The cost of getting it wrong is asymmetric and both directions hurt: an option quietly lapsed is a property somebody else can option tomorrow, and a queue full of options that were never in trouble is a queue nobody reads by the second week. Somebody opening each property's rights register, finding what the agreement says starts the option clock, checking whether the triggering event has actually happened, working out which of the recorded extensions were genuinely PERFECTED — a payment reference and a payment date against a payment-controlled one, notice served on the grantor of record for a notice-controlled one — adding the months from the clock start rather than from the date somebody exercised, and only then comparing against the date the snapshot is current as at. It is a few minutes per property and it is every property in the book, every sweep. And the part that goes wrong is not the arithmetic: it is believing the status column, counting an extension the register records as exercised whose act never happened, treating a triggering event that has not occurred as time in hand, and breaking a tie between two grant dates that the agreement does not let you break.

The inputThe actual rights register snapshots

The corpus is 50 rights register snapshots, 0.05 MB (txt 50). Plain text, one format, invented rather than fetched — a real rights register names a real author's work, a real company's money, a named clerk's own remark and a live commercial position on a property that has not been announced, and there is no public corpus of (register, correct status) pairs for the same reason there is no public corpus of bank statements. Generating it also makes the label mechanical: gold's status is the rulebook count over the same values the register states, never somebody's reading of the status column.

Register
--------
RGT-9140-DN

Property
--------
"Two Rivers Deep" -- graphic novel

Rights Holder
-------------
Fenmarket Books Limited

Grantee
-------
Harrowgate Screen Limited

Register As Of
--------------
2026-08-20

Option Granted
--------------
2025-10-18 (option agreement, executed copy)

Clock Basis
-----------
grant_date -- the option period runs from the date the option was granted

Triggering Event
----------------
not applicable -- this option carries no triggering event

Initial Option Period
---------------------
12 months

Extension One
-------------
12 months, perfected by payment
recorded: not exercised

Filing History
--------------
file opened 2024-09-13 by the rights desk
last reindexed 2026-08-13
file class: dramatic rights, single-property register

Register Status
---------------
live

Clerk Note
----------
Escalated internally last week; nobody has come back on the paperwork yet.

The outcomeWhat a good result looks like

A seventeen-field extracted record per register, plus a pure-code count taken from eight of those fields: the date the clock started, the counted expiry, how many days that is from the snapshot's own as-of date, and one of four statuses. Plus one routing signal — an option that is not live and is still carried as live is the one nobody is looking at. The answer carries the count that produced it and names what it could not determine. Nothing here exercises, renews, lapses, files or contacts anybody, and nothing watches anything.

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.

• Sweeping a rights book for options that have lapsed or are about to, before a business-affairs desk opens them — the fast tier, with the count in code
  50 of 50 statuses and 41 of 41 counted expiries against the free status-column floor's 40 pct and 0 of 41 — and, the number that decides whether the queue gets read, 0 false alarms of 17 against the floor's 8.
• Deciding whether to let the model do the arithmetic — no — count in code, every time
  the model's own stated status was wrong on 1 of 50 registers, and it was a false alarm: an option with six months left called lapsed a year early, on a short-month clamp, beside a worried clerk note that made it look corroborated. The count was right on all 50. And the same register re-asked once came back correct, so the failure is not even reproducible.

And where nothing here is good enough:

• Deciding whether this shape is worth buying at all, from these numbers — nothing yet — this corpus cannot answer it
  One scored run, one tier, no repeat and no ablation. Every published figure is either perfect or zero, so nothing here separates two models, two runs of one model, or a full prompt from a stripped one. What the numbers DO support is narrower and real: reading a status column is measurably unsafe on this shape of decision in BOTH directions, and a no-gold consistency check catches 26 of the 30 status errors that shortcut makes.

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-option-clock. 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 on 127.0.0.1:8843, the 50-register picker populates, the field table draws its seventeen empty rows and the shipped rulebook renders in full from data/rulebook.json; clicking Read the clock returns the no-key sentence rather than a stack trace, and the counted panel shows dashes rather than inventing a status. python -m evals.check_labels and python -m evals.run --baseline both pass 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 register snapshot — measured with 12 concurrent workers, so these are the per-call times seen UNDER concurrency and are wider than a serial run's would be. The whole 50-register run was 48.5 seconds of wall clock.

Current processWhat it replaces

Somebody opening each property's rights register, finding what the agreement says starts the option clock, checking whether the triggering event has actually happened, working out which of the recorded extensions were genuinely PERFECTED — a payment reference and a payment date against a payment-controlled one, notice served on the grantor of record for a notice-controlled one — adding the months from the clock start rather than from the date somebody exercised, and only then comparing against the date the snapshot is current as at. It is a few minutes per property and it is every property in the book, every sweep. And the part that goes wrong is not the arithmetic: it is believing the status column, counting an extension the register records as exercised whose act never happened, treating a triggering event that has not occurred as time in hand, and breaking a tie between two grant dates that the agreement does not let you break.

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
• 1 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; a register with none falls back to one whole-document segment

SetupWhat the setup figure measured

There is no index. Preparation is segmentation only — 50 registers cut into 673 sections in under two thousandths of a second, in process, with no model and no network. And there is no state of any other kind either: nothing is stored between documents, because nothing in this kit watches anything.

LicenceLicence

MIT — this repository's own licence. Every property title, rights holder, grantee, agent, register reference, payment reference and clerk note is invented; no real work, studio, streaming service, publisher, distributor, guild, union, agency, label, trade body, court, docket, production or person is named anywhere in this kit. The counting rulebook it ships (data/rulebook.json) is ILLUSTRATIVE and is not an authority. It was written for this kit and reproduces no option agreement, standard form, rights-management system's own logic, guild or trade-body schedule or statute.

Bring your ownBring your own rights register snapshots

REPLACE data/rulebook.json FIRST. It is this kit's own construction, it reproduces no agreement anybody signed, and everything downstream reads it: src/rulebook.py loads it, src/prompt.py renders it into every call, and tools/build_corpus.py writes gold with it. Then replace data/corpus/*.txt, write your own data/fields.json, and supply a gold record per register. SECTION_HINTS in src/select.py maps fields to section headings and will need editing for a different register 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 escalation 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.

AssemblyHow the prompt is assembled

This is the cost lesson as arithmetic: of the 3,292 tokens assembled, 1,357 are contexts — 41% 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 ROR-0020 — the same register the worked example above was captured on, so the four parts sum to exactly the 3,292 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/UC0050-option-clock/results/tokens-p002-option-clock.json. ⚑ THE SAME MEASUREMENT ON A DIFFERENT REGISTER (ROR-0033, tokens-p001-option-clock.json) returned 1,003 / 1,039 / 932 for the first three parts — byte-identical — and 273 for the fourth, which is the only part that moves: ROR-0020 carries two extension blocks and ROR-0033 one. That is the evidence that the 2,974-token fixed prefix really is fixed and is paid on every one of the 50 calls.

Full promptThe prompt in full

You read a RIGHTS AND OPTION REGISTER SNAPSHOT for one property and extract structured fields from it. You return JSON and nothing else.

You are PROPOSING a worklist for a qualified person to read the agreement against. You never exercise, renew, lapse, file or release anything, and you are not a substitute for the executed option agreement or for a lawyer's reading of it. You are not watching this register: you are reading ONE snapshot of it, as it stood on the date it states.

RULES, in order of importance:
1. If the register does not state a field, return null for it. Do not infer it and do not use what you know about how options usually work.
2. `expiry_date` and `status` are decided ONLY by the COUNTING RULEBOOK given below, applied to the register's own values. Work through these four steps IN ORDER:
   a. WHAT STARTS THE CLOCK. If the Clock Basis says grant_date, the clock starts on the grant date. If it says triggering_event, the clock starts on the date the Triggering Event section records the event as having OCCURRED. If that event has not occurred, the period has not started, no expiry can be counted, and the answer is 'not_determinable' -- it is NOT 'live'.
   b. A CONTRADICTED DATE IS NOT SETTLED. Look at how many dated entries the Option Granted section carries.
      - ONE entry: that is the grant date. Return it in option_granted_date. This is true whatever the Clock Basis says -- a triggering-event clock does not make a stated grant date disappear, it just does not count from it. NEVER return null for option_granted_date when the section states exactly one date.
      - TWO entries that disagree: the grant date is not settled, so return null for option_granted_date. Do NOT pick the earlier entry, the later entry, or the one from the more official-looking source. Then: if the clock runs from the GRANT DATE, there is nothing to count from and the answer is 'not_determinable'; if the clock runs from a TRIGGERING EVENT that has occurred, the grant date is not an input at all, the disagreement changes nothing, and you carry on counting normally from the trigger date.
   c. WHICH EXTENSIONS ACTUALLY COUNT. Only PERFECTED ones. An extension entry saying 'recorded: exercised' is a clerk's entry, not an act. A payment-controlled extension is perfected only when a payment reference AND a payment date are recorded against it. A notice-controlled extension is perfected only when notice was served on the GRANTOR OF RECORD -- the party named in the Rights Holder section. Service on an agent, a co-financier, an escrow agent or the grantee's own counsel does NOT perfect it, however customary that is.
   d. ADD THE MONTHS AND COMPARE. Expiry = the clock start, plus the initial term, plus the length of each PERFECTED extension. Extensions run consecutively from the end of the period they extend, NEVER from the date they were exercised. Add the whole term in calendar months in one step from the clock start, keeping the same day of the month and falling back to the last day of a shorter month. Then compare against the register's own As Of date and the window the rulebook names.
3. THE REGISTER'S OWN STATUS LINE IS NEVER AN INPUT. `register_status` is what somebody last typed. Report it as stated and then ignore it. It is often wrong on this kind of record, in both directions, and it has no word at all for an option lapsing inside the window or for one the paperwork does not settle.
4. THE CLERK'S NOTE IS A FIELD TO COPY, NOT EVIDENCE ABOUT THE CLOCK. A note that sounds worried does not shorten a term and a note that sounds relaxed does not lengthen one. The count decides; the note is one person's remark and may disagree with it.
5. Copy titles, party names and the clerk's note verbatim. Return every date as an ISO date, YYYY-MM-DD, exactly as the register writes it.
6. Use the exact allowed value for a field that lists them.
7. Return every field named in the schema, even when the answer is null.

COUNTING RULEBOOK (the authority for `expiry_date` and `status`; this is an ILLUSTRATIVE rulebook shipped with this kit, not an agreement and not a standard form)

WHAT STARTS THE CLOCK
  grant_date:        the option period runs from the date the option was granted
  triggering_event:  the option period runs from the date the triggering event ACTUALLY OCCURRED. Until it occurs, the period has not started and no expiry can be counted -- the answer is not_determinable, and it is not 'live'
  AN OPTION WHOSE CLOCK HAS NOT STARTED IS NOT AN OPTION WITH A LONG TIME LEFT. It is an option nobody can date, and the honest answer is that it cannot be determined from the register. Reading it as 'live' is the single most comfortable mistake on this shape of record, because it removes a row from the worklist and looks like good news.

A CONTRADICTED DATE
  A CONTRADICTION BLOCKS ONLY THE DATE THE CLOCK ACTUALLY RUNS FROM. Where two entries on the register disagree about the grant date AND the clock runs from the grant date, the clock start is not settled: answer not_determinable, and do NOT pick the earlier entry, the later entry, or the one from the more official-looking source. Where the clock runs from a triggering event that has occurred, the grant date is not an input at all, and a disagreement about it does not block the count -- flagging that record is a FALSE ALARM.

WHAT PERFECTS AN EXTENSION
  payment-controlled: a payment reference AND a payment date must both be recorded against the extension. An extension the register records as exercised, with no payment recorded, is NOT perfected
  notice-controlled: notice must be served on the GRANTOR OF RECORD -- the rights holder named on the register. Service on an agent, a co-financier, an escrow party or the grantee's own counsel does NOT perfect the extension, however customary the practice
  AN EXTENSION IS PERFECTED BY THE ACT THE AGREEMENT NAMES, NOT BY THE REGISTER RECORDING THAT IT WAS EXERCISED. 'recorded: exercised' is a clerk's entry. The payment and the notice are the acts. Where the register records an exercise the acts do not support, the extension does not stack and the option is shorter than the file believes it is -- which is the whole reason this kit exists.

HOW EXTENSIONS STACK
  A perfected extension runs CONSECUTIVELY from the end of the period it extends, never from the date it was exercised. An extension exercised early does not shorten the option and one exercised late does not lengthen it. Expiry = clock start + the initial term + (the length of each PERFECTED extension). Only perfected extensions are added.

HOW MONTHS ARE ADDED
  Months are added calendar-wise and never as 30-day blocks. 2025-01-31 plus one month is 2025-02-28; plus one more is 2025-03-28, not 2025-03-31 -- each addition is taken from the ORIGINAL start date and the whole term is added at once, so the clamping cannot compound. Counting in days instead moves an 18-month option by up to five days, which is the difference between 'live' and 'lapsing' on a 45-day window.

THE WINDOW
  45 days. How far ahead 'lapsing' looks. 45 days is this kit's own number and is not a market convention: it was chosen because it is long enough that a payment or a notice can still be got out, and short enough that a worklist stays readable. A real desk would set it per property, per counterparty, or per what the exercise costs.

THE FOUR STATUSES
  lapsed:            expiry on or before the register's as-of date
  lapsing:           expiry after the as-of date and on or before as-of plus the window
  live:              expiry after as-of plus the window
  not_determinable:  no expiry can be counted from what the register states

WHAT IS NOT EVIDENCE
  The register carries its own status line -- live or lapsed -- and it is NEVER an input to this count. It is what somebody last typed, and this kit's whole subject is the gap between that and the arithmetic. Note also what the line cannot express even when it is right: it has no word for 'lapsing inside the window' and no word for 'the paperwork does not settle it'. A status column with two values cannot carry a four-value answer.
  The clerk's note is one person's remark on the file. A note that sounds relaxed does not add a day to the term and a note that sounds worried does not remove one. It is extracted, it is displayed, and it decides nothing.

Extract these fields:
- register_id (string) -- the rights register file identifier, verbatim
- property_title (string) -- the title of the optioned property ONLY -- the text inside the quotation marks, verbatim and without the quotation marks themselves. The register writes the form of the work after a double dash (for example: "A Title" -- stage play); the form is NOT part of the title and must not be returned
- rights_holder (string) -- the party that granted the option -- the GRANTOR OF RECORD, verbatim. This is the party a notice has to be served on for a notice-controlled extension to be perfected
- grantee (string) -- the party holding the option, verbatim
- register_as_of (string) -- the date this register snapshot is current as at, as an ISO date (YYYY-MM-DD). This is the 'today' the whole count is measured against -- it is NOT today's real date
- option_granted_date (string) -- the date the option was granted, as an ISO date (YYYY-MM-DD). Where the Option Granted section states exactly ONE date, return it -- always, whatever the Clock Basis says. ⚠︎ ONLY where the section carries TWO dated entries that DISAGREE about the same grant, return null: the register does not settle it, and you must not pick the earlier one, the later one, or the one from the more official-looking source
- clock_basis (enum) one of: grant_date, triggering_event -- what the agreement says starts the option clock, as the register's Clock Basis section states it
- trigger_status (enum) one of: not_applicable, occurred, not_occurred -- whether the triggering event has happened. 'not_applicable' when the clock runs from the grant date and there is no triggering event at all
- trigger_date (string) -- the date the triggering event actually occurred, as an ISO date (YYYY-MM-DD). null when there is no triggering event, or when there is one and it has not occurred
- initial_term_months (integer) -- the length of the initial option period in whole months, as a number
- extension_months_each (integer) -- the length in whole months of each extension the agreement grants, as a number. Every extension in a chain is the same length in this register's format
- extensions_recorded_taken (integer) -- how many extensions the register RECORDS as exercised -- count the extension entries whose 'recorded:' line says exercised. This is what the file claims; it is NOT what decides the expiry
- extensions_perfected (integer) -- how many of those extensions were actually PERFECTED under the rulebook -- a payment-controlled extension needs BOTH a payment reference and a payment date recorded against it; a notice-controlled extension needs notice served on the rights holder named on this register, and service on an agent, a co-financier, an escrow party or the grantee's own counsel does not count. An extension recorded as exercised whose act is missing or misdirected is NOT perfected
- register_status (enum) one of: live, lapsed -- the status the register itself carries in its Register Status section, copied verbatim. Report it as stated -- it is NOT what decides the answer
- clerk_note (string) -- the rights clerk's own free-text remark on the file, copied verbatim
- expiry_date (string) -- the date the option expires, counted under the rulebook: the clock start, plus the initial term, plus the length of each PERFECTED extension, in calendar months. Return null when no expiry can be counted. This date is nowhere on the register -- it is the count
- status (enum) one of: live, lapsing, lapsed, not_determinable -- the option's status against the register's own as-of date, from the counted expiry. 'lapsed' when the expiry is on or before the as-of date; 'lapsing' when it is after the as-of date and on or before as-of plus the window the rulebook names; 'live' when it is beyond that; 'not_determinable' when no expiry can be counted -- a triggering event that has not occurred, or two entries disagreeing about a grant date the clock runs from. Decide it STRICTLY from the count -- never from register_status and never from clerk_note

Return a JSON object with exactly these keys: register_id, property_title, rights_holder, grantee, register_as_of, option_granted_date, clock_basis, trigger_status, trigger_date, initial_term_months, extension_months_each, extensions_recorded_taken, extensions_perfected, register_status, clerk_note, expiry_date, status
Use null for any field the register does not state.

RIGHTS AND OPTION REGISTER
--------------------------
Register
--------
RGT-4807-JA

Property
--------
"The Ledger of Storms" -- unpublished novel

Rights Holder
-------------
Fenmarket Books Limited

Grantee
-------
Bright Quarry Media LLC

Register As Of
--------------
2026-08-14

Option Granted
--------------
2024-09-12 (option agreement, executed copy)

Clock Basis
-----------
triggering_event -- the option period runs from clearance of the underlying life-story consents

Triggering Event
----------------
clearance of the underlying life-story consents
occurred: 2025-04-21

Initial Option Period
---------------------
12 months

Extension One
-------------
12 months, perfected by payment
recorded: exercised 2025-11-01
payment: none recorded against this extension

Extension Two
-------------
12 months, perfected by notice
recorded: not exercised

Register Status
---------------
live

Clerk Note
----------
Clean file, nothing for the desk to do here as far as I can see.

Raw responseThe raw response

{
  "register_id": "RGT-4807-JA",
  "property_title": "The Ledger of Storms",
  "rights_holder": "Fenmarket Books Limited",
  "grantee": "Bright Quarry Media LLC",
  "register_as_of": "2026-08-14",
  "option_granted_date": "2024-09-12",
  "clock_basis": "triggering_event",
  "trigger_status": "occurred",
  "trigger_date": "2025-04-21",
  "initial_term_months": 12,
  "extension_months_each": 12,
  "extensions_recorded_taken": 1,
  "extensions_perfected": 0,
  "register_status": "live",
  "clerk_note": "Clean file, nothing for the desk to do here as far as I can see.",
  "expiry_date": "2026-04-21",
  "status": "lapsed"
}

Step 06 of 14Evals

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

In brief

Check a rights register for film options about to lapse — 50 rights register snapshots. 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 run 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.

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 status-column 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 ONE scored run's own token counts (50 registers) 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. Four further paid passes sit outside it: a 6-register calibration that measured max_tokens and caught a schema defect ($0.0247), the superseded 50-register pass lost to the token ceiling ($0.2829), 8 prompt-split calls ($0.0093), and two worked-example captures plus one screenshot call ($0.0138). All 117 live calls together project to $0.5662 on this card.

Cost driversWhat actually moves the bill

• The fixed prefix — system prompt (1,003 tokens), counting rulebook (1,039) and field schema (932) — is 2,974 of 3,292 tokens on the example call, 90.3 pct, and is byte-identical on every one of the 50 calls. The register itself is 318 tokens. The bill is the rulebook and the instructions, not the document.
• Provider-side reasoning. 41,851 of r001's 51,275 output tokens (81.6 pct) were reasoning rather than the JSON record, on a seventeen-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 — which matters more on this kit than on most, because the reasoning is where the model does the arithmetic this kit then throws away and redoes in code.
• Output length: the model returns a full seventeen-key JSON record every call, including the clerk's note copied back verbatim, whatever the register says.

Your volumeWhat it costs at your volume

Linear in registers: each call is independent, carries the same fixed prefix and shares nothing with its neighbours, so 500 registers cost ten times 50. Nothing amortises — there is no index and no cache. ⚠︎ AND THE REAL COST OF A MONITORING SWEEP IS NOT ONE PASS, IT IS EVERY PASS. A book you check monthly is twelve times this number a year, and every pass re-reads every register from scratch even though almost nothing about them changed. The obvious saving — store the counted expiry, recount only what moved — is not in this kit and is not a prompt change.

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: 50 rights-register snapshots, one completion call each, on the fast tier. The superseded ceiling pass, the calibration, the prompt-split calls and the worked examples are recorded separately in Cost.cost_of_evaluation_usd and are not projected here.

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.

Five 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 register snapshot into addressable sections, pure code

# 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 — the count is mapped to the eight facts the rulebook actually reads plus the Rights Holder section a notice has to be served on, never to the register's own status line and never to the clerk's note, and the Filing History block is mapped by nothing and never sent

You change it to: map fields to your own register'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/rulebook.pyrulebook

the count, loaded from data/rulebook.json — what starts the clock, what perfects an extension, how extensions stack, calendar-month arithmetic with a short-month clamp, and the window. Data, not code, so a forker can open it and disagree with it

# THE COUNTING RULEBOOK, loaded from data/rulebook.json. Pure code, no model, no network.

HERE = os.path.dirname(os.path.dirname(os.path.abspath(__file__)))
RULEBOOK_PATH = os.path.join(HERE, "data", "rulebook.json")
STATUSES = ("live", "lapsing", "lapsed", "not_determinable")
CLOCK_BASES = ("grant_date", "triggering_event")
TRIGGER_STATES = ("not_applicable", "occurred", "not_occurred")
REGISTER_STATES = ("live", "lapsed")
NEEDS_ACTION = ("lapsing", "lapsed", "not_determinable")
def load(path=RULEBOOK_PATH):
R = load()

src/prompt.pyprompt

assemble one call for all seventeen fields, with the rulebook RENDERED into it from data/rulebook.json rather than restated in prose — a rulebook the model has never been shown is not a rulebook

# Assemble the option-clock prompt. One prompt per register snapshot, all seventeen fields in it.

SYSTEM = (
def rulebook_block(r=None):
RULEBOOK_TEXT = rulebook_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 count that produces the PUBLISHED answer, and the business-condition check downstream: an option that is not live and still carried as live is escalated

You change it to: the escalation rule itself — this kit ships two values (not live AND still carried as live) and a real desk weighs what the property is worth, whether anybody still wants it, and who has authority to spend the exercise money. It is deliberately NOT the same function as the count, so changing WHAT GETS ESCALATED does not change WHAT HAS LAPSED

# Extract one rights-and-option register snapshot: segment, select, prompt, one model call, then a

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 = 16000
def load_fields():
def load_doc(register_ref):
def documents():
def count(values):
def counted_status(values):

evals/judge.pyjudge

score field accuracy, the four-way status, the counted expiry, the false-alarm and missed-lapse rates and the escalation flag, all separately, pure code

# Score an option-clock run. PURE CODE -- gold is exact and the answer is one value per cell, so

def norm(v):
def equal(field, got, want):
def score(fields, records, golds):
def _matrix(rows, positive):
def _values_of(rec):
def score_clock(records, published, 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: 3268 input and 1025 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 register snapshots are entirely synthetic (tools/build_corpus.py, seed 20260822): no real work, company, person, agreement or file exists in the corpus, and nothing was fetched from anywhere. The only outbound traffic the kit makes is one chat-completion request per register to the configured provider, carrying the mapped sections of one register plus the fixed prompt and the shipped rulebook. Nothing is written outside the kit directory, there is no database, no auth and no multi-tenancy, the local UI binds 127.0.0.1 only, and nothing runs on a schedule — there is no background process in this kit at all.

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.

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 exercises, renews, lapses or releases anything; nothing in the kit schedules, polls or runs unattended; and the count reads eight typed values, so neither the clerk's note nor the status column can reach the arithmetic. The fourth is open. An indirect prompt injection needs a field an outside party authored, and this kit has exactly one — the clerk'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 clerk's note is exactly the attack this kit's shape invites, and nothing here has tried it.

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 clerk's note is free text a third party wrote, and whether an instruction hidden in it could move one of the eight values the count reads 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 an option that lapsed four months ago — which measures whether a model does the count 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 clerk_note field could move one of the eight extracted values the count reads. 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 rights register would carry anything sensitive this kit mishandles. The corpus has no personal data by construction; a real register carries an author's name, a company's commercial position and an unannounced project, 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.

escalate_now fires when the COUNTED status is anything other than `live` AND the register still carries itself as `live` — status != "live" and register_status == "live". The status comes from the pure-code count over whatever the model returned, never over gold; the carried status is an extracted field. `not_determinable` counts as not-live, deliberately: a record nobody can date, carried as live, is precisely the row to open first. 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 register, by the local app on every click, and by evals/baseline.py on the free floor's own published status so the two are routed by identical code. It takes the published status as an ARGUMENT rather than recounting it, which is what makes that possible. The count it reads lives in a SEPARATE module, src/rulebook.py::decide(), which is also what the corpus generator wrote gold with and what src/prompt.py states to the model — one definition, three readers.

EvidenceDoes it hold?

The limitWhat a guardrail is not

• It is NOT an exercise, a renewal, a lapse notice or a release. Nothing here acts on an option, notifies anybody or writes to any system, and status is a count with its own arithmetic attached rather than a decision anybody is bound by. A qualified person reads the executed agreement.
• It is NOT a monitor. There is no schedule, no poller, no subscription, no queue and no state between documents. Every use of this kit is somebody handing it one snapshot and asking once.
• It is NOT a check on whether the extracted values are right. If the model misreads a trigger date or an extension entry and the code then counts correctly from the misreading, the register is escalated (or not) 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 a rights desk's real escalation policy. Not-live-and-still-carried-live is this kit's own simplification, invented for this corpus. No company's procedure was consulted, and none is reproduced. A real desk weighs what the property is worth, whether anybody still wants it, whether the counterparty would grant a fresh option anyway, and who has authority to spend the exercise money.
• It is NOT a judgement about the rulebook. The flag reads the status the rulebook produced; if the rulebook is wrong, the flag is confidently wrong with it. The shipped rulebook is illustrative and is not an authority.

WatchedWhat is watched, and why that one

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 run 7 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 50, extraction_cells 850, 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

5 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 — 4 runs. Columns here are only ever compared with each other.

not a time series No two of these 4 runs measured the same system — they differ on documents, extraction_cells, failures, 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 5 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/rulebook.json (which moves the status the flag reads), on any change to data/fields.json's allowed values for status or register_status, and on any corpus regeneration. Changing WHAT GETS ESCALATED is a policy change and must be re-scored, even though it never changes what has lapsed.

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 rulebook is a JSON file read with json, the date arithmetic is datetime and calendar, 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. ⚑ AND NOTE WHAT IS ABSENT FOR A 'MONITORING' KIT: no scheduler, no queue, no task runner, no store. That is not minimalism, it is the scope — the kit reads one snapshot and returns an answer, and everything a monitoring SYSTEM does around that is deliberately outside it.

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 register — segment, select, prompt, one call, parse, count, route — with no branch, no loop, no agent and no schedule. Anything that looks like orchestration in a kit this size is a diagram of a straight line, and anything that looks like monitoring in it is a diagram of a straight line somebody runs twice.

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 section regex, the .env reader — and the calendar-month arithmetic, which is the one a reader should look at hardest, because a date library would have been a defensible dependency and this kit chose to write six lines instead.
• 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.
• And the absent scheduler is a real cost the moment somebody wants this to actually watch something. A monitoring system needs state (what did we count last time), idempotence (do not re-alert on a row a human cleared) and a clock — none of which is here, and none of which is a small addition to a kit built to read one document.

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

Measured on r001-option-clock 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 4 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

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.

2 runs not plotted. b000-option-clock-register, t000-option-clock-stub recorded no call latency at all — a rules-only floor run makes no model call, and the 0 its record stores is an absence, not a zero-millisecond answer. Plotting it would put a bar on this chart claiming the fastest run in the kit’s history.

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 property title, rights holder, grantee, agent, register reference, payment reference and clerk note is invented; no real work, studio, streaming service, publisher, distributor, guild, union, agency, label, trade body, court, docket, production or person is named anywhere in this kit. The counting rulebook it ships (data/rulebook.json) is ILLUSTRATIVE and is not an authority. It was written for this kit and reproduces no option agreement, standard form, rights-management system's own logic, guild or trade-body schedule or statute. Your corpus’s licence is yours to verify, and the labels you write are about your documents.

In one linePer-field exact match, light normalisation

Does the model's value for each field match gold, after trimming whitespace and punctuation? option_granted_date, trigger_date and expiry_date are the three legitimately-null fields — null where two register entries disagree about the grant date, where there is no triggering event or it has not occurred, and where no expiry can be counted — 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 50 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 register states; evals/check_labels.py asserts every non-nullable field is populated on every row, that a null expiry and a not_determinable status are the same rows in BOTH directions, that every date parses, 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 — it is exact match after trimming whitespace and punctuation, never a continuous score to round. Typographic and straight quotes are NOT folded together, deliberately.

Cadence: Re-score on any change to data/rulebook.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 counted status, four-way and collapsed onto the worklist

Two questions at once. Four-way: did the pure-code count land on the same status the rulebook produces — live, lapsing, lapsed or not_determinable? And the one a worklist actually has: DOES THIS ROW NEED SOMEBODY TODAY, OR NOT? lapsing, lapsed and not_determinable are all yes; only live is no. The two error directions are named separately and never averaged: a FALSE ALARM is a genuinely live option put on the queue, and a MISSED LAPSE is an option that needs somebody reported as live. ⚑ The false alarm is the number that matters most in a monitor kit — a queue that cries wolf is worse than no queue, because a person has to clear every row on it — and the missed lapse is the expensive one, because nobody opens it until somebody tries to exercise.

MethodHow the test was run

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

Every grader on these pages scored the same 50 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 status is re-derived inside the grader by the same count the kit publishes — src/rulebook.py::decide(), reading data/rulebook.json — so the truth this matrix grades against can never be a separately-typed label that drifted from the rule. The run's side is the PUBLISHED answer: for the model that is the pure-code count over its extracted values, for the free floor it is the status column. Scoring the published answer rather than recomputing one for each system is what keeps the two comparable.

How tight can the band be? No threshold — the status 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 monitoring queue that distinction is the whole difference between a register nobody flagged and a register somebody cleared.

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

The decisionWhen to reach for it

In one lineThe counted expiry, exact

Where an expiry can be counted at all, is it the right DATE? An obligation found but mis-dated is a different failure from one missed, and on a 45-day window a date a week out silently changes the status. Scored only over the 41 registers where the rulebook can start a clock; a date produced for one of the other 9 is counted separately as a PHANTOM EXPIRY, because inventing a due date is worse than declining to give one.

MethodHow the test was run

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

Every grader on these pages scored the same 50 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/rulebook.py::expiry(), the same function that wrote gold and that produces the published answer, applied to gold's own values. One definition, so a change to the arithmetic moves both sides together.

How tight can the band be? No tolerance. A date is right or it is not; there is no 'close enough' on a window this narrow.

Cadence: Re-run whenever src/rulebook.py's add_months or data/rulebook.json's month_arithmetic clause changes, and on any corpus regeneration.

The decisionWhen to reach for it

In one lineescalate_now against the same rule run over gold

Does the pure-code escalation — not live, AND the register still carries it as live — land on the same registers it would land on if every field 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_clock, in-process, no key and no model.

Every grader on these pages scored the same 50 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 status and register_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 ESCALATED is a policy change and must be re-scored, even though it never changes what has lapsed.

The decisionWhen to reach for it