Skip to content

Insights / Systems & implementation

Merged is not shipped: the life of a claim

A claim moves through five states, from PROPOSED to LIVE. A merged change is not LIVE until someone sees it on the wire.

This is the second of three replies to Suraj Sharma's (@suraj_sharma14) list of agent projects. His first is a durable state machine. His reason: "while True chat loops die on server restarts."

When is a claim allowed to be said?

He's right. My agents run on a harness that handles that part for me. The state machine I spend more time on is a different one. It answers one question: when is a claim allowed to be said?

A claim is anything my system might say out loud. A fix is live. A number is right. A post is ready.

Five states

1. PROPOSED. Someone drafted it. Nothing more.

2. HELD. Ready or nearly ready. Waiting on a decision.

3. YES. I approved it. The record keeps my exact question, the option I picked, the time, the scope, and what was excluded. I can void it later. Corrections are added, never written over.

4. MERGED. The change is in the main branch.

5. LIVE. Served to real users now, and checked on the wire.

Work can sit at HELD for days and pick up where it left off.

Why MERGED is not SHIPPED

A merge changes a repo. Nobody outside sees it. So I keep four words apart: merged, shipped, served, used. A merged change is not LIVE until someone sees it on the wire.

My schedules follow the same rule. Scheduled is not run. Ran is not succeeded. Succeeded is not verified.

I hold myself to it too. I have a version of my release lane drafted on Cloudflare Workflows. It is a draft. It is not shipped.

LIVE isn't the end either. After served, there are four more rungs: fetched by a known agent, indexed, cited, used. Each rung needs its own evidence.

Typed absence

When a source fails, the answer is not 0. It is UNMEASURED or UNKNOWN, written as a state of its own. An unmeasured number never turns green by default. No silent zeroes.

Here is why it matters. On Oct 19 my own fleet review said my decision log stopped at decision 12. It didn't. The copy the tool returned had been cut off, with 62,301 bytes missing. The real log ran to decision 36.

"I didn't see it" is an observation, not a verdict. The review was corrected the same night.

Before anything goes public

Every public claim is checked against the exact version of the file that will be posted. If the file changes, the check runs again.

What I'd keep from this

  1. Give claims states, not yes-or-no flags.
  2. Keep merged, shipped, served and used as four separate words.
  3. Write unknown as unknown. Never as 0.
  4. Treat "missing" as something you saw, not something you proved.
  5. A merge doesn't close a task. Proof on the real boundary does.

Limits

One builder's system, with the states named as I use them on Oct 19, 2026.

What does your system write when a number is missing?

A merge doesn't close a task. Proof on the real boundary does.