Build Reproducibility Audit Prompt

This prompt is for release engineers and platform teams who need to verify that their software builds are deterministic. The core job-to-be-done is producing a structured audit report that identifies sources of non-determinism—such as timestamp embeddings, floating dependency references, environment variable leakage, and unsorted file system traversal—so that two builds from the same commit produce identical artifacts. The ideal user is someone responsible for supply chain integrity, preparing for a SOC 2 audit, or debugging a CI/CD pipeline where identical commits yield different checksums. The prompt assumes you can provide build configuration files, lockfiles, and CI logs as input context. Without these artifacts, the audit cannot produce grounded findings.

Use this prompt when you are shipping software to regulated environments, hardening your release process for compliance, or investigating a specific reproducibility failure. It is designed to map each finding to a specific line in a build configuration, a tool behavior, or an environment capture. The output is not a generic best-practices list; it is a traceable audit trail. The prompt requires the model to cite evidence from the provided inputs for every claimed source of non-determinism. If the model cannot ground a finding, it must explicitly state that rather than inventing a plausible-sounding cause. This evidence-grounding constraint is the most critical part of the prompt's value.

Do not use this prompt when you lack the build configuration files, lockfiles, or CI logs that the audit requires. Without these inputs, the model will either refuse to produce findings or—worse—generate plausible but unverifiable claims. This prompt is also not a substitute for a full SLSA compliance review or a cryptographic attestation system; it is a diagnostic tool that helps you find and fix reproducibility gaps before you invest in heavier supply chain controls. If you need to compare build artifacts across different machines or operating systems, you will need to provide both sets of build contexts and explicitly instruct the model to perform a differential analysis. Finally, if your build system uses non-deterministic plugins by design (e.g., code generators that embed timestamps), the prompt will flag them, but remediation may require changing the plugin rather than the build configuration.

The prompt below is designed to be pasted directly into your AI harness. It instructs the model to act as a release engineering auditor, systematically identifying non-deterministic inputs, timestamp embeddings, environment leakage, and floating dependency references across your build configuration. Every placeholder in square brackets must be replaced with real values before execution—leaving a placeholder unresolved will cause the model to hallucinate or skip critical analysis.

textCopy
You are a build reproducibility auditor. Your task is to analyze the provided build configuration, lockfile, and environment metadata to produce a structured audit report. The report must identify every source of non-determinism that could cause two builds from the same commit to produce different artifacts.

## INPUTS
- Build configuration files: [BUILD_CONFIG_FILES]
- Lockfile contents: [LOCKFILE_CONTENTS]
- Environment metadata (CI variables, host info, toolchain versions): [ENVIRONMENT_METADATA]
- Build command or entrypoint: [BUILD_COMMAND]
- Target artifact description: [TARGET_ARTIFACT]

## AUDIT CATEGORIES
For each finding, classify it into exactly one of these categories:
1. **TIMESTAMP_EMBEDDING**: Build embeds current time, build time, or epoch seconds into artifacts or metadata.
2. **ENVIRONMENT_LEAKAGE**: Hostname, username, path, PID, or machine-specific values appear in artifacts.
3. **FLOATING_DEPENDENCY**: A dependency version is not pinned and can resolve differently across builds.
4. **NON_DETERMINISTIC_TOOL_BEHAVIOR**: A build tool, compiler, or plugin produces different output given identical inputs (e.g., randomized identifiers, map iteration order, parallel execution variance).
5. **SOURCE_OF_RANDOMNESS**: Random seeds, UUID generation, or non-seeded PRNG usage during the build.
6. **FILE_SYSTEM_ORDERING**: Build output depends on filesystem traversal order, glob expansion order, or inode assignment.
7. **NETWORK_CALL**: Build fetches resources from the network without content-addressed verification.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "audit_summary": {
    "total_findings": <integer>,
    "reproducibility_score": <float between 0.0 and 1.0, where 1.0 means fully reproducible>,
    "critical_blockers": <integer count of findings with severity CRITICAL>,
    "assessment": "<one-sentence overall assessment>"
  },
  "findings": [
    {
      "id": "F-<zero-padded index starting at 001>",
      "category": "<one of the seven categories above>",
      "severity": "CRITICAL|HIGH|MEDIUM|LOW",
      "location": "<specific file path, line number, or configuration key>",
      "evidence": "<exact string, variable, or pattern from the input that proves the finding>",
      "impact": "<what part of the artifact changes across builds>",
      "remediation": "<concrete, actionable fix>",
      "effort_estimate": "LOW|MEDIUM|HIGH",
      "verification_step": "<how to confirm the fix worked after applying it>"
    }
  ],
  "remediation_plan": [
    {
      "step": <integer order>,
      "finding_ids": ["<list of finding IDs this step addresses>"],
      "action": "<what to do>",
      "effort": "LOW|MEDIUM|HIGH",
      "risk_of_regression": "LOW|MEDIUM|HIGH"
    }
  ]
}

## CONSTRAINTS
- Every finding MUST include a `location` that references a specific file path, line number, or configuration key visible in the provided inputs. Do not speculate about files you cannot see.
- Every finding MUST include `evidence` as an exact string or variable name from the input. If you cannot quote the evidence, do not report the finding.
- The `remediation_plan` must be ordered by effort (lowest first) and must group related findings into shared steps where possible.
- If no findings are detected in a category, do not fabricate findings. A reproducibility score of 1.0 with zero findings is a valid result.
- Do not recommend switching build systems or toolchains unless the current tool has a documented non-determinism bug that cannot be worked around.

## RISK_LEVEL
[RISK_LEVEL: HIGH — this audit may be used to gate production releases. Every finding must be evidence-backed. When in doubt, mark a finding as MEDIUM severity and note the uncertainty in the evidence field.]

## EXAMPLES
[EXAMPLES: Optionally include 1-2 example findings from prior audits to calibrate the expected level of detail.]

Adaptation guidance: Replace [BUILD_CONFIG_FILES] with the full text of your build.gradle, pom.xml, Cargo.toml, CMakeLists.txt, Makefile, Dockerfile, or equivalent. Replace [LOCKFILE_CONTENTS] with your resolved lockfile (package-lock.json, yarn.lock, Cargo.lock, Pipfile.lock, etc.). Replace [ENVIRONMENT_METADATA] with the output of env, CI variables, uname -a, and toolchain version dumps. The [RISK_LEVEL] placeholder should be set to HIGH for production release gates or MEDIUM for development audits. The [EXAMPLES] placeholder is optional—include 1-2 prior findings only if you need to calibrate the model's output style. If your build system has additional non-determinism sources not covered by the seven categories, add them to the AUDIT CATEGORIES list before execution.

Validation and evals: After receiving the model output, validate the JSON schema programmatically. Then run these eval checks: (1) every location field must resolve to a real file path or key in the input; (2) every evidence string must appear verbatim in the provided inputs; (3) no two findings should have identical evidence and location; (4) the reproducibility_score must be consistent with the finding count and severities (a score above 0.9 with multiple CRITICAL findings is a red flag). For production release gates, a human release engineer must review every CRITICAL and HIGH finding before the audit is accepted.

The Build Reproducibility Audit Prompt is designed to operate as a gated step in a release pipeline, not as a one-off manual query. The prompt expects structured input—a build configuration file, a lockfile, and optionally a build log—and produces a structured audit report. To integrate this into an application, wrap the prompt in a harness that collects these inputs from the build environment, invokes the model, validates the output schema, and routes findings to the appropriate remediation queue. The harness should treat the model's output as a draft audit that requires post-processing before any action is taken.

Start by building a collector function that assembles the required [BUILD_CONFIG], [LOCKFILE], and [BUILD_LOG] inputs from the repository at the commit being released. For Docker-based builds, extract the Dockerfile and any docker-bake.hcl or Compose files. For language-specific ecosystems, capture the canonical lockfile (Cargo.lock, poetry.lock, package-lock.json, go.sum) and the build tool configuration (Cargo.toml, pyproject.toml, package.json, go.mod). The harness should then invoke the model with a strict JSON schema expectation. Use a model that supports structured output (e.g., GPT-4o with response_format or Claude with tool-use for schema enforcement) to reduce post-generation repair. After receiving the response, run a validator that checks: (1) every finding has a non-empty source_location field pointing to a real line or stanza in the submitted configuration; (2) every remediation step includes an effort_rank between 1 and 5; (3) no finding claims non-determinism without citing a specific input (e.g., a TIMESTAMP variable, a floating version range, or a hostname embedding). Findings that fail validation should trigger a single retry with the validation errors appended to the prompt as [PREVIOUS_ERRORS].

For production use, log every audit result alongside the commit SHA, the model version, and the raw prompt and response. This creates an audit trail for SOC 2 or SLSA compliance evidence. Do not auto-apply remediations from the model output. Instead, route findings to a review queue keyed by severity: CRITICAL findings (timestamp embeddings, hostname leakage, floating latest tags) should block the release and require human approval; HIGH findings (unpinned transitive dependencies, filesystem ordering assumptions) should generate a ticket in the build engineering backlog; MEDIUM and LOW findings can be batched into a monthly hygiene report. The harness should also compare the current audit against the previous release's audit to detect regressions—a new non-deterministic input that wasn't present in the last build is a release-blocking event. Avoid running this prompt on every commit; target it at release candidates, tag creation events, or scheduled nightly builds of the main branch to control cost and latency.