A saved Python file is hard to reuse if the next operator cannot tell what input it expects or what it verifies. I retained its definition, notebook, explanation and validation state as a set, then kept execution results separately. Reusability needed an operating context as well as code.

The recipe describes the work to be executed

The recipe holds starting context, parameters, tab aliases and steps. The normal generated Python entry forwards to the shared SDK rather than maintaining a second handwritten copy of the workflow. Specialized media runners can differ, so not every generated file should be described as the same short wrapper.

Definitions pass a strict recipe schema. Unsupported fields, arbitrary code and saved element references are rejected. That contract does not turn the Python process into an operating-system sandbox. The supported definition format and the ordinary local capabilities of Python code are different boundaries and must be reviewed separately.

The notebook is an operating view from inputs to results

The companion notebook divides setup, material and destination checks, execution, results and error inspection into cells. It creates a workflow for the same program identity and invokes prepare, run and status. It is an operating document with before-and-after checks rather than merely a descriptive report.

Opening the file is not executing its cells, and retained output is not evidence of a present run. A single library-launched item also has a different lifetime from multi-item work continued inside a project. Equal notebook extensions cannot establish identical execution and resume behavior; the instructions make that distinction explicit.

The manifest connects identity and validation state

The manifest retains identity, name, version, profile, digest and status. A newly generated definition is marked not yet execution-verified. Saving under the same name still produces another identity and location, preserving earlier files. Names help people search; identifiers distinguish retained objects.

Integrity hashing covers recipe, workflow and notebook cell sources. Execution outputs are not mixed into the definition digest. Unchanged code and a correct current result answer different questions. A reassuring manifest label should therefore never replace comparing the definition files it describes.

Keep results under a separate identity for each run

Each run receives a new identity and result location. Result records, actual outputs and executed notebooks stay distinguishable from the definition files. Repeated use of one program needs an unambiguous answer to which execution produced the material being inspected, beyond an interface label saying latest result.

Current active or last memory state differs from retained disk records. The status path checks run, profile and program identity before returning history. A retained running record is treated as unproven completion. File presence neither proves success nor permits repeating an operation whose external result is uncertain.

Use the explanation to distinguish preparation from execution

The README explains the shared definition and SDK, where inputs change and when revalidation is needed. Login material and run access credentials are not copied into the companion set. Reusable files must remain separate from a connection valid only during a particular execution.

Existing unit tests compare identities from repeated saves, profile isolation and preservation when one file changes. This article reads those functions and tests; it does not execute a new user procedure or establish installation on another computer. Shared SDK version and the external environment remain conditions for actual use, beyond possessing the saved files.

Change the questions the next operator can ask

A lone script invites the first question of whether it runs at all. A companion set makes inputs, destination, definition integrity and result location inspectable before execution. Increasing file count was not the aim; preserving those questions in a form another operator could answer was.

I use the same principle for shared website modules: code, tests, examples and limits belong together. Downloading a package does not establish successful integration in a real workplace. Shareable operating material lets the next maker check local conditions and continue deliberately. Retaining a workflow is broader work than saving an executable file.