The Obsidian plugin I’m building takes an article and has an LLM split the concepts, people, and resources in it into separate notes saved to a wiki (I call this ingest). Notes created together from the same source I call “sibling notes” here. This post is about a bug where one sibling note came out empty, holding nothing but links, and how I fixed it with prompt rules twice.
Part 5 (Korean only) covered how I proposed a post-hoc recovery approach twice and got corrected both times. This one is similar, except it wasn’t a single correction: only after reopening the source did I realize the place I was aiming at was wrong to begin with.
One note came out empty except for links — a side effect of the anti-duplication prompt
After I caught the bug where sibling notes copied the same paragraph verbatim with an embedding + LLM verification pipeline, the opposite symptom showed up. In the result of ingesting a source listing 13 MIT online courses, I opened the note for a course called “AI and Algorithms,” and its body held nothing but sentences pointing to other notes. Here are two of them, from the actual result of the third reproduction.
“AI and Algorithms situates [[Introduction to Machine Learning]] within the broader context of artificial intelligence and algorithms.”
“This resource is included in the [[wiki/2026/09/WeekOf14/Foundational AI Courses and Resources from MIT|Foundational AI Courses and Resources from MIT]] collection.”
There wasn’t a single word about what the course itself was; everything was handed off to other notes. Re-ingesting the same source independently three times, this one note came out empty the same way every time. It wasn’t chance; it was a pattern that reproduced deterministically for this particular pair.
The cause was a rule I had added the round before. To prevent duplication between sibling notes, I had added a rule that when the same fact relates to several sibling notes, it should be written only in the one note it most directly belongs to, and the others should just point to it with a link and mention it exists. This time it swung to the opposite extreme and emptied out an entire note.
First fix: “always keep a self-definition” — adding a counterexample to the prompt
I added one more caveat to the rule: the duplication ban applies only to the specific fact that actually overlaps with a sibling note, and does not mean handing off, via a link, even the minimal self-definition of what the note itself is about. Then I put this exact pair of courses into the examples as a counterexample.
I ran ingest on the same source twice more. The results were split. Once, the note’s summary line did include a description of itself. But the next time, the same course came out empty again. The hypothesis was half right and half wrong: “a note must not be empty” was right, but “so just fill in a different definition” was wrong.
Only after reopening the source did I see it
I couldn’t understand why half the runs still failed, so I went back to the source and put the descriptions of the two courses side by side.
AI and Algorithms: “Get an introduction to principles, algorithms, and applications of machine learning.”
Introduction to Machine Learning: “Get to know the principles, algorithms, and applications of machine learning.”
They were nearly the same sentence. The model wasn’t misapplying the rule; the source itself had given the two courses essentially the same one-line description. However firmly I insisted on “write your own definition,” there was no “different” definition in the source to begin with, so from the model’s side there was nothing to write. The counterexample I had added was wrong from its very premise.
The question that came back, “then merge them, why do you need a link?” — deciding what makes an atomic note
When I laid this situation out, the reaction I got was simple: if the two course descriptions really are identical, why split them into two notes in the first place? It was a fair point. Every fix so far had been made inside the rules about “how to write a note,” but the real problem was one step earlier, at the atomicity decision stage, where it’s decided how many notes one source gets split into. Once the two courses had already been split into separate notes, no amount of tuning the rules for “how to fill the body” could keep one of them from being structurally an empty shell. I had been fighting a battle no rule could win, in the wrong place.
Second fix: filtering at the splitting stage — criteria for splitting notes
I added a new criterion to the atomicity rules: even if two items look like separate resources with different URLs or names, if the definitions the source actually gives them are essentially the same and differ only in wording, don’t split them in the first place; merge them into one. I also added the condition that the judgment “these are different entities” must not rest on different URLs or names alone, but on whether the source actually describes distinct content. And this time I put that same pair of courses in as a “should be merged” counterexample.
I ran ingest on the same source independently twice more. This time, both runs merged them into a single note called “AI and Algorithms and Introduction to Machine Learning.” The body wasn’t empty either: the note itself explained why it had grouped the two courses together.
“The source gives both resources essentially the same description: an introduction to the principles, algorithms, and applications of machine learning. Because the descriptions do not distinguish separate subject matter, they are documented together rather than as two notes with duplicated content.”
Takeaways
I fixed the same symptom twice; the first fix only half worked and the second worked fully. The difference between them wasn’t how precisely I wrote the rule, but which stage I put it in. However firmly I pinned things down at the stage that decides “how to fill the body,” if a wrong premise had already been laid at the earlier stage that decides “how many pieces to split into,” the later rule was fighting a battle it could never win by design. A “fix it” instruction always aims at some place, and refining that instruction is a different question from whether it was aimed at the right place to begin with. This time I only noticed that difference after reopening the source.