Skip to content

docs: stop telling operators a halt performed nothing after the checkpoint - #87

Merged
abrichr merged 1 commit into
mainfrom
agent/durable-halt-truth
Jul 28, 2026
Merged

docs: stop telling operators a halt performed nothing after the checkpoint#87
abrichr merged 1 commit into
mainfrom
agent/durable-halt-truth

Conversation

@abrichr

@abrichr abrichr commented Jul 28, 2026

Copy link
Copy Markdown
Member

The sentence

docs/concepts/durable-runtime.md:

When the run halts (an unhandled screen, a refuted write, an escalation), it writes a pending escalation into the run directory and stops. Work already done is durably recorded; nothing after the checkpoint was performed.

The truth

False for the very case the sentence names.

A refuted write is a write that was delivered and then read back absent from the system of record. A postcondition halt fires on evidence collected after the click. In both cases an action after the last checkpoint was performed.

The engine says so itself — openadapt_flow/transaction.py::_reached_delivery:

A failed postcondition counts — a postcondition is checked after the click, so an over-halt that aborts the run on one is proof the write was already delivered, not proof it was not.

And runtime/durable/controller.py::record only writes a checkpoint when result.ok; the halting step's actuation is neither checkpointed nor rolled back.

The code is right. The prose is wrong. No behaviour changes here.

Why it is worth a PR

"Nothing after the checkpoint was performed" is precisely the sentence that tells a customer they have nothing to reconcile. The engine has a first-class terminal outcome whose entire job is to refuse that claim without positive evidence of absence (RECONCILIATION_REQUIRED, tightened in openadapt-flow #280). This page overrode it in prose on the operator-facing surface.

The fix

States what the runtime actually guarantees:

  • everything up to the last checkpoint is verified and durable;
  • the halting step is not checkpointed, is not rolled back, and a halt is not a rollback;
  • what it may already have done is read from the terminal transaction_outcomeHALTED_BEFORE_EFFECT (absence positively established; nothing to reconcile) or RECONCILIATION_REQUIRED (reconcile before resuming; the runtime will not blind-retry);
  • an empty evidence list means verification never ran, not that nothing happened.

Checks

scripts/validate_docs.py (passed) · mkdocs build --strict (clean) · pytest tests/ (101 passed).

Related

openadapt-flow #298 fixes the same class of stale halt claim in docs/EXECUTION_PROFILES.md, which named HALTED_BEFORE_EFFECT for a probe whose own pinned test asserts RECONCILIATION_REQUIRED.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM

…point

The durable-runtime page said:

  When the run halts (an unhandled screen, a refuted write, an
  escalation) ... nothing after the checkpoint was performed.

That is false for the case the same sentence names. A refuted write is a
write that WAS delivered and then read back absent from the system of
record; a postcondition halt is a halt on evidence collected after the
click. openadapt-flow states this explicitly in
`transaction.py::_reached_delivery`: "a postcondition is checked after the
click, so an over-halt that aborts the run on one is proof the write was
already delivered, not proof it was not."

The engine models this correctly and has a terminal outcome for it. Only
the prose was wrong -- and wrong in the most expensive direction, since
"nothing after the checkpoint was performed" is exactly the sentence that
tells a customer they have nothing to reconcile.

Replaces it with what the runtime actually guarantees: everything up to
the last checkpoint is verified; the halting step is not checkpointed and
is not rolled back; and what it may already have done is read from the
terminal `transaction_outcome` -- `HALTED_BEFORE_EFFECT` (absence
positively established, nothing to reconcile) or
`RECONCILIATION_REQUIRED` (reconcile before resuming).
@abrichr
abrichr merged commit f446a37 into main Jul 28, 2026
5 checks passed
@abrichr
abrichr deleted the agent/durable-halt-truth branch July 28, 2026 02:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant