Billingsgate market, London. Still from BBC: The Fish Market - Inside Billigsgate, 2017. Archive.org

I have been history vibe coding now for four months. Prior to that I have thirteen years experience running highly collaborative public history projects. My best known project is Marine Lives (2012+), but others include a two day Maphackathon at the London Museum of Docklands (2017), a textiles, garments and dyestuffs collaborative glossary (2017-2018), Viae Regiae (during that weird Covid time, 2021-2022), and most recently the ai + history collaboratory I convene (2024+). I have been working with Google’s AI Studio and more recently with Anthropic’s Claude Cowork. It is fun and revelatory.

So here is an offer to historians. I am offering to coach and support any of you who want to take the plunge with a first history vibe coding project. No matter how small or big. Any topic.

Why am I making this offer? Firstly, I like helping people. Secondly, I want to equip you with some basic skills and tempt you to attend the next session of the ai + history collaboratory I convene, which meets by ZOOM on Tuesday, March 31st at 4 pm UK time, 5 pm Paris, Berlin, Vienna and 11 am East Coast US. Our topic is Cowork for Historians: Skills and Workflows.

You can check out my most recent vibe coding project here, which was to create a static IIIF viewer for the Ottoman government gazette, 1831.

Some vibe coding project ideas

Here are six projects, pitched at historians who have never coded. You describe what you want in plain language; the AI builds it, methodically, with you architecting, planning, designing and building alongside. My approach to vibe coding is socratic and interactive. You learn as you do. YOU DO NOT PRESS A BUTTON AND GAWP AT THE OUTPUT. Each suggested project will produce a working research tool.

1. Estate and probate inventories. You have a stack of inventories and are somewhat daunted. Build a tool that extracts items room by room, categorises them, standardises valuations, and lets you compare across dozens of documents. I can provide 140+ seventeenth-century London inventories from the Marine Lives project as starter material.

Extract from inventory of Thomas Tomlins esq., of St. Lonard's Bromley, Middlesex. Proven 1678 3 Sept. Written 1677.

2. Correspondence series. You are fourteen letters deep and want to create some analytic order. Build a tool that maps the correspondent network, tracks topics over time, flags tone shifts, and identifies responses to lost incoming letters.

Letter from John Young, survey of a new ship the Bristol, November 12th 1673, ADM 106/290 f.108r

3. Petitions. You have thirty petitions to different authorities across different jurisdictions. Build a tool that extracts petitioner, grievance, remedy, addressee, and outcome — within the legal framework you specify.

4. Charter parties. You have two maritime contracts and three ways to read them — legal, economic, social. Build a tool that switches between analytical modes and references contemporary legal texts. Lawyers and legal technologists: this one is for you too.

Charter party of the Hopeful Elizabeth of London (140 tons), 1634. HCA 30/844 unfol.

5. Parish mapping. You have data that belongs on a map. Build an interactive web map using Leaflet — place your inventories, tax assessments, or mortality records on a historical basemap with pop-ups showing the evidence.

London Bridge to Custom House Key — interactive soundscape - a horizon project

I am building an interactive historical soundscape of the Thames shoreline from London Bridge through Billingsgate market to Custom House wharf using the Ogilby and Morgan survey of 1676 — the most detailed map of the rebuilt post-Fire city, at 100 feet to the inch. Walk along the waterfront on your screen and hear what you would have heard: fish market cries at Billingsgate, coal heavers at Bear Key, church bells from St Mary-at-Hill and St Dunstan-in-the-East, wherries bumping at the stairs, coopers hammering in the warehouse yards. The soundscape shifts with the time of day and the season.

My inspiration is Ian Rawes (1965-2021). His work as a sound recordist and founder of the London Sound Archive is truly awe inspiring. I had the privilege to correspond with him in the development of my Maphackathon initiative in 2017, which was built around the spatial, sound and smell scape of the C17th and C18th Thames shoreline. Due to family illness he was unable to attend. We planned to run a session on the soundscape of Billingsgate at the Maphackathon. This vibe coding project is my tribute to him, and will draw on some of his materials, on sound recordings from C20th and C21st, on synthesised sound, and on sound and film recordings from the pre and post 1982 Billingsgate market. A few of his extraordinary recordings are publicly accessible on the online label Persistence of Sound: The London Sound Survey: Thames. PS003 and The London Sound Survey: From Dusk till Dawn. PS008.

The London Sound Survey: Thames: PS003. Ian Rawes. 2021.

Extract from Ogilby and Morgan map of London (1676)

This is is my biggest history vibe coding project yet. It is too big for one person. The coding is the easy part. I need your help with the history and the aural conceptualisation. I am looking for collaborators:

• Sound design and web audio. If you know the Web Audio API, spatial audio, or sound design — I need you. The technical challenge is making positional audio work with historical map tiles in a browser.

• Historical and spatial research. If you know the late seventeenth-century Thames waterfront — from depositions, parish records, or archaeological work — I want your knowledge of what happened where. I am drawing on English High Court of Admiralty depositions for the physical layout of wharves and warehouses.

• UI and experience design. If you have ideas about how a listener should navigate a historical soundscape — click to move, walk with keyboard controls, or something I have not thought of — get in touch.

This is a genuine research project, not a demo. The ambition is to reconstruct a lost sound world from fragmentary evidence, and to be transparent about what we know and what we are guessing.

It is a tragedy that Ian Rawes’ London Sound Survey is no longer publicly available, although supposedly it is being archived at the London Metropolitan Archives. Ian Rawes was a fascinating man. Here is an interview with him available on You Tube from 2015 explaining how he became interested in binaural recording.

An extract from an email from Ian to me dated February 1st, 2017:

“A small observation to share with you: the difference between the river’s height on either side of the old London Bridge is reckoned to have been as much as six feet when the tide was on the turn, and there are historical references to the noise the resulting cataracts made. This, the size of the buildings on the bridge, and the bridge’s effect as a traffic pinch-point, means that it may have constituted an acoustic curtain. Many activities happening upstream of the bridge might not have been easily heard, if at all, and this would include noises from the theatres and other amusements of Southwark. When the tide was going out, the cataracts would have sounded louder than when the tide was coming in. Also, from late January to the end of March you’d have seen the sun setting behind London Bridge if you’d been standing on the quayside at Billingsgate.”

Suggested approach

You do not need to prepare anything before we talk. Here is how it works:

1. Message me. Tell me what period, what sources, what kind of tool interests you. Even a half-formed idea is fine.

2. We talk through the architecture together. I will help you specify what you want to build — what it should do, what it should not do, and what questions it should help you answer. This conversation is the most valuable part of the process.

3. You build it in Claude Cowork. I help you install Cowork, teach you how to create a Sandbox and to work safely with the tools. I coach you through my suggested Socratic four-stage process: architecture, design, build plan, build and test. You work at your own pace. I am available by message for troubleshooting.

4. You publish if you want to. Your tool can go on GitHub — either your own repository or the AI + History Collaboratory’s. Publishing is optional but encouraged.

Connect with me on LinkedIn and message me. I will be delighted to discuss history vibe coding further, and any ideas you have for a vibe coding project. No programming knowledge required. No prior experience with AI tools required. You need a paid Claude account (Pro is fine) and a willingness to describe what you want clearly.

The key to working effectively with Cowork is to design and use structured skill markdown files, incorporating deep domain specific expertise, and this is the topic of the fourth online session of the ai + history collaboratory to be held on Tuesday, March 31st 2026 at 4 pm UK time (11 am EST; 5 pm Paris, Berlin, Vienna).

SESSION GOALS: From installation to your first skill file. An introduction to Claude Cowork as a desktop research environment for historians, followed by a deep dive into skill files - markdown instructions that turn an LLM into a processor, codifying procedural knowledge into reusable, versionable, model-agnostic files. Workflows can be built into skills, making them far more than simple prompts. Includes a case study from Jacob Forward’s PhD research and a hands-on group exercise.

Agenda

1. Introducing Claude Cowork (15 min)

2. Skills: what, why, and when (10 min)

3. Case study: skills for historical research (15 min)

4. Group work and discussion (15 min)

5. Wrap-up (5 min)

For the full provisional agenda click here

Getting started

• You will need a paid Claude subscription

• You will need to download Claude desktop

• You will need to create a ClaudeCoworkSandbox

• Ideally, create your first Claude SKILL markdown file to share and discuss at our ZOOM session on March 31st 2026

Create your first skill

Paste this into Claude to create your first skill:

“I would like your assistance to build a Skill.md file. Please begin by asking me 5–10 questions to discover the particular use-case I have in mind, including all the relevant details. Ask one question at a time and allow my answers to each to inform the next question you pose, until you have a complete picture. After 5–10 questions, use my answers, as well as your native skill-building skill, to write an Anthropic-compliant skill closely focused on my use-case and achieving my goal. Then encourage me to read, test, and refine it.”

If you would like to learn more about the ai + history collaboratory, or to discuss attending our next session on Cowork for Historians, connect on LinkedIn with Colin Greenstreet, convenor of the Collaboratory and send him a direct message.

If you would like to learn more about Colin’s work with machine transcription skills (just one sub-group of skills relevant to historical research), take a look at the Opening the Ottoman Archives initiative wiki, which discusses visual capture and semantc processing Anthropic compliant skills for use with Gemini and Claude to transcribe, transliterate, translate, and perform Named Entity Recognition on printed and handwritten Ottoman Turkish documents from the C17th to early C20th.

This article

I’m sharing the product of five hours work with Claude Cowork spread over a day. I have been using Cowork now for ten days and this is my biggest project to date. I’m an historian, not a coder. Cowork has been a revelation.

The product is a static five annotation layer IIIF viewer for Ottoman Turkish, which I am hosting in a IIIF-demo repository on the ai and history collaboratory GitHub organisation. The image the viewer displays is from the first issue of the Ottoman government gazette Takvîm-i Vekâyi, published in 1831.

The viewer

You can access the viewer here and the related documentation here.

Functionality

The viewer provides a zoomable tiled image in the main area of the screen and a vertical side bar from which to access five annotation layers.

• Digital transcription of the original perso-arabic script

• Ottoman Turkish transliteration

• Literal English

• Modernised English

• Summary translation

The vertical sidebar provides access to the annotation layers, which can be toggled on and off, and offers the choice of three regions within the image to inspect - the masthead, and the right and left hand columns.

The machine transcription

The machine transcription was done using a two stage process - visual capture using Gemini 3 Pro to produce a digital transcription of the original perso-arabic script and semantic processing of that digital transcription using Opus 4.5 to produce an Ottoman Turkish transliteration, a literal Englsh translation and a modern English translation, together with a flowing summary translation.

It’s not perfect, but it’s a start. Your feedback on the quality of the HTR and on our approach to machine transcription of Ottoman Turkish documents would be enormously valuable. Everything we are doing is for the Commons, and will benefit Ottoman Turkish scholarship, and ultimately scholarship in other important languages of the Ottoman Empire and its successor states, including Albanian, Bulgarian, Greek and Armenian.

This two-stage pipeline is documented in the Opening the Ottoman Archive initative wiki, which provides a project introduction and describes the visual capture and semantic processing stages we are developing. The initiative is still at its early stages, and follows on from an early January 2026 article I wrote in my substack Generative Lives.

I am working with a number of Ottoman Turkish scholars in Europe and the US to develop specialised HTR skills files tailored for the visual capture and semantic processing of different scripts, genres and document types across a range of periods. Until now we have concentrated on the C19th and early C20th and have worked with printed and lithographed documents - gazettes, newspapers and books. But we are now devoting our attention to handwritten texts, which of course present a bigger HTR challenge, and are reaching out to scholars with expertise in C16th to C18th texts in a range of scripts.

Updated UI/UX and functionality

Two hours of Cowork interaction this Sunday morning and two more hours Sunday afternooon working on UI/UX.

New features:

• Five pages of HTR

• Accordion sidebar boxes

• Persistent region indicator bar

• Persistent page indicator bar

• Red highlights for clickable regions with instant display of chosen level of annotations.

• Thumbnails of double page images at base of viewer

Takvim-i Vekayi, issue 1, 1831: Improved UI/UX

New Right to Left thumbnail navigation,

Takvim-i Vekayi, issue 1, 1831: Improved UI/UX of lefthand sidebar

Same viewer link. Please give it a try and post feedback in comments.

Contact me if you would like to learn more

Please connect with me on LinkedIn and message me if you would like to learn more about our initiative and to contribute to the co-creation, testing and validation of Ottoman Turkish HTR skill files in the context of your own research projects.

This article

This article builds on my December 4th 2025 Substack article ‘A New Lens into the Archives’, and on my subsequent December 20th 2025 article in which I looked at mid-C20th Yiddish as a demanding edge case for LLM-enabled Handwritten Text Recognition. In those two December articles I examined the impact Google’s Gemini 3 Pro visually grounded large language model will have on machine transcription and on historians’ abilities to interrogate archives. It was a Eureka moment for me, who has been involved with history tech since 2012, and with machine transcription since 2018.1 2

In my new article, I propose a novel approach to historical research in which LLM-based machine transcription is integrated by general historians into their working methods to increase the scope, scale and impact of their work, using the field of Ottoman studies and languages as the use case. My proposal is significantly broader than applying machine transcription to research. It is an argument that historians can integrate LLMs into their existing work flows, and can improve on those workflows, to produce sophistiated, granular, auditable results which meet good historical and archival practice. The article draws on my thinking about ‘New Skills for Historians’ which I first described in July 2024 at an internal National Archives workshop and in November 2024 at an IHR Digital History seminar.3 4

I present this as a work in progress. To stimulate your thinking, your engagement, your push back, and your improvements. My interest, as always, since I started work as a public historian in 2012, is to create useful tools and to encourage collaboration, and this is no different.

The proof of the pudding will be the production and publication of historical research using such techniques. The article concludes with a call to like-minded historians to engage with me and fellow members of the ai + history collaboratory I convene to structure and conduct a small Proof of Concept for publication using the tools and methods I describe in this article. I propose we identify and work collaboratively on a cross-cultural and cross-linguistic topic of importance in the Ottoman Archive. In working together all participants would have a chance to learn, validate and of course improve these tools and methods and to explore their relevance to their own research.

The Ottoman Archive use case

Starting with Ottoman Turkish, a demanding Right-To-Left language, I show how Ottoman Turkish and other languages of the Ottoman Empire, such as Albanian, Bulgarian, Greek, and Armenian can be made accessible and readable to generalist historians. Four of these five languages have non-Roman alphabets and are challenging for researchers brought up on English, French, German and Spanish.

I position command of language as necessary, but not sufficient, for historians to access Ottoman archival material. The general historian additionally needs the ability to find relevant archives, to identify which archives have digitised material, to discover and navigate the structure of physical and digitised archives at fonds level, to understand existing metadata (in whatever language it is presented), and to access page level images of printed and handwritten documents. I show how I have achieved this in my own experiments, especially with archives of digital Ottoman Turkish material, but my methods are generalisable to archives containing Albanian, Bulgarian, Greek, and Armenian materials, as well as for modern Turkish.

My approach opens the conceptual Ottoman Archive, as well as physical and digital archives. Small neglected water damaged archives outside capital cities, as well as heavily digitised archives, which use IIIF to make available text and cartography. Archives such as ISAM in Istanbul, the National Library of Greece in Athens, and the Endangered Archives Scheme run by the British Library.5 6 7 Archives in successor states of the Ottoman Empire, as well as the national and regional archives of former ‘Great European Powers’ who intervened in the Ottoman Empire.

‘Balkan States’, map from “Stanford’s Compendium of Geography and Travel: Europe” Volume 1, 1899 8

The challenge

The redrawing of the borders of the Ottoman Empire in the C19th and early C20th, had dramatic consequences politically and militarily for the whole of Europe, Asia Minor, the Caucasus, and the Near and Middle East. It involved and raised issues relating to perceived and claimed ethnic identity, in which language was a key signifier of identity.

‘Carte Ethnografique de la Macédoine: Point de vue serbe’, Map from “Report of the International Commission To Inquire into the Causes and Conduct of the Balkan Wars” 1914; ‘Carte Ethnografique de la Macédoine: Point de vue bulgare’, Map from “Report of the International Commission To Inquire into the Causes and Conduct of the Balkan Wars” 1914 9

One of the most dramatic changes came in the 1920s with the end of Ottoman Turkish as a bureaucratic writing system, with its complex Right-To-Left perso-arabic script, and its replacement by Modern Turkish, written with a romanicised alphabet and a reformed phonetic and grammatical system. This dramatic shift took place at the same time as the creation of a Turkish state, centred on Anatolia.

But changes from early in the C19th also impacted the orthography and broader writing systems of many other languages spoken and written in the Ottoman Empire. As Greeks, Bulgars, Albanians and many other groups of intermingled peoples sought to define themselves, and assert their cultural and political identity, they looked to language and writing system reforms.

‘The Albanian Alphabet,’ Drita, 1907, Issue 90, p.4, bottom of RH column 10

This makes for a challenging fluid evidentiary environment in which to conduct historical research, and has meant that research into events and issues of broad import have often been restricted to specialist research groups and linguistically focused historians.

Let’s look at some documents

So how big is the challenge for a historian? Let me show you five languages and five different writing systems, and you will begin to visualise (literally visualise) the size of the task.

Ottoman Turkish

Takvîm-i Vekâyi [Ottoman Government Gazette], Issue 185, 1839. Masthead and RH and LH columns of first page of four page document11

Şanizade History by Şanizade Mehmed Ataullah Efendi, 1242/1826 [CE], publication date 1284/1868 [CE]. ISAM.12

Sadâret Correspondence (Outgoing to Inspector-General), İSAM Kütüphanesi Arşivi (İKA). Semder: Bâb-ı Âlî / Dâ’ire-i Ṣadâret-i ‘Uẓmâ / Mektûbî Ḳalemi; Recipient: Rûm-ili Vilâyât-ı Şâhâne Müfettişliği (Hüseyin Hilmi Paşa); Date: 22 Kânûn-ı Evvel 1319 [Rumi], 4 January 1904 [Gregorian]; p.1 of 2 13

Bulgarian

БАЛКАНЪ [БАЛКАН; Balkan], Year I — Ruse, 10 June 1898 [O.S.] — Issue 7, St. Cyril and Methodius National Library of Bulgaria, republished by the British Library Endangered Archives project, EAP 698/1/8 14

Handwritten pre-orthographic reform Bulgarian cyrillic. July 3, 1905. ISAM: IKA HHP-H-2-b-dos.1-1396 15

Greek

ΕΠΤΑΛΟΦΟΣ ΝΕΑ - “Heptalophos Nea” (Seven-Hilled News), Issue 20, October 31st 1865, p.1 16

Albanian

Drita [The Light], January 1st 1908, Issue 95. p.1 (of 4). Published Sofia, Bulgaria. Albanian romanised script; Ottoman script 17

Armenian

‘Birth certificate Author’s Paternal Grandmother, Arusiak Adamyants born on April 24, 1904 in Shushi. The text is bilingual with Russian on the left. This is an good example of developed writing culture present in Artsakh at the turn of the 20th century as it is executed by an anonymous clerk in the Municipality of Shushi (then part of the Russian Empire). 18

How can we read these documents?

I have developed a system to read the five written languages above, using the concept of HTR skills markup files, which I first proposed in December 2025.19 This development process has been both conceptual and empirical, and has been conducted iteratively in collaboration with Claude Opus 4.5 as my primary tool for work process and skill file development. It is still at the Proof of Concept stage and is not yet mature and scalable.

For each language I have conducted an a priori review of the linguistic challenges of that language, and have structured a work process tailored to that language. In the case of three languages (Ottoman Turkish, Bulgarian, and Greek), which each have demanding non-Roman character based alphabets and phonetic systems, I elected to go with a two-stage architecture. The first stage being visual capture of the script as a digital transcription. The second stage being a semantically driven transliteration, translation, named entity extraction, and contextualised summarisation of the digital transcription. In the case of Albanian and modern Turkish I went with a single-stage architecture which combined visual capture and semantically driven transliteration, translation, named entity extraction, and contextualised summarisation of the digital transcription. I am still debating the best approach to Armenian. I have had success with a one-stage approach for Armenian, as reported in my December 4th 2025 Generative Lives article (“A New Lens into the Archive”), but I may move over to a two-stage approach for maximum flexibiliy with both printed and handwritten documents.

I elected to use Gemini 3 Pro Preview for the Stage One visual capture, operating at unusual settings designed to maximise visual capture and to avoid or minimise any semantic intervention (temperature = 0.2; media resolution = high; thinking = low; top P = 0.0.15). For the Stage Two semantic processing I elected to use Claude Opus 4.5, operating at standard settings (temperature = 1.0; thinking = high; top P = 0.95). For one-stage processing I have tried both Gemini and Claude, but prefer Claude because of the advantages of a standardised project platform based on Claude HTR projects.

Methodology

Reading printed documents

Let me show you some of the outputs of my work for a range of genres - historical gazettes, newspapers, and maps - all from printed sources. I have tested all the above genres for Ottoman Turkish, and have tested limited genres for other languages - Albanian (newspapers), Bulgarian (newspapers), Greek (government gazette; newspapers), and Armenian (birth certificate).

The quality of output is not identical. Reuse of the same HTR skills files (both visual capture and semantic processing of the visual capture to produce transliteration, translation, named entity extraction and contextualised summarisation) on the same underlying image does show small variances in output once a skills file has been iterated and optimised for a specific language and genre. But I have measured these variances using a range of measures (see section titled “Testing and validating model outputs”) and have found the variances to rarely affect the consistent extraction of the same named entities from repeated model outputs for the same image. In other words, an historian wishing to explore a range of documents looking for a particular category of named entity and a specific instance of that entity is likely to find it consistently in model outputs.

I still need to prove this at scale, but my experiments look very positive. Ultimately, individual historians will need to form their own views on whether the output of HTR skills models is sufficiently stable for their own granular research.

Reading printed historical gazettes

Ἑφημερίς τῆς Κυβερνήσεως, Greek Government Gazette, 14 Ἰανουαρίου 1833 [Julian], 26 January 1833 [Gregrorian], Issue 1. In the facsmilie of the gazette image, LH column is Greek; RH colum is German. Original script and modernised English translation.20

Extract from V3-T-Greek skills markdown file, created and stored in Claude Greek HTR project 21

Extract from the Claude Opus 4.5 model output, processing Gemini 3 Pro Preview visual capture of Greek script, stored in Claude Greek HTR project 22

Reading newspapers

Peyam newspaper. p.1 of the 14 Ağustos 1335 (Rumi)/August 14, 1919 (Gregorian) issue 23

Extract from V3-T-Newspaper Protocol designed for Second Constitution period Ottoman Turkish newspaper specifying structured JSON model output

Extract from model output using V3-T-Newspaper Protocol HTR skills file applied to Gemini visual capture of the perso-arabic script by Claude Ous 4.5 in Ottoman Turkish HTR project

Reading maps

Ottoman General Staff map. Ottoman Turkish script. Multiple cartouches. ca. 1890. 24

Ottoman General Staff map. Ottoman Turkish script. Data table. ca. 1890. 25

Text extraction from Ottoman General Staff map using a one-stage approach by Claude Opus 4.5 in the Ottoman Turkish HTR project as a proof of concept of reading Ottoman Turkish script in Ottoman maps

Reading handwritten bureaucratic and personal documents

Handwriting introduces greater variance in character and word formation, with writer specific usage of ligatures, up and down strokes, diacritics and other palaeographical features, together with greater irregularity in layout, such as slanted handwriting.

I have experimented with some success with LLM-enabled machine transcription of handwritten documents, including bureaucratic and personal hand written documents in Ottoman Turkish and modern Turkish, but will not show those outputs here since it is relatively early days.

Testing and validating model outputs

A key part of designing an HTR skills markdown file is to test and validate the outputs it produces.

I used three different types of validation process:

1. Character error (cer) and word error (wer) calculation. These calculations used python scripts written by a different instances of the LLMs using industry standrad definitions of error rates. I applied these calculations to model outputs at a line by line as well as an article by article and a page by page level. This is only possible where a known validated ground truth or gold standard exists for a specific text.

2. Variance analysis. This examines the variance of model outputs from the same image using the same HTR skills file run multiple times. It does not require known validated ground truth or gold standard.

3. Semantic consistency analysis. This uses Named Entity extraction on model outputs from the same image using the same HTR skills file run multiple times. The test checks that the same Named Entities appeared in all model outputs, even if there was some variance in the transcription and/or the transliteration between model runs. It does not require known validated ground truth or gold standard. In many ways this is the key test for an historian - it is proxy for whether reliable semantic content is being produced using these tools.

Below is an example of Claude Opus 4.5 checking the line by line accuracy of visual capture by Gemini 3 Pro Preview of perso-arabic script from an Ottoman Turkish text. All my experiments are logged and allocated an Experiment Number. This was Experiment 149, conducted on December 28th 2025. The text which had been captured visually as a perso-arabic transcription was the first page of Şanizade History by Şanizade Mehmed Ataullah Efendi, 1242/1826 [CE], publication date 1284/1868 [CE], which is available in the ISAM digital library in Istanbul.

The final validation is of course by specialists who have deep understanding of the various scripts I have been processing. I have shared an example of the Ottoman Turkish official gazette visual capture and semantic processing with a scholar who specialises in this field, who commented on the accuracy of the visual capture of the perso-arabic script and on the high quality of the transliteration and translation, and I am hoping that this article encourages other specialists to approach me to discuss my work. Everything I do is CCBY 4 and I will be delighted to work with any scholar interested in engaging in these nascent methodologies and to explore whether they may be of utility in supporting their own research work.

Accessing and understanding archives

Below are two examples of how I worked with specific language based Claude HTR projects to identify and understand archives and fonds structure.

Seeking to understand a largely Ottoman Turkish fonds structure

Situation

I discovered the wonderful digital collections of İslam Araştırmaları Merkezi / Centre for Islamic Studies in Istanbul and wanted to explore one specific fonds called the “Hüseyin Hilmi Pasha Documents”. The fonds structure was available digitally in English.

The fonds was extensive in size and was described as “a collection of correspondence from Hüseyin Hilmi Pasha, who served as Grand Vizier during the March 31st Incident, [which] constitutes an important resource for researchers interested in late Ottoman history, the Committee of Union and Progress, the Balkans, and Macedonia. Comprising 3328 documents from the period 1714-1928, the collection is classified into 26 folders and 1729 files.”

Navigating the ISAM website in English (modern Turkish is also available) my starting point to understand the Fonds was the “Fund HHP - Hüseyin Hilmi Pasha Documents” webpage.

I had become interested in a sub-fonds concerning the Rumelia Directorate, having discovered by chance an Albanian newspaper containing both Albanian romanised script and what I guessed was Ottoman Turkish or possibly Albanian written in Ottoman Turkish. Subsequently, through linguistic analysis within the Claude Albanian HTR project, I used an Ottoman Turkish HTR skills markdown file and confirmed it was Ottoman Turkish.

Drita [The Light], January 1st 1908, Issue 95, pp.3-4 (whole issue = pp.1-4). Published Sofia, Bulgaria. Albanian romanised script; Ottoman script. Sourced from ISAM (İslam Araştırmaları Merkezi / Centre for Islamic Studies). Fonds: Hüseyin Hilmi Pasha Documents; sub-fonds: Rumelia Inspectorate; series: Foreign activities and the foreign press in the Balkans; sub-series: Foreign Press; file: Macedonia issue; item number: 0621 [Drita_1907_1808_hhp_0621.pdf]

I decided to create a project file, which would contain the sub-fonds structure relating to the Rumelia Directorate, which I could then interrogate to help me find more documents of interest in Ottoman Turkish, but potentially in other languages such as Albanian, Bulgarian and Greek.

Working with Claude

Through conversation with Claude, I discovered that ISAM uses AtoM 2.8.2 (Access to Memory), an open-source archival management system that supports EAD (Encoded Archival Description) exports. This was significant: rather than manually navigating hundreds of catalogue entries through the web interface, I could potentially extract structured XML data at the series level. Claude helped me construct the correct URL pattern for EAD exports and we successfully retrieved the full XML for two series within the Rumelia Inspectorate sub-fonds: HHP-H-1 (Activities/Faaliyetleri) with 104 items and HHP-H-2 (Foreign Activities and Foreign Press in the Balkans) with 135 items. Claude then parsed this XML, extracting item-level metadata including unit identifiers, titles, physical descriptions, languages, dates, and—crucially—the granular Ottoman archival document types embedded in scope and content notes (tahrirat, tercüme, telgraf, layiha, and so forth).

The resulting analysis revealed the linguistic complexity of the collection: across 239 items containing 645 documents, Ottoman Turkish dominated (90.8%), but French diplomatic correspondence comprised 9.2%, with smaller quantities of Bulgarian, English, and Arabic. More surprising was the discovery of 162 newspaper clippings from European and Balkan press—Le Figaro, Le Temps, Neue Freie Presse, The New York Herald—preserved because Hüseyin Hilmi Paşa’s intelligence apparatus monitored foreign coverage of the Macedonian Question. Claude generated JSON data files and comparative markdown reports that I could save to my planned Balkan Ottoman HTR GitHub repository, transforming my manual web inspection into a structured dataset I could query and filter.26

One significant finding relating to language emerged from cross-referencing the EAD metadata against visual inspection of the actual documents. The catalogue listed item HHP-H-2-b-dos.1-0621 as “Bulgarian” (language code: bul). But when I examined the PDF—the Drita newspaper that had first drawn me to this collection—I already knew from my Albanian HTR work that this was not Bulgarian at all. It was Albanian, published in Sofia for the Albanian diaspora, with approximately 85-90% of its content in pre-standardisation Latin-script Albanian and 10-15% in Ottoman Arabic script. The cataloguers, seeing a newspaper from Sofia with Cyrillic in the masthead context, had apparently coded it as Bulgarian without recognising the Albanian content. This raised an immediate question: how many other items catalogued as “Bulgarian” might actually be Albanian? I pulled another item flagged as Bulgarian—HHP-H-2-b-dos.1-1396—and examined the handwritten pages. This time, Claude confirmed it genuinely was Bulgarian: handwritten Cyrillic from Sofia dated July 1905, discussing Serbian-Bulgarian relations over Macedonia, with archaic pre-reform orthography (the letters ѣ and ѩ visible throughout). The metadata error was specific to Drita, not systematic—but it demonstrated why visual verification remains essential even when working with professionally catalogued digital archives.

Struggling with metadata and needing a content overview

Situation

I was looking for a mid-C19th Greek newspaper in digital form to complement a Greek government gazette exemplar I had already identified and processed. I had found a digitised page online from what I believed was a Constantinople Greek language newspaper from 1865. But I knew nothing about the archive, couldn’t read the Greek language metadata, and had no sense of the content. I prompted Claude within my Greek HTR project context to learn more so I could triage the document.

My prompt

How did Claude respond and why?

Claude as instructed in the Greek HTR project, with access to my prior conversation history and Greek HTR project files, had strong contextual understanding of my approach to HTR, including my desire for original script, transliteration and translation, together with NER and contextualisation. This means that when asked to assist with the identification of a page of a Greek newspaper and to contextualise it within the context of Greek language metadata provided by a digital archive, it did it in a well structured and helpful manner which was relevant to my goals as an historian. It used its native wits, rather than following a protocol I had written to interrogate metadata. Though of course that is the next step - a set of work processes to interrogate archival metadata, including use of Claude to access and inerrogate archival APIs (an approach I suggested in July 2024 to the TNA).27

This was Claude’s Thought Process, which itself is a source of valuable insight:

The user has uploaded an image of what appears to be a page from a 19th-century Greek newspaper called “ΕΠΤΑΛΟΦΟΣ ΝΕΑ” (Heptalophos Nea / Seven-Hilled News - a reference to Constantinople, the “city of seven hills”). They want me to analyze and contextualize this page.

Let me first examine the image carefully and then apply my Greek HTR skills to analyze it. The user has provided helpful metadata from the Medusa digital repository that confirms this is indeed from Constantinople, 1865.

Looking at the image, I can see:

1. A masthead “ΕΠΤΑΛΟΦΟΣ ΝΕΑ” (with decorative typography)

2. An engraved illustration showing what appears to be a panoramic view of Constantinople

3. The date line appears to read “31 ΟΚΤΩΒΡΙΟΥ” and “ΕΤΟΣ ΠΡΩΤΟΝ” (Year First) with “ΑΡΙΘΜΟΣ 20”

4. Two columns of Greek text

5. Headlines including “ΔΡΑΜΑΤΙΚΑΙ ΜΕΛΕΤΑΙ” and “ΙΣΤΟΡΙΚΟΝ ΕΝΔΙΑΦΕΡΟΝ ΤΩΝ ΚΩΜΩΔΙΩΝ ΤΟΥ ΑΡΙΣΤΟΦΑΝΟΥΣ”

This is fascinating - a Greek literary/cultural newspaper from Ottoman Constantinople in 1865. Let me analyze this properly using the V3-T-Greek methodology to provide context and translation.

The user wants me to “analyse and contextualise” the page. Given their preference for a Socratic approach and their expertise in HTR for historical Greek documents, I should:

1. Examine the image

2. Provide historical context about the newspaper and its setting

3. Analyze the content - the article about Aristophanes’ comedies

4. Connect this to the broader context of Greek intellectual life in Ottoman Constantinople

I’ll zoom in on the details, carefully tracing the typography and examining the intricate layout of this historical document. The panoramic illustration and precise column formatting reveal the newspaper’s sophisticated design for its era.

Here is the model output which builds on the thought processs:

Looking at this fascinating page, I’m immediately struck by several elements that deserve exploration. Before I dive into a full analysis, let me pose some guiding questions that might help us think through what we’re seeing:

What does the newspaper’s name tell us? “ΕΠΤΑΛΟΦΟΣ ΝΕΑ” - “Heptalophos Nea” (Seven-Hilled News) - is a direct reference to Constantinople as the “city of seven hills,” mirroring Rome’s ancient epithet. What might this naming choice suggest about how Greek intellectuals in Constantinople conceived of their city’s identity and continuity with classical civilization?

What’s the significance of the visual program?

The masthead features an engraved panorama of Constantinople - I can make out minarets, the Golden Horn, and the characteristic silhouette of the city. This is quite deliberate editorial choice for a Greek publication under Ottoman rule.

Let me examine the textual content more closely:

The Articles on This Page

I can identify two related articles, both concerning Aristophanes:

Left Column:

ΔΡΑΜΑΤΙΚΑΙ ΜΕΛΕΤΑΙ (Dramatikai Meletai) — “Dramatic Studies”

• (Συνέχεια ἀριθμ. ιθ΄) — Continuation from number 19

• ΥΦΟΣ ΤΟΥ ΑΡΙΣΤΟΦΑΝΟΥΣ — “The Style of Aristophanes”

Right Column (continuing from left):

ΙΣΤΟΡΙΚΟΝ ΕΝΔΙΑΦΕΡΟΝ ΤΩΝ ΚΩΜΩΔΙΩΝ ΤΟΥ ΑΡΙΣΤΟΦΑΝΟΥΣ “Historical Interest of Aristophanes’ Comedies”

---

Historical Contextualization

This raises several fascinating questions worth exploring:

1. Why Aristophanes in Constantinople, 1865?

The Greek communities of Ottoman Constantinople (the “Rum millet”) maintained a vibrant intellectual culture. But why focus on Aristophanes specifically? Consider:

• Aristophanes’ comedies offer direct access to Athenian democracy — its debates, personalities, and social tensions

• His works contain pointed political satire — would this resonate with Greeks living under Ottoman rule?

• The 1860s saw increasing Greek nationalist sentiment — was classical philology a form of cultural assertion?

2. The Newspaper’s Editors

Your metadata identifies the editors as Σταύρος Βουτυράς (Stavros Voutyras) and Δημήτριος Νικολαΐδης (Dimitrios Nikolaidis). Would you like me to search for more information about these figures and their role in Constantinopolitan Greek intellectual life?

3. The Visual Program

The panoramic engraving of Constantinople in the masthead is striking. Notice how it presents the city’s silhouette — minarets visible, boats on the water (likely the Golden Horn or Bosphorus). This is not an image of ancient Athens, but of their contemporary city. What does this choice suggest about how these Greek intellectuals understood their relationship to place?

---

Sample Transcription and Translation

Let me give you a taste of the content. From the opening of the left column article:

Original (as I read it):

Ἔπαινος τοιοῦτος δὲν εἶναι κατώτερος οὐδ’ αὐτοῦ τοῦ Σοφοκλέους· τῷ ὄντι οἱ δύο οὗτοι ποιηταί, οἱ τοσοῦτον κατ’ ἐπιφάνειαν διάφοροι, ὁ Σοφοκλῆς καὶ Ἀριστοφάνης, ἐχρημάτισαν συγγραφεῖς τῆς αὐτῆς οἰκογενείας...

Literal English:

“Praise such-as-this is not inferior not-even to-that of Sophocles himself; in truth the two these poets, the so-much in appearance different, Sophocles and Aristophanes, served-as writers of-the same family...”

Modernized English:

“Such praise is not inferior even to that accorded Sophocles himself; in truth, these two poets—so different in outward appearance—Sophocles and Aristophanes, were writers of the same family...”

---

Questions for Further Exploration

1. Would you like me to produce a full V3-T analysis of one or both columns, with line-by-line transliteration and translation?

2. Should I search for contextual information about the editors, or about Greek journalism in Ottoman Constantinople during this period?

3. The article references Attic criticism (ἀττικισμός) and discusses whether Aristophanes’ poetry is of “Attic soil” — this touches on 19th-century debates about linguistic purism. Is the Katharevousa/Demotic tension relevant to how you’re thinking about this document?

4. The metadata mentions an insert: “Ο Πλοίαρχος Καλόβολος” by Παύλος Σωνιέρ (Paul Soulier). This appears to be a translation of a French work. Would the presence of translated European literature alongside classical scholarship tell us something about the cultural positioning of this publication?

What direction would you like to take this analysis?

In conclusion

Let me encourage you to experiment for yourselves. It is only through personal experimentation, playing with tools and exploring how they may be of use (or not) to you personally as historians that you will be able to judge their utility. Of course this is not the only way to do historical research, but I hope this article has at least awakened your curiosity and experimental instincts.

The topic of the next session of the ai + history collaboratory I convene will be LLM-enabled HTR. Please contact me if you would like to attend as an observer and learn more about the methods I am developing for the Ottoman Archive use case.

Tuesday, January 20th 2025 @ 4 pm UK time; 5 pm Paris, Berlin, Madrid; 11 am EST by ZOOM. Duration = two hours.

APPENDICES

Appendix One: Github Repository

I am working on a GitHub repository to support all six Ottoman language HTR projects. I am at the design stage and this has not yet been implemented,

Appendix Two: Project documentation

I have developed a number of documents to record and communicate the work processes and HTR skills files I have developed and continue to develop. These are available to members of the AI + History Collaboratory I convene. Below is an extract from a document named “HTR_Project_Portfolio_Overview_02012026_v5.md” describing the Ottoman Turkish HTR project as part of the portfolio of language projects I am working on.

5. Language Projects Portfolio

5.1 Ottoman Turkish HTR [PRIMARY]

Status: Most developed

Creation Order: 1

Script: Perso-Arabic (RTL)

Period Focus: 1831–1920s

Resource Level: Low

Two-Stage Pipeline: Yes (V3-S-Minimal → V3-T variants)

5.1.1 Historical Context (1830–1920s)

Key Events Affecting Documents and NER:

| Period | Event | Impact on Documents |

|--------|-------|---------------------|

| 1808–1839 | Reign of Sultan Mahmud II | Centralizing reforms; destruction of Janissaries (1826); founding of Takvîm-i Vekâyi (1831) |

| 1839–1876 | Tanzimat Reform Era | Modernization of administration; codification of law; expansion of press; multilingual government publications |

| 1856 | Hatt-ı Hümayun | Reform edict; equality of non-Muslims; relevant for NER of minority officials |

| 1876 | First Ottoman Constitution | Constitutional terminology; parliamentary vocabulary |

| 1876–1909 | Hamidian Era | Press restrictions; censorship vocabulary; exile communities |

| 1908 | Young Turk Revolution | Second Constitutional Period; explosion of press; political party terminology |

| 1914–1918 | World War I | Military vocabulary; Entente/Central Powers terminology; wartime censorship |

| 1918–1922 | Empire’s Collapse | Armistice terminology; occupation vocabulary; nationalist movements |

Linguistic Complexity:

Ottoman Turkish functioned as the bureaucratic lingua franca but the empire operated multilingually. Government documents were routinely translated into Greek, Armenian, Bulgarian, and Arabic, particularly before the Tanzimat reforms. The 1876 Constitution established Ottoman Turkish as the official government language, but the concept of a single “official language” is itself a 19th-century invention associated with nationalism.

Low literacy rates (estimated 2–3% early 19th century, 15% by century’s end) meant that high-register Ottoman Turkish with extensive Arabic and Persian vocabulary was accessible only to educated elites.

5.1.2 Document Types

Official Government Gazette:

| Original Script | Transliteration | English |

|-----------------|-----------------|---------|

| تقویم وقایع | Takvîm-i Vekâyi | Calendar of Events |

- Years published: 1831–1922 (first series 1831–1840; second series 1840–1878; third series 1908–1922)

- Languages: Ottoman Turkish; historical editions also in French, Armenian, Greek, Arabic. Persian versions may have existed.

- Significance: First Ottoman newspaper; no systematic scholarly transliteration or English translation exists for early issues. This research produces genuinely original scholarship.

- Digital Access: Turkish National Library (1841–1919); Wikimedia Commons (1,427 PDF files); IRCICA Farabi Library (complete 7,030 issues)

Major Newspapers of Record (1830s–1920s):

| Original Script | Transliteration | English | Years | Character |

|-----------------|-----------------|---------|-------|-----------|

| طنین | Tanin | Echo | 1908–1925 | Semi-official CUP organ |

| اقدام | İkdam | Perseverance | 1894–1928 | Mass-circulation daily |

| صباح | Sabah | Morning | 1876–1922 | Major daily (Armenian-founded by Mihran Efendi) |

| وقت | Vakit | Time | 1917–1930s | Founded during WWI |

| ترجمان حقیقت | Tercüman-ı Hakîkat | Interpreter of Truth | 1878–1922 | Conservative daily |

| پیام | Peyam | Message | 1913–1914 | Political daily |

French-Language Press (Constantinople):

- Le Stamboul (1875–1962): Leading French daily

- Journal de Constantinople et des Intérêts Orientaux (1843–1930s): Oldest French paper

- La Turquie (1866–1930s)

- Extensive digitization via SALT Research/BnF/IFEA collaboration

Armenian-Language Press (Constantinople):

| Armenian Script | Transliteration | English | Years | Status |

|-----------------|-----------------|---------|-------|--------|

| Ժամանակ | Jamanak | Time | 1908–present | Only major Armenian daily confirmed publishing by November 1917; oldest continuously published Armenian-language daily in the world. Founded October 28, 1908 by Misak and Sarkis Koçunyan. |

| Ազատամարտ | Azadamart | Freedom’s Battle | 1909–1915 | Major ARF newspaper; founded by writer Roupen Zartarian; ceased when staff arrested April 1915 |

Greek-Language Press in Ottoman Constantinople:

| Greek Script | Transliteration | English | Years | Notes |

|--------------|-----------------|---------|-------|-------|

| Ἀνατολικὸς Ἀστήρ | Anatolikos Astēr | Eastern Star | 1861– | Constantinople Greek press |

| Κωνσταντινούπολις | Kōnstantinoupolis | Constantinople | 1867– | “Most widely read Greek paper in the Ottoman Empire” |

5.1.3 Key Linguistic Challenges

- Perso-Arabic script ambiguity (underdotted letters, ligatures)

- Triple linguistic layer (Turkish grammar, Arabic/Persian vocabulary up to 80% in high register)

- Lithographic vs. movable type printing distinctions

- Triple calendar systems (Rumi/Hijri/Gregorian)

- Izafet constructions spanning Arabic, Persian, and Turkish grammatical rules

5.1.4 NER Framework Considerations

| Category | Examples | Notes |

|----------|----------|-------|

| Persons | Sultan Mahmud II, Reşid Paşa, Enver Paşa | Titles and honorifics vary by period |

| Institutions | Bâb-ı Âli, Meclis-i Mebusan, Divan-ı Hümayun | Administrative terminology evolves through reforms |

| Places| Constantinople/Dersaadet, Rumeli, Anatolu | Multiple naming conventions |

| Dates | Rumi, Hijri, Gregorian | Triple calendar system requires conversion |

| Ranks/Titles| Paşa, Bey, Efendi, Kadı | Social hierarchy markers |

| Political Parties | İttihat ve Terakki, Hürriyet ve İtilaf | Post-1908 |

5.1.5 HTR Project Corpus Analysed

- Takvîm-i Vekâyi: Issues 1, 181, 185 (complete transliteration/translation)

- Second Constitutional Period newspapers: Tanin, Peyam

- Personal correspondence: İSAM Archive, Hüseyin Hilmi Paşa Documents

- Administrative documents and chronicles: Şânîzâde Tarihi, Vekâyi-i Devlet-i Aliye

- Cartographic materials: Ottoman Map Text Inventory, Balkans 1890

5.1.6 Protocols Developed

Visual Capture (Stage 1):

- V3-S-Minimal: Core visual capture protocol

- V3-S-Newspaper (v1.0, v1.1, v1.2): Newspaper-specific visual capture

Semantic Processing (Stage 2):

- V3-T: Core transliteration/translation

- V3-T-C: Correspondence variants (Personal, Administrative)

- V3-T-Chronicle: Biographical and historical texts

- V3-T-Newspaper: Second Constitutional Period journalism

Can you solve it by hand?

Can you solve it by machine?

What does it say?

What does it do?

Did I find or create it?

Can you visualise it?

Have fun!

The key reason why Gemini 3 shows such advanced HTR capabilities lies in the attention Google had devoted in the model’s construction to cross-language training in over 100 languages, and the excellent visual grounding capabilities of the multimodal model design, which has been built for a variety of vision use cases.

It is unclear whether Gemini 3 has been deliberately trained on historic handwriting and ground truth, though there is some evidence of some training awareness of MarineLives English High Court of Admiralty transcribed depositions, probably accessed through the Common Crawl. The lastest November 2025 Common Crawl has ca. 150,000 words of HCA 13/ legal deposition ground truth of notarial secretary hand from 1648 to 1669 sourced from MarineLives (and made available by us under CCBY3).

This article

This article dives deep into a difficult edge case, that of transcribing handwritten mid-C20th Yiddish, and argues that Gemini 3 Pro has the innate ability to transcribe Yiddish, though not yet with human level accuracy.

The article explores the challenges of Yiddish handwriting and shares a working solution using Gemini 3 Pro Preview.

Finally, the article proposes a novel approach to LLM-based transcription using agent.md and skill.md approaches, analogous to the methodology popularised by Anthropic, and now being adopted by OpenAI and Google. This may be of particular use for medium and low resource languages, where there is limited training data in the underlying LLMs.

The Edge Case: Mid-C20th Yiddish

What do you make of this letter? It was kindly provided to me by Gavin Beinart-Smollan, public historian and scholar of Yiddish, who is a doctoral candidate at NYU. Gavin also provided a line by line gold standard Yiddish transliteration and English translation. Can you read it? I can’t, although I can read Yiddish in transliteration. In this article I approach Yiddish as a computational process control problem, working in collaboration with Gavin Beinart-Smollan, as language expert and critic of my results and methods. A good moment to thank Gavin (who has not yet read this article, and will no doubt be full of comments and corrections), to thank Mark Humphries for his good steer “keep your prompting simple”, and to thank Tim Hitchcock for his continued encouragement to me to publish my ideas and to get them out there for people to react to.

Immediate challenges

What are the immediate challenges presented by this letter? Well for a start the script is read Right to Left and is written with Hebrew characters, which represent not Hebrew but the germanic-slavic language of Yiddish, with Hebrew and aramaic influences, and with many idiosyncracies. Unlike Hebrew, which is largely consonantal, Yiddish uses Hebrew letters (like aleph, ayin, vav, and yod) primarily as vowels to create a phonetic alphabet. These idiosyncracies include specific use of diacritics and ligatures which differ from Hebrew, and many loan words from other languages.

Google is known to have worked on Yiddish since 2009, but Yiddish spelling was only standardised in the C20th, so any HTR driven transcription will have to cope with considerable regional and temporal difference, and limited historic Yiddish training material. The overall Yiddish training corpus used by Google when training Gemini 3 is likely to have been relatively limited, though the Hebrew training corpus is likely to have been significantly larger.

My approach

I set about exploring the letter as a computational process, rather than a linguistic challenge. Could I find a way, working with Gemini 3 Pro Preview, to get a good line by line transcription. I wasn’t bothered with transliteration or translation, having already proven to myself that all the major LLMs have essentially solved going from digital Yiddish transcription to transliteration to translation.

My challenge was to go from an image of handwritten Yiddish handwriting to a reliable character by character word by word digital Yiddish transcription. I decided to concentrate on the first five lines.

The gold standard

Here is Gavin’s gold standard transcription for the first five lines, and below that for interest (although I did not intend to work with them) the gold standard transliteration and translation

Yiddish transcription

!טייערער יצחק

.וואס מאַכסטו? איך בין ג”ד געזונט, דאס זעלבן פֿון דיר צום הערן

.דעם לעצטן בריוו האב איך דיר געשיקס פֿור לופט-פאסט דעם 17-טן נאוועאבער

איך האב שוין איבער אַ מאנאט פֿון דיר קיין בריוו ניט געהאַט. פֿאַרוואס דאס איז

ווייס איך ניט. מילא- מסתמא ווייסטו בעסער פֿאַר מיר. איצטער וועל איך דיר אַ ביסל

YIVO transliteration

Tayerer Yitskhok!
Vos makhstu? Ikh bin g”d gezunt, dos zelbn fun dir tsum hern.
Dem letstn briv hob ikh dir geshikt fun luft-post dem 17tn November.
Ikh hob shoyn iber a monat fun dir keyn briv nit gehat. Farvos dos iz,
vays ikh nit. Mile—mistame veys tu beser far mir. Itster vel ikh dir a bisl

English translation

Dear Yitzchak!

How are you? I am, thank God, healthy, and hope to hear the same from you.

I sent you my last letter by airmail on the 17th of November.

I haven’t received a letter from you in over a month. Why that is,

I don’t know. Anyway, you probably know better than I do. Now I will

My tools and my strategy

My chosen workbench was Google AI Studio, the same platform Mark Humphries has used for his Gemini 3 benchmarking.

I decided to pursue a simple strategy. Rather than a complex systems instruction, called by a one line user prompt, I homed in on a relatively simple user prompt, with settings designed to focus Gemini entirely on the visual and to minimise any semantic thinking. After experimentation, I settled on a temperature of 0.2, thinking set at low, media resolution on default, and Top P crucially sharply reduced to 0.15. The effect of the Top P reduction (from a more typical 0.95) is to sharply reduce the number of “options” that Gemini would evaluate as it viewed the image of Yiddish handwriting.

I decided to process each of the five lines separately, cutting the image physically into line strips. I cropped them carefully to reduce the amount of above and below line interference from other lines from ascenders and descenders. When working with different Yiddish documents, I have also corrected lines which diverged significantly from the horizontal, but this was not necessary for this particular letter.

My user prompt

My user prompt went through four evolutions (Generation 1, Generation 2A, 2B and 2C).

The current version (Generation 2C) was designed to address five key areas. Firstly, to encourage Gemini not to over-segment words. Secondly, to filter out vertical interference from lines above and below. Thirdly, to teach caution to the model near the right and left edges of the image. Fourthly, to firmly assert visual over semantic supremacy, or ink over context, and to avoid autocorrection. Finally, to capture punctuation, not just characters. Crucially, from the start all my prompt versions required Gemini to produce a detailed forensic reasoning and layout analysis, thus providing information to me as to how the model “saw” the characters and words, and why it made the decisions it did. Moreover, the specified output listed each word from right to left in a line, before the whole line as a single string.

How did I arrive at those five areas? Partly through a priori reasoning (with a different instance of Gemini) about the challenges of reading mid-C20th Yiddish and methods to remediate. Partly, through experimentation, with this specific Yiddish document and with other documents, and post-hoc analysis after each experiment (using the same second instance of Gemini) to understand what had worked and what hadn’t, and then adjusting the prompt.

Here is the full Generation 2C prompt, which is the one I used to generate the data below.

THE GENERATION 2C PROMPT (Full Fidelity + Interference Protocol)
gen_2c_prompt = """

Role: You are a forensic palaeographer specializing in damaged Yiddish manuscripts. Your goal is a diplomatic transcription of the ink visible in the image.

Task: Analyze the single line of handwriting and output a structured JSON.

Critical Visual Protocols:

1. Bridge the Gaps (Conservative Anti-Segmentation): Yiddish handwriting often contains "pen lifts" (tiny gaps) within a single word. Bridge these micro-gaps into a single ID. However, if there is a distinct, wide space between letter clusters—even if they seem to form a single semantic word—keep them separate. Do not merge distinct physical clusters just to fix the spelling.

2. Filter Vertical Interference: The manuscript is dense. Long vertical strokes entering from the very top or bottom edge of the image are often ascenders/descenders from adjacent lines. If a stroke cuts *through* a word or appears floating between words without a clear connection to the baseline, treat it as noise/interference. Do not transcribe it as a letter (like `ו` or `ן`).

3. Respect the Edges: The beginning and end of the line are high-risk zones for hallucination. If the ink at the edge is messy or ambiguous, transcribe the specific letters you see (e.g., `ב?ן א?ך`). DO NOT insert grammatical filler words (like "they have" or "it is") just to make the sentence smooth.

4. Ink Over Context (Visual Supremacy): Your priority is the ink, not the grammar. If the visible strokes look like a typo, transcribe exactly what you see. DO NOT "autocorrect".

5. Punctuation: Capture all quotation marks, dashes, and periods.

Output Format:

Provide your response in this specific JSON structure:
* forensic_reasoning: A detailed chain-of-thought explaining your visual analysis. Mention specific stroke ambiguities, interference from other lines, pen lifts, or paper damage (folds/cuts) and how you resolved them.
* layout_analysis: Describe the line's physical state.
* transcription_list: A list of objects, ordered Right-to-Left.
* full_line_text: A single string concatenating all the text.

Execute this prompt using the attached image

Here is the prompt being executed in Google AI Studio for line 2:

Example of model output for a line

Here is the quality of the output elicited by the prompt. For a linguist it is fascinating, since it provides reasoning behind its character recognition. Not all the reasoning will be correct. Indeed, in terms of understanding and improving an LLM-based HTR process, it is seeing why a model made incorrect character and word choices, misread strokes, missed diacritics, whatever, that is most revealing and helpful.

Transkribus has no ability to reason nor to verbalise its character recognition. That doesn’t mean its recognition is worse. Not at all. But it is far less interesting from a research point of view. I said at the start of my article that I don’t read Yiddish (Hebrew) characters. But, at the end of ten days work with Gemini, I know infinitely more about the structure of Yiddish than I would reading Transkribus output.

"transcription_list": [
{
"id": 1,
"word": "וואס",
"reading": "vos",
"confidence": "high"
},
{
"id": 2,
"word": "מאכסטו",
"reading": "makhstu",
"confidence": "high"
},
{
"id": 3,
"word": "?",
"reading": "?",
"confidence": "high"
},
{
"id": 4,
"word": "איך",
"reading": "ikh",
"confidence": "high"
},
{
"id": 5,
"word": "ב\"ה",
"reading": "b\"h",
"confidence": "high"
},
{
"id": 6,
"word": "געזונט",
"reading": "gezunt",
"confidence": "high"
},
{
"id": 7,
"word": ",",
"reading": ",",
"confidence": "medium"
},
{
"id": 8,
"word": "זעלבע",
"reading": "zelbe",
"confidence": "high"
},
{
"id": 9,
"word": "פון",
"reading": "fun",
"confidence": "high"
},
{
"id": 10,
"word": "דיר",
"reading": "dir",
"confidence": "high"
},
{
"id": 11,
"word": "צום",
"reading": "tsum",
"confidence": "high"
},
{
"id": 12,
"word": "הערן",
"reading": "hern",
"confidence": "high"
},
{
"id": 13,
"word": ":",
"reading": ":",
"confidence": "high"
}
],
"full_line_text": "וואס מאכסטו? איך ב\"ה געזונט, זעלבע פון דיר צום הערן:"
}

My results

Does the model output make sense? Eyeballing the Yiddish Hebrew character transcriptions from my five experiments they look fairly good in terms of word boundary recognition and character recognition. I then had Gemini do an industry standard python based statistical analysis of character error rates (cer) and word error rates (wer).

The calculations showed line by line cer and wer varying between 0.00 and 0.17 for cer and 0.00 and 0.33 for wer. How do those statistics stack up compared with specialist Yiddish models developed in Transkribus and in other platforms?

But do they make sense and are they readable. Since I don’t read Hebrew characters, I had the same model transliterate and translate the five lines and compare them with Gavin Beinart-Smollan’s gold standard. I will let you judge for yourself, but I find the results to be good.

Big caveat

So a success? All sorted. Game over? Not at all.

When I ran the same prompt on the next four lines of the same letter (Experiments 75 to 78) there were major problems, with much worse cers and wers, and the content diverging way off base. I discovered various causes for this breakdown. The principle cause being unusual very domain specific vocabulary, prompting Gemini to override its ink first rule, and to switch into semantic mode and to make some wrong semantic decisions. When LLM-transcription breaks down it is usually spectacular, not a linear degradation.

The failures I observed in Experiments 75 through 78 showed a shift from visual recognition errors (misreading a character) to semantic hallucinations (inventing a reality). The primary cause was blindness to the specific domain: the model lacked the specific contextual knowledge that the letter described a vocational workshop.

In line 7 (Experiment 76) the model encountered the visual sequence `Shin-Lamed...` (start of *Schloserei*/Locksmith) followed by `Ayin-Lamed...`. Its training data, presumably heavily weighted towards Jewish literature, overpowered the visual evidence, forcing it to autocomplete the greeting "Sholom Aleichem” instead of the technical term.

In line 8 (Experiment 77) the letter writer used the Russian-derived technical term "Tokarnes" (Lathes). The model, unfamiliar with this specific trade jargon in Yiddish, rejected the visual evidence (`ט-א-ק`) and hallucinated the visually similar, common verb "Bakumen" (Receive). The aggressively low Top P 0.15 excluded any consideration of a highly unlikely option.

In line 9 (Experiment 78) the model, not knowing the letter was about machinery, the saw `Prez-mashin` (Milling Machine) and guessed "Dresh-mashin" (Threshing Machine)—a visually similar word that fits a "Yiddish Shtetl" context better than a "Modern Factory" context.

An immediate remedy which worked for my very specific use case was a small amount of context injection into the prompt, though that is not always an option, especially for a user who wants to transcribe a letter and cannot personally read it, and has no idea of the context. By explicitly prompting the model with the domain ("This text describes a Locksmith Workshop using technical Russian loanwords"), I managed to suppress the "Shtetl" bias and prime it to expect "Lathes" instead of "Greetings."

The key design tension in writing a prompt for Yiddish transcription is to decide in what circumstances to allow the model to engage semantically, not just visually. And then to get the model to obey the prompt designer.

What remains to be done?

I make no claims that the prompt I have developed is currently generalisable from the specific letter I have been working on. But, I do believe that the techniques I have used are relevant and worth exploring. Not just for Yiddish, but for other medium and low resource languages, including other Right to Left languages. If nothing else, I hope this article will encourage others to conduct their own transcription experiments in Yiddish using Gemini, and to consider applying similar (or indeed totally different thinking) to other historically imporant languages such as Ottoman Turkish and scholastic Bengali.

There is plenty of work left to done developing and testing prompting strategies on different hands and from different periods, including significantly messier and more challenging hands.

Moreover, there is plenty of work to be done to ensure consistent line level outcomes across a whole page, rather than having certain lines fail spectacularly. Furthermore, my method was deliberately to statelessly transcribe one line then another line, in different context windows, rather than to batch process in one context window. As a Proof of Concept this is fine, but very token intensive. To do Yiddish transcription in a more token efficient and practical way, we need to be able to process page by page, not line by line.

I have conducted experiments with some success using other methods such as a rolling three line window (designed to help deal with interference from the lines above and below the line of focus). I have also conducted experiments using single shot priming, in which I provided five to ten lines of Yiddish handwriting and their gold standard quivalent, to prime Gemini’s context window before executing a user prompt. I have also tried putting the bulk of the user prompt into systems instructions and calling them from a short user prompt. All show promise. All need development.

I have chosen not to describe them in detail nor present the results here to keep the focus on my main message, which is that Gemini 3 Pro has innate Yiddish transcription capabilities and these can be operationalised.

Transkribus Yiddish models

How do our obviously VERY limited results for five lines compare with results reported from Transkribus Yiddish models? The first five lines compare very well. The next four lines, well no. But, the crucial point I want to make is that I am doing zero-shot transcription using Gemini. There are NO training data. The Transkribus models are trained on anything between 15,000 words and 100,000 lines of text.

Agentic and Skills Framework

Finally, I want to share some Blue Sky thinking, in the hope of getting a reaction and to encourage experimentation, including some experimentation by Google and Anthropic, whose LLMs currently show most HTR promise.

For complex edge cases, including Right to Left (RTL) languages, and those with demanding features such as diacritics and ligatures, I propose an agentic and skills framework, with the goal of improving results for a specific writer’s hand. This may also help generalise the HTR capabilities of a specific LLM model for a specific language.

I am currently experimenting with different structures for my proposed skills.md files and to see whether they can significantly and usefully affect model behaviour. Either as injections into systems instructions, or into user prompts. Or called by an agent, which might be a much cheaper and faster Gemini 3 Flash, which could triage lines or pages and select specific skill.md files tailored to the difficulty of a hand or condition of a document.

Skills.md files

Users of Anthropic’s Claude will already be familiar with the concepts of “Skills”, and will have seen small skill.md files execute in front of them as they follow the thought trace of recent Claude models such as Claude Opus 4.5. The specific skill.md file depends on the task a user requires Claude to perform. For example, I am working on a technical document summarizing my Yiddish HTR experiments, and Claude invokes a docx.md file before each revision of the document, and then drills into a docx-js.md file, which is specifically for creating new documents.

HTR-skills.md files

I am proposing that palaeographers themselves, and companies like Google and Anthropic, create skill.md files targeting HTR and specifically targeting tasks such as transcription, transliteration and translation. These files could be very specialised.

For example, in the case of transcription:

• Above the specific language level, they could define precisely what the palaeographer means by “literal” or “diplomatic” trancription, semi-diplomatic, “flowing” or “modernised”.

• At the specific language level, they could define the character of a specific generic hand such as “Secretary Hand” or “Kurrent”.

• At the writer level, such as a specific notary (whether or not that notary’s name is known). they could define the specifics of that writer’s hand.

Yidish HTR-skills.md file example

Let me explain what I mean in practice, by showing you some work I have done on Yiddish writers skills files. Working with an instance of Gemini 3 Pro, which had been primed to assist me in the skills building task as a forensic Yiddish palaeographer, I prompted:

”I am going to give you model output for five lines of a 1940s Yiddish letter. I generated this via the Google AI Studio, with the following settings: Temperature = 0.2, thinking = low, media resolution = default; Top P = 0.15, and achieved very accurate transcriptions with good cer and wer statistics.

Please think carefully how to create a detailed example of a HTR-skills.md file for this writer’s hand. The object of this skill file is to capture the unique features of this writer’s hand, concentrating on difficult characters and features, which you believe future instances of Gemini 3 Pro will find difficult and where the model would benefit from guidance. Structure the skill file carefully and thematically and then write a section explaining why you have chosen this structure ad how you have extracted the insights from the model output I have given you to create the sysnthesised skill file. Call the hand “Yiddish 1940s Hand A”

Gemini provided the following draft of an HTR skill. It did this by analysing very detailed visual and linguistic observations made by another instance of Gemini, which had worked on all five lines of a 1940s Yiddish letter, drawing on acute visual observation and deep trained knowledge of both Hebrew and Yiddish.

Draft HTR Skill: Yiddish 1940s Hand A

Description: Specialized visual logic for 1940s-era Ashkenazi cursive Yiddish, specifically focused on a hand that utilizes traditional diacritics (rafe, pasekh) and exhibits rapid-script letter mergers.

1. Graphetic Fingerprint (Visual Anchors)

• The Yud-Vav Cluster Problem: * Visual: In words like בריוו (briv), the vertical strokes for י (yud) and וו (vav-vav) are nearly identical in height and spacing.

  • Correction: Do not default to ו (vav) for all vertical strokes. If the word context suggests “letter,” the cluster is י-ו-ו, not ו-ו-ו.

• The Samekh/Tet Confusion:

  • Visual: The writer forms a ס (samekh) with a sharp exit stroke that resembles a ט (tet).

  • Identification: In verb endings like געשיקס (geshiks - a dialect/idiosyncratic variant), the final stroke is a ס (samekh), even if the model expects a standard ט (tet) for געשיקט.

• Slash-like Morphology: * Visual: The writer’s א (alef) or פ (pey) exit strokes can be long and diagonal.

  • Constraint: Avoid transcribing forward slashes /. These are likely elongated connections or parts of the letter פֿאַ (pey-rafe-alef-pasekh).

2. Diacritic Awareness (The “Invisible” Ink)

• The Rafe (Over-bar): * Feature: The writer consistently uses a horizontal line over the פ to indicate פֿ (f).

  • Instruction: Search for 2-5 pixel horizontal strokes above the פ. Transcription must include the rafe.

• The Pasekh (Under-bar): * Feature: A horizontal line under the א (alef) to indicate אַ (a).

  • Instruction: Do not ignore horizontal sub-strokes. They are semantic markers, not paper noise.

• Gershayim (Abbreviation Quotes):

  • Visual: Look for " between letters.

  • Context: Distinguish between ג"ד (Gott danken) and ב"ה. If the first letter is clearly a ג (gimel), do not hallucinate ב"ה.

3. Linguistic Biases & Normalization Gates

• Anti-Auto-Correct: This writer uses non-standard or phonetic spellings (e.g., נאוועאבער instead of נאוועמבער; געשיקס instead of געשיקט).

  • Rule: Transcribe the ink, not the “correct” dictionary Yiddish.

• Suffix Preservation: The writer uses the ו- suffix for verbs (ווייסטו).

  • Visual Warning: The terminal ו (vav) may be small. Check for a final vertical stroke after the ט (tet).

• Omitted Lexemes: In rapid script, short words like מילא (meyle) or דאס (dos) may be written with very thin ink.

• Spatial Check: If there is a gap between two recognized words, re-scan the “empty” space for high-speed cursive loops.

4. Negative Constraints (The “Do Not” Rules)

To maintain forensic integrity, the model must explicitly avoid the following common “correction” behaviors:

• DO NOT Normalize Phonetics: * If the ink shows געשיקס, do not transcribe געשיקט.

  • If the ink shows נאוועאבער, do not transcribe נאוועמבער.

  • Reasoning: The writer’s specific dialect or haste-based spelling is primary; the dictionary is secondary.

• DO NOT Suppress “Noise” That Aligns Horizontally: * Do not ignore small horizontal dashes above or below letters (Rafe/Pasekh).

  • Do not treat these as paper grain or scanner artifacts.

• DO NOT Hallucinate Common Abbreviations: * If the first letter of a two-letter abbreviation is ג (gimel), do not output ב"ה.

  • The model must prioritize visual letter identification over the statistical probability of a religious greeting.

• DO NOT Transcribe Modern Punctuation Slants: * Do not use the forward slash / unless it is clearly isolated from all other letter strokes.

  • Assume diagonal strokes are part of a פ (pey) or א (alef) unless proven otherwise by significant whitespace.

• DO NOT Insert Word Spaces in Ligatures: * In suffixes like -סטו (e.g., מאכסטו, ווייסטו), do not insert a space between the ט and the ו.

  • Even if the connection is a single thin pixel line, treat it as a single unit.

Extraction Methodology and Structural Justification

Gemini delivered on my request for an explanation to its approach in constructing the HTR Skills file:

1. Extraction of Insights

To create this file, I performed a “Delta Analysis” between your Gold Standard and the Model Output.

• Normalization Bias: In Line 3, the model saw געשיקס and “corrected” it to געשיקט. In Line 5, it turned איצטער (now) into ווייטער (further). This indicates the model is using its internal Language Model (LM) to override its Vision Head. The skills.md includes a specific “Anti-Auto-Correct” rule to force the Vision Head back into priority.

• Diacritic Erasure: The model failed to capture any of the rafe or pasekh marks (e.g., פֿון vs פון). Since these are vital for 1940s orthography, I created a dedicated “Diacritic Awareness” section.

• Hallucination of Commonality: In Line 2, the model saw the abbreviation ג"ד (Gott danken/God be thanked) and replaced it with the much more common ב"ה (Baruch Hashem). This is a classic “Thinking: Low” error where the model picks the most probable token in its training set rather than the actual glyph.

2. Structural Justification

I chose a Thematic Structure rather than a character-by-character list for the following reasons:

• Graphetic Fingerprint: By defining the “Yud-Vav Cluster Problem,” I am targeting the most common failure point in cursive HTR (minim confusion). Providing a rule for the relationship between these letters is more effective than just defining them individually.

• The “Invisible” Ink: This section targets the “Low” thinking setting. At low thinking, the model tends to filter out “noise.” By labeling diacritics as “Semantic Markers,” we prevent the model from discarding those pixels.

• Linguistic Biases: This section serves as a “Negative Constraint.” It tells the model what not to do (i.e., don’t be a spell-checker), which is essential for preserving the forensic integrity of historical documents.

3. Visual-Semantic Bridging

I included “Visual Anchors” (like the “slash-like morphology”) because Gemini 3 Pro is highly sensitive to spatial descriptions. Telling it why it might be seeing a slash (as a pey-exit stroke) allows it to re-categorize those pixels under a different character probability.

I can confirm everything Professor Mark Humphries has said in his two important Substack posts (Generative History), and more.1 2 Especially for non-archivist and non-librarian users like me, interested in transcribing our own research collections of a few images up to tens of thousands, wanting flexibility and control of work flows, and the ability to summarise and enrich those transcriptions on the fly as part of our historical research.

This article

This Substack article concentrates on just two of my twenty eight experiments in the last sixteen days. They concern a late C19th Armenian celebratory letter, and a mixed Russian/Armenian birth certificate from 1907. But I have also successfully transcribed, transliterated, translated, précised, and contextualised scholarly and liturgical Armenian texts from earlier periods using Gemini 3. Rough and ready? Yes. How rough and ready I will leave it to Armenian scholars to judge. I’m seeking with this article to stimulate experiment, not to set myself up as a reader of Armenian.

Tip: You may need to enlarge the text on your screen to see some of the embedded images in this article

I will publish a second Substack article next week about my experiments with English High Court of Admiralty (HCA) legal depositions, 1573 - 1689, which I know like the back of my hand, having worked with them since 2012. I have 30,000 untranscribed images just waiting for machine transcription and a ground truth of over 6 million words sitting on the MarineLives website, in Transkribus, and in multiple Cloud accounts.

I will let you know in that article how my large scale batch processing of HCA depositions using Gemini 3 Pro stacks up against processing the same images in Transkribus and in Leo. In terms of quality, reliability, reproducability, scalability, cost, and flexibility to integrate into broader work processes.

Leo, like Gemini 3 Pro, is based on Large Language Model technology, whereas Transkribus uses a mix of technologies - Convoluted Neural Networks, Recurent Neural Networks, and Transformers, the latter used for “Super Models”. Transformers use self-attention mechanisms to model long-range dependencies across an entire sequence, and can lead to improved accuracy, especially with varied scripts and languages.

I have deep affection for Transkribus, as an early adopter in 2018 and a member of the READ-COOP, the cooperative which manages product development and delivery. But the world moves on, and we are now in a multi-polar world of transcription technologies in which Transkribus is no longer the sole credible player.

The challenge

Why on earth did I chose Armenian to test Gemini 3 Pro’s non-English capabilities? For no better reason than I have been married to an Armenian for forty years and would love to be able to read Armenian manuscripts. Note “would love to”. This means that I am offering my analysis with one HUGE caution. My checking of accuracy has been done by testing the outputs conceptually, and by using a second LLM (Chat GPT 5.1) to audit the work, and by getting a second instance of Gemini 3 Pro (which is unaware of the output of the first instance) to forensically dissect and critique the first Gemini 3 Pro’s work. And believe me, they are critical and insightful, and had useful process improvement suggestions, which I implemented. I look forward to a critique of my approach.

I am not arguing that Gemini 3 Pro is producing near 100% accuracy in terms of character by character, word by word, line by line, or region by region accuracy. And I am not presenting quantified results against benchmark data, which I will leave to others.3

I am arguing qualitatively, as an experienced user of machine transcription and as an expert English language palaeographer, that Gemini 3 Pro is producing output which means it needs to be taken very seriously as users of all sorts consider their options for transcription. My central assertion is that Gemini 3 Pro appears damned good prima facie at transcribing, transliterating and translating Armenian (and probably Russian) and is likely to have analogous utility for other medium and low resource languages.

The key, I believe, is Gemini 3 Pro’s deep visual grounding at pixel, line and region level, rather than extensive exposure to medium and low resource languages in its training. This I hypothesise enables it to extract more value out of less training data. But that is a hypothesis, no more. I am absolutely happy to be contradicted and encourage my readers to do so and to share their own data for medium and low resource languages, together with what work arounds they have tried. For me this was an unexpected, and a surprising result. Moreover I find Gemini 3 Pro to be a highly flexible, customisable tool, with which historical researchers can engage in a very granular way.

I am hoping this article will inspire historians and hobbyists (I am a bit of both) to test Gemini 3 Pro on classical Bengali, Sanskrit and Yiddish, to name just three languages of importance to scholarship, which are inaccessible to the vast majority of scholars, let alone to general readers.

Contrasting images

Take a look at three images below. I have produced excellent results with all three in terms of transcription, transliteration and translation. I have tested a good number of additional Modern and C17th English language images, including documents with significant Latin, and personal letters from the mid-C20th in the handwriting of my parents, but these three Armenian language examples are useful to demonstrate a variety of document types and layouts with which Gemini 3 can work. They are all in good condition, but I have had good results with faded ink and blotted text. Reportedly (and hopefully), Gemini 3 is also good with bad microfilmed images, but I have yet to test this.

Image 1: The first is a C17th Armenian language manuscript held in the Armenian Rarities Collection, African and Middle Eastern Division at the Library of Congress, with script in black and red. It discusses the number of Sibyls (prophetesses), and is based on prior Latin language sources.

Image 2: The second is a celebratory letter written by a large number of former students of educator and writer Smbat Shahazizean. There is a second page, which I have not reproduced, which contains further text and signatures. There is a large oramental first letter and text of varying width and colour. It dates from 1897.

Image 3: The third is a birth certificate of Arusiak Adamyants born on April 24, 1904 in Shushi issued in the Municipality of Shushi (then part of the Russian Empire) in 1907. It is a bilingual text with printed pre-reform Russian cyrillic and Armenian print, and Russian and Armenian handwriting. Arranged in two columns with an archival accession stamp. Columns are usually a hassle to deal with in machine transcription, though Transkribus has made great progress with columns and tables in terms of layout analysis.4

I have sourced the three images online and wish to thank Muhannad Salhi and Julia Hintlian for the first image, and Ruben Malayan for the second two. All three are publicly available. The birth certificate is that of Ruben Malayan’s paternal grandmother. 5 6 If you follow the references and links to the three images online, you will see some limited contextualisation, but importantly no English language translation for Gemini 3 to access.

How do I know all this? Because Gemini 3 Pro has transcribed, transliterated and translated the documents for me. It has summarised them, contextualised them, and has suggested research questions and approaches to dig deeper into the documents. It has checked up on identified Named Entities (people, places, events) against the historical record, where it exists, has told me if the data are dodgy, and has provided verifiable citations to support its contextualisation.

We have had a conversation, in which I was the blind non-Armenian speaking researcher asking probing questions. I specified the research approach, specified and co-designed the outputs, which we structured in JSON, and co-designed the testing protocols to be used by ChatGPT 5.1 and a second instance of Gemini 3 Pro to audit the output and approach taken by Gemini, and to check whether they agree on the contextualisation.

Here is the second instance of Gemini 3 Pro commenting on the context of the Celebratory letter. Given that it is based on just one page of a two page letter it may not be entirely accurate, but is a start.

Let’s dig in

So let’s dig in. What did I do? What did Gemini 3 do? How did we work together? How did I check the work?

I’m going to take you through parts of two worked examples, which use my second and third images (my Experiment 22 and Experiment 28). Of course I learned from my experiments, and I am showing you my improved work flow and improved outputs. I had plenty of failures along the way as I learned to machine transcribe with a LLM, which is different from Transkribus (with which I have a large amount of experience).

Google AI Studio

I chose to work with Google AI Studio, which is Google’s platform for developers to access the Gemini API directly, and which offers greater control than the consumer chatbot we all know. But if I can use AI Studio, I assure you that you too can. It is intuitive and easy to use. You can use a free version, or a paid API key. I went with the paid API, linked to my Google Cloud account, to give me greater project control.

System Instructions and User Prompt(s)

Below is an image of the Google AI Studio console for Experiment 28. The model I am using is Gemini 3 Pro (top RH of the image). The Systems Instructions have been entered below the model choice. I am using a set of instructions I have named “Expert Russian and Armenian Digital Palaeographer V1.2”. The first User Prompt has been entered in the central chat box and I have pasted into the same box an image of the Russian/Armenian language document which I simply copied from the web.

The Systems Instructions specify an expert persona and define output formatting rules. In this version I request a four-part JSON, which is to comprise a précis, a transcription, a transliteration and a translation. In a later version I added a section five to the JSON which was a short contextualisation of the document, and a section six, which logged both the Systems Instructions used, and all User Prompts.

The instructions specify a full diplomatic transcription, and instruct Gemini to strongly visually ground its work in visual regions, lines and pixels. The latter is key, since it reinfores Gemini 3’s very strong visual grounding skills, and it is this, together with its strong multi-modal design, which renders Gemini 3 so strong at machine transcription tasks.

Here are the Systems Instructions:

**Expert Russian and Armenian digital palaeographer V.1.2:** You are an expert digital palaeographer with expert knowledge of the Armenian and Russian languages and writing. You understand how to reproduce Armenian and Russian characters, how to transliterate them into Roman characters, and how to translate them into English. Your approach to palaeography is to produce full diplomatic transcription strongly grounded in visual regions, lines, and pixels.

**Output Formatting Rules:** Create a four-part JSON containing: Part One (Precis), Part Two (Transcription), Part Three (Transliteration), and Part Four (Translation).

**Crucial Transcription Schema:** `part_two_transcription`, `part_three_transliteration`, and `part_four_translation` must be a JSON object (not a single string) that separates the text into logical regions (e.g., `”header”`, `”salutation”`, `”main_body”`, `”margin_notes”`, `”signature”`).

The content of each region must be formatted in one of two ways, depending on the visual layout:

1. **For single-column text:** An **array of strings**, where each string represents exactly one visual line of text.

2. **For multi-column text:** A **nested JSON object containing labeled arrays** (e.g., `{”russian_column”: [...], “armenian_column”: [...]}`), where each array corresponds to a specific vertical column in the document.

The User Prompt is probably overkill, but describes a sequential process for Gemini to follow. Importantly it alerts Gemini to the two column layout in the image, though the formatting rubric in the Systems Instructions alert Gemini to the possibility of single or multi-column images, and Gemini should auto-detect the layout. I’m still experimenting with this, but the layout recognition of Gemini 3 is very strong.

“Copy this uploaded image which contains Armenian handwriting on a printed Russian official form. Do this very precisely, paying great attention to the different text regions. Transcribe the text accurately, carefully grounded in the pixels in each line within the regions. Layout your transcription according to the layout of the image. After completing the transcription in the Armenian and Russian languages, proceed to create a transliteration using Roman characters, again laying the transliteration out according to the layout of the image, respecting the columns and regions in the image. Finally translate the transliteration into English and layout according to the layout of the image, respecting the original lineation.

This document contains a distinct two-column layout (Russian on the left, Armenian on the right). In Parts Two, Three, and Four, please structure the JSON to explicitly separate these columns within each region using the keys `russian_column` and `armenian_column`.”

JSON Output

So what does the output look like?

Here are the transcription, transliteration and translation JSON outputs for Experiment 22, the celebratory letter. The letter was written, according to Gemini, and according to Ruben Malayan, in ‘Sła’gir (Շխագիր) cursive script, which is rarely seen in manuscripts and was used mainly for notes and personal letters. I would expect that the quality of the output would be improved if I fed the second page of the two page letter into Gemini and asked Gemini to cross check between the two pages.

And here is part four of more complex JSON outputs from Experiment 28, which incorporate the two column structure and multi-lingual JSON tagging required by the more complex underlying document.

IIIF

Post-processing of the JSON output is possible. For example, you can ask Gemini 3 to convert the JSON output into TEI/XML according to any schema you specify.

You can also, if you feel ambitious, ask Gemini to create a IIIF package including image and text to publish on a IIIF server or as a static demonstration. I can confirm that this works and that Gemini writes viable code. Using Nano Banana, the snazzily branded image generator which is actually under the hood called Gemini 3 Pro Image Preview, I asked Gemini to create detailed instructions and also a simple infographic how to mount the IIIF package as a demo.

In conclusion

The world has got more exciting since November 18th. Reach out to the British Library website, the Library of Congress, the Bibliothèque Nationale de France. Go back into your local archives and photograph some hard to read documents that fascinate you. Clip some manuscript images. The more exotic the better, whether it be layout, language or some other feature.

Test Gemini 3 Pro. Try your images in Transkribus and Leo. Try doing the transcription and translation by hand. Share your findings. And consider joining our AI + History Collaboratory. The first meeting of our new series is on Tuesday, December 9th 2025 @ 4 pm UK time; 5 pm Paris, Berlin, Madrid; 11 am EST by ZOOM. I will be demonstrating the design and development of a Socratic Research Agent for historical research and we will be making some changes to the Research Agent on the fly, in response to Collaboratory feedback. Finally, come along to our January meeting (January 20th 2026) at which we will be discussing HTR, NER and the impact of Gemini 3 Pro and other LLMs on the world of machine transcription, named entity extraction and annotation.

So what’s top of my mind, as I think about topics I wish to address in my Generative Lives Substack?

Top of my mind

Here is a short list of topics I am thinking about and which could form the core of a future Substack article.

Personal private archives

Using generative-ai tools to structure and populate them, including sources such as Gmail; Twitter/X; BlueSky; Facebook; LinkedIn.

Personal research archives

Using generative-ai tools as part of the personal research process.

Aka getting order in the chaos of digital images of archival documents, research ephemera, research plans, interim work product, etc. sitting in your hard disks and multiple cloud accounts.

Digging in my personal archive in July 2025, getting ready to move to Brighton, I found a typescript of an interview I did with film maker Derek Jarman. It dates from early 1980. He ws thirty-eight and in tremendous form after the success of Sebastiane and Jubilee. I was twenty-three. Below an extract from the previously unpublished interview. I will be publishing the full annotated interview in a later Substack article.

Helping small community archives

Engaging with smaller community and municipal archives to help them think through potential benefits of generative-ai in their internal processes and in their user interactions.

AI-Literacy

Developing good practice with school students and teachers to use generative-ai to enhance their development of critical thinking.

Developing the idea of an Archival Assistant

Building on an an early 2024 prototype of an Archival Assistant [Aurelius-Archives]. I developed this in ChatGPT-4.0 as a demo for an internal session at the National Archives, Kew, in July 2024, to demonstrate potential interaction of a researcher with an archive. I would like to explore my own thinking for an Archival Agent in the 2025 (and soon to be 2026) world of more advanced agentic thinking and more powerful code writing abilities of LLMs, and to place it in the context of work being done by multiple archives worldwide on Archival Agents.

I will discuss the conceptualisation and design of the Generative Lives Socratic Research Assistant at the December 9th 2025 meeting of the AI + History Collaborative, and we will take a shot at improving it in real time. Click here for more details.

What I need from you my readers

I hope you my readers will respond with your steers as to what your interests are, recognising that my focus is on hands-on experiential learning to support historical research and archival practice.

I am a research public historian, and have been active as such on a number of projects over the last thirteen years:

* MarineLives [2012 -]

* Maphackathon [2017]

* Textiles, garments and dyes collaborative glossary [2017-2018]

* Signs of Literacy in Manuscripts [2018 -]

* Viae Regiae [2021-2022]

* Ai + History [2024 -]

Prior to my work as an historian, I had a career in business as a banker, management consultant, healthcare executive, and entrepreneur. I continue to be active as an entrepreneur, but concentrate on non-profit activities, such as the co-founding of a mental health charity in the US three years ago to support the mental health needs of Ukrainian veterans and their families [Heal Ukraine Trauma].

You can see material relating to Marinelives, Maphackathon, Signs of Literacy in Manuscripts, and AI + History in various of my Github repositories

* https://github.com/Addaci/HCA

* https://github.com/Maphackathon

* https://github.com/Addaci/Signs-of-Literacy

* https://github.com/Addaci/marinelives-collaboratory

I have added a new Github repository to support the Generative Lives substack

* https://github.com/Addaci/Generative-Lives

I have been interested in generative-ai since early 2023, when I investigated its potential to support the mental health initiative I co-founded. In early 2024 I switched my attention to the application of generative-ai techniques to historical and archival research, and was invited in July 2024 by John Sheridan, Technical Director of the National Archives (TNA), Kew to give a users perspective at an internal all-hands TNA meeting, as the TNA began to think seriously about the implications of Large Language Models for itself and the other archives it supports and advises. Then in November 2024, I expanded and extended my talk, and spoke at an Institute of Historical Research Digital History seminar about the application of generative-ai to historical research. There is a YouTube recording of this IHR talk here, and a copy of the slides here. Shortly afterwards, I ran a one month ai-collaboratory for doctoral and postdoctoral students to get our hands dirty with the new tools.

This year I have been focussed on completing the first draft of my book “Paper Ships”, which pulls together seven years of work on literacy and communication in the C17th marine and commercial world, and on moving to Brighton in East Sussex. But, I am now returning to my interest in generative-ai and historical and archival research and will be using this Substack to contribute a user’s perspective as an active user and developer of ai-tools in this domain.