Build Artifacts and Provenance

What you will be able to do

• Distinguish source revision from build artifact in a realistic build artifacts and provenance case.
• Interpret the delivery evidence and boundary associated with artifact digest.
• Choose an appropriate action involving provenance record without exceeding the named operational scope.
• Verify promotion evidence through an observable service result and reproducible handoff.

01

Frame Build Artifacts and Provenance

Treat build artifacts as immutable revision-linked packages and use digests, storage records, and provenance attestations to verify their origin.

Two files are both named checkout-service.zip. Operations must determine which package came from the approved commit and workflow before deployment.

Keep the delivery target, declared intent, execution evidence, reliability boundary, and recovery choice separate. Start with observable state and preserve enough context for another operator to reproduce the decision.

02

Source revision

The source revision fixes the versioned files and instructions intended for the build. Within build artifacts and provenance, this role answers a separate delivery or reliability question and keeps its own evidence.

Record the approved commit as the artifact input identity. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not build a release from an uncommitted workspace. The observable result is specific: the artifact record contains the exact source revision.

03

Build artifact

A build artifact is the retained output produced by an automated workflow job. Within build artifacts and provenance, this role answers a separate delivery or reliability question and keeps its own evidence.

Upload the package once and promote that same output between environments. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not rebuild separately for staging and production. The observable result is specific: one immutable package moves through the release path.

04

Artifact digest

A cryptographic digest identifies the bytes of an artifact for integrity comparison. Within build artifacts and provenance, this role answers a separate delivery or reliability question and keeps its own evidence.

Compare the stored digest before using the downloaded package. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not treat a matching filename as proof of identical content. The observable result is specific: the retrieved package matches the recorded digest.

05

Provenance record

Provenance connects an artifact with its source, build instructions, and execution context. Within build artifacts and provenance, this role answers a separate delivery or reliability question and keeps its own evidence.

Verify the attestation against the expected repository and workflow policy. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not assume an attestation proves the software is vulnerability-free. The observable result is specific: the package origin satisfies the defined trust policy.

06

Promotion evidence

Promotion evidence shows that the verified artifact, rather than a rebuild, reached each target. Within build artifacts and provenance, this role answers a separate delivery or reliability question and keeps its own evidence.

Match revision, digest, and deployment record after promotion. Apply that action to the named service case before widening the rollout, infrastructure scope, or incident response.

Respect this boundary: do not close the release using only a successful upload message. The observable result is specific: production references the same approved artifact digest.

07

Apply Build Artifacts and Provenance to One Service Change

Use one bounded delivery decision: Two files are both named checkout-service.zip. Operations must determine which package came from the approved commit and workflow before deployment.

First, record the approved commit as the artifact input identity. Then, upload the package once and promote that same output between environments. Keep both observations attached to the exact revision, environment, or service window.

Next, compare the stored digest before using the downloaded package. After that, verify the attestation against the expected repository and workflow policy. Close the work only after you match revision, digest, and deployment record after promotion.

08

Recap Before Practice and Prove

Source revision: The source revision fixes the versioned files and instructions intended for the build. In this service case, record the approved commit as the artifact input identity. Preserve the boundary: do not build a release from an uncommitted workspace.

Build artifact: A build artifact is the retained output produced by an automated workflow job. In this service case, upload the package once and promote that same output between environments. Preserve the boundary: do not rebuild separately for staging and production.

Artifact digest: A cryptographic digest identifies the bytes of an artifact for integrity comparison. In this service case, compare the stored digest before using the downloaded package. Preserve the boundary: do not treat a matching filename as proof of identical content.

Provenance record: Provenance connects an artifact with its source, build instructions, and execution context. In this service case, verify the attestation against the expected repository and workflow policy. Preserve the boundary: do not assume an attestation proves the software is vulnerability-free.

Promotion evidence: Promotion evidence shows that the verified artifact, rather than a rebuild, reached each target. In this service case, match revision, digest, and deployment record after promotion. Preserve the boundary: do not close the release using only a successful upload message.