A program can keep yesterday's familiar name after its Python code or notebook cells change. A retained success label then risks describing something that no longer exists. I bound verification to the inspected definition content rather than to the display name and compared that content before reuse.
Choose hash inputs according to their role
Library hashing reads recipe and workflow bytes, then hashes notebook cell types and sources. It binds the definition, Python entry point and notebook execution source together. Checking only one file would let another supported form change while still carrying the former validation state.
The implementation does not hash the entire notebook byte-for-byte. It compares source structure rather than outputs and execution counts that can change after running. This is a selected definition boundary, not a universal claim that notebook metadata never matters. Stating what is excluded is part of explaining the integrity contract.
Connect list status with the actual load boundary
Listing compares current content with the manifest digest and displays changed-code status when they differ. Loading performs the comparison too and rejects the definition. A warning in the interface and unrestricted execution would otherwise create two incompatible contracts.
Automatic discovery excludes programs that fail loading because their code changed. A highly relevant old name cannot quietly override that failure. The execution boundary matters beyond the wording of a warning: it must still hold when a person misses the label or an agent reads only part of the catalog.
Procedure identity and execution integrity are different digests
Procedure identity ignores names and ordinary defaults to find an equivalent reusable structure. Execution integrity compares retained file content. A candidate can be structurally equivalent despite changed naming without granting permission to execute an altered Python file under old verification.
Calling both values hashes must not obscure their jobs. One helps recognize a procedure; the other asks whether the inspected files remain unchanged. They expect different kinds of change and need different tests and failure states. Reducing duplicate library entries cannot weaken the check that binds verification to actual source.
Do not attach an old run result to files changed during execution
The completion path also compares the present library hash with the run's starting hash before updating manifest status. A successful earlier definition should not lend its success label to replacement files. Reservations independently retain their creation-time hash and compare it again before dispatch.
These checks are not a complete filesystem lock against every concurrent change. They do not establish protection against all races between comparison and execution or hostile modification inside the same process. They tighten the link between inspected content and reported results. Stronger deployment requirements can call for immutable packages or dedicated execution copies.
Change one copy and compare the untouched peer
The existing library test saves two definitions and appends content to one Python workflow. That load must fail while the other still loads its original definition. Project-definition tests similarly edit one recipe while comparing the peer and common catalog bytes with their earlier state.
Evidence here is the actual implementation and existing test code, not a fresh original-application execution. Independent website modules have their own package tests and digest comparisons. Combining those scopes does not establish every deployment environment as verified. The inspected files and the time of that inspection must remain identifiable.
Equal bytes still leave business correctness to be checked
Equal digests indicate unchanged inspected content. They do not prove an unchanged service, correct present input or current permission to execute. A digest is not a universal safety badge; integrity is one condition among several at the execution boundary.
After editing, the relevant changes must be read and revalidated. Manually updating the manifest digest merely to restore a reassuring status skips that work. The maker goal is not a green label itself, but a structure that can explain which definition and which checks justify the label being shown.