[RFC Comment] Historical Job cannot unambiguously identify the process definition that actually created it

Hello OGC Standards Team,

I have a second, distinct public-review comment on OGC API – Processes Version 2 (Parts 1 and 2). As with my previous comment, please record it in the current RFC if possible or direct me to the non-GitHub public-comment path.

Issue: once dynamic replace is supported, a historical job can identify the process ID without unambiguously identifying the process definition that actually executed.

Part 1’s job/status model carries processID and lifecycle timestamps/status. Part 2 allows the deployed process definition at a process ID to be replaced. That combination creates a reproducibility problem:

Process P definition/version A exists.
Job J executes P.
An administrator replaces P with definition/version B under the same process ID.
A later consumer inspects J and sees processID = P.
Dereferencing/currently inspecting P now describes B, even though J actually ran A.

For geospatial processing this can matter materially. A change in algorithm, container image, model, parameters/defaults, CRS handling, calibration, dependency set, or other executable configuration can change results while the stable process ID remains the same.

Suggested requirement/recommendation:

• When a job is created, bind its status/provenance to an immutable identifier for the exact process definition used for that execution.
• That identifier could be a process-definition revision identifier, immutable version URI, content digest, deployment revision, or equivalent; the Standard need not mandate one packaging technology.
• The job status/result metadata should expose that identifier after execution so a historical job remains interpretable even after the process at processID is replaced or undeployed.
• If the process exposes a human/application version property, clarify whether it is guaranteed immutable/unique for a deployed definition. If not, it should not be the sole reproducibility identifier.
• If the executed definition can be retained safely, provide a link to the immutable definition or provenance record; otherwise preserve at least the immutable identifier/digest and enough metadata to resolve it in an external provenance system.
• Add a conformance/interoperability test: execute a job using definition A, replace the process with B under the same process ID, then verify that the completed job still identifies A rather than being retrospectively ambiguous or appearing to have used B.

This complements, but is independent from, lost-update prevention on PUT/DELETE. Conditional requests protect the current deployed resource from accidental overwrite; execution-bound provenance protects historical results after an intentional replacement.

Thank you,
Seth Morrow

Start by reading the Part 1 job/status model and Part 2 process-replacement rules described in the issue. Define how an execution-bound immutable identifier would be exposed and how the completed job remains linked to definition A after replacement by B. Add the proposed conformance/interoperability scenario and verify that the historical job identifies A rather than the current definition.