Long-running work drifts away from the evidence it started with, and the drift is invisible from inside because every individual step looked reasonable. This sets out the problem I have spent my time on, what makes it hard, and why the implementation is withheld — which is a claim about intellectual property rather than a claim about the work.
Two signals that are not the same
How confident a claim sounds and how correct it is are different measurements.
In ordinary conversation they correlate well enough that nobody separates them. A person who is unsure tends to sound unsure, and treating the sound as the substance is a reasonable shortcut most of the time.
Over a long piece of technical work the two come apart. Nothing announces it when they do. The register stays the same while the relationship to evidence quietly changes, which is precisely why the shortcut keeps being applied after it has stopped working.
How a project drifts
A claim gets made. It is plausible. Checking it would cost a day, and it is almost certainly fine.
Work is built on it. More work is built on that. Some of it is good, and the fact that it is good is part of the problem, because working software is taken as evidence that the ground under it was sound.
By the time somebody asks, the question is no longer about one claim. It costs whatever has been built since, which is why it does not get asked.
And no single step was careless. There is no moment at which anyone did the wrong thing, which is the entire difficulty — the failure has no author to correct.
Why the usual controls do not catch it
Review, documentation and tests all compare the work against what was recorded.
The unchecked claim is in the record. It was written down early, in good faith, and it has been the reference point ever since.
So a test confirms the code does what the specification says. It is silent on whether the specification rested on anything anybody established. The system becomes internally consistent at the same rate it becomes detached, and consistency is what the controls are looking for.
Three things that would have to hold
These are the three concerns of the Linear Anti-Hallucination Protocol, which is in development. What follows states what would have to be true. It does not describe how any of it is done.
Evidence gating. Recording a claim that has not been checked should cost more than recording one that has. Not be discouraged — cost more, in a way that does not depend on the recorder's mood.
Intention preservation. What the work was for should remain available and unedited at the point where a decision is being taken, so that a project cannot slowly redefine its own objective into whatever it turned out to produce.
Drift detection. The distance between what is currently being asserted and what was actually established should be observable while it is still small, rather than reconstructible afterwards.
Three requirements. Whether they are the right three is a question I would genuinely like answered, and it is answerable without seeing any of my code.
The lesson that cost the most
A rule that can be talked around is not a control.
Enforcement that depends on somebody choosing to comply stops applying at exactly the moment it is needed, because the moment it is needed is the moment complying is inconvenient. A policy that yields to pressure has its coverage defined by the absence of pressure.
If I had to discard everything else here, I would keep that sentence. It is the one that changed what I built rather than what I believed.
Why the implementation is not here
The problem statement is public. The implementation is withheld pending intellectual-property review.
That is a statement about ownership and nothing else. It is not a hint, it is not a stage in a launch, and there is no list to join.
A reader is entitled to discount a claim they cannot inspect. I would discount it too — that is the correct response to an undisclosed assertion, and I have argued elsewhere that the absence of a checkable statement is itself information.
Publishing the problem while withholding the answer is the honest shape of that position. The alternative is publishing neither, or publishing a description of a mechanism nobody can verify and everybody is invited to admire.
What can be checked in the meantime
Whether the problem as described occurs in your own work. Most long projects I have seen have at least one load-bearing claim nobody has revisited, and the useful exercise is finding yours rather than agreeing with me about mine.
Whether the three requirements are the right ones, or whether there is a fourth that matters more.
And whether the reasoning above holds independently of who wrote it, which is the standard I would want applied.
Disagreement about the problem is welcome and is the part that is actually public.
Close
A problem stated precisely is worth something before anybody has solved it, because it says what would count as a solution.
That is a lower claim than the one usually made at this point, and it is the one I can support.