Skip to content

Diagnose, Repair, and Verify

Pioneer's repair workflow is explicit enough to be auditable without requiring you to perform database archaeology.

failed run → diagnosis → current target → proposal → apply approval
          → changed revision → run approval → new run → comparison

1. Diagnose the baseline

Identify the failed run in Executions, copy its run ID, and ask Chat to diagnose that run. Chat should cite the diagnostic evidence and label causal claims as MODEL_INFERENCE.

2. Inspect the current target

The historical snapshot is not automatically the current target. Chat inspects the current Canvas draft or Saved Flow and retains its identity guards:

  • draft fingerprint for a Canvas target; or
  • Saved Flow ID, revision, and executable fingerprint for a durable target.

3. Review the proposal

Ask Chat to propose a repair. A structured proposal describes operations and is validated against a candidate copy. Review the affected blocks, configuration, validation result, and expected consequence.

No proposal is an apply request. “Looks good” can be assent without authority; use explicit language such as Apply this proposal to Saved Flow 7.

4. Apply explicitly

Review the apply approval. Pioneer rechecks live guards after approval and performs an atomic saved update or guarded draft mutation.

  • A changed target produces a stale result with zero writes.
  • Pioneer does not auto-rebase the old proposal.
  • A draft apply remains unsaved.
  • A saved apply advances the revision and changes the executable fingerprint when execution-relevant content changes.
  • Apply does not run the Flow.

5. Rerun explicitly

Ask Chat to run the repaired Saved Flow. Chat inspects the current saved guards, then presents a new run approval. Approve it separately. Any nested Script still has its own decision.

Pioneer does not automatically rerun after apply and does not loop until green.

6. Verify against the baseline

After the new run reaches a terminal state, ask Chat to compare the baseline run ID with the verification run ID. The comparison can prove facts such as:

  • whether both runs belong to the same Saved Flow;
  • whether revision and fingerprint changed;
  • whether the original failed block completed or failed again;
  • whether a new block became the failure anchor;
  • terminal states, row transitions, and safe Script runtime metadata; and
  • whether persistence or authority evidence is available.

The comparison deliberately does not claim that the repair caused the outcome or that the root cause is fixed. Those remain inferences you assess from the evidence.

Stale proposal recovery

When apply reports that the target changed:

  1. do not repeat the old approval;
  2. inspect the current target again;
  3. ask for a new proposal based on current evidence;
  4. review its candidate validation; and
  5. explicitly approve the new apply if it is still appropriate.

See Human Authority for why each approval is separate and Evidence & Truth for the claim boundaries.