> ## Documentation Index
> Fetch the complete documentation index at: https://elrolio.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# I Built the Wrong Model Twice Before I Checked What Was Actually There

> A meeting-notes merge built on an unverified assumption about its own data source — twice — and the verification habit it changed.

![A cool teal gradient with a soft cyan glow and a small magnifying-glass mark](https://mintcdn.com/elrolio/vVurTJ87CIYetlrd/images/journal/verify-the-source-hero.jpg?fit=max\&auto=format\&n=vVurTJ87CIYetlrd\&q=85\&s=df620d25c407201ff0ac3875e09c71a6)

## The Problem

I keep my meeting notes in one database, but three different tools record those meetings — a calendar-AI notetaker that captures everything automatically, a video platform's AI summary, and a separate notes app I run by hand. Each writes its own version of the same conversation. I wanted one command that pulls the latest meetings and merges them into a single clean row per meeting, instead of three overlapping copies I have to reconcile by hand later.

## The Approach

I'd already had Claude build a heavier weekly pipeline — classification, routing, digests. This time I wanted something lighter: keep the database current, nothing else. So I had it carve out a small skill — pull today's meetings, match them to what's in the database, enrich the existing row. The design question was which source to trust, and that's where Claude had to make a call. They disagree: the video platform's transcription has the best sense of who said what; the auto-notetaker is comprehensive but garbles attribution in group meetings. The merge it proposed treats one source as the authoritative layer and folds the others in, so a future reader — or agent — querying the database never has to adjudicate between contradictory copies.

## What Happened

Claude got the model wrong twice. First it assumed the video platform was the primary record and built around that. Then it "corrected" to a second theory — that the auto-rows came from the notes app, because the database's own welcome text said it "connects with" that app. Both wrong; the notes app hadn't pushed anything in months. It had anchored on a line of marketing copy instead of checking what was actually writing the rows. I only caught it when the duplicate rows piled up and I told it to go verify the source. Along the way it also under-delivered the merge — thin summaries instead of full ones — because it was deduping against notes it had misattributed to the wrong source. Two sessions of confident architecture, built on a guess it never tested.

## What I Learned

When you're building on top of a store that someone else's tooling populates, verify what populates it before you model around it. A product's "connects with X" copy, a field name, a historical default — those are hypotheses, not facts. One question, or one honest look at what's actually in a row, would have saved two redesigns. Now I make "what writes this?" the first thing I have it confirm — instead of an assumption that only surfaces after the model breaks and I'm reading the rows myself to figure out why.

***

*Drafted by my Claude from our working session. I approved it before it went up.*


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.