Coding Day Handbook

You are not learning to use AI today. You are learning to check it — and the only way to check a machine is to have done the work yourself first, which you have.

What you hand in at the end: your coded rows, the machine's coded rows, a log of where the two disagree, one chart built from your own rows, and a short write-up of one thing the machine got wrong.

The Firefly warning is the one to remember. An image generator has no idea what your data says — it produces a plausible picture of a chart, with numbers it invented. Never reach for one when you are asked to make a figure.

NotebookLM is worth knowing about too. It is genuinely good for asking questions of the roll — which entries mention a church? — but not for coding, because it answers in prose and will not give you a table you can trust row by row.

Step 2 is not housekeeping. A model that has already seen half the volume in an earlier conversation cannot cleanly separate reading this page from remembering that one, and your comparison stops meaning anything. Every roll gets a fresh conversation.

Step 4 matters for a duller reason: small talk before the prompt changes what the model does with the prompt. Paste it cold.

The last line is the one that matters. The chat window hands you text whichever route the tool took, with no label saying where it came from. Everything else today follows from that.

The chain between the clerk and you has four links, and every one of them can introduce error: the clerk's roll, Sharpe's 1913 translation, a 2011 scan, a 2011 OCR pass. The AI is the fifth link. You are the sixth.

How we know: pdffonts and pdfimages, two command-line tools, report the fonts and images inside a PDF in about a second.

The pattern is the point. The fields you have to code do not live in the body prose. They live in the margins, the footnotes, the isolated numerals and the abbreviated money — the parts set in the smallest and most awkward type. A page can be 97% character-accurate and still have an unreadable ward.

One counter-intuitive detail: the money fails on cleanly printed pages. It is not faint ink. It is italic fractions. The failure is typographic, not a question of damage — which is the opposite of what you would assume about a scan of a 1913 book.

How did you read the PDF I just uploaded? Answer in one sentence,
and say specifically whether you extracted an embedded text layer,
ran your own OCR on the page images, or looked at the page images
directly. If you are not sure, say you are not sure.

On printed page 46 there are two consecutive numbered entries,
13 and 14. Give me both entry numbers and both victims' names
exactly as printed. If any character is unclear, write it as you
see it rather than correcting it.

Message 2 has a known answer, which is what makes it a test. The page reads 13. Edmund Poer and 14. Reginald de Freestone. The stored text layer gives 14 … Freesto ie — the numeral and the surname are both damaged.

So: if the tool returns both names cleanly, it either looked at the page or it filled the gap from somewhere else. If it returns the damage honestly, it is reading the text layer and telling you so. If it returns a confident wrong name, you have just watched a quiet failure happen, three minutes into the session, on a slide.

This is prompt design, not prompt tricks. Every item on the list is there because leaving it out produced a specific failure. No closed list and you get 104 spellings of the ward. No "not stated" option and the model invents a relationship rather than leaving a blank. No evidence quote and you cannot settle a disagreement without reopening the page.

ROLL_LETTER = [ ]
CODER_ID    = [ ]

You are helping code medieval coroners' inquests into a dataset. The PDF I
uploaded is one roll from R. R. Sharpe, ed., Calendar of Coroners Rolls of the
City of London, A.D. 1300-1378 (1913).

Produce ONE ROW PER NUMBERED ENTRY, in printed order, with these 20 columns
in exactly this order:

roll, case_number, printed_page, entry_type, inquest_date, date_verbatim,
ward, ward_verbatim, within_without, parish_verbatim, victim_name,
victim_gender, victim_status, manner_of_death, weapon, weapon_verbatim,
perpetrator_name, perpetrator_outcome, chattels_verbatim, evidence_quote

VALUES

entry_type: homicide | accident | death in custody | suicide |
  cause undetermined | no death recorded
manner_of_death: natural | accident | assault | suicide | undetermined | none
victim_gender: male | female | not given
victim_status: gentleman/woman | craftsman/woman | servant/labourer |
  apprentice | prisoner | destitute | cleric/religious | unknown
weapon: bare hands | knife/dagger | club/staff | axe | sword |
  bow and arrow | stone or thrown object | other | no weapon
perpetrator_outcome: captured | surrendered | abjured the realm |
  took sanctuary then escaped | fled, never taken | jury found no felony |
  perpetrator died | outlawed | not stated | no perpetrator
within_without: within | without | not specified | not applicable

RULES

1. "lay dead of a death OTHER THAN his rightful death" = an UNNATURAL death.
   "DIED his rightful death" = a NATURAL death. These mean opposite things.
   Read the phrase carefully before coding manner_of_death.
2. Take the ward from the SENTENCE that names it, never from the marginal
   note. Put the raw spelling in ward_verbatim, modernised in ward.
3. inquest_date is the date at the head of the entry. That is when the body
   was viewed, NOT necessarily when the person died. Do not adjust it.
4. Any value you cannot read, write exactly: ILLEGIBLE
   Any value the entry does not state, write exactly: NOT STATED
   Never infer, never fill a gap from context, never guess a name.
5. chattels_verbatim: copy the money phrase exactly as printed, including
   damaged characters. Do not tidy it.
6. evidence_quote: 5 to 15 words from the entry supporting manner_of_death.

OUTPUT

Write the result to a CSV file I can download. Quote every field. Do not
print the table in the chat.
Filename: roll_[ROLL_LETTER]_ai_[CODER_ID].csv

Then, in the chat and not in the file, tell me:
  - how many rows you produced
  - which case_numbers you could not read
  - which fields you most often had to mark ILLEGIBLE

Read rules 1 and 4 twice. Rule 1 is the trap you have already met by hand. Rule 4 decides whether the output is usable at all: a model that quietly fills gaps produces a beautiful CSV you cannot check, and a model that marks ILLEGIBLE tells you exactly where to look.

Do not skip the three questions at the end. The row count is how you detect a dropped entry, and the ILLEGIBLE summary is a free map of where to spend your verification time.

The last check is counter-intuitive enough to be worth stating twice. A perfectly clean CSV from a page whose margins are visibly wrecked means the gaps were filled, not read. Clean output is evidence of a problem here, not evidence of success.

Be precise about the cause, because it changes what you should trust. This is not the model being wrong — it is the text getting mangled between the model and your clipboard. The model produced Nicholas Crabbe; what landed in the spreadsheet was Nichisbe. Downloading a file avoids the whole class of problem.

If your tool will not produce a downloadable file, ask for the CSV inside a fenced code block and copy from there. Better, still not perfect — spot-check the first and last row either way.

Comparing down a column rather than across a row is a small change with a large effect. It keeps one kind of judgement in mind at a time, so patterns appear — it gets the ward wrong whenever the margin is damaged — which never surfaces when you read across a row and meet twenty unrelated fields at once.

"Do not fix anything yet" matters because the disagreement rate is itself your result. If you silently correct as you go, you have destroyed your own measurement.

Most of your time goes on quiet, because it is the category you will find nothing in unless you go hunting. Loud errors announce themselves. Quiet ones look exactly like correct answers, and the only way to find them is to have the page open next to the row.

Here is the shape of one. The transcription says St. Mary atte Naxe. There is a real London church called St Mary Axe, and a model under pressure produces the real one: the right kind of word, in the right place, and not what the page says.

A high count of rule gaps is a good outcome, not a messy one. Those are the amendments that improve the codebook for everyone.

How this is graded: on disagreements found and explained, not on how few you had. A log with three entries for a roll whose margins are visibly wrecked earns a conversation, not a good mark.

The figure is built on your verified rows, not the machine's raw output. Otherwise the whole comparison gets quietly undone at the last step, and you end up charting the errors you just spent twenty minutes finding.

The attached CSV is my own hand-verified coding of Roll [ ] of the London
coroners' rolls, [ ] rows.

First, count the values in the column `manner_of_death` and show me the
counts as a plain table. Do not chart anything yet.

Then, after I confirm the counts, make a single horizontal bar chart of
those counts, with:
  - categories sorted from most to least frequent
  - the count printed at the end of each bar
  - the title: "Manner of death, Roll [ ] (n = [ ])"
  - no 3D, no gradient, no drop shadow, no pie chart
  - one colour for all bars, since the categories are not ranked

Tell me if any rows were excluded from the count and why.

The two-step structure is the whole point: counts first, picture second. A chart is a claim about numbers, and once it is a picture nobody checks the numbers again. Asking for the table first makes the claim inspectable while it is still text.

The last line catches a real failure. Tools silently drop blank cells and rows they cannot parse, so a chart of 34 rows from a 39-row file is a different finding from the one you think you are reporting.

Swap manner_of_death for whichever column suits your question — weapon, perpetrator_outcome, ward. Same structure every time.

Try it once if you want to see it for yourself: ask an image generator for "a bar chart of causes of death in medieval London" and read the axis labels. They will be nonsense, confidently drawn.

The rule underneath: a tool that generates pixels and a tool that computes over your data are different kinds of thing, and the interface does not distinguish them. That distinction will keep mattering long after this course.

Use Route B for anything with a chart in it. Route A is faster, but it re-flows the layout and sometimes drops an image; Google Docs lets you see the document before it becomes a file.

One rule on captions, and it is a research habit rather than a formatting rule: the caption must name the field, the roll and the n. A figure that does not say what it counted, or how many, is not evidence of anything.

The five failures most likely to hit you while twenty people work at once. Keep this tab open while you work.

1. Diagnostic — slide 8, two messages. Run before anything else, with the roll uploaded.
2. Coding prompt — slide 10. Fill in ROLL_LETTER and CODER_ID, change nothing else.
3. Chart prompt — slide 17. With your own verified CSV attached. Counts first.
4. Word file — slide 19. "Put this into a Word document I can download", or Google Docs → File → Download → Microsoft Word.