An asset is a production dependency

1189. Lesson identity

Module

3.9 — Assets

Lesson

An asset is a production dependency

Academic type

Concept

Schema type

text

Order

Lesson 1 in the module

Estimated time

30–40 minutes, including practice

1190. Learning objective

After this lesson, you can identify the risks in an asset dependency and specify evidence or controls for its naming, format, production accountability, runtime resource ownership, loading, and validation.

1191. Why this matters

An asset is not merely a file placed in a project folder. A texture, sound, font, model, or data file becomes part of the game’s production system when code or content depends on it. A dependency can fail before runtime because its name is ambiguous, its format is unsuitable, or its ownership is unclear. It can also fail during loading, replacement, or cleanup, or produce an incorrect result that is not detected by a superficial test. Treating assets as managed inputs gives you a way to direct AI-generated code and evaluate whether the resulting game is actually using reliable inputs.

1192. Prior knowledge

You should be able to describe a bounded lifecycle failure from Module 3.8, including an initial state, expected result, actual result, and repeated outcome. Incorrect load timing, replacement, unloading, or cleanup can be documented with that same lifecycle evidence. You should also be comfortable distinguishing a failure in an input from a failure in the rule that processes it.

1193. Working vocabulary

• Clean checkout: a fresh copy of the project obtained from its version-controlled source, without relying on untracked local files or prior generated state.
• Authoritative source: the designated source whose version should be used when copies disagree; it is the source of reference for replacement and maintenance decisions.
• Import requirement: a setting or transformation the engine or content pipeline must apply so that the source file becomes a usable game resource.
• Runtime: the period when the game or application is executing.
• Runtime resource ownership: responsibility within the engine or loading system for retaining a loaded resource, deciding when it may be replaced or unloaded, and verifying its cleanup. This does not mean legal ownership of the file.

1194. Core concept

An asset dependency has a production contract. The contract answers five main questions:

1. Naming: What exact identifier or path does the consumer request?
2. Format: Can the target system read the file and interpret it as intended, including its import requirements?
3. Ownership: Who or what is accountable for the source asset, and who or what manages the loaded resource at runtime?
4. Loading: When and through which mechanism does the game obtain, retain, replace, and release it?
5. Validation: What evidence proves that the loaded result is present, compatible, correct for its use, and cleaned up as intended?

If one answer is missing, the dependency is only partially specified. The code may still appear reasonable while the game remains fragile.

Ownership has two distinct dimensions:

• Production accountability or provenance: the person, team, system, or authoritative source responsible for providing, approving, and maintaining the asset file.
• Runtime resource ownership: the engine component, loading system, scene, cache, or other runtime mechanism responsible for retaining the loaded resource and determining when it can be replaced, unloaded, or released.

The exact runtime responsibilities depend on the engine and loading system. If the system manages them automatically, the contract should say system-managed and name the observable check used to verify replacement, unloading, or cleanup. Do not infer lifecycle safety merely because no manual release call is visible.

A useful distinction is:

• Presence: the file exists somewhere.
• Availability: the game can locate and load it through its intended path.
• Correctness: the loaded asset has the required format, dimensions, content, and behavior.
• Lifecycle safety: the resource is retained for as long as it is needed and can be replaced, unloaded, or cleaned up according to the intended lifecycle.

These are different claims and require different evidence.

1195. Mental model

Use the asset dependency chain:

Do not collapse these questions into “the asset is there.” A file can pass a presence check and fail an availability, correctness, or lifecycle-safety check.

1196. Concrete example

Suppose a menu displays a warning icon. The implementation depends on an image named warning-icon.

• The naming contract might require ui/warning-icon.png, with the exact capitalization used by the target environment.
• The format contract might require a PNG with transparency, a known pixel size, and specified import settings.
• The production accountability contract might identify the UI asset directory as the authoritative source and name who approves replacements, rather than relying on a copied file in a temporary folder.
• The runtime resource ownership contract might identify the menu’s resource cache as responsible for retaining the icon while the menu is active and releasing or replacing it through the loading system. If the engine manages this automatically, the contract records that fact and specifies how cleanup or replacement is verified.
• The loading contract might require the image to be available before the menu is shown.
• The validation contract might require opening the menu in a clean run, confirming that the icon appears with transparency at the expected size, replacing or closing the menu as applicable, and checking the expected lifecycle result.

A missing file is only one possible failure. A file with the wrong capitalization, an opaque background, a load that occurs after the menu renders, or an old resource retained after replacement can produce different failures even though the path appears plausible.

1197. Common mistake

The common mistake is treating a successful file lookup as proof that the dependency works. A lookup proves only that something was found at a location. It does not prove that the format is compatible, that the correct source was used, that loading occurs at the right lifecycle point, that the loaded resource remains available for the required duration, or that the game presents the intended result.

Another mistake is assigning production accountability to “the project” or “the AI.” A tool can generate a file or suggest a path, but accountability still belongs to the production process. Someone must define the expected contract and verify the result.

A related mistake is assuming that production accountability also identifies the runtime owner. The person maintaining an image is not necessarily the system retaining its loaded resource. Record both responsibilities, or explicitly mark runtime lifecycle management as system-managed and verified.

1198. Guided practice

Review this dependency description:

The pause screen uses pause.png. It is stored in an assets folder, loaded when the pause screen opens, and checked by confirming that the file exists.

1. Identify one risk in each contract area: naming, format, production accountability, runtime resource ownership, loading, and validation.
2. Choose the highest-risk issue for a game that must run from a clean checkout. Explain why it has greater impact than the other issues.
3. Rewrite the description as short contract statements. Each statement must name either a requirement or observable evidence.
4. Record the runtime owner responsible for retaining, replacing, unloading, or releasing the resource. If the lifecycle is system-managed, write that explicitly and define how you would verify it.
5. Mark which statements remain unverified if you do not have access to the actual project, engine configuration, or asset file. Do not infer evidence from the description alone.

A strong answer might prioritize an unclear authoritative source, an unspecified format, or an unverified runtime lifecycle rather than assuming that the existence check covers them. The important decision is to rank risk and justify the ranking, not merely to list possible defects.

1199. Validation / evidence

Your evidence is an asset dependency review containing:

• one explicit naming requirement;
• one format or import requirement;
• one accountable production owner or authoritative source;
• one runtime resource owner, or an explicit system-managed designation with a lifecycle verification check;
• one loading point or mechanism;
• one validation procedure with an expected result;
• at least two identified dependency risks; and
• a risk ranking with a written reason for the highest-ranked risk and a corresponding control or observable check.

The review is complete only when it distinguishes claims that are known from claims that still require verification. If another developer can use your review to check the dependency without guessing what “works” or “owned” means, the capability is demonstrated.

1200. Key takeaways

• An asset becomes a production dependency when another part of the game relies on it.
• Presence, availability, correctness, and lifecycle safety are separate claims.
• Naming, format, ownership, loading, and validation form the dependency contract.
• Production accountability identifies who maintains the asset or its authoritative source; runtime resource ownership identifies who or what retains, replaces, unloads, or releases the loaded resource.
• System-managed runtime ownership must still be recorded and verified.
• A file lookup is not proof that the game can use and clean up the intended asset correctly.
• Good asset management makes risks explicit and gives each risk observable evidence.

1201. Practical assessment

Complete Asset dependency risk and control review. You will analyze a bounded scenario, identify and rank dependency risks, and write a control or observable check for the highest-ranked risk. The project criteria provide the scoring rubric.

1202. Next lesson

Continue to 3.9 L2 — Audit an asset set / Auditar un conjunto de assets.

1203. Knowledge check