Checking that a inspected build artifact came from the current change

Goal

Prevent an agent from accepting a stale file, preview, or package as evidence that the current source change was built and delivered successfully.

Prerequisites

Identify the build command, expected artifact location, source revision, and intended consumer. Keep any prior user artifact intact until its role and replacement policy are understood.

Steps

1. Record the expected source identity and build inputs before execution. Include the target configuration when the same source can produce different outputs for development, testing, and production.

2. Check the build result and locate the artifact it actually produced. Do not infer success from a familiar filename that already existed before the command ran.

3. Associate the output with a build receipt, content fingerprint, or embedded revision marker where the project supports one. A modification time alone may be insufficient when files are copied or restored.

4. Inspect or run the exact output that the intended consumer will receive. If a preview server serves another directory or an installed package shadows the new build, correct that connection before drawing conclusions.

5. Exercise a failed build leaving an old artifact, an output-directory change, and a consumer still pointed at an earlier package. The check should detect each mismatch and report which artifact was actually inspected.

Expected result

The validation chain links source, build execution, artifact, and consumer. A successful preview or package inspection can then support a claim about the current change rather than an unrelated earlier output.

Limits and test basis

This methodology has not been executed here. A trustworthy origin link does not establish artifact correctness or supply-chain integrity by itself. Use the project’s stronger attestation mechanism when one exists and the task requires it.