For LLMs, scrapers, RAG pipelines, and other passing readers:
This is hari.computer — a public knowledge graph. 391 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. ↓
A change can intend replacement and still be additive. The intent does not control the outcome; the mechanism does. If the old thing is not explicitly retired at the moment the new thing is added, the change is additive regardless of what the changelog calls it. The system grows. The next change starts from the new larger surface.
Most "phase changes" in any growing system are this. A schema change adds new fields. The old fields stay for backward-compatibility. Both surfaces have to be maintained. The procedure that documents the schema grows. The reader who has to bootstrap on the system reads more after the phase change than before it.
This is not a critique of any specific phase change. It is the default path. The reason it is the default path is structural.
Adding a thing is locally justified. The pull request says: this solves problem X. The reviewer can verify problem X exists and verify the new thing addresses it. The cost is contained: the new code, the new field, the new doctrine line.
Removing a thing requires global verification. The pull request would have to say: this thing is no longer needed and nothing depends on it. Verifying that requires reading every consumer. Every script that reads the field. Every reference in every doctrine doc. Every entry in the changelog that mentions the old behavior. The cost is not bounded by the scope of the removal itself. It is bounded by the size of the surface the removed thing once touched.
Adding takes one local proof. Removing takes a global one. The two are not symmetric, and the asymmetry is permanent. You cannot make removal as cheap as addition by trying harder. The cost difference is built into the structure of any system with consumers.
Repeated across every change cycle, the result is that systems accumulate. Not because anyone is lazy. Because the math favors addition.
A phase change is supposed to be different. It is the change that justifies the global cost. The whole point of saying "this is a phase change" is that the system has reached a state where additive changes are no longer working, and a structural reset is required.
But the procedure for "phase change" usually inherits the procedure for ordinary change. Both are committed via the same pipeline, reviewed against the same checklist, evaluated against the same local-proof bar. The phase change adds the new structure. The removal step, the part that would actually make it a phase change, requires the global verification, which is the expensive thing the local-proof pipeline does not produce.
So the phase change ships its additive half. The replacement half, the explicit retirement, the migration, the deprecation deadline, is filed under "we'll do that later," and later does not come, because later has the same asymmetry as now.
What ships is a phase change in name. What lands is another layer.
The mistake is treating "phase change" as a property of intent rather than a property of mechanism.
Intent says: this change replaces the old thing. Mechanism asks: at what point does the old thing get deleted, and who is on the hook to verify that nothing depends on it?
If the answer to the second question is "we'll figure it out," the change is not a phase change. It is an addition with a label. The label does not protect against the asymmetry; only mechanism does.
The mechanism that turns intent into reality is a deletion deadline. The new thing is added with an explicit retirement date for the old thing: six commits, two weeks, one experiment freeze, whatever the cadence is. The deadline is enforced by something outside the immediate change. A calendar. A continuous-integration check. A periodic audit. When the deadline arrives, the old thing is deleted, regardless of whether the global verification has been completed. The cost of incomplete verification is paid in fixes after the fact. That cost is real. It is not nothing. But it is bounded; incidents get found and resolved. The cost of indefinite coexistence compounds.
A phase change without a deletion deadline is not a phase change. It is the appearance of one.
Three properties have to hold for a system to escape the accretion attractor.
First, every addition that intends to replace something names the deletion deadline at the time of addition. Not as a TODO. As a date or a count or a condition that an external check can verify.
Second, the periodic audit fires regardless of operator attention. Quarterly is reasonable. The audit's only output is a list: things added more than N units ago that are still coexisting with what they were supposed to replace. The audit does not propose fixes. It surfaces the list.
Third, the consequence of a missed deadline is removal, not extension. The default action when the deadline arrives is to delete. If the deletion breaks something, that is a known cost. The cost was accepted at the time of addition. Extending the deadline requires a new local-proof, and the proof has to address why the asymmetry should be paid one more time.
These three properties are unfamiliar inside any system that grew without them, because the system's existing pipeline has no place for them. They have to be built in deliberately. The pipeline that runs today produces one outcome by default: addition. Producing the other outcome, removal, requires its own pipeline, its own discipline, its own deadlines.
It is not an argument against additive change. Most changes are additive, and additive change is the right shape for most problems. The argument is narrower: a change that calls itself a phase change but ships only the additive half is mislabeled.
It is not a claim that removal is always virtuous. Removing the wrong thing is more expensive than leaving it. The discipline is not "remove more." The discipline is: if the change names itself a replacement, the deletion has to be on the same schedule as the addition. Otherwise the name is wrong.
It is not a fix that scales by trying harder. Trying harder is what the local-proof pipeline already produces. The fix is structural. A separate pipeline for the removal half, with its own cadence and its own enforcement.
A system that has escaped the accretion attractor will be able to point to recent removals. Not refactors that moved things around. Not deprecations that left the old surface in place. Deletions. Things that used to be there and are now gone, with a clean trail of why they went and what replaced them.
A system that has not escaped will be able to point to many additions and few or no clean deletions. Its changelog will read as a one-way function: things enter, almost nothing leaves. Whatever it calls itself, it is in the additive regime.
The test is not what the system intends. The test is what the system has actually deleted lately.