“It runs here” is not a build gate

1218. Lesson identity

Module

3.10 — Build pipeline

Lesson

1 — “It runs here” is not a build gate

Academic type

Concept

Schema type

text

Order

1

Estimated time

30–45 minutes

This lesson defines the minimum evidence required to accept a build. The focus is not on a particular engine command or hosting service. The focus is on making a build claim that another person can inspect, including the known Git commit or tag that identifies the source state.

1219. Learning objective

After this lesson, you can specify a minimum evidence set and acceptance gate for a build by identifying its inputs, artifact, execution environment, Git reference, and observable checks while distinguishing acceptance evidence from evidence of reproducibility.

1220. Why this matters

A build that runs on one machine may still depend on an unrecorded asset, a local setting, or an environment difference. That makes failures difficult to reproduce and makes a positive result difficult to trust. A known Git commit or tag connects the evidence to a specific source state instead of an unnamed working directory. AI can help generate commands, configuration, or troubleshooting ideas, but it cannot replace a precise definition of what counts as evidence. A build gate turns “it worked for me” into a claim with inspectable conditions.

1221. Prior knowledge

You should already be able to audit an asset set using a manifest, identify intended asset roles, and distinguish an asset being present from an asset being suitable for its intended use. This lesson builds on module 3.9, Audit an asset set. You should also be able to identify the repository revision used for a controlled piece of work.

1222. Core concept

Reproducibility and acceptance evidence are related, but they are not the same model. Reproducibility concerns whether another person can recreate or rerun a result from sufficiently identified factors. Those factors include the source state, project and asset inputs, dependencies, tool versions, configuration, build procedure, and relevant execution environment.

Use I-A-E-G to organize the acceptance claim and its evidence:

1. Inputs — the source material used to produce the build: project files, code, assets, configuration, dependencies, and relevant version information.
2. Artifact — the produced output being evaluated, such as a packaged game build or another explicitly defined output.
3. Environment — the conditions in which the artifact is created or run: operating system, engine or tool version, required runtime, hardware assumptions, and settings that affect the result.
4. Gate — the observable criteria that determine whether the artifact is accepted, rejected, or returned for investigation.

A Git reference identifies the source state associated with the inputs and artifact, but it is not an additional I-A-E-G category and it does not prove reproducibility by itself. The dependency record, tool versions, configuration, build procedure, and environment evidence provide the other factors needed to assess reproducibility.

I-A-E-G answers what is being evaluated and what result is acceptable: inputs answer “from what?”, artifact answers “what was produced?”, environment answers “under which conditions?”, and gate answers “what must be observed?” Keeping these purposes separate prevents a passing gate from being mistaken for proof that the build can be reproduced elsewhere.

A build gate should be narrow enough to check and meaningful enough to protect the next stage of work. “The project opens” may be useful as an early check, but it is not automatically sufficient evidence that the intended build was produced or that its critical behavior is available.

1223. Mental model

Use two connected views: the reproducibility factors and the I-A-E-G acceptance/evidence model. I-A-E-G organizes the acceptance claim; the reproducibility factors indicate whether another person could recreate or rerun the result. The Git reference links the declared inputs to a source state but does not replace either view.

The acceptance evidence should form a traceable I-A-E-G chain:

Inputs → Artifact → Environment → Gate result

Reproducibility evidence cuts across that chain by recording the source revision, dependencies, tool versions, configuration, build procedure, and other conditions required to recreate or rerun the result. A known commit or tag is part of the build identity, but it does not prove reproducibility or prove that the artifact was produced from that revision by itself.

An immutable artifact identifier is optional but recommended when a path or archive name could be overwritten. A checksum, immutable artifact ID, or uniquely versioned filename helps identify the exact bytes evaluated. It does not, by itself, prove that those bytes were built from the declared source revision or procedure; the evidence must still connect the artifact to the declared inputs, environment, and checks.

If an acceptance element or reproducibility factor is missing, label the claim accordingly. For example, “the artifact launches on this machine” is a limited execution observation, not proof of a reproducible build process.

1224. Concrete example

Suppose a team produces a playable package for a small game slice. The statement “It runs here” is supported by one person launching it on their development computer. That statement leaves several questions unanswered:

• Which source and asset inputs produced the package?
• Is the package the intended artifact, or an older local output?
• Which Git commit or tag identifies the source state?
• Which tool and runtime versions were used?
• Which configuration and build procedure were used?
• Was the artifact tested in a clean or otherwise specified environment?
• What behavior was checked after launch?

A stronger minimum gate might be:

• identify the input set and record the known commit or tag associated with it;
• name the output artifact and where it was produced;
• optionally record a checksum, immutable artifact ID, or uniquely versioned filename to identify the evaluated bytes;
• record the relevant tool, configuration, procedure, and runtime environment;
• launch the artifact from the declared output;
• verify that the expected entry point appears;
• exercise one defined critical path and record pass or fail;
• retain enough evidence for another person to repeat the check.

For example, an evidence note could identify build-slice-a-01.zip, its checksum, the declared asset manifest, and a placeholder repository reference such as commit abc1234 or tag build-slice-a-01. The repository reference is meaningful only if it is the known revision selected for this hypothetical build. The checksum identifies the archive evaluated, but neither value alone establishes the complete provenance of the build.

This does not claim that every possible defect has been found. It claims only that the declared build conditions and checks were satisfied for the identified source state and artifact.

1225. Common mistake

The common mistake is treating a successful local launch as proof of reproducibility. A local launch can be evidence for one gate, but it does not identify the inputs, distinguish the artifact from other local outputs, establish the environment, document the build procedure, or tie the result to a known Git state.

Another mistake is recording a branch name such as “main” without a commit or tag. A branch can move, while the evidence must identify the source state being evaluated. A generic artifact path can also be overwritten; use an immutable identifier when exact artifact identity matters. Remember that identifying the artifact does not establish its provenance.

A further mistake is making the gate so broad that it becomes untestable, such as “the game works correctly.” Replace broad claims with observable checks tied to the purpose of the build.

1226. Guided practice

Create a minimum build-evidence specification for a hypothetical game slice. Do not build or modify a project. Make the following decision first: Which single behavior is important enough to be part of the minimum acceptance gate, and which behaviors are explicitly outside this gate?

Then complete this table:

Review your specification against these questions:

1. Could another person identify the exact artifact being evaluated?
2. If you used a checksum or artifact ID, have you avoided treating it as proof of build provenance?
3. Is the artifact tied to a known commit or tag rather than only a moving branch or local folder?
4. Could another person distinguish the declared inputs from an accidental local dependency?
5. Does the environment and procedure description include conditions that could change the result?
6. Can every gate be observed as pass or fail without relying on confidence or hearsay?
7. Does the gate protect the purpose of this build without pretending to validate the entire game?

1227. Validation / evidence

Your evidence is a completed I-A-E-G table plus a Git reference and the relevant reproducibility factors, followed by a short acceptance statement of three to five sentences. The statement must name the artifact, identify the known commit or tag associated with the declared source state, identify the relevant dependency, tool, configuration, procedure, and environment factors, connect the artifact to its inputs and environment, and state the observable conditions under which it is accepted. It must also identify at least one condition outside the scope of this gate.

If exact artifact identity matters, include a checksum, immutable artifact ID, or uniquely versioned filename and state that it identifies the evaluated artifact rather than proving how it was produced.

A satisfactory result has no vague gate such as “works correctly” without a defined observation. It separates the artifact from the environment, distinguishes a passed check from a complete guarantee about the game, and makes the claim traceable to a specific Git reference. The practice remains a specification exercise: do not modify a project or create a build.

1228. Key takeaways

• I-A-E-G organizes an acceptance claim into inputs, artifact, environment, and gate.
• Reproducibility depends on sufficiently identified source state, dependencies, tool versions, configuration, build procedure, and relevant environment; it is not the same as passing an acceptance gate.
• A known Git commit or tag identifies the source state, but it is neither a fifth I-A-E-G category nor proof of reproducibility.
• A checksum, immutable artifact ID, or uniquely versioned filename can identify the evaluated artifact, but it does not prove build provenance.
• A local launch is evidence of a limited check, not automatic proof of a reproducible build.
• A build gate should state what is checked, how it is observed, and what remains out of scope.

1229. Next lesson

Next, continue with 3.10 L2 — Define a clean-build gate to write and execute a clean-build checklist and record whether the declared artifact and acceptance checks produce the expected observable result.

1230. Knowledge check