Running a notebook cell again should not repeat every completed submission. Treating equal input as permanently finished would prevent a legitimate new occurrence next week. I used job and item identities to distinguish continuation from new work, while comparing the input and definition retained under each identity.

Identify the batch and its items together

An operations notebook sends a job identity and distinct item identities. The journal location separates program, project-context key and job, while each item retains input fingerprint, definition digest, status and run identity. Equal display titles do not turn distinct item identities into one processing unit.

Continuing the same work requires retaining those identities. Generating random replacements every time a cell runs prevents finding the original completion record. Identifiers preserve the meaning of continuation, not merely internal implementation convenience. The distinction between another occurrence and the same occurrence must also be explainable outside the code.

Reuse completion only when input and definition still match

Finding an existing item first triggers input comparison, then definition comparison. Changed input or code is rejected. Only matching values and an earlier succeeded state return the saved result and run identity marked reused. A former success label cannot complete different material by itself.

This item fingerprint sorts input key-value pairs before hashing, unlike the serialization used in the active SDK gate. The layers should not be described as identical comparisons. Retaining the equality criterion helps another operator understand continuation conditions rather than treating the journal as an unexplained cache of reassuring status words.

Persist intent before invoking the actual work

A new item is saved as running with its fingerprints before the execution port is called. Creating the journal only after the first action would leave an unexplained interval if the application exited. When work returns, the real run identity, result, completed steps and error are attached to the item.

The save path writes a temporary file and renames it. That is not a universal lossless transaction guarantee for every storage device. Failed or invalid records still need explicit handling rather than manufactured completion. The ordering preserves what was intended before asking what actually happened.

There is no rule to replay every failed item

An item that did not succeed is not automatically replayed. The code checks specific conditions such as read-only procedures, supported workflows with their own durable dispatch journal, or proven pre-dispatch failure. An uncertain generic click or mutation requires review.

Creating another job identity to evade that protection is not continuation. The original service result must be reconciled first. A legitimate new occurrence needs its own present intent, destination and inputs before it begins. Changing an identifier is an explicit work-lifetime decision, not an error-clearing trick to hide an unresolved earlier action.

Count execution calls when a completed item is revisited

Existing unit tests recreate the service and require a completed item to return reused without increasing execution count. A separate read-only failure can continue under its permitted conditions while preserving history. An uncertain mutation must remain at one execution after another invocation is refused.

Changed inputs and foreign-profile access are rejected, and a changed project key opens another journal scope. That evidence uses owned temporary folders and an execution stub in the existing tests. This writing performs no new customer submission or browser replay. A stub's returned success does not certify an actual external transaction.

Equal input can still belong to a different occurrence

A weekly report can retain the same title while representing new work. Deduplicating solely by input would block legitimate later occurrences. Job and item identity define the occurrence, and fingerprints then protect the content inside it. Equal material and the same business item are different concepts.

The next operator should know which identities to keep, which items finished and where actual results can be inspected. Continuation should read established facts before performing remaining work rather than becoming a retry-everything button. The journal preserves those decisions outside conversational memory so they can be checked again.