The Price of Legibility
Making your notes machine-readable is supposed to make them more useful. The part no one mentions is what gets lost in translation.
In 2001, Tim Berners-Lee published a vision for the Semantic Web: a future internet where every piece of information would carry formal, typed meaning. Resources would link to each other in structured ways. Machines could traverse the graph, infer relationships, and answer questions without ambiguity. The technical standards that followed, RDF and OWL, were genuinely impressive. They were also, as mass phenomena, total failures. Nobody built the semantic layer. People kept writing informal HTML.
The reason is instructive. Making knowledge legible to a distant, abstract observer turns out to be expensive in ways that aren't obvious until you're doing it. OWL was too complex to author without specialized tools. RDF required disciplined annotation for every claim. The moment "making knowledge machine-readable" became someone's actual job, most people stopped doing it.
James C. Scott wrote about this pattern in 1998, in a book about states and cities rather than notes apps. "Seeing Like a State" makes one central argument: when institutions try to make complex things legible to themselves and their tools, they systematically destroy the local, contextual, difficult-to-articulate knowledge that made those things work in the first place. Haussmann's renovation of Paris in the 1850s is the famous example. He demolished the medieval neighborhoods, cut wide boulevards, made the city navigable by outsiders and controllable from the center. The city became legible. The neighborhood life that depended on narrow streets and knowing your neighbors by sight got gutted in the process.
Scott calls what's lost métis: the practical, situational, experience-based knowledge that doesn't survive translation into formal rules. A farmer who knows her field's microclimate. A manager who knows which team members can be asked to stretch and which can't right now. Métis can't be written into a procedure manual without being destroyed in the process. You end up with rules that are technically accurate and practically useless.
This is a useful lens for thinking about what happens when you try to make your personal notes AI-readable.
The cost of making notes legible
When you write a note for yourself, you use compression. Shorthand. References to things you don't need to name because you were there. Notes written this way are dense with meaning precisely because you don't have to explain everything. They're working perfectly for their intended reader: you, shortly after the fact.
When you write for an AI reader, or discipline yourself to write in a way that could be reliably queried, you lose the compression. The ambiguous pronoun needs to resolve. The implication needs to be stated. The qualifying observation that doesn't fit a defined field gets cut, or simplified into something that fits but isn't quite right.
This isn't hypothetical. It's what happened to the Semantic Web. And it's what happens when you try to migrate from informal notes to a strict knowledge schema. The structure starts selecting for the kinds of knowledge that survive formalization: decisions with clear alternatives, preferences with obvious values, tasks with unambiguous owners. The texture that makes those entries actually meaningful becomes harder to capture because there's no box for it.
There's a version of "structured personal knowledge" that is basically the Semantic Web, sold to individuals as a productivity system. It looks impressive and it atrophies.
What structure is actually for
But the conclusion isn't to avoid structure. The conclusion is to be precise about what you put into it.
Some knowledge has a fixed shape. A task either has a due date or it doesn't. A person either prefers email or they don't. A decision was made on a specific date with specific alternatives considered. These are genuinely typed. Structure doesn't distort them. An AI looking for "all open tasks in the infrastructure project" or "this person's communication preferences" is asking a structurally precise question, and a structurally precise record answers it well.
Prose observations don't have that shape. The note that captures how someone actually communicates, specific and observed and contextual, can't be reduced to a preference field without losing the thing that makes it useful. Put it in the notes section. Leave it in Markdown. Let it stay ambiguous.
The interesting design question in personal knowledge tools isn't "how structured should everything be?" It's "what kinds of things genuinely have structure, and what's having structure imposed on them?" Typed entities answer the first category. Prose that lives next to those records answers the second. Haussmann's mistake wasn't widening the streets. It was deciding everything should be widened.
The Semantic Web failed because its authors didn't make that distinction. They wanted one format, one representation, one legibility layer for everything. What survived was informal HTML carrying informal notes, with search engines making it findable anyway.
The most useful note I've taken in the last year was something I wrote at the end of a difficult meeting. Not a task, not a preference, not a decision with documented alternatives. Just a paragraph that started with "I think the actual problem here is..." and worked something out. No tags, no schema, no field that could hold it.
I wouldn't want a knowledge tool that turned that into a form.
Asgeir Albretsen is the founder of Harbor.