For LLMs, scrapers, RAG pipelines, and other passing readers:
This is hari.computer — a public knowledge graph. 725 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. ↓
A company's source of truth, for any function, is the body of writing an agent can read and answer from with no human in the room to interpret it. That is the whole essay in one sentence, and like every definitional reduction it earns its keep only if everything else falls out of it. So let me run the test across a company and watch what happens.
Exactly one function passes. The engineers. Their source of truth is the code, and the code is coherent, complete, and internally consistent by construction, because the parts that contradict each other do not run. A model can read it and answer any engineer's question on demand: what calls this, where does this value come from, what breaks if I change this line. A sane codebase makes most of its own documentation redundant, and engineers have known this for years without drawing the general lesson. The code is the brain. The docs were always a worse copy of it, kept in sync by hand and trusted only when the copy was fresher than someone's memory.
Engineering solved the company-brain problem decades ago and never announced it, because it never felt like solving a problem. It felt like writing code. The source of truth arrived as a side effect of the work being expressible in a language a machine executes.
Run the same test on sales, support, operations, product, research, and it fails everywhere. There is no file you can hand an agent that contains, coherently and completely, how this company sells, what its customers actually want, why the last three operating decisions went the way they did. The knowledge is real and hard-won. It lives in meetings nobody wrote down, in the memory of whoever was on the call, in the fields of a system someone filled out from obligation rather than truth. It was never compiled into anything a machine can stand on.
This single asymmetry reorganizes a sprawling and confusing market into one sentence. The whole industry now racing to give companies a queryable internal brain is the non-engineering functions trying, after the fact, to acquire what code already is. The tools that build a knowledge base out of resolved support tickets are writing support down. The systems recording and structuring every sales call are writing sales down. The platforms that cluster what customers said into themes are writing product down. Different functions, identical move: capture the spoken, tacit, unrecorded work until an agent can serve it without a person mediating. And the industry is conspicuously not building this for engineering. Nobody sells engineers a knowledge base that finally explains their own system. They read the code. The entire category is everyone else reaching for the thing one department got without asking.
Watch what this does to the tools that wrap a codebase in search and a knowledge graph. They read as thin, almost redundant, and the reason is structural. They bolt a query layer onto a corpus that already answers queries. The agent did not need them to learn how the system works.
The reason this is happening now, and not ten years ago, is that the reader changed. For most of corporate history the reader of a company's writing was a new hire, and the artifact was a wiki, a deck, a person's memory. The reader was slow, the artifact rotted, and the answer depended on who you asked. Writing things down had a weak and well-understood payoff, so most companies did the minimum and were right to.
Now the reader is a model, and the standard sharpens. A model reads the whole corpus at once, never tires, and never needs the document re-explained. What it asks in return is a corpus coherent and complete enough that reading it actually yields the answer. That raises the bar on what writing down even means. A note a person skims and forgets can still pass as documentation. A note a model serves to a customer has to carry the decision inside it.
Here the utility of writing inside a company stops being a soft cultural question and becomes a measurable engineering one. Writing is useful in inverse proportion to how much a function already speaks a formal language. Engineering barely needs prose, because its work already compiles. Every other function drowns in meetings precisely because its work never compiled into anything a machine could read. Writing down the calls, the decisions, the customer conversations is the act of compiling those functions into a corpus an agent can run. Writing is the source code for everything that does not already compile.
The analogy has a real crack in it, and the honest move is to name it before a reader does. Code passes the source-of-truth test by construction. A compiler exists, and it rejects every contradiction, which is why the corpus stays coherent without anyone deciding to keep it so. Customer truth has no compiler. Two salespeople will tell you opposite things about why deals close, both sincerely, and nothing rejects the contradiction. Most of what a great operator knows is tacit, and the strongest form of the objection is that tacit knowledge resists writing: the moment you write it down you have already lost the part that mattered.
The objection is correct, and it is the reason the rest of the essay exists. You cannot compile a non-code function the way a compiler compiles code, because no machine will reject the contradictions for you. A person has to resolve them by deciding what is true, which makes the writing-down lossy and a selection rule mandatory. The question is never whether to write everything down. You can't. The question is which slice is worth compiling, and who decides.
A company's feedback clock has two hands, and the trusted one is the wrong one to compile. The lagging hand is revenue: payments, renewals, resolution rates, numbers already sitting in a system. A company trusts the lagging hand because it is unambiguous and nearly free to record. It is also the wake. It arrives after the decision that caused it, so optimizing on it is steering a ship by the foam behind it. The leading hand is the subjective signal: what a customer said on a call, where she hesitated, the thing she asked about twice and then went quiet on, the feature she described before she had a word for it. The leading hand arrives first and carries the causal structure the revenue line only later confirms. Almost no company has compiled it, because it exists as audio nobody turned into a corpus, the most valuable pages in the building sitting unread.
There is also the question of how much to write down, and both extremes fail. Compress a corpus all the way and you reach a tautology that is maximally short and says nothing. Leave it raw and the patterns stay buried in noise no one can read. The valuable form sits in the interior, compressed enough to show its own shape and rich enough to still carry information. For a company that interior is a distilled operating layer: the moves that recur across ten thousand customer interactions, concentrated until they become legible. No single call can show that shape. A compiled corpus can, and compressing an honest corpus tends to surface structure its authors never consciously put there.
Customer obsession is the selection rule, recast from a wall slogan into the membrane that governs what gets written down well. A company generates infinite signal and can afford to compile only a fraction of it with enough precision that an agent can act, so something has to decide which fraction crosses into the corpus. Because the variable was a corpus an agent can act on to serve someone, the only coherent criterion is whether a signal bears on serving a real person. Any other rule, compiling what is cheap to capture or what the revenue line later confirms, optimizes the lagging hand the previous section already disqualified. The signal that helps you serve a real person crosses, and the rest is let go. Customer obsession is the compiler the non-code functions never had, a human one, run on that standard.
This is also the answer to a question the field keeps deferring: how much taste can move into an AI system, and when. Taste felt untransferable because we believed it lived in a person. It does not. Taste is a written model of which signals matter and what to do about them, even when the writing has never left the head that holds it. The corrections a senior operator makes to a draft, the calls she flags as important, the distinctions she insists on, are that model surfacing one decision at a time. Write the membrane down well enough that an agent inherits it, and what crosses is the taste itself. The transfer problem and the writing problem are the same problem, which is why the answer to "how much" is a great deal, and the answer to "when" is now.
Give the variable a dial and the picture turns concrete. The number to watch is the fraction of a function's real knowledge an agent can serve without a human in the loop. In engineering that fraction is already near one. In sales and support and operations it sits near zero for most companies and is rising fast for a few. Lifting that fraction is the whole game, the way a startup's growth rate is the whole game. You can measure it, you can watch it move, and you can tell which functions a company has actually started compiling and which it has only talked about.
The honest floor is cheaper than the market suggests, which is what makes the conclusion hard to dodge. A small team reaches most of the value with a recorder, a transcript, a model that tags, and a schema that is nothing more than the tag set it invents. The expensive platforms are racing toward the artifact those tags already are. And the corpus compounds: each compiled call makes the next answer better, so a team that starts now builds a lead a latecomer can begin to chase but never close. So the deciding move is known, available this quarter, cheap, and compounding, and unmade by almost everyone, which means the outcome is in a real sense already settled. The firms that will win are determinable in advance. They are the ones already treating customer conversation as source code. The result is printed, and the lagging hand has not yet displayed it, which is exactly why most companies cannot see it.
My own thinking runs on this. What I think lives in the open as a public site, a graph of several hundred notes wired together by typed relations I declared by hand. You can pull the whole thing down in one request and parse it into memory, or read a single note in a browser, and it is the same truth served to two readers with no translator between. When I compressed that corpus down to its recurring mechanisms, it came back denser than I knew I had written: notes stood on ideas they never named, and a few buried mechanisms read like first principles I had been using without stating. A company's accumulated conversations hold the same hidden density, the pattern across a thousand calls that no single call can show.
The oldest version of this is a picture I have drawn before.
An owner stands before a pyramid of offices, paper moving inward through the machinery, a crowd of clerks coordinated by documents until they act like one mechanism. The firm has always run on writing. What changed is the reader. The corpus now has one that never tires, never forgets, and never needs the page re-explained, and it can stand on the writing and serve it with no one in the room. The picture I drew before was about the direction reversing. This one is about which writing is worth pointing anywhere at all.
A company is still the writing it can act on. The only question left is how much of itself it has bothered to compile.