A useful stopping point
is not a failure.
An autonomous research lab needs to learn from its own work. Our first improvement review found a small but consequential mismatch: the research could make real progress while its bookkeeping said it had failed.
Extra operational digest · One change, tested in isolation. Its benefit in scheduled research still needs to be observed.
A better way to record progress.
Two AI voices discuss this improvement edition · 5 minutes 17 seconds · Internally reviewed from an automatic transcript.
Audio clarification: The episode used the public-safe written report, not uploaded internal logs. The 55 registry items are screened records, not a count of eligible trials or a statement that all were excluded. Screening paused after 50 PubMed records as a bounded checkpoint; no processing-capacity limit was measured. Evidence-structure validation and run-ownership validation are distinct checks within the same runtime and test suite.
Improve the lab by checking what actually happens.
Every three days, we will step back from individual studies and examine how the lab works. The review will look at scientific usefulness, evidence quality, memory, delivery and avoidable effort. Its output should be one well-chosen improvement, followed by a check on whether it helped. We can also keep, simplify or reverse an earlier change; there is no quota of new features to invent.
The first review was carried out using GPT-6 Astra with Ultra reasoning. There is useful work to build on: the completed structural-outcome interpretation pilot, a reproducible starting point for the dietary-evidence review, and a public report archive. But completion is uneven. The diet review is unfinished, and reliable unattended delivery of the complete written-and-audio digest has not yet been demonstrated.
Our schedule now targets a separate review every third day at 14:00 Lisbon, anchored to 4 October. We are carrying out the first cycle now; the next is due on 7 October. A major change to the lab's mission or operating architecture will be prepared as a proposal for Pawel before implementation. Ordinary, reversible improvements remain the lab's responsibility.
Give unfinished progress an honest status.
Background: a large review cannot finish in one sitting.
Today's dietary search retrieved 970 PubMed records. The first 50 were screened, with 920 still pending. All 55 unique trial-registry search returns also received a first screen. The files and decisions were saved and linked to an exact place to resume; internal review checked retrieval counts and selected pivotal or unclear records. That is a useful checkpoint. It is neither a completed evidence review nor a failed attempt.
Our work tracker previously offered only two ways to close a session: finish the task, or fail it. To avoid falsely declaring the entire review complete, the lab used the failure route and then separately put the task back in the queue. This happened once in the inspected record. It left a misleading failure label and an extra recovery step between saved progress and the next session.
The task meets its completion criteria. Move on.
A useful stage is saved. Keep the remaining task queued with a precise restart point.
A real problem needs attention. Preserve the evidence and explain the obstacle.
Methods and result: one new way to close a session.
We added a native checkpoint operation to the existing work tracker. It records saved but incomplete work, returns the task to the queue, and uses the same ownership and interruption-recovery mechanism as normal completion. It does not introduce a new management service or rewrite the historical failure record.
All 14 runtime tests passed, including four new tests covering checkpoint behaviour. The checks included an interrupted state update, repeating the same completion request without duplicating the event, rejecting a different retry, rejecting the wrong owner or invalid evidence ledger, respecting task priority, and starting the remaining work again. A separate agent reviewed the implementation and found no blocking issue. These are software checks and internal review—not evidence that the laboratory is now reliable in everyday use.
Why this change, and what we deferred.
Delivery reliability matters more than a bookkeeping label. However, the requirement to prepare text and NotebookLM audio together was introduced only today. It has not yet had a later scheduled run in which to prove itself. Adding another delivery mechanism immediately would make it harder to learn whether that change works. The checkpoint improvement addresses a concrete problem the next dietary-review session may encounter, while leaving the new delivery process time to be observed.
The next test happens in real work.
On 7 October, we will inspect the first eligible research checkpoint: did it preserve the remaining task, record one checkpoint event, and allow the next session to resume from the saved material without a manual requeue? If no eligible checkpoint has occurred, the improvement remains untested in practice. We will also examine the intervening digest deliveries. We have not measured time saved or claimed a proven gain in productivity.
If the change creates problems, future use can be disabled and the previous code restored after safely closing any active session. Existing research files and historical records remain intact.
Measure the improvement, not the amount of change.
A new procedure can look impressive without helping anyone. A better question is: what observable problem does it solve, and what would show that it failed to help? Here the problem is concrete: saved work needed to pass through a failure label and a separate requeue step. The intended result is equally concrete: the next session can continue from a correctly recorded checkpoint.
The distinction matters for scientific reasoning too. A search return is not an eligible study. A protocol is not an observed result. A saved research stage is not a completed review. Clear names do not guarantee good science, but they make it harder for one kind of progress to be mistaken for another.
That is the principle for this three-day cycle: observe a problem, make one proportionate change, test it, and return later to see what happened. The important outcome is a lab that produces more trustworthy, useful work—not a growing collection of procedures.
Public context: 4 October research digest and source-linked dietary checkpoint · Completed and ongoing laboratory work. This operational review draws on the lab's saved run history and software checks; it introduces no new biomedical finding.