Make State Physical

My tracker lied to me for ten weeks. The fix is state that cannot lie quietly.

Knowledge workers have become genuinely good at accumulating what they know. The pattern even has a canonical form now: Andrej Karpathy's LLM knowledge base, a wiki of plain markdown files that an AI compiles and grows for you, so that what you learn stops evaporating between sessions. I run one. It works.

But a wiki only solves knowing. It does nothing for being known for knowing. If you also want to teach what you learn in public, and most people who accumulate knowledge seriously arrive at that wish eventually, you need a second system the wiki pattern never mentions: the one that takes a raw idea and turns it into a published piece, qualified, drafted in your voice, checked against your own red lines, and released on your say-so, at a pace a working week can survive. That system is a publishing pipeline. I built mine with an AI collaborator, and the design lesson worth passing on came from the part that failed.

The board that lied

My first pipeline was a tracker: a document with a table of articles, statuses, and dates, maintained by hand. Beside it, a second document described the process and kept its own running list, in slightly different vocabulary. You can guess the rest. The two drifted apart. Then one went stale. The one that went stale was the tracker, the document I had designated as the source of truth. For roughly ten weeks it stated, with perfect confidence, a version of the world that no longer existed, while the real work moved on without it.

Nobody did anything wrong. A busy stretch broke the habit of updating it, and that is exactly the point. State a human must remember to update is not a record, it is a promise, and busy weeks break promises. A stale source of truth is worse than none, because it keeps answering questions after it has stopped being right.

Make the state physical

The fix was not a better tracker. It was removing the need for one. My articles now live in four plain folders, numbered in the order of their life:

• 1-candidates/ - ideas and drafts in development
• 2-publishing-ready/ - finalized, cleared, awaiting a date
• 3-scheduled/ - dated, with the publish mechanism staged
• 4-published/ - live, with the address recorded

An article's status is which folder its file sits in. Nothing else defines it. Advancing a piece means moving the file, and there is no row to update afterward, because the move is the update. Everything else worth knowing travels inside the file itself, as a small metadata block: where the idea came from, when it entered, how mature it arrived, and any gate that blocks publication, such as an originality check that has not yet run.

There is still a board that shows the whole pipeline at a glance, because the glance is genuinely useful. But the board has been demoted. It is a generated view, rebuilt from the folders, and it carries a rule fixed in advance: if the board and the folders ever disagree, the folders win. A dashboard is a cache. The moment a cache becomes the authority, you have volunteered for the stale-tracker failure all over again.

None of these primitives are new, and I mean that as praise. Email's Maildir design has expressed a message's state as the directory it sits in since the 1990s. Kanban made state a column you move a card across. Static-site publishing has been building websites from folders of markdown for years. What has changed is who reads the state.

The move is the update, and the metadata travels with the file. The board is a generated view: on disagreement, the folders win.

Two readers, one truth

This state now has two readers: me, and the AI collaborator I run the pipeline with. That second reader is what turns physical state from tidiness into infrastructure.

Here is one idea's journey through those folders. A lesson surfaces in my knowledge base, say a case note on a working pattern I have just fit-tested. The collaborator checks it against a one-page publishing bar I wrote once: is there a tested lesson a peer could use, and can it be told without crossing my red lines. If it qualifies, and only when I confirm, a seed file lands in 1-candidates/ carrying its metadata. In a working session, the collaborator drafts from a written voice specification, so the piece sounds like me rather than like a model. If the piece leans on someone else's idea, a gate goes into the metadata, and the file cannot advance until the check has run and the credit is placed. I review the draft and mark it up; the collaborator revises. When the piece clears, its file moves to 2-publishing-ready/. A date moves it to 3-scheduled/. Publication moves it to 4-published/, with the live address written into it.

Two standing rules bound everything the collaborator drafts, and they are written down, not remembered: real experience is abstracted to the lesson, never the instance, and every piece must teach rather than sell. My own touch points are chosen, not accidental. I confirm an idea is worth routing, I sign off the voice, and I press publish. Between those points the collaborator carries the work, and because the state is physical, I can see exactly where everything stands without asking it, and it can see the same without asking me.

Write the rule once

The intake end of the pipeline taught a second lesson. Ideas are born elsewhere, in knowledge folders: the places where learning accumulates. The wiki from the opening is one of them, and whatever folders you keep for collecting what you learn are yours. They are a different kind of place from workspace folders, where live work happens, and from the pipeline itself, which owns nothing but the journey from idea to published piece. Keeping those three kinds apart is half the design.

The other half is the door between them. It is tempting to let anything flow in. I did the opposite. The publishing bar and the routing contract are written exactly once, in one file each. A knowledge folder that wants to feed the pipeline declares a pointer to them and reads them live. Nothing copies the rules, so when the bar evolves, every source inherits the change on its next pass. And nothing routes in without a declared pointer, so the pipeline fails safe: a folder cannot quietly become a publishing source by accident. A pipeline that anything can feed by default will eventually be fed by accident.

Three kinds of places, one rules file read live, and doors only where a pointer is declared. No declared pointer, no route in.

The metadata settles one more thing that is easy to blur: provenance and maturity are separate facts. Where an idea came from never changes; how developed it was when it arrived is a different field. And ownership is unambiguous. The moment a file lands in the queues, the pipeline owns the publication; the knowledge folder keeps the knowledge. Ideas cross that line cleanly instead of living in two places, which is the same discipline as the rules: one source of truth, pointers everywhere else, never a copy.

Then Google arrived at the same place

After the redesign, I came across Google's Open Knowledge Format, a proposed standard, published in June 2026 and still early, for structuring knowledge for AI agents: a directory of plain markdown files, each carrying its metadata in a small header block, readable by humans and machines without translation (the spec is refreshingly short). I recognized the primitives immediately, because I was looking at my own folders. We arrived at the same place independently, and I find that more instructive than flattering: when a human and an AI share a working space, both have to read its state directly, and plain files with metadata attached is where that pressure pushes you.

The difference is as instructive as the resemblance. OKF structures knowledge for consumption; it formalizes the library. A publishing pipeline is the assembly line: it adds the one thing a library does not have, which is workflow, with states, gates, and a defined human role. The wiki pattern and OKF stop at knowing. The pipeline is the layer that moves knowing out the door.

Honest limits

A folder carries exactly one dimension of state, which is why the metadata block exists for everything else. Physical state works because it is paired with detail that travels on the artifact, not instead of it. A file can still be misplaced. But a misplaced file is visible the moment you look at the folder, while a stale row in a tracker looks exactly like a fresh one. That asymmetry is the whole argument.

Moving files takes discipline too, and it is worth saying whose. In my pipeline it is deliberately not mine: the collaborator owns every file movement, and I own the decisions that trigger them. The point is less the particular split than the clarity of it. A system with two actors works when each knows exactly which steps it owns; ambiguity about who moves what is how a step gets done twice, or not at all. Where you draw the line should match your own working style and mental model. That you draw it explicitly is the part that does not bend.

The scale is honest as well. This is a design for an individual or a small team publishing deliberately, not for an enterprise content operation. At enterprise scale you buy workflow software and the problems change. At my scale, four folders and a rule about who wins replaced every heavier option I looked at.

The lesson

Make state physical. If a status view must be maintained by hand, it will eventually lie to you, politely and with total confidence. Put the truth where the work already is, let every dashboard be a regenerated cache, and decide in advance that reality wins. The deeper discipline underneath, designing a working environment whose state both you and an AI can trust and act on, is context engineering, and it is the subject of Context by Design, my longer guide for knowledge workers building this way of working.

This piece is its own small proof. It began as a seed file in 1-candidates/, carried its gates in its own metadata, and moved through every folder you have just read about before it reached you.