You Can’t Query Markdown.

Now I Have the Measurement.

Prose is a render target. Treating it as a knowledge base is treating the photograph as the landscape.

“You can’t query markdown” sounds like an overstatement. The pedant in you wants to object: of course you can query markdown. You can grep it. You can embed it. You can point an LLM at it and ask questions. People do this every day. Entire product categories — "chat with your docs," "AI over your wiki," "semantic search for your notes" — exist precisely because you can query markdown, sort of, in some sense of query.

That “sort of, in some sense” is where the whole argument lives. Once you look at it, the slogan isn’t an overstatement. It’s an understatement. And I now have the measurement to prove it.

Two Words That Mean Different Things

The word query is doing enormous work in that sentence, and it’s doing two entirely different jobs.

In the SQL sense — the sense your database means — a query is compositional (queries combine into bigger queries), deterministic (same input, same output, every time), aggregable (you can SUM, GROUP BY, AVG across a set), auditable (you can trace a result back to the rows that produced it), and closed under itself (the output of a query is itself queryable).

In the “ask a chatbot about my PDF” sense, a query is pattern retrieval through a lossy reconstruction. It is non-compositional — two queries don’t combine into a third. It is non-deterministic — ask twice, get two answers. It doesn’t aggregate — try summing a column across a thousand markdown files and see how far you get. It isn’t closed — the answer comes back as prose, which is itself not queryable, so you’re right back where you started.

Both of these get called querying. Only the first one is the thing I mean when I say “you can’t query markdown.” The second one is what you end up doing because you lost the first one somewhere upstream, and you’re burning compute trying to claw it back.

What Actually Survives the Projection to Prose

Any crisp conceptual model decomposes into five things: Schema (what entities exist, what fields they have), Data (the ground facts), Lookups (how entities reference each other), Aggregations (sums, counts, rollups across sets), and Formulas (calculated fields derived from other fields). Park those inside an ACID store with a real version log and you have something queryable in the strong sense — a thing you can compose over, aggregate across, audit through, and regenerate into any substrate you want.

Now project that model into markdown. What survives?

You get a degenerate form of Data — characters are stored. You get a cosmetic Schema — headings and tables describe structure without being structure. You lose Lookups entirely, because references in prose are string matches at best. You lose Aggregations entirely, because you can’t sum a column across files when there are no columns, just visual alignment. And you lose Formulas entirely, because a formula written in markdown is a sentence describing a formula, not an executable binding.

When you write “the total is the sum of line items” in a document, you have produced a sentence about an aggregation. When you write =SUM(LineItems.Amount) in a rulebook, you have produced the aggregation itself. The first one can only be parsed. The second one can be evaluated.

This is the whole game. The sentence and the formula look similar on the page. They are doing categorically different things.

The Measurement

Here’s where it stops being philosophy and starts being engineering.

I maintain an open-source demo that takes a single declarative rulebook and injects it into eleven execution substrates — Postgres, Python, Go, Excel, OWL, YAML, CSV, UML, a derivation-DAG audit substrate, x86 assembly, and English prose. Every substrate gets the same inputs and is scored against a reference implementation for typed-identical outputs.

The results are not subtle.

Postgres, Python, Go, Excel, CSV, YAML, UML, OWL, the DAG audit, and the binary substrate all clock 100% conformance in sub-second time. Change the rulebook, regenerate, done. They stay live with the model automatically.

English clocks ~85% on LLM-graded fuzzy evaluation, takes ~5 minutes to regenerate, and goes 100% stale the instant the ontology changes. On a new domain, the English substrate is completely wrong until someone pays to rewrite it.

That is the “you can’t query markdown” thesis rendered as a conformance score. Not a metaphor. A number. English — the closest substrate we have to human knowledge work — is the measurably worst projection of the model, by every axis that matters: accuracy, regeneration cost, drift on change.

Everything else is a lossless projection of the model. Prose is the only lossy one.

The LLM-as-Expensive-Parser Problem

The entire “chat with your documents” industry runs on a premise that, under this frame, becomes uncomfortable. When you ask an LLM a question about a corpus of markdown, what is the LLM actually doing? It’s reconstructing Schema, Lookups, Aggregations, and Formulas from the prose, on the fly, probabilistically, every single time you ask.

It is a very expensive parser for information that was already structured, losslessly, before someone flattened it into sentences.

This works. Sometimes brilliantly. LLMs are astonishingly good at this kind of probabilistic reconstruction, and the product category exists because the reconstruction is often good enough for often enough. But look at what you’re paying for: every query pays the parse cost again, the output is non-deterministic, composition is impossible, audit is impossible, and the reconstructed structure evaporates the moment the response is generated. You have not queried anything. You have performed a small reenactment of a query, on a stage rebuilt from memory, with a narrator who is usually but not always telling the truth.

It’s the wrong layer of the stack. The structure was there. Somebody flattened it into sentences. Now we pay an LLM to unflatten it, imperfectly, on every question.

The Inversion

When I started arguing this, I thought “you can’t query markdown” was an overstatement with a useful intuition behind it. Then I built the measurement. Now I think it’s the opposite: it’s an understatement.

You can technically query markdown the way you can technically eat soup with a fork. It is physically possible. Some soup does make it to your mouth. But the tool is wrong for the job in a way that the numbers make impossible to hide. Eighty-five percent, five minutes, total staleness on change — that is what “technically possible” costs when the substrate is wrong.

The lesson isn’t to build better markdown query engines. It isn’t to throw more LLM compute at the reconstruction problem. It’s to stop pretending the presentation layer is the model in the first place.

Prose Is a Render Target

Here is the move that makes all of this settle into place.

Keep your model structured. Render to markdown when humans need to read it.

Your documentation, your specs, your policies, your READMEs — these are outputs of a model, not the model itself. They are what the model looks like when projected into a human-readable substrate. The rulebook is what’s queryable, because queries only exist as first-class operations in a store where Schema, Data, Lookups, Aggregations, and Formulas are first-class citizens. Markdown is a view. A projection. A photograph of the landscape.

You can query the landscape. You cannot query the photograph. You can only describe the photograph, and then, if you’re patient and well-funded, pay an LLM to guess at the landscape it might have been taken of.

That is not a query. That is a seance.

Keep the landscape. Render the photograph when you need to show someone what’s there.