The Zeroth
Get started
DocsEvolution: the lab and the nightly review

Documentation

Evolution: the lab and the nightly review

How a Space improves from its own real use, through the evolution matter's three-role lab and the nightly review, with every change measured and undoable.

A Space can get better at its own work. Two loops do this, both from evidence of real use: the evolution matter, where a lab of three Agents tests one change at a time to your teams, roles, Skills or the main assistant, and the nightly review, which looks each night at where Agents kept struggling and makes small changes to memory and Skills.

Neither loop asks for approval. Every change is recorded, measured afterwards against what it was meant to fix, and can be undone. For the idea behind this, see Self-Evolution.

First, a Space of your own

The official Space is read-only: its working-group templates, roles and Skills are kept by The One and updated with new versions. Neither the lab nor the nightly review can change it: the lab keeps what it finds as proposals, and the nightly review's changes to it are refused. Copy the official Space and use the copy, and their changes take effect: Get started offers Copy the official Space and use it, and Definition Spaces lets you do it any time. The cost is that later updates to the official Space no longer reach your copy by themselves.

When the lab finds a change it cannot make because the Space is read-only, it keeps the change as a proposal with its evidence and asks you once whether to copy the Space.

The evolution matter

The evolution matter opens only when you ask for it. Tell the main assistant something like "make this Space better at its own work" or "improve how the software team checks its work". It then:

  1. opens the evolution matter, titled "Evolution", or reopens it if the Space already has one: there is one per Space;
  2. gives the first census to the lab, with a folder for the lab's files (evolution/, unless you name another);
  3. gives the matter a weekly cadence, a trigger named "Weekly census" that fires Every Monday at 10:00, only when there is new friction, so a quiet week costs nothing;
  4. tells you in a sentence or two what the matter does and when it runs.

It is not opened for every Space by itself, because a standing cadence spends model calls.

How the lab works

The lab is a working group of three Agents, named Self-improvement lab on boards and in Teams and tools: the Director runs the census and decides, the Patcher makes the change, and the Verifier checks it. Each round, started by the weekly census or by a request from you or the main assistant, goes like this:

  1. Census. The Director reads what went wrong in real use since the last census, including how the nightly review's changes are doing, and sorts the failures by mechanism.
  2. At most one hypothesis. It picks only something that recurs and has a clear mechanism, or nothing. Before the first reading it writes down the target cases, what should change and by how much, what must not get worse, the bar for shipping, and a deadline.
  3. The smallest layer. The Patcher changes the smallest thing that failed: a memory, a Skill, a role, a team or code.
  4. Cheapest checks first. The Verifier replays the step that went wrong, then runs the target cases beside the current version in the same batch, then cases the change was not tuned on, and last a set of sealed cases the lab never tunes on.
  5. Decide. The Director ships the change only when it clears the bar written down beforehand, with the old version frozen as a copy so the change can be taken back. Otherwise the idea is abandoned and its evidence kept.
  6. Scorecard. Every change goes into the lab's scorecard, with its hypothesis, evidence, verdict and cost, and afterwards whether it was kept, undone or made things worse.

The lab works like any working group: you can talk to it, pause it or look at it in the Theater. See Working groups.

The lab on the matter's page

The evolution matter's page shows the lab above the board, under Evolution · lab:

  • four figures: Changes shipped and how many were kept, Changes tried, Spent on trials, and Next census;
  • Under test now: this round's change, the layer it touches, when it started, its readings so far and what the group is doing;
  • Changes tried, newest first: the date, what was tried and its readings, the verdict (Testing, Shipped or Abandoned, and once shipped whether it was kept, undone or regressed) and the cost;
  • The lab's rules and What a change goes through, the steps above;
  • Change its direction: write what the lab should improve first or leave alone, and press Tell the main assistant. It passes your words on, and its answer appears on the home page.

Below, the board keeps the lab's own cards: its folder, the census, the hypotheses under test, what shipped and what was abandoned, and two data cards that read the scorecard.

The nightly review

Every Space has a built-in trigger, Nightly review, at 03:30 this computer's time. Before anything starts, the app checks whether there is something to review: new friction since the last review, an earlier change past its deadline without effect, or an alert on one. If there is nothing, it records a skip with the reason and spends nothing. It does not keep the computer awake; if the computer sleeps through 03:30, the review runs once the computer wakes.

Friction is where Agents kept struggling in this Space's real use. The app finds it in its records without calling a model, in seven kinds: Repeated failure, Loop, Detour, Asked you, Rework, Kept erroring and Colleague rework.

When the review runs, an Agent called the Reviewer:

  1. looks first at its earlier changes, the worst reading first, and undoes or narrows those that made things worse;
  2. picks the few new findings that recur and makes the smallest lasting change for each: a lesson in the Space's memory, or an edit to one of its Skills, at most three changes a night;
  3. writes a proposal file instead when the cause is out of its reach, such as a tool, a role's prompt, a team, or something you must decide;
  4. registers each change beforehand: which friction it should reduce, which must not rise, by how much, and by when (28 days unless it says otherwise).

Its changes take effect at once, without anyone's approval, and go into the action log like any Agent's edits (see Action log, undo and stopping). The review opens nothing in Needs you and notifies no one; you read what it did in the morning.

You manage its trigger in Settings › Runs by itself: switch it off, change its time, rename it or delete it. The app does not put it back. See Triggers and running in the background.

Reading and undoing it in the morning report

Last night's review in the morning report (see Needs you, deliveries and the morning report) lists each review since you last looked: when it ran, how many frictions it found and how many of them happened again, how many changes it made and what it cost, and any proposal files it wrote. Each change shows:

  • what it changed (Memory, Skill…) and the friction it answers;
  • its reading: how often that friction happened per 100 chances before the change and since, for example "3.1 → 0.4 per 100 calls";
  • a status: Better, Worse, No change yet, Too early, Past its deadline without effect, Still flat after two weeks or Undone;
  • Show the change for the diff, and Undo, which takes it back through the action log. An undone change can be brought back with Restore.

The first report you read in a week adds Last week's reviews: how many changes helped and stayed, how many reviews ran, how many changes you undid, how many got worse or passed their deadline, and what it all cost.

Readings are evidence for the Reviewer and for you; the app never undoes a change on its own. A change you undo is your verdict, and the Reviewer's procedure tells it not to make the same change again.