To identify the commit running in an API service, you need to connect the source checkout, the built image and the runtime image ID. A tag such as latest can move between builds, so it cannot establish that connection by itself.
Hakopod alpha.18 added per-service provenance for images built by external CI. A deployment can carry the exact image digest, source commit, repository and run URL together. Your existing build pipeline can submit this metadata with the deployment.
Start from the checkout, not the trigger
The commit that triggered a workflow is not always the commit it built. A pipeline can check out another repository, use a remote build context or build several services from different sources.
Report the commit from the source actually used for the image. Attach it to the full digest-pinned image reference in that service’s specification. A moving tag is too loose for this job: two deployments that say the same tag can refer to different bytes.
If several services use the same image, report the matching claim for each selected service. Keep the provenance in both the plan and deployment request so the metadata you reviewed is the metadata recorded with the release.
Keep the claim and the release together
Hakopod stores provenance atomically with the immutable release. It also includes the metadata when checking whether a request is a retry of the same operation. Reusing a request key with a different claim returns a conflict instead of quietly rewriting the history.
External CI records are marked ci_reported. The platform accepts metadata from your authenticated pipeline; it does not independently reproduce the build, verify a registry signature or fetch the workflow URL as proof.
Conflicting claims are treated as ambiguous. The platform does not resolve that ambiguity by choosing whichever claim arrived last.
Close the loop at runtime
Accepted metadata is only one part of a release investigation. Check that deployment succeeded, inspect the runtime image IDs and confirm the relevant services are ready. If you are closing a bug, exercise the behavior that was broken.
This is particularly important in applications with several services. A new API image does not establish that a worker or migration job used the same build. Read each service’s evidence rather than treating the application name as a single executable.
Older unknown images are not automatically assigned a guessed commit. When you have the exact build information, make a new reviewed deployment with that metadata.
The CI provenance guide links a complete request example. Use it to record the digest and checkout with your deployment, then verify the running image separately.