How I keep a build record.

When I build something with AI agents, I want a record I can return to after the conversation has gone cold. What was the job? Why did we choose this direction? What did we actually check? What is still open?

The record gives those questions a place to live. It also gives the next person enough context to challenge a claim or pick up the work.

Start with the work

I write down the job and its constraints before judging the output. Who needs to use it? What has to survive a restart? What is it allowed to change? What would make me hold a release?

The answers determine the checks. A household display, a learning library and a reporting exercise need different evidence. Each record should say which job its evidence covers.

Give alternatives a reason

BuryBoard had several complete visual directions. Pillow Fort won the daytime vote, and Lantern Lane was chosen separately for nighttime. We kept both because they fit different moments in the house.

That decision belongs in the record. It explains why the result looks the way it does and why a rejected direction may still contain something useful. I use alternatives when they help judge a meaningful choice; the number depends on the decision.

Write the gate before accepting the result

Berry’s held-out semantic evaluation found the expected evidence in its top five results on 102 of 120 supported probes, or 85%. The proposed gate was 95%. Context handling also missed its gate, so automatic semantic answers stayed disabled.

The released reader could still suggest reviewed questions and open reviewed passages. The record keeps that distinction visible. A retrieval result on those probes does not establish overall answer accuracy or child safety.

Check what changed

In Family TV, a script moved silent shows, then ended before the control room saved the changes. The shows came back. A second agent found the problem while writing the operations guide. The fix saved the change on purpose and read it back.

That is a useful failure record: what went wrong, how it was found, what changed, and how to check the change. It also tells the next crew why reading back saved state matters.

I use plain code for checks with a definite answer, then give review a specific question. An independent reviewer needs the relevant evidence and a clear scope. When review raises a concern, I check that concern against the source or running behavior and record the decision.

Keep the human decision visible

Some questions still need the person who will use the thing. BuryBoard’s day and night choices came from the family. Berry’s record keeps hands-on child navigation and narration observations open. Family TV’s published record leaves the family-use verdict open.

A record can say that a software check passed and human acceptance is pending. It should name both, along with the build, device or setup the check actually covered.

Leave enough to hand it over

The last part is operation: how to tell whether it is working, what to try when it fails, and who is allowed to make the change. Add the evidence links, the collaborators and asset credits, and anything that must stay private.

Keep the record small enough to update when the work changes. Preserve the original publication date. Change the record date when the explanation meaningfully changes, and keep the date of an actual check separate.

Use the build record template →

These examples come from the public build records linked beside this note. Their checks apply to the dated builds and conditions described there. This note adds no fresh application, device or family-use test.