You have a commit in Git, a green CI run and an image in a registry. Now someone asks which commit is running in the API service. The answer should not depend on remembering what latest meant this morning.
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. That connects useful evidence without asking you to move your build pipeline.
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 in the idempotency hash. Reusing a request key with a different claim returns a conflict instead of quietly rewriting the history.
External CI records are marked ci_reported. That label is intentional. The platform accepts an authenticated assertion from your 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. Picking whichever claim arrived last would produce a tidy display, but it would hide the uncertainty the operator needs to see.
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. Keep the digest, checkout and runtime observation close enough that the next investigation can follow them.