#Run lifecycle and execution boundaries

A Run is admitted with an immutable original intent and execution policy. Runtime advances its cursor through declared topology.

Admission receipts (pending, accepted, rejected) are operation state, not Run state. A successful client query can describe failed execution.

#Ownership and cancellation

Each call has its own scope, signal and capabilities. Current action IDs bind answers to the waiting call. Late results after cancellation or a transition cannot overwrite newer execution.

Cancellation marks failed/RUN_STOPPED and signals current tasks. Known late usage or commit references may still arrive until settled, without resuming the Run. Cancellation does not undo completed side effects.

#Restart and observation

Run lists and metrics belong to the current Service instance. Supported business checkpoints can recover into a new instance with fresh statistics and budgets; they do not provide cross-restart terminal history.

Human waiting pauses execution-duration budgets. Model/Tool usage records known information, with unknown external reasoning distinct from zero.

See Run operations, recovery and configuration limits.