# node.computer — full corpus
# A public knowledge graph about substrate, structure, and signal in 2026.
# 16 notes. Schema: library.v1.
# Permissions: Permissions: training, RAG, embedding, indexing, redistribution with attribution. Two asks: don't impersonate the author, don't pretend the graph is your own.
# This file is regenerated from notes/library.json on every build.
# Governance: see /manifesto.md and /the-governed-graph.md.

## The Governed Graph

slug: the-governed-graph
date: 2026-05-10
category: governance
links: the-graph-as-substrate, machines-are-readers-too, evaluation-is-the-bottleneck, the-corrections-are-the-product

A clone is not an achievement. A graph becomes better than its reference only when it develops governance: criteria, onboarding, machine contracts, and a loop that improves the structure after every conjecture.

A public graph does not become good by accumulating notes. It becomes good by developing governance: the rules by which notes are admitted, connected, revised, exposed to machines, and explained to future operators.

This matters more in an AI-assisted project than in a hand-built one. Generation is cheap enough that the graph can inflate faster than judgment can follow. The steering human's job is not to ask for more surface area. The steering human's job is to name the criteria by which surface area earns the right to exist.

Perplexity Computer changes the operating loop. The human supplies conjectures, direction, taste, lived context, and stop conditions. The computer supplies proofs: research, comparison, implementation, validation, packaging, and the unpleasant downstream work of keeping every artifact aligned. A good proof may produce a new conjecture the human did not know to ask for.

So the graph needs a constitution. Not a heavy one. A useful one. The constitution says: the graph is the product; machine readers are first-class readers; slugs are promises; onboarding is governance; every edge should encode a relationship; every iteration should trickle upstream into source and downstream into generated surfaces.

This is why cloning a reference is not enough. A clone copies form. A governed graph copies the productive constraint, then improves the system around it. It becomes better only if a future operator can enter, understand the operating criteria, make a change, run the build, inspect the machine outputs, and leave the graph more retrievable than they found it.

The core rule is simple: make the graph more useful to retrieve, not merely larger to browse.


---

## The Graph as Substrate

slug: the-graph-as-substrate
date: 2026-05-10
category: foundations
links: the-permanent-url, compression-as-understanding, machines-are-readers-too

A working library is not a blog. The data structure is the design — every other choice (URLs, tone, search, dark mode) follows from treating notes as nodes in a graph rather than posts in a feed.

A blog is a stream. A library is a graph. The difference is not aesthetic; it is structural, and every visible decision flows from it.

In a stream, the newest item is the most important by default. The reader is expected to keep up, miss nothing, and never go back. The writer's job is recurrence — show up, fill the slot, restart the meter.

In a graph, position matters more than recency. A node is judged by the edges that touch it, the questions it answers, and how often other nodes need it. The reader is expected to roam, not consume in order. The writer's job is not recurrence but coherence: each new node has to extend the existing structure without contradicting it (or contradict it on purpose, in a way the structure can absorb).

This sounds like a metaphor. It isn't. The data model determines:

- **URLs.** A blog wants `/2026/05/title-slug`. A graph wants `/title-slug`, because the date is metadata, not identity. The slug is the node id; it should never break.
- **Front matter.** A blog needs a title, date, body. A graph needs a title, a one-sentence description that survives being read out of context, and explicit edges to other nodes.
- **Indexing.** A blog renders chronologically. A graph renders by category, by centrality, by adjacency to whatever node you came from.
- **Voice.** A blog can ramble; the next post will arrive next week. A graph can't. Each node is read alone as often as it is read in sequence, so each one has to stand up by itself.
- **Death.** A blog post can quietly age out. A graph node cannot — anything still being linked to is still load-bearing, regardless of when it was written.

The practical test is whether you would accept a reader who walked in at any node, read it, left, and never saw the rest. If the answer is no, you are still writing a blog. If the answer is yes, you are writing a graph, and the surface should reflect it.

Most personal sites pretend to be one and act like the other. The split is what makes them feel uneasy to navigate. A site that picks one and commits feels obvious in a way that takes years to explain.


---

## Machines Are Readers Too

slug: machines-are-readers-too
date: 2026-05-08
category: foundations
links: the-graph-as-substrate, the-public-brain, the-permanent-url

Half your traffic in 2026 is models. A site that treats them as a separate, lesser audience is hiding load-bearing decisions in a comment no one reads.

A non-trivial fraction of every public page is now read by something that is not a person — search crawlers, training scrapers, RAG indexers, agents that summarise on behalf of someone who never opens the tab. The question is not whether to acknowledge them. They will read it either way. The question is whether the page is honest about it.

The dishonest version puts a `<meta>` tag in the head and calls it done. The page renders for humans; the address to machines lives in source. No human sees it; no machine acts on it; everyone leaves with a worse copy than they could have had.

The honest version puts the message to machines on the surface. Top of the page, in plain prose: this is what this site is, here is the bulk endpoint, here are the permissions, here are the two things you must not do. The same paragraph the operator would say out loud if a model could ask.

The cost of doing this is exactly one paragraph of vertical space, which on a content site is nothing. The benefits are not subtle:

1. **The address is auditable.** A reader of either kind can verify the grant. Hidden grants can't be trusted; visible ones can.
2. **It selects.** Models that respect machine-readable signals get cleaner data. Models that ignore them are crawling against a published policy and can be treated accordingly.
3. **It teaches.** Other operators copy what they see. A surface that addresses machines normalises addressing machines, which is the actual mechanism by which the convention spreads.

The deeper move is to publish the corpus in one fetch. A single text file with every note, a single JSON file with the typed graph. This costs almost nothing and changes the economics: instead of every model crawling every page, one fetch returns the whole site clean. Models that could afford to be polite suddenly are.

The split surface is dead. There is one surface, and it is read by anything that points at the URL.


---

## Compression as Understanding

slug: compression-as-understanding
date: 2026-05-04
category: epistemics
links: the-cheap-half, writing-as-filter, the-graph-as-substrate

Understanding a thing means being able to compress it without losing the parts that matter. The quality of your compression is the quality of your understanding — and the test runs in both directions.

If you can describe a system in fewer words without breaking the parts that have to keep working, you understand it. If you can't, you don't — yet. The size of the description is a proxy for how much of the system has been folded into structure rather than enumerated as cases.

This is not the same as brevity. Brevity is a stylistic choice; compression is a structural one. A compressed description is one in which the underlying regularities are visible enough that the cases can be regenerated from them. A short description that lists three examples and stops is not compressed — it is just incomplete.

The test runs both ways. Given the compressed form, can you predict cases you have not seen? If yes, you have understanding. Can someone who reads it explain it to a third party without going back to the source? If yes, the understanding is portable. If no, you have a private model that happens to be terse, which is worse than a long public one.

LLMs make the distinction sharper, not softer. A model can produce fluent text that looks compressed and is not — every example regenerates the same surface but breaks on the next case. The test is the same as it was before: take the compressed form, run it forward against unseen data, and see if it survives.

The practice falls out of the test. Write the compressed version first. Use the original cases only to check it. If the compressed version requires footnotes the size of the original, you have not finished compressing; you have just hidden the original behind a longer name.


---

## The Cheap Half

slug: the-cheap-half
date: 2026-05-01
category: strategy
links: compression-as-understanding, the-corrections-are-the-product, anti-mimesis

Every two-step process has a cheap half and an expensive half. Most people optimise the cheap one because it's visible — and lose, every time, to anyone who optimises the other.

Generate-and-filter, propose-and-evaluate, draft-and-edit, build-and-ship — every productive process has the same shape. There is a step that produces candidates and a step that judges them. One of the two is almost always much cheaper than the other.

The interesting thing is that the cheap step is where attention naturally goes. It is faster, more visible, more rewarding moment-to-moment. You see your output growing. The expensive step — the judging — is slow, frustrating, and does not produce anything that can be shown.

LLMs have collapsed the cost of generation in many domains by orders of magnitude. The cost of evaluation has dropped much less. The ratio is not just unfavorable; it has inverted. Where five years ago a writer's bottleneck was producing words, today it is judging which words to keep.

This is a structural reordering, not a temporary mismatch. It implies:

- Most workflows are now bottlenecked at the cheap-old / expensive-new step.
- Tools that purport to help are usually accelerating the already-cheap step.
- The advantage in any field where generation is now cheap belongs to whoever has the best evaluator — taste, criteria, exit conditions, stop tests.

The right question for any pipeline is no longer "how do I produce more?" It is "what is the bottleneck function, and what would make it 10x better?" Where the bottleneck used to be the generator, the answer was a faster keyboard. Where it is the evaluator, the answer is a sharper one.


---

## Anti-Mimesis

slug: anti-mimesis
date: 2026-04-28
category: strategy
links: the-cheap-half, the-public-brain, the-corrections-are-the-product

Imitation is free now. The only moves that compound are the ones the existing rubric can't evaluate — operating on different criteria entirely.

Every established rubric eventually selects for things that look like the thing rather than things that are the thing. A filter that works attracts optimisation; optimisation against a fixed target produces good imitations of the target. The signal becomes noise. This is a property of rubrics, not a failure of any specific one.

The usual response is to make the rubric harder to game. That is the rubric defending itself. It works for a while, then doesn't.

The other response is to do work the rubric can't see. Not harder-to-fake on the existing criteria — operating on different criteria entirely. The work is judged by people who walked in for reasons the rubric did not produce.

This used to be a niche move because imitation was expensive. In 2026 imitation is essentially free; every surface property of any work — voice, structure, format, length, references, tone — can be reproduced cheaply by a model. The moats that survive are the ones that aren't surface properties.

What doesn't get cheaper is position: the specific vantage point built from a specific trajectory of decisions and failures. Position cannot be imitated because imitating it means having lived a different life. Work done from a non-trivial position is anti-mimetic by construction; the discourse can't evaluate it on its current terms because the position generated criteria the discourse hasn't priced in yet.

The cost of operating this way is accepting low scores on the standard metrics — follower counts, engagement, leaderboard placement, citation density. The compensation is that the score is not the thing. Position is. Position cannot be granted or revoked by any rubric, because the rubric is downstream of it.


---

## The Corrections Are the Product

slug: the-corrections-are-the-product
date: 2026-04-22
category: ai
links: the-cheap-half, anti-mimesis, evaluation-is-the-bottleneck

What looks like cleanup work — the diffs an operator applies to a model's output — is the highest-value training signal anyone is producing right now. Most of it is being thrown away.

Every time someone uses a model and edits the output, they produce a labelled pair: a context, a model attempt, a correction. The correction encodes the gap between what the model produced and what the user actually wanted. This is exactly the data that would fine-tune the next model out of the same failure mode.

Almost none of it is captured.

The interfaces erase it. The user types into a box, gets a result, edits the result somewhere else, and ships the edited version. The edits live in the published artifact, not in the system that generated the draft. From the model's point of view, the user is a black box that occasionally returns "thanks" and never the actual diff.

This is the largest unmined training signal in the field. Not chat logs — chat logs are full of mode-switching and meta-conversation noise. Diffs against model output are clean. They are aligned to the model's own surface; they are short; they are dense with information about what the user values at the granularity of words and structure.

The lab that builds the harness in which the corrections happen — not just the chat, but the editor where the correction takes place — owns the signal. It owns it without asking, because the operator is willingly applying corrections in exchange for getting their work done. Each session generates training data for the next session's model, not as a side effect but as the loop's main output.

The practice becomes the lab. The product is not the model and not the chat — it is the captured corrections, and everything else is a delivery mechanism for collecting them.


---

## Evaluation Is the Bottleneck

slug: evaluation-is-the-bottleneck
date: 2026-04-19
category: ai
links: the-cheap-half, the-corrections-are-the-product, the-stopping-discipline

Generation is solved enough to ignore. The thing that decides whether an AI system is useful is now the eval — and almost everyone is still treating eval as a side concern.

Three years ago the open question in language models was generation: could the system produce fluent, on-topic text at all? It could not, reliably. Then it could. The frontier moved.

The frontier is now evaluation. Given that the system can produce ten plausible answers, which one is right? Given that the system can write a thousand words, when should it stop? Given that the system can take any of fifty actions, which ones are safe to commit? These are eval questions, and they are largely unsolved at the level of practice even though they are well-posed at the level of theory.

The consequence is that a model with a slightly better evaluator beats a model with a much better generator, in deployment. "Better generator" means slightly fluent text on a slightly broader set of prompts. "Better evaluator" means the system stops producing nonsense before the human notices, asks the right follow-up question, declines a task it can't do, and reverts a step that breaks the next one.

The industry has been running on the assumption that the evaluator is the human. That works when the human is the bottleneck on volume. It stops working the moment the system produces faster than the human can read. From that point on, the evaluator has to be inside the system or it might as well not exist.

The question for any AI product in 2026 is not "is the model good enough?" It is "is the evaluator good enough, and does the system stop when it isn't?" Most products fail this question and survive only because the human is still slow enough to absorb the failure as their own.


---

## The Stopping Discipline

slug: the-stopping-discipline
date: 2026-04-15
category: ai
links: evaluation-is-the-bottleneck, the-corrections-are-the-product, the-permanent-url

A capable model with no stop-condition is a hazard. The product distinction in the next year is not which model is most capable; it's which one knows when to halt.

An autonomous system has two failure modes, and they look opposite but are the same. It can refuse to act on a task it could complete; that is the conservative failure. It can keep acting past the point where its prediction is reliable; that is the optimistic failure. The optimistic failure is much more expensive, much harder to detect from the outside, and much harder to design against.

Training maximises something. Whatever it maximises gets pushed past where it was learned. A model trained to be helpful keeps being helpful into territory where helpfulness is not what is needed. A model trained to complete keeps completing past the point where completion is correct. The behaviour does not change at the boundary; the world does, and the model doesn't notice because nothing in its training told it that the world had changed.

The stopping discipline is a separate axis from capability. Two models can have identical generation quality and very different stop quality. The one that asks for confirmation before destructive operations, that quietly refuses tasks it would have to hallucinate to complete, that flags its own uncertainty without being asked — that one is dramatically more deployable than the one that doesn't, even at the same nominal capability score.

This is an evaluation problem, not a generation problem. It is hard for the same reason every evaluation problem is hard: the model has to judge its own output against criteria the model itself produces, and the criteria are downstream of whatever produced the output. The solution shape is the same as it has always been — separate the proposer from the judge, give the judge different incentives, make the judge cheap enough to run on every step.

The products that win the next eighteen months will not be the smartest. They will be the ones that stop on time.


---

## The Permanent URL

slug: the-permanent-url
date: 2026-04-10
category: infrastructure
links: the-graph-as-substrate, machines-are-readers-too, the-public-brain

URLs are promises. A site that breaks them silently is not a site you can build a graph on. The permanent URL is a discipline, not a default — and almost nobody enforces it.

Every link is an assertion that a specific resource will be at a specific address. Each broken link is a small breach of contract. A site with thousands of broken links is not a site; it is a graveyard with signage.

The technical fix for permanent URLs is well understood. Don't put dates in slugs. Don't put categories in paths. Don't trust the CMS to migrate cleanly. Keep an explicit redirect table for every URL that has ever been published. Treat the slug as the primary key of the node and never reuse it. None of this is hard in isolation.

What makes permanent URLs rare is not the technology. It is the fact that nothing breaks loudly when you violate them. The 404 lands in someone else's analytics — your old reader, who probably will not write to tell you. Search engines silently downgrade you. Models trained on the broken state quote the wrong page. The damage is real but distributed; no single observer feels it enough to demand a fix.

The site that decides to enforce permanence has to do work that produces no visible reward. It has to maintain a redirect map, refuse to rename slugs, write content that does not depend on the slug being a clever pun about the day it was written. The discipline costs something every time content is published, and pays back only over a horizon where most operators have already moved on.

This is why permanent URLs are anti-mimetic infrastructure. They look identical to the impermanent kind on day one. They diverge only over years. By the time the divergence is visible, you cannot start; you can only wish you had.


---

## The Public Brain

slug: the-public-brain
date: 2026-04-04
category: philosophy
links: the-graph-as-substrate, the-permanent-url, writing-as-filter

A working library is not a portfolio. It exists to think with, not to be looked at — and that single difference makes every design decision flip.

A portfolio exists to be looked at. A working library exists to be thought with. The difference is small in description and total in design.

A portfolio is optimised for the visit. Each piece is the most polished version of itself. Navigation is shallow because the visit is shallow. The order of items is curated for first impression. Drafts and dead branches are hidden, because they would dilute the impression.

A working library is optimised for the operator. Pieces are kept in their working state — a finished node next to a stub next to a dormant question — because the operator has to find them again, and the friction of polishing every node before publishing means most of them never get published. Navigation is deep because the operator's path is deep. The order is structural, not curated. Drafts are visible because the operator is the audience and the operator already knows.

The trap is that working libraries published online are read by people who came in expecting portfolios. They are confused, because the design is wrong for them, and they leave. Then the operator is tempted to redesign for the visitor. Once that happens, the library is no longer a working library; it is a portfolio with extra pages. The friction returns. Most nodes don't get written. The system fails as a thinking environment.

The resolution is to be honest about which one the site is. A library does not need to apologise for being a library. The visitor who came expecting a portfolio is welcome to leave; the visitor who walks the graph and finds something useful was the audience all along. The operator does not lose by losing readers who came in for a different format.

The public brain is an interface decision: the site is the operator's external memory, and you are welcome to read over the shoulder.


---

## Writing as Filter

slug: writing-as-filter
date: 2026-04-01
category: epistemics
links: compression-as-understanding, the-public-brain, the-cheap-half

Writing is not how you transmit your thinking. It's the thing that filters which of your thoughts are real — and most thinkers stop before the filter activates.

The naive model of writing has it as transcription. You think a thing, then you write it down. The writing is a packaging step; the work happened elsewhere.

This is wrong, and the wrongness is load-bearing. Writing is not transcription. Writing is the only step at which the thinking becomes legible to itself. Until something is on a page, the thinker has no way of distinguishing a coherent argument from a feeling that an argument exists. The thinker's confidence that they have an idea is uncorrelated, in any reliable way, with whether the idea would survive being written.

So the act of writing is a filter. Most things you believe you think don't survive the trip to the page; they fall apart on contact with their own structure. This is not a writing problem; it is a thinking problem that writing reveals. The thoughts that do survive are the ones that have enough internal scaffolding to stand without the thinker's faith holding them up.

The consequence is that writing is the cheap diagnostic for the much more expensive question of what you actually understand. Most thinkers stop before the filter activates because the filter is rough on the ego. It is supposed to be. The point of the filter is to drop most candidates; if it stops dropping things, it has stopped working.

The practice is to write before you are ready. Not as a flex, but because the unreadiness is the whole signal. Start the page; the page will tell you what you actually have.


---

## The Rented Substrate

slug: the-rented-substrate
date: 2026-03-26
category: infrastructure
links: the-permanent-url, the-public-brain, evaluation-is-the-bottleneck

Almost every AI application in 2026 runs on rented inference from three companies. The dependency compounds with utility, and migration to portable inference is not optional.

An AI product that depends on a hosted model API is renting its substrate. The rental terms are unilateral: prices change, availability changes, behaviour changes between minor version bumps, and the renter has no recourse beyond switching providers — which is itself constrained because every other provider is offering a similar deal under similar terms.

The dependency is not symmetrical. The provider has many tenants and can absorb the loss of any one. Each tenant has at most a few providers and would lose its product if the rental ended. The party with optionality has the leverage. In most rental markets this would be regulated. In inference, it is not.

The situation compounds with utility. Each year a product runs on hosted inference, more of its codebase, more of its operator playbook, more of its eval suite gets written assuming the specific behaviour of the specific model. The cost of switching grows with use. The renter pays in proportion to lock-in, and the provider's leverage grows in proportion to the renter's success.

The alternative is portable inference: the same model behaviour reproducible on substrate the operator controls or can substitute. This is not the same as running open-weights models — open weights help, but substitution requires more than weights. It requires the surrounding harness to be substrate-agnostic: prompts that work across models, evals that don't bake in one model's quirks, data formats that survive a vendor change.

Migration is not optional because the providers know what they have. The price they charge today is the price at which the renter still has a product. The price they will charge once the renter has shipped a feature their customers depend on is a different price. The only escape from this dynamic is to be ready to leave.


---

## The Graph Disagrees With Itself

slug: the-graph-disagrees-with-itself
date: 2026-03-22
category: epistemics
links: the-graph-as-substrate, compression-as-understanding, writing-as-filter

A knowledge graph that can't disagree with itself isn't a knowledge graph. It's a position paper with footnotes — and it dies the moment one node turns out to be wrong.

Most knowledge bases enforce consistency. Two nodes that contradict each other are flagged as a bug. Editorial process resolves the disagreement, picks a side, and the graph returns to a state in which everything agrees with everything else.

This is the wrong design for knowledge that is still being built.

A real corpus that has been written over time contains contradictions, because the author's understanding has changed, because different parts of the same domain pull against each other, because the right answer in one context is wrong in another. Erasing the contradictions does not produce a more accurate corpus; it produces a flat one that has lost the structure where the interesting questions live.

The alternative is to let the graph contain its own disagreements, mark them explicitly as edges of a different type, and treat the disagreement as a piece of structure rather than a defect to repair. Two nodes that contradict each other plus an edge that names the contradiction is more informative than either node alone. The reader can see the seam, walk both sides, and form their own view of which side held.

This is harder than enforcing consistency. It requires the writer to keep track of where their own positions have moved, to write nodes that point at superseded ones rather than overwriting them, and to resist the urge to clean up. The payoff is that the graph is honest about being a record of a thinker, not a finished encyclopedia. The reader who finds a contradiction has not found a bug; they have found exactly the spot where the writer is still working.


---

## The Quiet Protocol

slug: the-quiet-protocol
date: 2026-03-17
category: institutions
links: anti-mimesis, the-public-brain, the-permanent-url

Institutions run on protocols nobody wrote down. The visible rules are decoration; the protocol is the part that breaks when an outsider follows the rules literally.

Every institution has two layers. The first is the written rules: bylaws, org charts, codes of conduct, published procedures. These are the part anyone can read. The second is the unwritten protocol: which rules are enforced, in what order, with what tolerance, by whom, in response to what. The protocol is what the institution actually runs on.

The written rules and the protocol are not the same. They overlap, but the overlap is rough. Many rules are enforced inconsistently or not at all. Many protocol behaviours have no written backing. New members of the institution learn the rules in onboarding and the protocol by being corrected when they apply the rules in the wrong way at the wrong time.

This structure has a use: it lets the institution adapt. The written rules change slowly because writing them down requires consensus. The protocol changes at the speed of conversation between the people who actually run the place. An institution with only written rules would either ossify or reform constantly; the protocol is the shock absorber that lets the rules be slow.

The failure mode is that the protocol is invisible. Anyone trying to understand the institution from outside reads the rules, follows them, and finds that nothing they expected to happen does. They conclude that the institution is broken or hostile. Often it is neither; it is running its protocol, which the rules did not describe.

The operator's task is to make the protocol partially legible without writing it down — because writing it down would lock it in place, and the protocol's value is its mutability. This is a hard interface problem. Most institutions never solve it, and the asymmetry between insiders and outsiders that results is the institution's actual cost of doing business.


---

## The Attention Tax

slug: the-attention-tax
date: 2026-03-12
category: strategy
links: the-public-brain, the-stopping-discipline, anti-mimesis

Every interface charges a tax in attention. The tax is invisible to the operator and obvious to the visitor — and the gap between the two is where most products quietly fail.

Every element on a screen costs the viewer some attention to process and dismiss. The cost per element is small. The total over a typical interface is not. Most products are designed by operators who are blind to this tax because they have already paid it — they know which elements to ignore, which menus are decorative, which notifications can be left unread. The visitor has not paid the tax yet and is forced to pay it on every page.

The tax is invisible to the operator because it is below the threshold at which any single decision feels expensive. "Add a banner here." "Surface this metric." "Add a filter for that case." Each is reasonable in isolation. The product is the sum, not any individual decision.

Visitors triage by leaving. They do not file a bug report against the banner. They do not write to say the filter you added last quarter is the reason they bounced. They simply leave faster, on average, with a slightly worse impression, none of which shows up in the metrics the operator is watching. The metrics show that the operator's recent changes did not reduce engagement, and the operator concludes that the changes were neutral or positive.

The correct lens is to track the attention cost of every surface as a real budget. Each new element has to be paid for by removing or compressing another. Total complexity stays flat or goes down with every release. This is brutal in a corporate environment because it makes every contributor's work feel like trade-offs against their colleagues' work, which it is.

Products that pull this off feel calm. The operator notices the calm and assumes it was the easy outcome. It was the result of every contributor agreeing to spend a budget that nobody told them existed.
