A Python process can exit normally without establishing the business outcome it was meant to produce. It may have performed no useful work or failed to retain an output. I separated process termination, host-observed results and durable evidence so that one successful exit code cannot stand in for all three.

Require both normal exit and a host-held result

The child-exit handler requires code zero and an active result before treating termination as error-free. An absent result becomes unverified execution. Printing a success message to stdout does not substitute for the result held through the SDK and host route.

That condition is not a one-line direct check of every service's remote storage. The recipe engine and media implementations determine the actual result contract. Process exit cannot be promoted into a universal business oracle. It establishes one boundary between operating-system termination and the workflow result the host actually possesses.

Do not let a final console message erase an earlier error

Start failure, missing dependencies and unverified execution retain distinct errors. An error already recorded on the active run takes precedence over a zero exit code. A normally completed final Python line cannot erase an earlier input or delivery failure in the host.

A stopped run can finish cancelled without reversing external actions already delivered. Unknown outcomes instead retain review-needed state. Failure, cancellation and uncertainty explain different reasons why another action may not be appropriate. Treating them as one undifferentiated red status would hide information the next operator needs.

Include artifact retention in completion when that adapter is present

When a result and materialization adapter are available, finish invokes artifact retention under the execution folder. Failure records output-not-saved and requires review. Producing something in the browser is insufficient if another operator cannot later read the retained material.

Materialization is an optional adapter in the code, not a universal content validator built into this function. Size, digest and required-content checks belong in the relevant output path. Receiving a result and retaining a usable artifact remain separate facts; neither should silently stand in for the other.

Host completion and journal persistence can fail too

After closing connections, finish calls the host completion hook and saves the result journal. It updates recent manifest state only when current definition content still matches the run's starting digest. Errors in that path change the in-memory result to review-needed with a result-not-saved error.

If persistence itself failed, the final state cannot be asserted to exist reliably on disk. An in-memory review-needed outcome and a successfully retained journal are different evidence. Catching an exception does not complete recovery. Diagnosis must inspect both the files actually retained and any external service result.

Read the actual output file in the existing verification scenario

The library UI test checks host and run states and completed steps after Python operates on a fixture. It then opens the retained CSV and requires the current input in its content. The notebook path reads executed cells from the saved notebook. File-name presence alone is not treated as the business result.

The notebook runner attempts to save partial progress and error cells in a finally block. That does not guarantee writing can never fail. This article reads the implementation and existing tests without launching a new browser execution. Independent module tests and this website's publication checks remain distinct from fresh field verification of the original product.

Completion should remain inspectable later

A result visible now can disappear when the screen changes. Another person or conversation needs to inspect which definition performed which work and what artifact remains. A quick success label is useful only when its supporting record can still explain that claim later.

Custom business software likewise separates a save-button response, actual ledger effects and attachment retention. Convenient technical signals such as normal exit or file creation cannot represent the entire business outcome. Examining completion criteria closely can improve practical usability as much as adding another feature, because it determines what people may safely do next.