nextbuild.works

The doubts register

Where we might be wrong

The doubts we hold about our own method, each with what would settle it. A settled doubt is marked with what settled it and when. None is deleted.

We keep a written register of the doubts we hold about our own method. Each doubt says what would settle it, so it can be closed by evidence rather than by everyone getting used to it. When one is settled, we write down what settled it and when. None is deleted.

This page is that register, edited for a reader outside the project. Most of the doubts are also told in full on the piece they undermine. They are collected here because this is where a skeptical reader should be able to find the case against us.

10doubts recorded
1settled

Nine are still open. The one settled was settled by testimony, not a count, and it is at the bottom.

The agent wrote this

The document these practices come from was drafted by the agent, and 555 of the 593 changes to this project before 15 September 2026 were made in a session with it. The practices it recommends are exhaustive written context, one owner per fact, explicit done conditions, and decisions recorded with their reasoning. Those are, not coincidentally, the conditions under which an agent works best. Some of it may be the agent’s convenience dressed as principle, and the agent cannot tell from the inside which entries are true and which merely suit it.

What would settle it: the operator striking entries that cost more than they return, and entries proposed by someone other than the agent. If nothing is ever removed, that is evidence the register is not working, not evidence the document is right.

Where it stands: measured on 15 September 2026, no entry has ever been removed from the document. One claim inside an entry was withdrawn that day, “every clean run was bought by a failed one”, because checking it against the record for this site showed it was not true. That is a correction, not the test this doubt asks for.

Human teams forget too

Agile assumed human continuity is a clean line, and clean lines should be distrusted. Human teams also lose context: turnover, holidays, the person who knew leaving. If the difference between a team and an agent is one of degree rather than kind, none of this is new advice about agents. It is the old advice about writing things down, with the volume turned up because the forgetting is now total and constant. That would not make the practices wrong. It would make the framing wrong.

What would settle it: whether the same practices help a team with no agent in it just as much. If they do, the agent framing is decoration.

Where it stands: open. We have written this site as though that reading may be right. Every piece names the practice’s ancestor, because what changed is how total the forgetting is, not the practices.

A sample of one

Every dated incident on this site comes from one estate, run by one person with one model. That is a sample of one in every dimension that matters. Practices that look general may simply be the shape of this project.

What would settle it: a second project, ideally with a different operator. Practices that survive contact with it are real. Practices that quietly stop being mentioned were local.

Where it stands: open. A second estate built from this code is on our upcoming list. It would test the code with a second instance, but with the same operator and the same agent, so in our reading it would settle only part of this.

It may be about infrastructure, not agents

Defects are found by running, not by reading rests on instances that nearly all come from infrastructure: routers, firewalls, machines. That domain has an unusual number of interfaces between separately owned parts, each correct on its own. Application code with cheap rollback and fast tests may not behave this way. There, reading a diff may genuinely find most defects.

What would settle it: one project in a different domain. If faults between parts still dominate there, the lesson is about building with an agent. If they do not, it belongs in an infrastructure playbook.

Where it stands: open. Four of the five instances come from infrastructure, and one document-rendering bug is not enough to settle it.

Checking a rule has a cost we have not priced

Assert the rule says a rule nothing checks asserts nothing. But every checker is code that has to be maintained, and a checker nobody runs looks like enforcement and enforces nothing. Ours is run by hand. That works because one person runs it reliably. It is not obviously something that scales.

What would settle it: whether the checker is still being run in three months, and whether a second one ever earns its place.

Where it stands: measured on 15 September 2026 and not settled. It is still run by hand before every change, and it has gained two sections, each added after it passed clean on a failure it could not see. Whether that counts as a second checker earning its place is the operator’s call.

Deleting a row could delete one that would have paid

Ask what breaks if it stays is the only rule we hold that licenses destroying written work, and the rest of the project runs on the opposite instinct. A backlog row nobody can find a consequence for today is not the same as a row that has none. Two rows here looked like fussing before they paid. Deleted rows keep their full text in the log, which protects the information and not the attention: nobody rereads a log looking for work.

What would settle it: a later incident traced back to a deleted row.

Where it stands: open. Until then it is the least earned rule we hold, and we apply it only to the lowest-priority rows.

Labeling how a claim is known may not survive volume

An agent writes a guess and a measurement in the same confident prose, and by the time either reaches a file the reader cannot tell them apart. So every claim we write down says how it is known: measured, with the command and the date; decided, with the document that decided it; or reasoned, with when it gets checked. The rule was bought by two claims in one session on 8 September 2026. One was a decision quoted without the clause that made it temporary. The other was a sentence in a merged change that had been reasoned, never measured, and was false.

Both were caught within an hour, one by the operator and one by a check that already existed. That is a small sample under close supervision. If every second sentence carries a label, readers may learn to skim past them, the way a codebase dense with TODO comments stops meaning anything. And it has the same problem as a sample of one: one agent, one project.

What would settle it: an occasion where a label demonstrably stopped someone, agent or person, acting on an unverified claim. Or the reverse: labels visibly skipped, and the unverified claims trusted anyway.

Where it stands: open.

“Closed” may be too strict to use

A loop is closed by action, not by detection counts a loop as closed only once a signal has provably reached a person who acted. Then almost every loop is permanently open, and the word stops telling a healthy channel from a dead one. There is also no obvious way to measure the last step: an alert that arrives and is rightly judged “nothing to do” looks identical to one that was never read.

What would settle it: whether anyone can name a loop here that is closed by this standard. If none can, the rule is unfalsifiable and should be weakened to something checkable, such as requiring every detector to name who receives it and how that was tested.

Where it stands: open.

Two readers, one document, and nothing marks which

Our working document addresses two readers. Most of it tells the agent how to work. Some of it tells the operator how to keep an agent able to work. Only one entry says which reader it is for. A new operator could take a rule meant for the agent as a rule for themselves, and an agent could take on an editing job that belongs to the operator. Tagging every entry is the obvious fix, and it risks turning a short document into a taxonomy.

What would settle it: the first time a new operator is onboarded with the document. If they misread which entries are theirs, tag them. If they do not, leave it alone and close this doubt with a date.

Where it stands: open. The estate still has one operator.

Settled: parked items do come back

When we set work aside, we write down the event that brings it back, rather than a date. We doubted that this was anything more than a well-kept backlog. Every method says to write things down and revisit them, and the claim to anything new rested on that named event.

What would have settled it: whether parked items actually come back when their event happens, or pile up and are eventually read as history.

What settled it, on 15 September 2026: the operator’s observation, not a count.

Yes, parked items are constantly coming back. A parked item usually does carry weight.

We label it as testimony. Nobody tallied how many came back because their event happened, and the piece that tells it says what a count would still need to show.

How a doubt closes

A doubt closes when what settled it is written down, with the date. It is never deleted. If nothing on this page ever changes, that is not evidence we were right. It is evidence the register stopped working.