Every week, the boys in our house take piano lessons over Microsoft Teams. Every week, I want a permanent searchable record of what was taught. The free tier of Teams doesn’t record, and the paid tier is a few dollars a month I didn’t want to add to the household budget. So I started recording the screen with OBS. That was the workaround. Then I started keeping the files. Then I started running them through a transcription pipeline. Then I started diarizing them so the transcript knew who was speaking. Then I started generating a structured summary at the top of each one. The pipeline that resulted is self-running: I drop a new recording into a watched folder, the next hour the pipeline processes it, and a few hours later I have a transcript, subtitles, a speaker map, and a lesson summary, all in a dated subfolder, all searchable.
This post is about how I built it, what the pieces are, and what it has already surfaced from the lessons I record.
The full production flow:
flowchart TB
A[New .mp4/.mkv/.mov<br/>lands in NAS<br/>Piano-Recordings/_inbox/] --> B[Hourly cron:<br/>watch-piano-inbox.sh]
B --> C{File size<br/>unchanged for 60s?}
C -- no --> B
C -- yes --> D[Move to<br/>_processing/]
D --> E[ffmpeg:<br/>16kHz mono WAV]
E --> F[whisperx:<br/>transcribe + align]
F --> G[pyannote<br/>speaker-diarization-3.1]
G --> H[rename_speakers.py:<br/>vocabulary heuristic<br/>SPEAKER_xx → role]
H --> I[claude --print:<br/>structured summary<br/>HOME=/Users/mini-1]
I --> J[Output:<br/>dated folder<br/>YYYY-MM-DD_HHMMSS/]
J --> K[.mp4 .wav .txt .srt<br/>.vtt .tsv .json<br/>.speakers.json<br/>.summary.md]
J --> L[Watcher reports<br/>to Slack on activity,<br/>silent when idle]
style A fill:#e1f5e1
style K fill:#e1e1f5
style G fill:#fff4e1
style H fill:#fff4e1
style I fill:#fff4e1
Six stages. The orchestrator script chains them. The watcher at the front is the only thing continuously running; the rest fire only when there’s a new file.
The recordings are screen captures of Teams calls: .mp4 or .mkv files with both audio and video. WhisperX wants audio. The first stage extracts a 16 kHz mono WAV:
ffmpeg -i "$INPUT" \
-ac 1 -ar 16000 \
-c:a pcm_s16le \
"$WORKDIR/${BASENAME}.wav"
Why 16 kHz mono: WhisperX’s required input format. Why we keep the WAV after the run: re-runs are much faster when audio extraction is already done, and re-running happens often during prompt tuning.
WhisperX is Whisper with forced alignment. The small model handles initial transcription. A separate alignment pass fixes word-level timestamps. The output is word-level segments with start and end times, which the next stage needs.
whisperx "$WORKDIR/${BASENAME}.wav" \
--model small \
--language en \
--output_dir "$WORKDIR" \
--initial_prompt "$INITIAL_PROMPT" \
--compute_type int8 \
--batch_size 8
Two knobs worth flagging:
--compute_type int8 is the right choice on Apple Silicon CPU. float16 is rejected on CPU. int8 runs at about 5x real-time on the M-series chip this pipeline runs on.--initial_prompt is the single biggest accuracy lever after model size. The default prompt is short and vocabulary-only: a list of piano terms (scale, chord, treble clef, bass clef, sharp, flat, natural, slur, tie, measure, harmonic interval, melodic interval, whole note, half note, quarter note, eighth note, middle C, finger one through finger five, left hand, right hand, forte, piano, mezzo, crescendo, staccato, legato). Long sentence-form prompts leak into transcripts — Whisper echoes them as if they were spoken, especially on low-confidence segments. Keep the prompt a vocabulary list. Override per-run when a specific piece is being practiced.Transcription without speaker labels is mostly useless. A transcript that says “good job” with no idea who said it is a dead end. Diarization is the step that figures out who said what.
The pipeline uses pyannote/speaker-diarization-3.1 from HuggingFace. The model clusters audio segments by voice, and the output is segments tagged with SPEAKER_00, SPEAKER_01, etc. The model downloads on first run (~50 MB) and is cached. It requires a HuggingFace token and explicit acceptance of the pyannote license.
pipeline({
"audio": wav_path,
"min_speakers": 2,
"max_speakers": 3,
})
min_speakers=2 max_speakers=3 is the right setting for a 1-on-1 lesson with occasional drop-in from a parent. Auto-detect (no constraint) over-segments the teacher’s voice into 4+ clusters because the model treats slight pitch variations as different speakers. The constraint forces clean turn-by-turn labels. It is a hint, not a hard cap — pyannote can still emit a SPEAKER_UNKNOWN bucket for unassigned segments when the actual count exceeds the cap. The rename step handles those.
Raw diarization output is SPEAKER_00, SPEAKER_01. The pipeline needs role labels: Teacher, Parent, Student. The rename step walks each speaker’s text and scores the speaker against a small vocabulary table:
TEACHER_TELLS = [
"good job", "let's try", "play it again", "one more time",
"slower", "faster", "louder", "softer", "count out loud",
"look at the page", "next piece", "let's start with",
]
PARENT_TELLS = [
"say thank you", "sit up", "are you listening",
"say hi", "wave", "be nice", "share",
]
def classify(text, scores):
text_lower = text.lower()
for phrase in TEACHER_TELLS:
if phrase in text_lower:
scores["teacher"] += 1
for phrase in PARENT_TELLS:
if phrase in text_lower:
scores["parent"] += 1
return scores
The speaker with the highest teacher score is labeled Teacher. If multiple speakers tie, the tiebreaker is total speech time. Speakers that score below a threshold default to Student. The mapping and the raw scores are written to a .speakers.json file next to the transcript, so the labels can be reviewed and the heuristic retuned without re-running diarization.
It is not perfect. About 10% of segments end up with the wrong label, usually on the boundary between “instructional encouragement” (teacher) and “encouragement” (parent). The summary step is forgiving about this. The human reader is forgiving about this. The search index is forgiving about this.
The transcript is 30-50 minutes of dense audio. The summary is a short Markdown file with five sections: Topics, Pieces, Books/Pages, Issues, Homework. It tells a reader what the lesson covered, what book pages were worked from, what was flagged as a problem, and what to practice before the next class.
The summarizer calls claude --print with a structured system prompt. The transcript goes in as the user message. The output goes to <stem>.summary.md.
HOME=/Users/mini-1 claude --print \
--system-prompt-file "$PROMPT_PATH" \
< "$TRANSCRIPT_PATH" \
> "$SUMMARY_PATH"
The HOME=/Users/mini-1 override is required. The claude CLI reads its OAuth credentials from the real user home, and the agent that runs the script has a sandboxed home. Without the override, the call fails with an auth error. The orchestrator sets this explicitly.
The watcher is a small bash script that runs once an hour. It checks the inbox, waits 60 seconds to confirm the file is no longer being written, then moves it to _processing/, runs the pipeline, and parks the output in a dated folder. If the inbox is empty, the script stays silent — no Slack noise.
Piano-Recordings/
├── _inbox/ # drop new .mp4/.mkv/.mov here
├── _processing/ # watcher moves file here while pipeline runs
├── _failed/ # watcher moves file here on pipeline error (with .error.log)
└── YYYY-MM-DD_HHMMSS/ # completed lessons
The watcher is a real cron job, not a long-running daemon. Empty stdout means silent — the hourly tick is designed to produce no Slack output unless there’s actual work. On activity, the watcher emits a structured summary: how many files processed, how many failed, first 10 lines of each new lesson summary.
A stability check is the most important detail. macOS file copy is not atomic — a file can appear in the inbox before the bytes are flushed. The watcher waits 60 seconds of unchanged file size before processing. Skipping this step causes intermittent “file not fully written” errors on slow connections.
A stale rescue handles the failure case: any file stuck in _processing/ for more than 2 hours gets moved to _failed/ with an .error.log sidecar. Without it, a transient pipeline failure leaves a file in limbo forever.
Each completed lesson gets its own dated folder:
Piano-Recordings/2026-05-30_163000/
├── Video-20260530_163000-Meeting Recording.mp4
├── Video-20260530_163000-Meeting Recording.wav
├── Video-20260530_163000-Meeting Recording.txt
├── Video-20260530_163000-Meeting Recording.srt
├── Video-20260530_163000-Meeting Recording.vtt
├── Video-20260530_163000-Meeting Recording.tsv
├── Video-20260530_163000-Meeting Recording.json
├── Video-20260530_163000-Meeting Recording.speakers.json
└── Video-20260530_163000-Meeting Recording.summary.md
The .txt is the speaker-labeled transcript. The .srt and .vtt are the same content as subtitles. The .tsv is the machine-readable word-level output. The .json is WhisperX’s full output including word-level timestamps. The .speakers.json is the diarization debug file (mapping, scores, threshold). The .summary.md is the human-readable summary. The .wav is kept for fast re-runs.
On Apple Silicon, the small Whisper model:
medium model is 2-3x slower; I haven’t needed itwhisperx 3.7.5 hard-pins torch ~=2.8.0. I couldn’t downgrade torch to bypass a weights_only issue introduced in PyTorch 2.6+. PyTorch 2.6+ defaults to weights_only=True for torch.load, which rejects the omegaconf classes in pyannote’s model files. The fix is a small Python wrapper that monkey-patches torch.load(weights_only=False) unconditionally — lightning_fabric passes weights_only=True explicitly, so a conditional patch doesn’t help. The wrapper is whisperx_safe.py. The pipeline invokes whisperx through this wrapper, never through the bare whisperx CLI.
Long initial prompts leak into transcripts. A prompt containing book titles and series names appeared verbatim as a transcript line for a low-confidence audio segment. Whisper echoed the prompt as if it were spoken. The fix is a strict rule: the prompt is a vocabulary list, not a sentence. Per-run override is allowed for specific piece titles, kept short.
Auto-detect over-segments the teacher’s voice. Without min_speakers=2 max_speakers=3, pyannote splits the teacher’s voice into 4+ clusters based on slight pitch variations. The constraint forces a clean turn-by-turn label set.
~ in agent context expands to a sandbox home. The orchestrator script always uses absolute paths to files on the NAS and to the workspace. Shell ~ in this context points to the agent sandbox home, not the real user home, and the NAS is mounted under /private/tmp/nas_movies, not under a /Volumes/ path.
The NAS mount is at /private/tmp/nas_movies, not /Volumes/video. macOS’s auto-mount puts SMB shares under /Volumes/, but the SMB share on this NAS is mounted at the temporary path for a reason I no longer remember. The script uses the absolute path everywhere; nothing in the pipeline assumes /Volumes/.
I have ~17 hours of audio in the archive now. Reading back through the summaries, the transcripts surface things the videos alone never would have. A few worth flagging:
The 38-minute lesson. Z.M. had a lesson that ran almost 40 minutes — twice the normal length — because he got frustrated with a piece and refused to play. The teacher didn’t push. She sat with him. She let him try, let him fail, let him try again. The summary captured, in its own words, that the student experienced frustration, the teacher used patience, and the piece was eventually completed. That is what happened. The transcript is the only reason I know the texture of how that lesson actually went.
A.M. coaching Z.M. A.M. has been playing longer. In one of Z.M.’s lessons, after the teacher explained the sharp-within-measure rule, A.M. was at the piano before the next call and walked Z.M. through it himself. The summary noted that the older sibling provided peer instruction during an inter-lesson period and demonstrated an internalized grasp of the rule. I would not have written that sentence in a thousand years. The model surfaced it because diarization caught a third voice during what was supposed to be a one-on-one lesson. I had no idea it was happening. The model did.
“Rockin’ Rabbits.” One of the first pieces in the book is called “Rockin’ Rabbits.” The model — at least in early runs — kept hearing it as “Rockin’ Rabies.” A five-year-old saying the word “rabbits” produces audio the model is not confident about, and its first guess was a different small animal entirely. I have at least four transcripts in a row that all say “Rockin’ Rabies.” It became a family joke. The model got it wrong consistently enough that the wrongness became a record in its own right — a small data point on what a five-year-old’s voice sounds like to a model trained mostly on adult speech.
The pipeline was supposed to be an archive. It became a study tool. The reason is that text is searchable, indexable, and reviewable in a way video isn’t. A few of the things the transcripts let us do that the videos alone never could:
Vocabulary growth across time. A simple grep "staccato" *.txt across all 17 weeks of lessons returns every mention, in order, with the date. You can see when the teacher first introduced the term (lesson 4), how many times she repeated it across the first month, when one of the boys started using it correctly, and when she stopped having to explain it. The vocabulary of piano has a curriculum — techniques like staccato, legato, curved fingers; rhythms like eighth-note pairs, syncopation, dotted-quarter + eighth; tempo terms like andante, allegro. The transcripts are the curriculum rendered in a searchable form. As a parent, I can see which concepts are landing and which the teacher has to keep re-teaching. The list is the teaching plan. The transcripts are its audit log.
The “Issues” list is a weekly diagnosis. Every summary has a section called “Issues” — what the teacher flagged as problems that week. Reading 17 weeks of Issues in chronological order is like reading a doctor’s chart: “curved fingers, slowing down on the upbeat, missing the repeat sign.” Each issue is a target. At practice time, we know which of the boys’ instincts the teacher is still correcting, and we listen for them. The video doesn’t give you that. The video gives you 30 minutes of footage and the lesson is over.
Piece progression, measured. You can see when a piece was introduced (the teacher says “let’s start with X”), when it was reviewed (“let’s play X again this week”), and when it was retired (“you know this one now”). Across 17 weeks the boys worked through 11 pieces, and the transcripts are the only record of how long each one took to land. “Hot Cross Buns” took two weeks. “Alpine Song” took six. The data is in the text. The videos would require a manual review we never would have done.
Look-back without rewinding. When the teacher says, mid-lesson, “remember what I told you about X last week,” the transcripts let you look up last week’s lesson and find X. With a video, you’d have to scrub through 30 minutes of footage and hope you remembered the timestamp. With a transcript, it’s a 5-second search. This changed practice at home. We started being able to answer our own questions about what the teacher had said, instead of waiting until the next lesson to ask.
The 1% better pattern. Reading the summaries in order, a quiet pattern emerges: each boy gets 1% better at one thing every week. The first month is mostly counting out loud. The second month is mostly fingering. The third month is mostly dynamics. The summaries surface the change without me having to find it. The model is the one doing the diff. Reading 17 weeks of “what changed this week” answers the question I would have asked, if I’d thought to ask it: how do you get better at piano? Slowly, one thing at a time, with a teacher who notices.
The pipeline was supposed to be a record. The pipeline is now a teacher aid, a study tool, and a parent cheat sheet. None of that was the original plan. All of it was enabled by the fact that the lessons became text.
The archive is not the lessons. It is an approximation of the lessons. The model still mishears proper names on the first run about a third of the time. When two students play the same phrase in unison, diarization merges their voices and assigns the line to one speaker. The summaries smooth over small moments — a teacher telling one of the boys to sit up, a parent gently correcting which one actually needed to sit up — because the model averages across many small choices, and the right one is in the average, but not the one it picks.
I have to keep remembering that. The temptation to treat the transcript as authoritative is the new version of believing the camera saw the truth. The camera didn’t see the truth. The transcript isn’t the lesson. Both are flattened versions of something that happened between a few people in a room with a piano. The archive is a record that the lesson happened. It is not a record of what the lesson was.
But a record that the lesson happened is enough. It is more than I had before. It is more than the average family has when the boys are grown.
The current pipeline is enough. It runs itself, the lessons are searchable in a way the videos alone never were, and the archive is a permanent record. The next moves are nice-to-haves:
.txt files. A simple ripgrep across all dated folders answers questions like “when did harmonic intervals come up.” A proper search index (SQLite FTS or Meilisearch) would make this faster and more flexible.The pipeline is the goal. Everything after that is polish.
]]>What follows is the process, and a few of the things it turned up. The full report runs twenty-four pages. This is the part I think is worth writing down.
I told the model what village I was looking for, gave it three spelling variants, and added one clause that turned out to matter more than anything else in the rest of the conversation:
Even if it has information about other villages around that might reference it, or at least relatively or very closely mentions it.
That single instruction is what turned up Turbasaim — a Crusader-Latin form of the name that I had never seen in any modern source. Turbasaim doesn’t appear in Wikipedia. It doesn’t appear in the village’s own profile pages. It shows up in a nineteenth-century Palestine Exploration Fund nomenclature study that itself was reading twelfth-century church cartularies.
I asked the model where, exactly. It pointed me at Eugène de Rozière’s Cartulaire de l’église du Saint-Sépulcre de Jérusalem, published in 1849 from Vatican manuscripts, and at Reinhold Röhricht’s Regesta Regni Hierosolymitani, the master registry of Crusader-era charters. The entry is dated 14 August 1145. Patriarch William I of Jerusalem is settling a dispute between Pontius, abbot of Mount Tabor, and Peter, prior of the Holy Sepulchre. The patriarch awards Mount Tabor the church at casale Sancti Egidii — the village of St. Gilles, which is the next village over from mine, today called Sinjil — together with half the tithes of Turbasaim et Dere.
Half the tithes. That’s the thing that lodged in my head. The Crusader Latin doesn’t grant anyone the village. It grants half the income on agricultural produce from the village to the church next door. Eight hundred and eighty years ago, my grandparents’ village was an income stream in a dispute between two French monastic orders, written down in a manuscript that eventually ended up in the Vatican.
The name had been sitting in a footnote for a hundred and forty years.
The model produced a 24-page comprehensive report. Here are the findings that surprised me most.
The 1145 grant has a sequel. Thirty years later, on 17 October 1175, the same two institutions met again. This time the Holy Sepulchre got the church back — along with the half-tithe rights to St. Gilles, Turbasaym, and Dere. The reciprocal act from Mount Tabor also mentions vineas vero et domos, “vineyards and houses,” sold for a sum in bezants. So the ecclesiastical presence was not just a fiscal abstraction. There were physical houses and vineyards owned by the Latin Church in or near my village in 1175.
The story doesn’t end with the Crusades. When Frankish power collapsed, the village did not vanish from the documentary record. It got picked up by the next regime. In 1268–69 CE (668 AH), the Mamluk sultan Baybars founded a waqf — an Islamic charitable endowment — for the shrine of Nabi Musa, near Jericho. The deed, edited by Kamil al-Asali, lists the villages whose revenues would support the shrine. One of them is written ترمسعيا — Turmusayya. Already, by 1268, the name is in recognizably modern Arabic form. So the documentary line for my village runs: 1145 Crusader Latin → 1175 Crusader Latin → 1268 Mamluk Arabic → 1596 Ottoman tax register → 1838 American missionary survey → 1882 British survey → 1922, 1931, 1945 British censuses → today. Across eight centuries, three empires, and three languages, the name moved from Turbasaim to Turmusayya to Turmus Ayya without ever breaking.
The “Dere” question. The 1145 and 1175 acts always pair Turbasaim with another place called Dere. Nobody knows for certain where Dere was. Conder, in the nineteenth century, proposed Deir es-Sudan, west of Sinjil. Twentieth-century scholarship moved the identification east, to Khirbet Deir el-Fikia / Ras ad-Deir, where Palestine Exploration Fund surveyors found “the ruins of a monastery and chapel” with masonry they identified as Crusader work. If that identification is right — and the consensus now leans that way — then the medieval landscape around my village included a small monastery whose stones are still on the ground. I had never heard of it.
The negative result on Tur Shimon. Some twentieth-century scholars proposed that Turmus Ayya was the ancient Tur Shimon mentioned in rabbinic sources, partly on the resemblance of the names. The Israeli archaeologist Boaz Zissu argued against that identification — not on philological grounds but on dirt. Surface survey at Turmus Ayya produced sherds from several periods but none from the Hellenistic period. If the village were Tur Shimon, you’d expect Hellenistic-era pottery. There isn’t any. That’s the kind of finding a casual search will never give you, because nobody writes a Wikipedia paragraph about an identification that didn’t hold up.
The sarcophagus. In 1912, a richly carved marble sarcophagus was discovered near the village. Jacob E. Spafford of the American Colony in Jerusalem described it the next year. German art-historical cataloging dates it to 240–250 CE and identifies the carving program as Bacchus and the genii of the seasons. So there was, in the Roman period, somebody important enough in the area to be buried in an imperial-quality sarcophagus carved with Dionysus. The model surfaced the German catalog entry, which an English-only search would never have found.
The diaspora is real but the number is folklore. Multiple journalistic sources describe Turmus Ayya as a town where more than 80 percent of residents hold U.S. citizenship, with secondary migration to Latin America — Panama in particular. The model initially repeated the 80 percent figure as fact. When I asked where the data came from, the honest answer was: no official source. It is a journalistic estimate that has self-replicated across dozens of news articles. The underlying pattern is well-documented: large diaspora, remittance-built villas, seasonal occupancy. The specific number is folklore that sounds like data.
The town is still being made and unmade. The model also surfaced something I knew but had not seen catalogued: the B’Tselem documentation of repeated settler attacks on Turmus Ayya in 2023, including arson against vehicles belonging to named members of the Abu ‘Awwad family — one of the village’s older lineages, attested in local material and continuous enough that the same family name shows up in modern human-rights litigation. The historical record for this village is not closed. It is being added to in real time, in a register very different from twelfth-century cartularies, but no less archival.
The reason a clause like “even something close” mattered: this is a place whose name has been written in Arabic, Ottoman Turkish, Latinized Crusader French, nineteenth-century English, nineteenth-century German, and modern transliterations that don’t agree with each other. The British Mandate’s own census officials wrote in 1931 that the transliteration system they were using was already being abandoned, while the census was still going to press.
If you search for “Turmus Ayya” you find the modern village. If you search for “Turmus ‘Aiya” you find the 1931 census. If you search for “Tourmous’aya” you find a French art-history article about a Roman sarcophagus. If you search for “Turbasaim” you find a 1145 land grant. If you search for ترمسعيا you find a 1268 Islamic waqf.
These are all the same place. None of them link to each other.
A few things crystallized over the course of the research that I want to remember.
Ask for the negative result. The single most valuable thing the model surfaced wasn’t a confirmation, it was a contradiction — the Zissu argument that the Tur Shimon identification doesn’t hold up. Negative findings clarify what the evidence actually supports. You have to ask for them directly.
Source classes matter more than source counts. I told the model to prioritize in roughly this order: official censuses, primary historical publications, explorer/survey literature, archaeology, and only then secondary compilations or local profiles. The reason is that local profiles tend to silently compress together primary facts, antiquarian conjectures, and oral etymologies. Without explicit ranking, the model treats them all as equally citeable. With ranking, it tells you when it’s reaching for the bottom of the stack.
Filter your false positives early. Two categories of garbage results plagued every search: there is another place called Tall al-Turmus in Gaza, which is not the same village; and turmus in Arabic also means lupini beans, which dominate the search results for anything resembling the name. Telling the model these two patterns existed before it started cut the noise in half.
Push deeper on the thread that surprises you. When Turbasaim came back, I didn’t move on to the next question. I spent the next several turns just on Crusader cartularies — which is how the 1175 follow-up, the Dere identification debate, and the Baybars waqf all surfaced. The diminishing returns on a single thread come much later than you expect.
Treat the variant table as a precondition. Every script, every spelling, every transliteration convention, before issuing a single search. Turbasaim, Turbasaym, Turbasym, Tourmous’aya, Turmus ‘Aiya, Turmus ‘Aya, ترمسعيا, Thormasia, Tur Shimon — list them all up front, decide which are evidentiary and which are conjectural, then go.
It is not a perfect collaborator.
It conflated dates more than once. An English-language summary called the sarcophagus “2nd century B.C.”, and a separate German art-history catalog dated the same object to 240–250 CE. The model initially reported both as if they were consistent. I had to push it to flag the discrepancy. When I did, it correctly noted that one source was a popular retelling and the other was specialist cataloging — but it didn’t volunteer that distinction on its own.
It over-anchored on the most-cited claim. The 80 percent diaspora figure appears in dozens of journalistic sources. The model repeated it confidently several times before I asked where the underlying data came from. There is no underlying data. It is an estimate that has self-replicated.
It is bad at adjudicating what can’t be known. Some questions — the exact pre-Roman name of the site, the full hamula genealogy of the village’s families — have answers that simply don’t exist in any accessible archive. The model wants to give you an answer. You have to actively push back and ask it to enumerate the limits of the evidence, not just summarize the evidence.
It cannot, on its own, distinguish Turbasaim is securely attested in 1145 from Turbasaim is identified with modern Turmus Ayya by later scholarly inference. Those are two different epistemic claims. Holding them apart was one of the hardest parts of the conversation, and it required me — not the model — to keep reasserting the distinction.
Three things.
Start with the negative-result prompt earlier. Asking “what identifications for this place have failed, and why?” should be one of the first questions, not one of the last. It calibrates everything that follows.
Build the variant table before doing any searches. I had to back-fill it after I’d already done a lot of single-spelling searches. Future-me should treat the variant table as a precondition, not a deliverable.
Ask for the source class of every claim, every time. Not “is this true,” but “what kind of source is this.” Charter versus regesta versus survey versus secondary compilation versus folk etymology. The five categories require five different levels of trust, and the model will assign all five the same confidence if you don’t make it differentiate.
This is the first post on this blog. I want to write more like it — research notes, builds, things I’m working through. Mostly for future-me. The next one is probably about Obsidian, six years in.
If you have your own deep-research project — a hometown, a family name, an ancestor, a forgotten place — I’d encourage you to try this. The internet hasn’t forgotten the things you think it has. It has just filed them under names you don’t know yet. Mine was filed under Turbasaim in a Vatican manuscript and ترمسعيا in a Mamluk waqf, and it took the right kind of prompt to put them in the same place.
]]>