Five loops of our own

In this chapter, we will read five ledgers from projects behind this shelf, each improved by a loop built from program.md. Every number is from the project's own results file or README, and the two ledgers on this machine are quoted row by row. The interactive is the site loop's score, at the real values of its first row, so you can see why its first keep was the one it was.

HanuDB: a database

The engine that stores this shelf's accounts was tuned by the loop before anything else here was. HanuDB is a document database for one small virtual machine whose durable home is a cloud bucket. The site's own program file says it adapted program.md to a website the same way the database's program had adapted it to a database. From the HanuDB README, as the project inventory of 6 October 2026 quotes it:

experiments        "tuned through 108 controlled experiments"
benchmark score    12,273 to 40,116 on the one-core harness
throughput         writes 34,800 per second, reads 46,000 per second
soak               ten-minute soaks write 14 M documents on a 768 MB container with zero errors
recovery           a 4.5 GB snapshot plus tail rebuilds in 40 s

The metric was a benchmark score on a fixed harness; the editable surface was the engine; the ledger is the project's results.tsv with one patch and one log per kept run. The database is open source, so the ledger can be read.

hanumemAI: a memory layer

The memory layer in the memory book on this shelf was tuned the same way, and its book has a chapter on what the experiments taught. Its results file has about 160 logged runs. The numbers it reports, each with the judge model and the context size per question, from its status file:

LoCoMo, 1,540 questions       96.1 at 1,533 context tokens per question
LongMemEval-S, 500 questions  94.0 at 2,428 tokens
BEAM-1M, 700 questions        68.5 rubric mean, 73.4 pass rate, at 2,716 tokens

The same file states where it is not first: others report 96.2 and 95.6 on LongMemEval-S. A ledger that records where it loses is a ledger you can trust where it wins. The memory book's chapter What 121 experiments taught us walks through the runs.

The voice cloner: a recipe

Seventy-four experiments, eighteen kept, fifty discarded, six crashed, across three versions of the harness. The question was how close open-weights models can get to cloning a voice on a Mac. The editable file is experiment.py, one recipe: which model, how the reference clip is prepared, which sampling settings. The harness is read-only and measures speaker similarity, word error rate, output quality and speed. Chapter 3 told the story of its three harness versions. Here is how a night reads in its ledger, four consecutive rows from 2 October, the discards with their reasons in the description, as the program requires:

run              clone_score  sim_norm  wer    dnsmos  rtf   status   description
20261002-180550  97.8         0.985     0.007  3.34    0.47  keep     voxcpm 1.5 (mps), prompt mode (ref wav + whisper ref text), cfg 2.0, 10 steps
20261002-180824  96.0         0.969     0.009  3.36    0.92  discard  qwen3-tts 0.6B base (mps fp32), default sampling, ref wav + whisper ref text [worse score: 96.0 vs 97.8]
20261002-181151  99.2         1.001     0.009  3.31    0.91  keep     voxcpm2 (mps), prompt mode, cfg 2.0, 10 steps (sim at ceiling; rtf 2x of voxcpm1.5)
20261002-181546  93.9         0.948     0.009  3.40    1.23  discard  qwen3-tts 1.7B base (mps fp32), default sampling [worse score: 93.9 vs 99.2]

rows        74
keep        18
discard     50
crash        6
keep rate   18 / 74 = 24.3%
best        84.9 on harness v3, the only version whose rows are comparable with each other

Two things this ledger does that program.md's does not. Every discard says why, in brackets, with the two numbers. And every row carries a harness tag once the harness changed. Both were added by the human after the first night.

The voice twin: a smaller night

Twenty-eight experiments, three kept. The project builds a "twin" from a twelve-question voice interview: a model of how a person answers, a cloned voice, a real-time agent that answers as them. The metric is a fidelity score against a benchmark of simulated people. From its README: fidelity 77.5 on 12 simulated people, about 86% of how consistently a person agrees with themselves, at $0.87 per benchmark run. The README also says plainly that the people are language-model role-plays and that no real person has used it yet. Three keeps in twenty-eight is a hard metric and a young recipe, and the loop paused on 4 October with the benchmark of real people still unrun.

This website: a loop on a schedule

madhudream.dev is improved by a loop that runs every night at 01:30 with a budget, and its ledger has 47 rows. Its program names its ancestry in the first paragraph and ends the same way program.md does: "The human is asleep. Never stop. Never ask." The metric is a score printed by a check script in one to two minutes: a geometric mean of sub-scores for routes, links, retrieval quality, coverage, speed, recall cards and accessibility, with privacy leaks, the build and the routes as hard gates.

id    score  routes   links      mrr10  coverage speed recall_cov a11y   privacy_leaks status  description
0001  73.96  237/237  4252/4252  0.912  100.0    92.4  70.7       20.3   0             keep    baseline: lab landing, preprint papers, lab notebooks, blog essays, ...
0002  92.87  237/237  4252/4252  0.912  100.0    92.4  70.7       100.0  0             keep    a11y: label the chapter and essay one-sentence fields; drop the ...
0003  96.35  237/237  4252/4252  0.912  100.0    92.4  91.5       100.0  0             keep    recall: cards from essay conclusions and summaries (122) and ...
0042  95.68  183/183  3058/3058  0.912  100.0    92.9  (retired)  100.0  0             keep    the word-by-word review of every public page (owner): two notebooks ...

rows        47
keep        40
discard      7
score       73.96 at the baseline, 95.68 at the last row
first keep  a11y 20.3 to 100.0 took the score from 73.96 to 92.87

Why did labelling form fields and fixing headings move the score by nineteen points? Because the score is a geometric mean, and a geometric mean is dragged down by its weakest term. Here are the seven sub-scores at the real values of row 0001. Before you move anything, guess what the score becomes if accessibility goes to 100 and nothing else changes.

Two more things to notice in this ledger. The last row's score is lower than the rows before it, and it is a keep: the owner removed pages during a review, the route count fell from 210 to 183, and the description carries the tag "(owner)". The human's own changes go through the same ledger as the agent's, so the morning reader sees one history. And this loop runs on a timer, not a prompt: a scheduled job starts it at 01:30 with a budget in dollars and minutes and a cap on experiments, then stages the result as a revision that gets no visitors until the owner promotes it. A loop that can deploy needs that last fence more than any other.

What the five have in common

                   editable surface      sealed scale                      the hard part
HanuDB             the engine            a one-core benchmark harness      making the harness stable
hanumemAI          the memory library    three public benchmarks, a judge  naming the judge and the tokens
voice cloner       experiment.py         harness.py, three versions        a scale that stopped saturating
voice twin         the twin's recipe     a fidelity benchmark              people that are not yet real
this website       src/                  check.sh, score plus gates        a gate for taste no script runs

In every case the loop's first real work was the scale. The recipe improved only as fast as the harness could tell the truth about it.

Try it yourself

Open any of the two ledgers quoted here in full (the site's and the cloner's are in their repositories) and read the discards only. Count how many name a reason. Then count how many you could have predicted from the rows before them. That second number is what a ledger is for.

Common questions

Did all five loops run the identical program?

No. Each program names program.md as its source and changes the file names, the command, the grep and the keep rules. The database's program came first; the site's says it followed the database's. The loop is the same nine steps; the fences differ.

Why does the site loop keep so much?

Because most of its experiments add something, a page or a section, and the score mainly checks that the addition is sound: routes answer, links resolve, pages are fast and accessible. A loop that tunes a number discards most tries; a loop that builds keeps most.

Can the agent deploy the site on its own?

It stages a revision that gets no visitors. Sending visitors to it is the owner's command. That fence is in the deploy script, not in the agent's instructions, which is where a fence like that belongs.

Where are the ledgers?

HanuDB's is public with the database. The cloner's and the site's are in their repositories, and the cloner's README regenerates its results table from the ledger. The memory layer's counts are published; its row-by-row log is not.

Carry this

• Five loops, one shape: an editable surface, a sealed scale, a ledger, keep or discard, never stop.
• The cloner: 74 runs, 18 kept, three harness versions, every discard with its reason.
• The site: 47 rows, 40 kept, 73.96 to 95.68, and the first keep was the weakest sub-score.
• A geometric mean rewards fixing the worst term first.
• In every loop the scale was the hard part, and the human's changes to it are tagged in the ledger.

Check yourself

1. Why did the site's first kept experiment move the score by nineteen points?

Answer

The score is a geometric mean of seven sub-scores and accessibility was 20.3; raising the weakest term to 100 lifts a geometric mean far more than raising any other term.

2. What do the cloner's discard rows carry that program.md's example does not?

Answer

The reason in brackets with the two scores compared, and a harness-version tag once the harness changed.

3. What fence keeps a loop that can deploy from reaching visitors on its own?

Answer

It can only stage a revision with no traffic; promoting it is a separate command the owner runs.