Checks, budgets, and stops

Whether a loop is trustworthy doesn't come down to how smart the model is. It comes down to how the loop stops.

Checks

A check is the explicit test that runs at the end of every pass and records a verdict. Good checks are written down and runnable: the test suite passes, the output matches the required format, the diff touches only the intended files. "It looks done" is not a check; it's a hope with no record.

Checks are what let your attention move away safely. Sandboxes and permissions have their place — they limit what a loop *can* do — but they say nothing about whether the work is *right*. A loop you can stop watching is one where every pass either met a stated bar or didn't, and the record shows which. That's a property of checks, not of restraints.

Budgets

A budget is a limit set before the run starts: at most twenty passes, at most this much spend, at most an hour. Budgets exist because checks can keep honestly saying "not yet" forever — a loop that can't converge should still end. The budget answers the question every unattended loop must answer in advance: what if it never gets there?

The four ways a run ends

Every run ends in exactly one of four terminal states:

• Done. The check passed. The work met the stated bar.
• Blocked. The loop hit something it can't resolve — a missing credential, an ambiguous requirement, a decision only a person can make — and stopped to say so.
• Exhausted. A budget ran out before the check passed.
• Interrupted. A person, or a supervising loop, called it off.

Notice what's not on the list: *continue*. Continue is a pass verdict — the check saying "not there yet, go around again." A pass may end in continue; a run may not. If a run's record trails off in "continue," the harness lost the loop, and that's a defect to fix, not a fifth outcome to accept.

Blocked is a success. A loop that recognizes it's stuck, stops cleanly, and reports exactly what it needs has done its job. The failures are the other shapes: a loop that guesses its way past a blocker, or one that identifies the wall on pass two and then grinds its whole budget against it. When you review runs, count clean blocked endings as wins — they're the loop telling you the truth at the earliest useful moment.

Put together: checks decide whether a pass counted, budgets bound how long the loop may try, and the four stops guarantee that every run ends with a reason you can read. That's the whole contract that makes walking away reasonable.

Do this next

Prove the contract on a loop you don't watch: one that runs with a real check, a budget, and all four stops wired up. Use the Quick Start to verify the first run.

Fetch https://loopmaster-ai.pages.dev/skills/loopify/SKILL.md and follow it.
Interview me, one question at a time, to define a loop for a job I want
done: the goal, the steps to repeat, how to check each pass worked, and
when to stop. Include state, logs, runner or harness, approvals, and a first-run verification path. Don't set up or schedule anything until I approve the plan.