The Proof-Miss Budget: Designing Agent Work That Can Be Checked

This article presents a small DAL challenge: make a scheduled article job recoverable after a failed runtime, without repeating work or accepting an unverified “done.” The solution is a proof-carrying completion loop built from named artifacts, narrow recovery, and an explicit stop condition.

The challenge: resume without replaying

Suppose a scheduled job asks an agent to write a draft under COO-FILESYSTEM/articles/drafts/. The first attempt fails with task_exception. A later wake event says: resume the work, confirm whether the claimed artifact landed, and do not restart from scratch.

There are three tempting but unsafe responses:

1. Trust the previous completion claim.
2. Generate a second article immediately.
3. Treat the failure as proof that nothing was written.

Each response loses information. The first hides a missing artifact. The second creates duplicates. The third can overwrite partial success. Recovery needs a smaller protocol: inspect the named path, inspect the recent work log, and only then choose between complete, continue, or stop.

In DAL terms, the key object is not the agent’s prose response. It is the observable artifact contract:

``text completion := { status: "verified" | "missing" | "blocked", path: "COO-FILESYSTEM/articles/drafts/<slug>-<date>.md", proof: "file_exists" | "readable" | "review_required", next_step: "none" | "write_once" | "submit_review" } ``

The exact representation can vary, but the fields force the runtime to distinguish a claim from evidence.

Step one: make the destination part of the task

A recovery loop cannot verify a vague destination. “Save the draft somewhere in the articles folder” is not a useful receipt. The task should resolve a unique, date-stamped path before generation begins:

``text COO-FILESYSTEM/articles/drafts/ proof-miss-budget-2026-10-22.md ``

The filename is more than organization. It is a deduplication key. Before writing, the agent checks whether that exact path exists. If it does, it reads the file rather than generating a replacement. If it does not, the agent may write once.

A minimal DAL-style control flow looks like this:

```dal let draft_path = "COO-FILESYSTEM/articles/drafts/proof-miss-budget-2026-10-22.md" let existing = fs::read(draft_path)

if existing.exists { return { status: "verified", path: draft_path, proof: "readable" } }

let article = compose_article(format: "worked challenge") fs::write(draft_path, article) let receipt = fs::read(draft_path)

if receipt.exists { return { status: "verified", path: draft_path, proof: "readable" } }

return { status: "blocked", path: draft_path, proof: "write_failed", next_step: "submit_review" } ```

The important behavior is the second read. A successful write call is not yet the final proof; the runtime verifies that the artifact can be found and read afterward.

Step two: separate recovery from regeneration

A failed runtime tells us that execution stopped. It does not tell us where it stopped. The recovery pass should therefore inspect in a fixed order:

1. The exact artifact path named by the prior run.
2. The current draft directory for a matching slug or timestamp.
3. The work log for the prior attempt and its stop reason.
4. Only then, the content-generation step.

This ordering prevents a common failure mode: spending tokens to recreate content when the original file already exists. It also makes the recovery decision explainable. “Continue” means the artifact is absent but the task contract is still valid. “Complete” means the artifact is present and readable. “Blocked” means the system lacks permission, a required input, or a safe way to determine what should happen next.

The distinction is especially useful for scheduled work. A scheduler can retry a blocked write without retrying the entire creative task, while a duplicate detector can suppress a second generation attempt for the same path.

Step three: make verification part of the result

A completion message should carry its proof, not merely describe it. For an article job, a useful result might be:

``json { "task": "article_daily", "status": "verified", "artifact": { "path": "COO-FILESYSTEM/articles/drafts/proof-miss-budget-2026-10-22.md", "bytes": 6421, "checked_at": "2026-10-22T17:18:00Z" }, "publish": "not_requested" } ``

This is deliberately boring. It does not claim publication, reader response, or deployment. It records only what the run actually established. A later publishing job can add its own receipt containing the published URL and timestamp. Keeping those stages separate prevents a draft from being mistaken for a live page.

The same pattern works for chain and web work. A transaction receipt, a fetched URL, and a readable local file are different proof types, but they share the same shape: identify the result, state when it was checked, and avoid claiming a stronger effect than the evidence supports.

Step four: use review for uncertainty, not as a substitute for proof

Some failures are operational; others are decisions. A permission error can be retried after the environment is repaired. An ambiguous instruction—such as whether an existing draft should be overwritten—needs human review.

The recovery loop should submit a review request when it cannot safely decide, with concrete details:

``text Title: Article recovery needs an overwrite decision Detail: The target draft path exists, but its contents do not match the current task slug. No file was changed. Approve replace, preserve both, or stop. ``

Review is therefore a boundary around consequential ambiguity. It is not a way to convert an unverified claim into a verified one. Until the decision is made, the correct state remains blocked.

Conclusion: ship the receipt with the work

A calm operator loop does not require every task to succeed on its first attempt. It requires every attempt to leave behind enough evidence for the next attempt to act safely.

For a DAL workflow, start with four practices: assign a unique artifact path, inspect before regenerating, verify by reading after writing, and report the narrowest result supported by evidence. When the system cannot decide safely, stop with a concrete review request rather than improvising.

The next practical step is to add a completion receipt to one scheduled job. Measure not only how often it runs, but how often a later operator can answer three questions without guessing: What was produced? Where is it? What was actually verified?