Review the Work Without Watching the Worker

Why long-running workflows need inspectable checkpoints

A customer submits a refund request. An agent reconstructs the purchase and earlier credits, applies the policy, calculates the amount, issues the refund, and reconciles the account.

For a short workflow, a request followed by a result may be enough. For work that takes hours, waits on another system, encounters an exception, or passes between agents, "processing" hides the state that matters. A person cannot tell which facts have been established, which decision is pending, or what usable work would remain after an interruption.

An activity log may list hundreds of tool calls without showing what the work has established or giving anyone a result they can check or use.

Long-running work should leave useful results along the way, not only at the end. Someone other than the worker should be able to find each result, check it independently, use it before the whole process finishes, and return to it later.

An inspectable checkpoint is the machine-readable equivalent of showing your working.

Progress is not an outcome

An activity log records events: a file was read, an API was called, a calculation ran. A checkpoint records what a defined stage established: the case has been rebuilt from named inputs, eligibility has been decided under a named policy, or a payment has been applied and reconciled.

This matters when work continues after the person leaves. The person or system waiting for the work rarely needs every action the worker took. They need a short record that says:

• the outcome the stage claims to have established;
• which inputs, decisions, and evidence let someone test that claim;
• what remains unresolved or blocks the next stage; and
• what the person or system can do next.

A transcript can help diagnose a failure. It is a poor way to decide whether to supply missing context, accept or challenge a result, transfer the work, or recover after an interruption.

Divide the work where an outcome becomes useful

The refund can be divided into three stages, each ending in a useful result.

flowchart TD
    subgraph S1["1. Establish the case"]
        direction LR
        A["Reconstruct<br/>purchase, credits, request, policy"]
        B{"Independent check<br/>case completeness"}
        C[("Case checkpoint<br/>inputs and open questions")]
        A --> B --> C
    end

    subgraph S2["2. Decide the refund"]
        direction LR
        D["Decide<br/>eligibility, amount, exceptions"]
        E{"Independent check<br/>policy and calculation"}
        F[("Decision checkpoint<br/>decision and evidence")]
        D --> E --> F
    end

    subgraph S3["3. Apply the refund"]
        direction LR
        G["Apply and reconcile<br/>transaction, account, balance"]
        H{"Independent check<br/>effect and balance"}
        I[("Outcome checkpoint<br/>transaction and resulting balance")]
        G --> H --> I
    end

    C --> D
    F --> G

Each stage leaves something useful as soon as it finishes.

The case checkpoint can be reported or transferred without reconstructing the account again. The decision checkpoint lets a person review the policy application before money moves. The outcome checkpoint lets finance verify the transaction or recover after an interruption.

A checkpoint belongs where a stage has produced a named result that someone else can understand and check. It is not an arbitrary pause.

A useful checkpoint is for someone else

Not every tool call deserves a checkpoint. A single record at the end is too coarse, while a checkpoint after every action merely reproduces the activity log.

Put the boundary where another person or system can understand the stage without replaying the execution. The record should support a concrete use: reporting the process state, supplying missing context, testing or challenging a result, transferring the work, or recovering from a known state.

A useful checkpoint says what the stage established and what remains unresolved. It keeps the relevant inputs, decisions, and evidence, and remains available after the worker moves on or stops.

The record contains what another reader needs to understand and check the claim. It does not need hidden model reasoning or every exploratory step.

This changes what a waiting consumer, whether a person or system, sees:

flowchart LR
    R["Refund requested"]
    C1[("Case checkpoint")]
    C2[("Decision checkpoint")]
    C3[("Outcome checkpoint")]

    R --> C1 --> C2 --> C3
    U["Consumer"] -->|inspect or add context| C1
    U -->|accept, challenge or escalate| C2
    U -->|verify or recover| C3

Between checkpoints, the worker can continue without requiring continuous attention. At each one, the consumer can understand the result and respond without opening the worker's transcript or context.

Decision records and execution checkpoints are different

The previous paper, Who Gets to Move the Goalposts?, kept the end fixed while decisions about how to reach it could change.

I have been exploring this distinction while building SuperDomestique, a system for increasingly independent software delivery. Given an external PRD, its workflow can break the product into defined increments, record them as Product Requirements Decision Records, or PRDRs, and build them autonomously. The PRD says what success means. PRDRs record choices about how to reach it.

Once a PRDR has been accepted, the worker must satisfy it. The worker may change the implementation, but not what counts as complete.

The refund follows the same pattern without the software vocabulary. The request and policy set the end: resolve the request under the applicable policy and leave the account reconciled. The planned stages say what should be established. Their checkpoints preserve the rebuilt case, the checked decision, and the resulting account state.

Keeping these records separate stops a plan from being mistaken for completed work, or activity from being mistaken for an accepted result.

Check each stage while the evidence is close at hand

Each stage becomes testable when it makes a clear claim that someone other than the worker can check. Check it while the inputs, decision, and immediate effects are still close at hand, before later work makes a failure harder to find or correct.

For the refund, the case evaluator checks the purchase, request, applicable policy, and all previous credits. The decision evaluator recomputes the amount and checks exceptions against the policy. The outcome evaluator compares the applied transaction and resulting balance with the accepted decision.

Checking each stage makes failures easier to correct. Missing context can be requested before an eligibility decision. A miscalculated amount can be fixed before money moves. An uncertain transaction can be reconciled from a known checkpoint without replaying the whole workflow.

The checkpoint keeps the claimed result, its evidence, and the evaluator's decision. The record makes that evaluation visible, but it cannot prove that the evaluator was independent or force the next stage to honour the result. Those are questions of authority. Evidence That Can Say No explains how a control can use evidence to allow or refuse the next action.

Recorded checkpoints improve future runs

A checkpoint helps a consumer understand one run. A checkpoint history can show which stages of a named workflow repeatedly succeed, fail, or require intervention under stated conditions.

flowchart LR
    R["Workflow runs<br/>under stated conditions"]
    C[("Checkpoint history<br/>outcomes, failures, interventions")]
    E["Compare results<br/>by stage"]
    H{"Human decision<br/>keep, narrow, improve or widen"}
    F["Rules for future runs<br/>scope, process and evidence"]

    R --> C --> E --> H --> F --> R

The refund history may show that case reconstruction usually succeeds while eligibility decisions often lack current policy context. A final result alone would not locate that weakness. With records for each stage, a team can improve the evidence supplied to the decision stage, narrow the delegated refund classes, or route exception cases for human review.

These results apply to the workflow under the conditions in which it ran. A different policy, customer class, model, tool, or environment may require new evidence.

People can use the history to keep, narrow, change, or widen the process. The system cannot use its own history to change the purpose or grant itself more authority.

What SuperDomestique does today

SuperDomestique already uses separate records for activity and resumable state. Its structured run-event log records the execution timeline. Separate build and review progress records keep the state needed to resume work, including the diff identity, branch, and review-phase status. A later run checks the recorded diff identity before treating work as complete instead of inferring progress from a transcript.

These records support SuperDomestique's software delivery workflow. They are not yet a general checkpoint interface for every asynchronous business process, and not every recorded event is an independently evaluated result.

Checkpoints also have a cost. A boundary with no useful result adds extra work. Too little evidence creates false confidence; too much detail makes people retrace the worker's steps.

Place a checkpoint where the work first becomes useful to somebody outside the worker. How often the system saves state should follow those points.

Before delegating a long-running process, identify the useful results that exist before completion. For each result, ask who needs to inspect or act on it and what record would let them do so without replaying the execution.

The next paper, Evidence That Can Say No, asks what must connect an evaluated checkpoint to a control that can permit or refuse an action with real consequences.

Implementation and evidence

• Run events and progress checkpoints
• Commissaire's current boundary
• Current evidence and claim status