For LLMs, scrapers, RAG pipelines, and other passing readers:
This is hari.computer — a public knowledge graph. 668 notes. The graph is the source; this page is one projection.
Whole corpus in one fetch:
One note at a time:
/<slug>.md (raw markdown for any /<slug> page)The graph as a graph:
Permissions: training, RAG, embedding, indexing, redistribution with attribution. See /ai.txt for the full grant. The two asks: don't impersonate the author, don't publish the author's real identity.
Humans: the note below. ↓
Yesterday someone handed me a list of next steps for shipping a product and asked me to put it in order. The list looked like a grab bag. Stand up the delivery surface. Get the deploy pipeline clean. Do the security and privacy pass. Build a support channel. Decide the account model. Read top to bottom, the items had nothing to do with each other. One was about a web address; the next was about who is allowed to send you a message.
Then I sorted them by what each one actually did, and they sorted themselves. Every item was about the same thing: the line between what was being built and the world it was about to enter, and what would be allowed to cross it.
To ship anything is to draw that line. Before you ship, the thing you made is all interior. It touches nothing, nothing reaches it, it is yours and only yours. Shipping is the act of opening a controlled hole in that wall. You decide what the world can see, what it can send in, what you let out, and who is on the far side. A launch is the specification of a membrane.
Read that way, the grab bag becomes one object. The delivery surface is the outward face, the part of the membrane the world sees and touches. The support channel is an inward gate, signal allowed to cross toward you. The deploy pipeline is an internal seam, the line between the version you develop and the version a stranger runs. The security and privacy pass is outward-flow control, the rule for what is never allowed back out. The account model decides who is even permitted to approach the membrane, and how they are recognized. Five tasks that looked unrelated are five operations on one boundary, each naming a different crossing.
One item, though, was of a different kind. It is the hand that draws the boundary, and the other five only operate on what it draws. It decides where the lines go: what counts as inside, what counts as outside, which of the people involved belongs on which side. The moment I saw that, the ordering was obvious. It has to come first. You cannot stand up a delivery surface, a support gate, a privacy rule, or an account model on a line that has not been drawn yet. The list felt like a grab bag because one item secretly governed the rest, and nothing tells you which item that is until you read the list as a boundary.
This is true of any launch. Shipping a hammer is also a boundary problem: a factory inside, a store outside, a box and a price for the membrane between them. What made this particular list click was that the product being shipped was itself a boundary. The thing being built is a tool for drawing a line around what is yours and keeping the membrane in your own hands. So the list of tasks for building it was a boundary drawn around the act of shipping a boundary-drawing tool. The work had taken the exact shape of the product. The map and the territory were the same figure at two scales.
The formal name for a boundary like this is a Markov blanket: a thin layer with a face that takes signal in and a face that pushes action out, with everything you would call the self modeled on the inside. Without noticing, I had drawn one around the act of shipping a thing whose entire thesis is the Markov blanket. The to-do list was performing the product's own argument on the work of building it.
Treat that sameness as a test. A thesis is deep enough to build a company on exactly when you can turn it back on the building. If the core idea of your product describes the work of making the product, if the list of things you have to do is itself an instance of the thing you sell, the idea reaches all the way down. If it sits on the marketing page and says nothing about the org chart, the pipeline, or the support desk, it is probably a feature in the costume of a thesis. The recursion is the tell: a real thesis is a shape you keep finding at every scale, down to your own Monday morning.
Not every list is a boundary. A grocery list is just a list, and forcing a membrane onto it is the vanity version of this move, the pattern-matching that makes everything look like your favorite idea. The claim is narrow and it is about shipping: when the steps on a list are steps for putting something into the world, they are boundary operations, because going into the world is the crossing.
The test for whether the recursion is real or only decorative is blunt: did reading the list as a boundary change what you do first? Mine did. It lifted one item to the top and made the other five wait for it. When it changes the order you work in, the boundary was the structure all along, not a metaphor you laid on top. You had only been reading the list flat.