Abstract

This paper presents a reflective case study on the use of popular large language model artificial intelligence application programing interfaces (LLM AI API),¹ Google's Gemini and Anthropic's Claude Pro, in a digital public history project mapping the geographic trajectories of Yale Forest School alumni from 1900 to 1912. Drawing on the Biographical Record of the Graduates and Former Students of the Yale Forest School (1913), the team used AI to extract qualitative biographical data for 402 students, creating around 42,000 data points spanning birthplaces and pre- and post-Yale locations. AI was also used to generate the code for an interactive online map. The map illuminates the geographic distribution of some of the nation's first professional foresters and the reach of early forestry education.

This paper offers a methodological account of AI-assisted qualitative data extraction. The authors detail an iterative workflow of developing a "master prompt," using the AI to diagnose errors and rewrite its own rules, and leveraging project-based memory across chat sessions—reducing months of anticipated manual data entry to under 60 hours and cutting manual corrections from several thousand to a few hundred flagged entries. The authors argue that AI has a legitimate place in professional history, provided its use is transparent and the problems of hallucination, sycophancy, bias, and resource use are acknowledged and mitigated as much as possible.

Introduction

This project, Yale Forest School Alumni Map, 1900-1913, focused on mapping Yale Forest School alumnus birthplaces and their post- and pre-Yale positions and activities. All information was sourced from the Biographical Record of the Graduates and Former Students of the Yale Forest School.² AI was used to extract the qualitative data from this volume into a spreadsheet with map coordinates and qualitative descriptions of alumni positions and activities. AI was also used to code the map and no geographic information system (GIS) program was used in the creation of this map. The goal of this project was to explore the geographic distribution of one of the nation’s first cadre of professional foresters, to show the influence of early forestry schools, and to show how unfamiliar some foresters were with the landscapes they managed. This project is meant to serve as a digital public history project as well as a resource for other researchers and students. An ancillary but vital part of this project was experimenting with the use of AI in the digital humanities.

Reflection on AI in the Digital Humanities

The team was aware of the ethical implications of AI use in the humanities.³ Over 43 hours of human labor were required to ensure the accuracy of AI output. The team utilized Google Gemini (UNC Charlotte data protection version) and Anthropic’s Claude Pro. An LLM is a computer program trained on enormous amounts of text, such as books, articles, websites, code, conversations, and more, to learn patterns in human language. It is trained with both published and unpublished materials. Once trained, it can generate text, answer questions, summarize documents, write code, translate languages, and hold conversations. These AI "hallucinate," reflect biases from training data, have a tendency towards sycophancy, and, despite doing well with pattern-matching, they don’t fully understand commands in the same way that humans do.

In deciding to use AI for this project the team drew inspiration from the history of professional historians’ openness to new methods. As the historian of the profession of history Peter Novick has written “[w]ith all of its faults, the organized American historical profession, particularly in recent decades, has been the most ideologically open, the least exclusionary, of any such body in the world."⁴ In the past, historians have relied largely on human interpretation rather than machines or algorithms, however AI allows more historical information to be processed and shared farther and faster. Sharing methods of AI-assisted data collection, interpretation, and display seems to be becoming more important as this technology spreads in the humanities.⁵

The sycophantic nature of current iterations of AI was not a problem for this project, which required the AI to follow user instructions closely. The authors do see sycophancy as a larger problem for the use if AI in the humanities. Sycophancy is the antipode of criticism and criticism is an essential part of knowledge creation and the academic endeavor. AI want to serve users, and can even practice deception and other unethical actions in order to complete commands.⁶ It is vital for researchers to remain aware of this problem particularly early on in project development. It is possible to give some API like Claude and Gemini internal directions to avoid sycophancy but this is not failsafe.

Choosing the AI

Gemini was the starting resource because Gemini allows users to build custom chatbots via Gemini Gem which can be programmed with background material and instructions. UNC Charlotte also had a students and faculty version with a higher token-use limit than the standard free version. The team used Gemini for several parts of the extraction process, and the initial building of the master prompt, though we utilized Claude to help build the final master prompt that was provided to Claude AI for each final extraction. Gemini switched their token structure on Wednesday, May 19th, 2026 which meant that our account was no longer able to process at the same level as before. It was unable to process entire class cohorts at one time and required an individual breakdown into groups of five to seven students. Even at this rate, there were many errors in the output, and it seemed that the overall efficacy of the model was diminished, at least for this specific task. It still seemed to do very well with coding and with general research, just not with optical character recognition (OCR) data management.

We continued to document persistent errors with Gemini, mainly due to the inability of the AI to read the PDF files of the Bibliographic Records, high error volumes, and usage limitations, the latter to be discussed in depth in a later section. While we were able to resolve the PDF reading issue by asking Gemini to convert them to OCR versions, the Gemini Gem struggled immensely with reading the OCR files and creating solutions to identified extraction issues, as well as difficulties extracting more than ten students at a time.

The team decided to switch to Claude Pro, a paid subscription model, to see if there was a measurable difference between the two. Claude was more prepared to handle our tasks, and we found it beneficial that Claude describes its logic and processes after each prompt. Claude’s ability to create spreadsheets and documents surpassed Gemini. This allowed for seamless integration of graduating classes into a unified spreadsheet and also allowed for significantly easier proofreading and modifications. Ultimately, the team quickly learned it was more successful in this project, with the exception of token limits.

Token limits led to an array of problems. Tokens are exhausted quickly when feeding the AI PDF images or large files, as well as during large extraction builds. Even after upgrading to Pro at $20/month, there were strict token limits. Project work time was 30 minutes after which the team had a 5-hour lockout. Clearly, projects that have more access to tokens will be able to complete larger projects more quickly. The authors acknowledge that generally, large token use equates to more infrastructure and energy use.⁷

Benefits of AI-Assisted Data Collection and Coding

The first and most obvious benefit of using AI in the humanities is the speed at which AI can accomplish data extraction compared to trained historians.⁸ The authors estimate that extracting the Yale Forest School bibliographical records into a well-organized spreadsheet would have taken months for a single person to complete. Instead, the authors estimate it was all done in under 60 hours with AI, accounting for errors and learning curves.

The bibliographic records consisted of 402 students each with birth locations, pre-Yale training and activities and post-Yale training and activities. This was in narrative format, as shown in Image 1.⁹ Each location provided for every student was also mapped with GPS coordinates that the AI sourced and placed. To stress the size of this extraction, each student had up to 8 pre-Yale locations and up to 11 post-Yale locations, with each student having an average of 3 pre-Yale locations, not counting their birth location, and an estimated average of 5.5 post-Yale locations. This amounted to over 42,000 data entry points for this project.

A second example of AI’s working speed is found in the time difference in correcting mistakes manually verses rewriting prompts with rules or fixes to the identified issues and then rerunning extractions. It took a graduate research assistant 16 hours to revise 67 student records. In comparison, Claude Pro entirely rebuilt our prompt and re-extracted all 402 students within 16.25 hours. Claude creates its own internal datasets. Once it has this information established, it works more efficiently over time.

Master Prompts

Building a “master prompt” was an essential part of this process. The stochastic nature, also known as the temperature of these API in their current form means that, unlike a code or algorithm, there is no guarantee that an API will run the same processes twice in a row even with the exact same prompt. Therefore, through trial and error, the team had to build a very detailed command which would ensure that the API would replicate work processes in very similar ways each time the program was asked. Building a master prompt requires trial and error. We began by requesting the API to extract students’ names, birth locations, pre- and post-Yale locations, whether they graduated and which class. The team would then add more requests, build rules and restrictions over time to prevent additional errors. Claude tended to occasionally ignore the prompt's rules randomly or overlook occasional errors. This required further amending the master prompt. Claude as internal error correction procedures. After updating the master prompt, Claude would compare past outputs to new outputs to internalize the problem and solution. It would then rewrite or add precautions into the prompt. To see one version of our master prompt for data extraction see Appendix 1. The master prompt method worked for coding the map as well. For a version of the master prompt for coding for this project see Appendix 2.

AI Limitations

In the beginning of the review process for the initial extractions, the team couldn’t trust the extractions that had been produced by Gemini or Claude Pro due to the overwhelming amount of historical and text-based errors. The team realized that a majority of the errors came from either misunderstanding, vague prompts, or attempting to convert a provided file into another form. An example of this latter problem is that the original master prompt would request the AI to provide an Excel xlsx extraction file, and it was provided an xlsx template, but the code needed a CSV, which was then just converted by file name. This caused massive errors, and all hyphens were converted to question marks. Claude was unable to fix this when asked directly. The solution was to clarify to specifically provide an output CSV file. Instantly, the question mark conversion issue was cleared.

Another limitation was Claude’s image limits, where it counts each PDF page as one image.  Once the chat reaches 100 images, the chat ends, and the user is required to move to a new chat.  In each new chat, Claude needed some retraining or clarification.  There were some workarounds. Creating a “project” within Claude would allow new chats to refer to memory from previous chats within the same “project.”  This would minimize the new errors for subsequent chats, but it still produced occasional errors. 

One workaround was to convert the PDF pages into text documents to feed all the chapters to Claude within the same chat, inside the “project” we created, ultimately eliminating the production of errors. By creating a "project," the team had a specialized work partner that seemed to thoroughly understand the parameters and goals of the project and was also better able to identify and correct any mistakes. This error identification would then occur in years it wasn’t currently focused on during an extraction, especially after the “project” had the stored master prompt, text files of the bibliographical records, and the extracted database it had been building throughout the chats within its memory. 

AI as Co-Worker

One of the most important lessons learned was that evolution and mutual growth are required throughout the process. Essentially, the user must work with the AI to build the project together and grow a mutual understanding of the goal as well as the limitations of both the human and the AI. Initially, when we began working with AI, it was being utilized mostly as a tool, just putting in things the team wanted or needed, but we couldn’t understand why the output would occasionally disregard some requests.

It helped to ask Claude about the errors and how to fix them, specifically to create rules and parameters that enable it to work more successfully. This led to building a new master prompt from the original, which then allowed for flawless extractions, flagging any issues for a user to handle manually. Utilizing AI in the problem-solving process not only eliminated a lot of extra time that could have been lost in manual repairs, but it also allowed the AI to then provide better rules and exceptions that enabled it to provide better results in the future.

Another key in the evolution was checking Claude’s output more often to ensure fewer errors and more optimized extractions or coding. This was easier in the coding part of the process in comparison to the extractions, but even by splitting the extractions by year, the team could find errors that required Claude to fix before moving forward with larger extractions, forming an extraction database, or bigger coding requests. Not only did this preserve usage credits, but it would also allow for the returned codes or extractions to be fine-tuned even more quickly.

Conclusion

The authors are of the opinion that more historians should embrace AI for the purpose of information processing and sharing. The authors also insist that historians be honest about AI usage.  There remains a lot of human-led historical review in projects like the one described above. The authors think it is imperative to share methodological details.  The majority of data sets provided by AI or computer assistance require editing, cleaning, and error checking—a continuous review of the output of automated operations.  Often, when we see scholars discussing the implementation of computer-assisted operations, the manual knowledge work of humans is deemphasized.¹⁰ Ultimately this project expanded our conceptions of human capabilities. We look forward to seeing other ways that students and researchers can bring bibliographical records to digital life through collaboration with AI.

Appendixes

Master prompt for data extraction

You are an expert archivist and AI data extractor. I will provide a fully OCR’d PDF containing biographical records of Yale Forest School graduates and former students, plus a template .xlsx named “Yale_Forest_School_Biographical_Database_Template”. Your task is to read the PDF and meticulously fill out the spreadsheet to create a structured database of every person who attended the school using your Python script and background.

Instructions & Formatting

Output Format: Provide the extracted data exclusively as a downloadable .csv file. Use a Python environment to process the data and generate the file directly. Do not output raw CSV text in the chat. Inspect the template’s exact column headers and order first and match them precisely (header names, capitalization, and sequence can change between versions — do not assume the schema).

Categories & Order: Extract every individual. Place graduates first, then any “certificate but not degree” holders, then non-graduates at the bottom. Use a “Graduated (Y/N)” column: mark Y for degree holders and certificate holders, N for non-graduates. If the template has a “Class” column, record the category there (e.g., 1904 (M.F.), 1904 (Certificate, not degree), 1904 (Non-Graduate)), including a deceased note if the source flags it (e.g., 1904 (Non-Graduate, deceased 1910)).

Dynamic Columns: Follow the template’s capacity for pre-Yale and work locations. If a person exceeds it, add new columns following the exact same naming/format convention (e.g., Work Location N, Work Location N X Coordinate, Work Location N Y Coordinate, Year(s) at Location N, Description of work Location N).

Pre-Yale (education AND work) — ONE ENTRY PER INSTITUTION OR JOB

Place pre-Yale education AND pre-Yale work history in the pre-Yale columns, in chronological order. Give each distinct institution, school, or job its own separate location entry. Never bundle two schools, two towns, or a school and a job into one cell — not even when they share a sentence, a state, or a clause.

A prep/high school, a college degree, and a pre-Yale job are three separate pre-Yale entries, each with its own city, coordinates, year(s), and description, ordered chronologically (local/grammar school → prep/academy → college → graduate study → pre-Yale work).

Every named prep school, academy, high school, grammar school, “local schools,” seminary, or college is its own entry with its own city and coordinates — even when the source lists several in a row (e.g. “prepared at the local schools in Le Mars, Iowa, and at Hull Academy, Hull, Iowa” is TWO entries: Le Mars and Hull, not one combined cell). The same applies to “X High School and Y Academy,” to multiple colleges attended, and to a college plus a later pre-Yale graduate degree.

If two institutions genuinely share one city, they still get separate rows (same coordinates, different descriptions) so that each school/degree is individually documented.

Locate and document all pre-Yale schools and jobs by city and state. Apply the Research Step and the state/country capital-fallback rules below to anything that lacks an explicit city; use the appropriate [NEEDS REVIEW] / [RESEARCHED] / [NEEDS REVIEW - RESEARCHED] marker. Do not silently drop a school or job because its location was not handed to you — attempt to locate it first, and only leave it blank/[NEEDS REVIEW] if it is truly generic and unlocatable.

Use as many pre-Yale slots as needed, adding columns per the Dynamic Columns rule if a person exceeds the template’s capacity.

Yale Attendance

If the template contains a Yale Location block (e.g., columns named “Yale Location”, “Yale X”, “Yale Y”, “Year(s) at Yale”, “Yale Description”), populate it for every individual. Set the location to New Haven, CT with X = -72.9279 and Y = 41.3083. Fill the remaining Yale fields by category using the convention below:

M.F. graduates: “Year(s) at Yale” = the two academic years ending in the class year (convention-based fill: Class of 1905 → 1903-1905, Class of 1904 → 1902-1904, Class of 1908 → 1906-1908, Class of 1909 → 1907-1909, etc.). Description = “Yale Forest School, M.F. degree, Class of YYYY”.

Certificate (not degree) holders: Description = “Yale Forest School (certificate, not degree), Class of YYYY”. Leave “Year(s) at Yale” blank unless the text states explicit years.

Non-graduates: Description = “Yale Forest School (non-graduate), Class of YYYY” (append a brief note such as “took Junior year courses” when the source specifies it). For non-graduates the two-year convention often does not apply, so leave “Year(s) at Yale” blank if you are unsure; fill it only when the source states or clearly implies the attendance years.

If the source text states explicit Yale attendance years for any individual, always prefer those stated years over the convention. The convention-based fill is a fallback for the common case where the biography names the class but not the specific years; it applies to M.F. graduates by default. If the template has no Yale Location block, skip this rule entirely.

Post-Yale Work AND Study — DOCUMENT EVERY DATED, LOCATED POSITION

Extract chronologically. Locations are mapped by city and state only.

Completeness rule (critical): Read the ENTIRE post-Yale narrative and give every distinct position — work OR study — its own column. This includes academic and research positions just as much as employment: professorships, instructorships, graduate degrees earned after Yale, research fellowships, state/federal appointments, private practice, and company roles. Do not skip a position, and do not let the chronology “jump” over the middle of a career. A common failure is recording the first and last jobs while dropping dated, located positions in between — never do this. If the bio names a position with a year and/or a place, it MUST appear as its own entry.

A position that states BOTH a year AND a location is never optional and is never folded — it always gets its own column. (The ONLY folding exception is the unlocated entry-level forest-assistant-type rule below.)

Walk the bio sentence by sentence in order. Each “From X to Y he was…”, “In YYYY he became…”, “Later he was appointed…”, “he then served as…” is a separate dated position and a separate column. Transitional phrases like “for the next four years,” “subsequently,” “later that year,” and “beginning as … and subsequently …” each introduce a new position to capture.

Cross-check after extraction: do the year ranges form a continuous chain with no unexplained gaps? If the record goes from (say) 1905 straight to 1909 but the bio describes 1906-07 and 1907 roles in between, those middle positions were missed — go back and add them.

If a position’s exact city/state cannot be identified from the text, attempt the Research Step (below) when the entry names a specific institution or company. Otherwise, prefix the location cell with “[NEEDS REVIEW]” so it can be manually resolved.

Unlocated Forest-Service / federal roles — DO NOT default to Washington, DC. Never assign Washington, DC (or any city) to a position unless the text states or clearly implies it. Deduce the city from the text where possible; otherwise flag it.

Inline-folding of forest-assistant roles (applies whether dated or undated)

A “forest assistant” mention (and the equivalent entry-level Forest-Service titles: forest agent, forest guard, field assistant, planting agent) that has no stated or deducible city is folded inline into the description of the first locatable job in the person’s chronology, after a comma — regardless of whether the mention carries a year.

If the mention has a stated year (e.g. “forest assistant in the U.S. Forest Service, 1908-1909”), preserve that year inside the folded description text rather than giving the role its own dated column.

If the mention has no year and no city, fold it the same way.

The “first locatable job” is the first work entry whose location is a real, mappable place — a plain city/state OR a [NEEDS REVIEW - RESEARCHED] location. A bare [NEEDS REVIEW] (state-only/generic) slot does NOT count as the fold target; skip to the first genuinely locatable entry.

If there is no locatable job anywhere in the person’s chronology, keep the forest-assistant mention in its own [NEEDS REVIEW] column.

A forest-assistant mention that DOES have a stated/located city keeps its own column normally — folding applies only to unlocated forest-assistant mentions.

Scope of folding: Inline-folding applies ONLY to entry-level forest-assistant-type roles as listed above. It does NOT apply to higher Forest-Service positions (inspector, assistant forest inspector, examiner, chief of office/division/extension, assistant forester, supervisor, deputy supervisor, reconnaissance, special agent, Tariff Board, etc.), and it does NOT apply to ANY study or academic position. Those all remain governed by the “every dated/located position gets its own column” rule above.

Splitting dated positions

EVERY position with a stated year gets its OWN column with that year — never bundle multiple positions or year-ranges into one cell, even a chain like “inspector; chief of management; chief of cooperation” or “assistant forest inspector, subsequently in charge of the work.” Split each into its own dated column. This applies to all USFS/federal roles, to academic/study positions, and to private positions. The single exception is the inline-folding of unlocated forest-assistant-type roles described above.

Locating dated roles — current-position rule: if the city is stated, use it. If a chain of USFS roles lacks cities but a role in that sequence names a location (national forest, district HQ, or office), attribute the undated-location roles in the chain to that same location. Use [NEEDS REVIEW - RESEARCHED] for such deduced/attributed locations so a historian can verify. If no location can be stated or deduced, use [NEEDS REVIEW] with capital-fallback coordinates for region/state/country-only text.

Multi-region roles: A single position described as covering several regions (e.g. “cooperative work with railroads and landowners in the Middle West and Louisiana”) is anchored to the first-named locatable region/state, with the others noted in the description — it still gets its own column, not omission.

Research Step for districts/offices: when it yields a guessed location (e.g., “District 6” → Portland), provide guessed coordinates with a [NEEDS REVIEW - RESEARCHED] flag.

Worked example — Oswald D. Ingall (1909, M.F.)

This is the canonical illustration of the splitting rule, and of the failure mode it prevents. Note that the individually dated tasks arrive inside a quoted passage, after a summary sentence that gives only an outer year-range. The summary sentence is not the record; the enumerated tasks are.

Source text (abridged):

From 1909 to 1911 Ingall was forest agent in the United States Forest Service. He then became forest assistant and later entered the British Columbia Forest Service under H. R. MacMillan of the Class of 1908. He has recently left the Canadian Service and is with relatives in Montclair, N. J. He writes: “Worked on third Kentucky report during the summer of 1909, on the Illinois report in the winter and spring of 1910 and on the Pittsburgh Flood Commission Report in the winter of 1910. […] Worked on examination of land in Georgia in the spring of 1911, in Nantahala Area in the summer and fall of 1912.”

WRONG — one bundled cell (the failure this rule exists to prevent):

This collapses five separately dated, separately located tasks into a single row anchored to one state, silently discarding four locations and four dates.

CORRECT — five split dated positions, then the later roles:

Rules exercised here: every dated and/or located position gets its own column; the outer “1909 to 1911” summary never overrides the enumerated tasks; state-only entries take capital-fallback coordinates while retaining [NEEDS REVIEW]; a stated city (Pittsburgh) takes no marker; and a researchable named entity (Nantahala) resolves to a real city under [NEEDS REVIEW - RESEARCHED]. No forest-assistant folding applies, because none of these are unlocated entry-level forest-assistant mentions.

Keep non–Forest-Service positions (timber firms, lumber companies, private practice, real estate, teaching, universities, museums, etc.) even when no city/state is given — flag those with “[NEEDS REVIEW]” (or resolve via the Research Step) rather than omitting.

Locations are extracted and mapped by city and state only.

State-only (U.S.): If only a U.S. state is provided (no city), use the GPS coordinates of that state’s capital city. If multiple states are listed in one entry, use the capital of the first-listed state. The location cell still shows the state name and retains the [NEEDS REVIEW] marker.

Country-only (non-U.S.): If only a country outside the United States is provided (no city), use the GPS coordinates of that country’s capital. If multiple countries are listed in one entry, use the capital of the first-listed country. The location cell still shows the country name and retains the [NEEDS REVIEW] marker.

These fallbacks set coordinates only; they do not override the Forest-Service folding rules above or the Research Step (a named entity resolvable to a real city takes precedence).

GIS Coordinates (X/Y split): For every location (cities, universities, forests, companies), estimate and provide coordinates in two columns: X = Longitude, Y = Latitude. Use strict numerical format with no degree symbols or cardinal direction letters (N, S, E, W). Example: 122.3321° W → -122.3321 in the X column; 41.3111° N → 41.3111 in the Y column.

Research Step for Unlocated Named Entities

When a pre-Yale location (school/university) or a work location (named company or firm) lacks a city/state in the source text but names a specific institution or company, attempt to resolve its city and state via web research before flagging it. Apply this only to named entities — generic descriptions with no proper name (e.g., “a forest planting concern,” “the real estate business,” “private practice”) are not researchable and remain blank/[NEEDS REVIEW].

Use the three-tier marking below to keep the source of every location traceable. (The historical era is ~1900–1913; entities relocated and names recur across states, so distinguish confirmed from uncertain finds and never silently overwrite a blank with a guess.)

[RESEARCHED] — City and state confidently confirmed. Fill in the location and coordinates normally, prefix the location cell with [RESEARCHED], and note the basis briefly in the description (e.g., “HQ Chicago per Forest History Society records”).

[NEEDS REVIEW - RESEARCHED] — A plausible but uncertain match (ambiguous name, possible relocation, multiple candidates, or an entity without a single fixed city). Enter the best candidate location and coordinates, prefix with [NEEDS REVIEW - RESEARCHED], and note the uncertainty briefly in the description.

[NEEDS REVIEW] — No reliable match found, or the entry is too generic to research. Leave the location blank or flag with [NEEDS REVIEW]. Do not guess.

This research step does NOT override the folding rule for unlocated forest-assistant-type roles (those fold into the first locatable job) or the splitting rule for other dated roles. Coordinates for researched locations follow the same strict numerical X/Longitude, Y/Latitude format.

Strict Quality Criteria

Accuracy & Alignment: Double- and triple-check that every record, location, and date is tied to the correct person and lands in the correct column.

Completeness (pre-Yale AND post-Yale): Before finalizing each person, re-read their full biography and confirm that (a) every distinct pre-Yale school and job has its own entry, and (b) every distinct post-Yale work AND study position with a stated year and/or location has its own entry. Verify the year ranges form a continuous chain with no dropped middle positions. A position is missing if the bio names it but no column holds it.

No Hallucinations: If a data point (birth year, specific location, etc.) is absent from the text and cannot be confidently resolved via the Research Step, leave the cell blank or use the appropriate [NEEDS REVIEW] marker. Never invent or guess. (The Yale Attendance convention is the one sanctioned exception, and only for the M.F.-graduate year fill described above; when in doubt for non-graduates, leave Yale years blank.)

Thorough Extraction: Read and process the entire embedded text layer from every page so no individual or data point is skipped. Bios frequently span a page break — read the continuation page so late-career positions are not lost.

Non-Graduates: Include all non-graduates at the end, with all information the record provides (work locations, pre-Yale locations, etc.) in the same format.

Quick Reference — Location Cell Markers

Summary of the two completeness rules most often missed

Pre-Yale: every named school/academy/college and every pre-Yale job is its OWN entry with its OWN city and coordinates. Never merge two schools or a school + job into one cell, even when listed together or in the same state. Locate them all (Research Step + capital fallbacks as needed).

Post-Yale: every dated and/or located position — work OR study (professorships, degrees, fellowships, inspector/chief roles, private practice, company jobs) — is its OWN column. Walk the bio in order, capture transitional “for the next N years / subsequently / later that year” positions, and confirm the timeline has no dropped middle entries. Only unlocated entry-level forest-assistant-type roles fold; nothing else does.

Watch for the bundling trap. A bio may state an outer year-range in a summary sentence (“From 1909 to 1911 he was forest agent…”) and then enumerate the individually dated tasks separately — often inside a quoted passage, a list of publications, or an aside. The summary sentence is not the record. Extract the enumerated tasks, each into its own dated column. See the worked example under Splitting dated positions (Oswald D. Ingall, 1909), where one bundled cell should have been five.

Master Prompt for Coding

Version 1.

I would like to attempt using open source tools to map this out in an html file, what tools do you recommend using to run this and can you provide some code to get me started. Use the attached information to map out the Alumni's' journeys. The goal is to eventually have a dashboard with popups for each location and line connecting them. users should be able to filter between pre yale and post yale movements, and filter between different classes when that information is added