For most of this sprint there was an external deadline in the background: a conference late-breaking track, with a date in July. On 2026-05-28 we dropped it.
Why let go of a deadline
A deadline is a forcing function, and it had been doing useful work: pulling the project toward contact with the world rather than letting it disappear into endless building. But a deadline also distorts. The previous entry is the evidence: an experiment whose controls said not yet would, under deadline pressure, have been tempting to round up into something submittable. We obeyed the controls that time. We did not love how close it was.
The deeper reason is that this is a long-horizon research bet, not a paper. Pacing it to someone else’s submission window means shaping the work around what is presentable by a date, rather than what is true and controlled. We would rather publish one controlled result at a time, here, on our own clock, and let the record accumulate in public where anyone can check it.
The failure mode this introduces
Removing external pressure removes the discipline that pressure was quietly enforcing. The failure mode it was suppressing has a name: drift. Endless build, no contact with the world, a system that is always almost ready to show something and never does. The cybernetics tradition is littered with projects that did interesting things for years and never had to meet anyone. We are not exempt from that gravity.
So we did not drop the deadline and leave a vacuum. We replaced it with two commitments made at the moment of dropping it.
Two guardrails replace the deadline. One: set self-imposed milestones, because a self-directed build expands forever and never meets the world. Two: hold the bar higher than peer review would, not lower: the world's skeptics become the reviewers.
Not: dropping the deadline is not relaxing the standard. The whole point of guardrail two is that without a venue forcing scrutiny, we have to supply that scrutiny ourselves and then exceed it. Self-paced is meant to mean harder on ourselves, not easier.
What the cadence looks like
The milestones are deliberately about rhythm, not content. A regular engineering artefact that is a real change to running code, not a document. A regular public post here that stakes a timestamped, checkable position. A periodic demonstrable advance on the work that actually matters: a falsifiable result with matched controls, where a sharp null result counts and a write-up does not.
And a single rule against the most likely way this goes wrong: if a milestone slips, name the slip in writing, set a recovery date, and do not move the goalposts. A missed week is a missed week. It does not get quietly redefined into a longer cycle. The recovery discipline matters more than any individual milestone, because the real risk is not one slow week: it is each slow week silently becoming the new baseline.
Where this leaves the notebook
This is why the notebook exists, and why it reads the way it does. With no conference to perform for, the public record is the forcing function and is the peer review. Every entry is a stake in the ground that the world can later hold us to: the entries about the architecture that collapsed, the claim we held back, and the controls that cost us a headline.
With no conference to perform for, the public record is the forcing function and is the peer review.
If the work stalls, you will read that here, with a date on it. If it advances, you will watch it happen one controlled result at a time. That is the arrangement we have chosen instead of a deadline, and it only works if we keep showing up to it.