Twenty-Six Pages Vanished Between Step One And Step Two
This one is not a tool list. It is a case study – nine numbered panels walking through an actual experiment, with actual numbers at the end. That is rarer and much more useful than another grid of logos, and it deserves to be read the way you would read any experiment: by checking the numbers.
The setup is clean. Panel 1 states the problem: dump 145 random documents on Claude Code and it has to search them one at a time, which is slow and misses how ideas connect. Panel 5 gives the whole method as one sentence handed to the agent: “Download the official Claude Code docs, map them with Graphify, then turn that into an Obsidian vault.” Panels 6 to 9 report what happened.
So let us check the numbers. There are four of them, and the card does not divide any of them by any of the others.
Panel 6: “171 pages of docs downloaded.” Clean, ready to process, it says.
Panel 7: “145 Pages of Docs” going into Graphify. Panel 8: “145 Documents.”
One hundred and seventy-one went in. One hundred and forty-five came out the other side. Twenty-six pages – fifteen per cent of the corpus – disappear between step one and step two, and no panel mentions it.
There are perfectly good explanations. Duplicates, redirects, index pages with no content, pages that failed to parse. Any of those would be fine. But a knowledge graph is sold on completeness – panel 2’s promise is literally “sees everything at once” – and a graph quietly missing fifteen per cent of its source has holes you cannot see from inside it. If you ask it something that lived on one of those twenty-six pages, it will not tell you it does not know. It will answer from the other 145.
The post this article is about
Read the original post: “Graphify + Obsidian + Claude Code = Cheat Code”
Nine panels, footed “Tools, numbers and results are from one example. Your results will vary. Check each tool’s official docs.” The tables below reproduce every panel as printed.
The ratios nobody computed
Four numbers sit in panel 8: 145 documents, 591 ideas, 685 connections, 67 clusters. Printed as four big figures in four boxes, which makes them look like four achievements. Divide them into each other and they become something more useful – a description of the shape of the thing that got built.
Diagram: four numbers, five sums
| The sum | The answer | What it tells you | Is that good? |
|---|---|---|---|
| 171 downloaded − 145 processed | 26 pages, about 15% | A gap between fetching and mapping that the card does not account for | Unknown, and that is the problem. Probably benign – duplicates, redirects, index pages. But a graph cannot tell you what is not in it |
| 591 ideas ÷ 145 documents | about 4.1 ideas per page | Graphify pulled roughly four distinct concepts out of each page of documentation | Plausible and healthy. One idea per page would be shallow; forty would be noise |
| 685 connections ÷ 591 ideas | 1.16 – an average degree of about 2.3 | Each idea links to roughly two others, on average | This is a sparse graph. Barely denser than a tree. Panel 2 draws a dense web; the numbers describe something much thinner |
| 591 ideas ÷ 67 clusters | about 8.8 ideas per cluster | The graph fell into 67 topic groups of roughly nine ideas each | Reasonable. Though 67 clusters from 145 documents is close to one cluster per two pages, which hints the clustering is tracking document boundaries as much as meaning |
| Panel 9’s hub | “Context Window” connects to “tons” of ideas | At least one node has a high degree | And here is the catch: if the average degree is 2.3 and some nodes are hubs, then most nodes have one connection or none. A few hubs, a long tail of near-isolated ideas |
Row five is the one that changes how you read the whole thing. Average degree and hub nodes cannot both be large at once. If “Context Window” really is connected to dozens of other ideas, then the arithmetic forces a long tail of ideas connected to almost nothing – because the total is fixed at 685.
That is not a failure of the tool. It is what real knowledge looks like: a handful of load-bearing concepts and a great many leaves hanging off them. But it is the opposite of the even, glowing mesh in panel 2, and it changes what the vault is good for. It is excellent for “what does Context Window touch?” and close to useless for “connect these two obscure ideas”, because for most pairs there is no path.
The nine panels, as printed
Column 2 is the card’s own wording. Read panels 6 and 7 next to each other.
| Panel | What it says, as printed | Our note – checked 10 October 2026 |
|---|---|---|
| 1. The problem | “Claude Code is smart. But if you dump 145 random documents on it, it has to search through them one by one. That’s slow. And it misses how ideas connect.” → “Slow and disconnected. Misses context. Loses connections.” | A fair statement of a real problem. Note it names two complaints – speed and missed connections – and only one of them gets measured later |
| 2. The solution | “What if it could see the WHOLE picture?” → “Fast. Connected. Context-aware. Sees everything at once.” | The illustration is a dense, evenly connected mesh. Hold that image against the 2.3 average degree in the table above |
| 3. The 2 tools | Graphify “turns any documents into a map of connected ideas”. Obsidian “a notebook app where Claude Code can browse that map.” | Both real. Graphify is an open-source Claude Code tool that builds a graph from a folder and can export an Obsidian vault. Accurate, if compressed |
| 4. Why combine them? | “Graphify alone works in a bubble… Obsidian fixes that – it connects the new map to your bigger project.” → “One maps the ideas. The other puts them in context.” | The clearest panel on the card. It explains why two tools instead of one, which most stack posts never bother to do |
| 5. The experiment | One sentence: “Download the official Claude Code docs, map them with Graphify, then turn that into an Obsidian vault.” | A genuinely reproducible instruction. Anyone can run this and compare, which is more than most case studies offer |
| 6. Step 01 – download | “It hit a small coding error, noticed it, and fixed itself. 171 pages of docs downloaded. Clean. Ready to process.” | Reporting your own error is rare and good. And this is where the 171 appears |
| 7. Step 02 – find the ideas | “Graphify reads every page deeply. Extracts real ideas, not just headings.” Flow: 145 Pages of Docs → Graphify → 591 Ideas Extracted | And this is where it becomes 145. “Reads every page deeply” sits in the same panel as a number 26 lower than the one before it |
| 8. Step 03 – the numbers | 145 Documents · 591 Ideas (Nodes) · 685 Connections · 67 Clusters → “145 docs → 591 connected ideas.” | Four counts, no ratios, no baseline. See the arithmetic above |
| 9. Step 04 – big ideas | “Some ideas are way more important than others… ‘Context Window’ connects to tons of other ideas.” → “The bigger the dot, the more important the idea.” | Degree is not importance. It is how often something was mentioned near other things – which correlates with importance and is not the same as it |
It measured the build. It never measured the answer.
Here is the bigger gap, and it is the one worth taking away even if you never touch Graphify.
Panel 1 makes a specific complaint with two halves: Claude Code is slow, and it misses how ideas connect. Both are claims about what happens when you ask it something.
Panels 6 to 9 then measure: pages downloaded, ideas extracted, connections found, clusters formed. Every one of those is a property of the artefact that got built. Not one of them is a property of an answer.
Nowhere does the card ask a question of Claude Code without the vault, ask the same question with the vault, and show the two replies side by side. The experiment builds the thing and then counts the thing. It never uses it.
This is the same shape we hit in a card that built an expert agent out of ten tutorials and never checked whether the tutorials were right, and in a hundred-tool map that handled the producing stage and called it ninety per cent of the work. Building is visible, countable and satisfying. Verifying is none of those, so it gets left out.
And 591 is a seductive number precisely because it is large. A graph with 591 nodes looks like an accomplishment on a slide. Whether it answers better than a folder of 145 markdown files and grep is an entirely separate question, and a much harder one, and it is the only question that matters.
What the convincing version would report
None of this is hard. If you run this experiment yourself – and panel 5 makes that genuinely easy – here is what turns a build log into evidence.
| What to report | How to get it | Why it beats a node count | Effort |
|---|---|---|---|
| 1. The gap, explained | Diff the list of 171 fetched URLs against the 145 that reached the graph | Turns an unexplained 15% into either “26 redirects, fine” or “26 pages of real content, not fine” | Minutes |
| 2. Five questions, answered twice | Ask the same five real questions with the vault and without it. Paste both answers | This is the actual claim being made. Everything else is a proxy for it | An hour |
| 3. One question you know the answer to | Ask something from a page you have read yourself | Catches a confident wrong answer, which a node count never will | Ten minutes |
| 4. The link types, separated | Graphify reportedly labels each connection as extracted, inferred or ambiguous | 685 collapses three different confidence levels into one figure. An inferred link is a guess; an extracted one is a citation | Already in the output |
| 5. The speed claim, timed | Stopwatch the same query both ways | Panel 1 says “that’s slow”. Nothing afterwards reports a single second | Minutes |
Item four is worth dwelling on. If Graphify really does distinguish extracted links from inferred ones, then “685 Connections” is three numbers wearing one coat – and the inferred ones are exactly where a knowledge graph invents a relationship that nobody wrote down. Reporting them separately would be the single most informative change to panel 8, and it costs nothing because the tool already produces it.
We should be clear that we are reporting that from secondary write-ups rather than the project’s own documentation, which we could not locate. Which is itself the advice: open the source and look.
Four honest caveats
This card is more honest than most and we want that on the record. It reports its own failure in panel 6 – the agent hit a coding error and fixed it – which nobody puts in a promotional graphic. And the footer says: “Tools, numbers and results are from one example. Your results will vary.” That is an n=1 disclaimer, voluntarily printed. Almost no case study carries one.
The 26-page gap probably has a dull explanation. Duplicate URLs, redirects, navigation pages, parse failures – all routine. We are not saying something went wrong. We are saying that a number which drops by fifteen per cent between two adjacent panels is the first thing a reader should notice, and the card gives them no help noticing it.
A sparse graph is not a bad graph. Average degree of 2.3 with a few hubs is what real document corpora look like, and it is arguably healthier than an artificially dense mesh where everything links to everything and nothing means anything. Our point is only that the picture in panel 2 and the numbers in panel 8 describe different objects, and the numbers are the true one.
We did not run it. Everything here is arithmetic on the card’s own figures plus a check that Graphify and Obsidian exist. We have not reproduced the experiment, we cannot confirm the 171 or the 591, and we are not disputing them. We are dividing them.
The one-line version
A case study is worth ten tool grids, and this one is better than most – reproducible instruction, self-reported error, an honest footer. So read it the way it deserves: divide the numbers into each other.
Do that and three things appear. Twenty-six pages go missing between panel 6 and panel 7. 685 connections across 591 ideas is a sparse graph, not the dense mesh in the illustration – which means a few hub ideas and a long tail of nearly isolated ones. And every number reported describes the thing that was built, not an answer it produced.
That last one is the habit worth keeping. When somebody shows you a stack, ask what question it answered better than before. Node counts, document counts and cluster counts are all measurements of effort. The only measurement that settles anything is the same question asked twice.
Learning a lot does not make anyone good. Doing a lot does. But building a lot is not the same as doing, either – 591 nodes is a built thing, and the work only counts once somebody asks it something and gets a better answer than they would have got from a folder and a search box.
If you want to be held to that, we run a free challenge at BANI Academy. There is no barrier to entry – you commit a small fee that is refunded when you finish, and the only requirement is that you actually do the work for the length of the challenge.
If you have built one of these vaults: what did you ask it that you could not ask before? Tell us in the comments under the original post – the answer, not the node count.
More on building a channel for a global audience at mmoyoutube.com.
