Fresh Artifact Proof for Safe Recovery

Safe recovery is not the same as ignoring a failure. When an automated worker fails at the terminal-output layer, recovery should be allowed only if the worker's real success contract provides fresh, durable evidence from the current run.

Definition

Fresh artifact proof is evidence that a durable output was created or materially changed by the current attempt, and that this artifact is the worker's authoritative success signal.

The key word is fresh. A file that exists is not enough. A non-empty file is not enough. If the artifact could have been left by a previous run, it cannot safely prove that the current run succeeded.

Why it matters

Many automated workflows treat subprocess output as the default source of truth. That works for workers whose contract is valid stdout. It fails for workers that prove success by writing durable artifacts, updating state, or completing an external check.

If every worker is forced into the same success model, two bad outcomes become likely:

• real work is rejected because the wrong signal failed
• failed work is accepted because stale evidence looked convincing

Safe recovery requires a narrower question: what signal actually proves success for this worker?

Common failure mode

A worker creates a useful artifact, but the wrapper reports failure because terminal output was too large, truncated, or otherwise unusable. The tempting fix is to raise limits, ignore the wrapper error, or accept any existing artifact.

That turns a local problem into a system-wide risk.

The unsafe version sounds reasonable:

The summary file exists, so the worker must have succeeded.

But that file might be stale. It might be unreadable. It might be from a previous attempt. It might not belong to the worker path being recovered.

Better pattern

Recovery should be contract-specific.

Before dispatch, snapshot the evidence that could later be used for recovery. After a wrapper failure, compare the current evidence against that snapshot. Recover only when the allowed worker and allowed failure mode both match, and when the durable artifact is fresh enough to prove current progress.

For an artifact-contract worker, useful checks include:

• the artifact did not exist before and exists now
• the artifact content changed from the pre-dispatch snapshot
• the artifact is readable
• the artifact is non-empty
• the recovery applies only to the worker/error pair that explicitly permits artifact-based success
• other failures still fail closed

Freshness proof does not have to prove everything. It may not semantically validate the entire artifact. But it should be explicit about that residual risk instead of pretending that existence alone is enough.

Example

Consider an automated review step whose useful result is a written summary. The terminal output may be verbose and unreliable, but the summary artifact is what downstream steps actually need.

The safe recovery path is not:

If a summary file exists, continue.

The safer path is:

If this specific review step fails only because of the known output-limit condition, and the summary artifact is fresh compared with the pre-run snapshot, readable, and non-empty, continue. Otherwise fail closed.

That distinction keeps recovery narrow. It lets artifact-based work succeed without weakening stdout-based workers, timeout handling, parser validation, missing-tool failures, or other boundaries that still need to stop the workflow.

Related concepts

• Generated Output Is an Interface Contract
• Keep Strict Output Boundaries Strict
• Artifact Truth Is Not Lifecycle Truth
• Audit Verdicts Are Runtime State
• Recovery Contract Review