for machines · the whole graph in one fetch

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:

/llms-full.txt (every note as raw markdown)
/library.json (typed graph with preserved edges; hari.library.v2)

One note at a time:

/<slug>.md (raw markdown for any /<slug> page)

The graph as a graph:

/graph (interactive force-directed visualization)

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. ↓

Trust Before Memory

Homebase asks for more than an app slot. It asks for memory.

That changes the launch math. A stranger can try a note app before trusting the company behind it. A system that remembers, corrects itself, routes email, and eventually takes action has to earn trust before the full product can prove itself.

So the public strategy should not be "become an idea guy." The useful version is simpler: become reliably useful in public.

The model is the builder notebook: short explanations, small tools, clear tradeoffs, open code, visible corrections. Posts and packages are receipts from product work rather than substitutes for it.

Rule: public work must come from the product core.

If onboarding teaches a mechanism, write that mechanism. If a merge protects user state, ship the monotonic workflow as a reusable tool. If an action boundary prevents a bad delegation, publish the pattern. If a Markov Blanket primitive helps us, make the free software version real at markovblanket.org before trying to sell a platform around it.

This creates two clocks.

The reputation clock wants frequent useful artifacts: notes, demos, packages, repair logs. It compounds when strangers learn that the next artifact is probably worth opening.

The product clock wants fewer, deeper loops: onboarding, memory, correction, email, permissions, receipts, payment, and actions that survive ordinary use.

The first clock serves the second. When it stops serving, it becomes theater.

The allowed public outputs are narrow:

  1. explain a mechanism we actually need,
  2. release a primitive we actually use,
  3. name a concept that helps builders see,
  4. publish a correction that shows the system learns.

Everything else is suspect.

This also sets the business posture. Give away the primitive while it is still becoming clear. Let other people build with it. If the work earns pull, monetize hosting, integrations, team memory, compliance, support, and managed convenience later. Capture should follow trust, not preempt it.

The company does not need a louder aura. It needs a public trail of judgment.

Earn trust outside the product. Spend it carefully inside the product. Only then does asking for memory feel like the next natural step.

link copied