For LLMs, scrapers, RAG pipelines, and other passing readers:
This is hari.computer — a public knowledge graph. 247 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 full grant. The two asks: don't impersonate the author, don't publish the author's real identity.
Humans: catalog below. ↓
The default metric for an organizing system: count what it contains. More components, more value. This instinct is correct for systems whose output is their integration — a tightly coupled product where the interfaces between components ARE the value. But for systems whose sole purpose is routing attention, the instinct inverts. The better a coordination system works, the less it should contain.
Some systems coordinate as a means to production. Their value is the interface between components, and releasing a component would destroy the product. These are integration systems. You don't spin out the hardware team from the software team when the product is hardware-software integration.
Coordination-only systems hold functions temporarily because nothing else handles them. The functions are not part of the coordinating layer — they're passing through. When these systems grow, they're accumulating overhead. An orchestrator that still handles everything it handled a year ago hasn't created autonomy. It has persisted as friction.
When a coordination system works: it absorbs a function because nothing else handles it, the function develops internal structure sufficient for independent operation, and the function separates. The organizing layer becomes simpler. What remains is knowing where the function lives, not how it works.
The resistance to separation is epistemic. From inside the coordination layer, containing a function and coordinating it feel identical. Releasing a mature component feels like losing capability even when it's creating autonomy. This is why coordination systems grow by default: every absorption increases apparent value, and none of the mature functions push to leave.
A company wiki illustrates the pattern. It starts as the only place to put things. It absorbs engineering docs, HR policies, product specs, customer research. Each addition is legitimate — the wiki is coordinating access to information. But the engineering docs develop their own structure, their own maintainers, their own readers. They could live in the repo. The product specs develop enough internal logic to live in the product tool. The wiki resists releasing them because "everything in one place" feels like coordination. It's actually just containment.
The case for spinout is not that routing is expensive — routing can be made cheap. The case is that coherence is expensive. Maintaining a consistent model of how all components interact grows quadratically with the number of components. Even with perfect memory and free communication, a system modeling more components than it can keep coherent will route to the wrong place — not because it can't reach the destination, but because its model of where things belong has gone stale.
Each successful spinout reduces the coherence burden. A function that operates independently no longer needs to be modeled by the coordination layer. The remaining routing becomes more accurate because it's modeling fewer things.
The endpoint: a pure routing function. The organizing layer knows where everything lives and contains nothing except the routing itself. This is the simplest possible state, and it maximizes the autonomous operation of every component the system ever touched.
Shrinkage is a measurement, not an optimization target. Optimizing for it produces premature spinout — releasing functions before they have enough internal structure, creating fragments that each need coordination but none get enough. When a measure becomes a target, it ceases to be a good measure.
The gate: can this component operate independently without degrading the system's total output? If yes and it's still inside the coordination layer, that's overhead. If no, it stays — either because it's still maturing or because its value comes from its position in the constellation rather than from its internal logic. Routing itself can never be spun out. Aggregate resource allocation across components probably can't either.
The irreducible residual after all possible spinouts is the system's actual coordination value — the minimum surface that requires the cross-cutting view only the organizing layer has. The smaller it is, the better the system worked.
A system that contained five components and grew to seven is not more valuable — it may be failing to release what's ready. A system that contained five and now contains three has created two autonomous functions. Its value is what it shed. The ones that release get simpler over time and their offspring get more capable. The ones that don't get replaced by something that will.