Audit an asset set

1204. Lesson identity

Module

3.9 — Assets

Lesson

Audit an asset set

Academic type

Workflow

Schema type

Mixed

Order

Lesson 2 in the module

Estimated total

45–60 minutes

This lesson turns asset intake into an auditable production decision. You will inventory an asset set, create requirement-level validation records, retain traceable evidence, derive accurate asset statuses, and prioritize corrective actions.

1205. Learning objective

After this lesson, you can produce an asset audit with complete intake records, requirement-level checks, evidence-supported statuses, and actions prioritized by production impact.

1206. Why this matters

A file can exist and still be unusable, unlicensed, incorrectly referenced, excluded from a build, duplicated, or unsuitable for its runtime role. A repeatable audit makes those conditions visible before they become runtime or build failures.

The audit is not merely a folder listing. It consists of three connected records:

1. Asset manifest: what is in scope and what each asset is supposed to do.
2. Validation records: one record for every requirement checked.
3. Action list: what must happen next, why it matters, and what information supports its priority.

AI can challenge the completeness and consistency of these records, but it cannot provide evidence for files or systems it has not inspected.

1207. Core model: Manifest → Checks → Evidence → Status → Action

A status without evidence is an assertion. Evidence without a named requirement is an isolated observation. An action without production context cannot be assigned a defensible priority.

1208. Record 1: baseline asset intake

Create one manifest entry per asset. Group entries only when the assets share the same role, source, constraints, ownership, and validation path, and record why grouping is safe.

Use this compact baseline checklist:

Use N/A only when a field genuinely does not apply, and record the rationale. Missing information is not N/A; it is unresolved.

A practical manifest schema is:

Asset ID | Name/version | Intended role | Source/license record | Location | Runtime owner | Duplicate/unused state | Build expectation

The manifest may link to validation records rather than placing every test in one wide row.

1209. Record 2: requirement-level validation

Do not combine several requirements into a single result. Create one check record for each asset-and-requirement pair:

Check ID | Asset ID | Requirement | Method | Evidence | Result | Corrective action

Use these result terms:

• Pass: the recorded evidence satisfies this requirement.
• Fail: the evidence shows that the requirement is not satisfied.
• Needs review: available evidence is insufficient or conflicting.
• N/A: the requirement does not apply, with a recorded rationale.

If a production template requires canonical tokens, use pass, fail, needs_review, and not_applicable as field values while displaying the readable labels above.

Evidence should identify what another person could inspect: a measured property, a test result, a reference-path check, a license record, a build report, or a documented absence. “Looks fine” is not sufficient evidence unless the requirement and inspection conditions make that observation meaningful.

Deriving the overall asset status

Derive an asset status from its individual checks:

• Fail: at least one required check fails.
• Needs review: no required check fails, but at least one required check remains unresolved.
• Pass: every applicable required check passes and every N/A result has a rationale.

An asset cannot pass because one check succeeded. For example, a valid format does not prove correct scale, reference integrity, licensing, or build inclusion.

1210. Worked example

Assume ENV-01 is an environment prop expected in the next integration build.

Manifest entry

Validation records

ENV-01 is therefore Needs review, not Pass: its format passed, but three required checks remain unresolved. The audit does not claim that the asset must be replaced because the evidence supports investigation, not replacement.

1211. Prioritizing actions without manufacturing certainty

Priority reflects production consequence and timing, not visual prominence or uncertainty alone.

Use this policy:

• P1 — blocker: prevents a required integration, release, or safety-critical decision now; no acceptable substitute or workaround is available.
• P2 — time-bound risk: does not block the current step but must be resolved before a named near-term milestone or dependency.
• P3 — routine correction or cleanup: can be scheduled without threatening the stated milestone.

Equal priorities are allowed. Do not force a strict P1/P2/P3 ordering when the evidence does not distinguish the actions. Record missing decision information, such as milestone date, feature criticality, substitute availability, downstream dependencies, owner availability, or cost of delay.

1212. Guided practice

Use only the observations and production context below.

Production context

• The next integration build is due tomorrow.
• WORLD-01 is required for a collision test in that build, and no substitute is currently recorded.
• HUD-01 is needed for a review next week; a temporary icon is already available.
• SFX-01 is already referenced by the current interaction test. Its file plays correctly, but the ambiguous name creates maintenance risk rather than a current runtime blocker.

Intake observations

HUD-01: status icon; PNG; 64 × 64; preview available; appears readable; source and license record linked; temporary substitute available.
WORLD-01: small environment prop; model file present; intended scale not recorded; no in-context preview; required tomorrow for collision testing; no substitute recorded.
SFX-01: interaction sound; audio file present; playback confirmed; current reference resolves; filename does not identify the event.

For each asset:

1. Create the baseline manifest fields. Mark missing information as unresolved rather than N/A.
2. Write separate check records for every requirement you evaluate.
3. Assign each check a method, evidence, result, and corrective action.
4. Derive the asset status from its checks.
5. Prioritize the actions using the stated policy.
6. Identify any missing information that prevents a stronger decision.

A defensible response may classify the WORLD-01 scale test as P1 because it blocks tomorrow’s required collision test and no substitute is recorded. HUD-01 may be P2 or P3 depending on the stated review requirement. Renaming SFX-01 is likely routine unless additional dependency information changes its consequence. These are conclusions from the supplied context, not universal priorities.

1213. AI-native workflow

Use AI as a structure reviewer, not as a source of observations:

1. Define the intake fields and acceptance requirements yourself.
2. Record observations, measurements, test results, and documented absences.
3. Give AI only the audit records you want reviewed.
4. Ask it to flag missing baseline fields, combined requirements, unsupported pass results, mismatched actions, and weak priority rationales.
5. Verify every suggestion against your evidence and production context.
6. Retain rejected or revised suggestions when they clarify your decision process.

Example prompt:

Review this asset audit without inventing file properties or test results. Check whether each requirement has its own method, evidence, result, and corrective action. Flag unsupported pass results, missing intake fields, unexplained N/A values, and priorities that lack milestone or dependency context.

1214. Common mistakes

• Combining format, scale, readability, and licensing into one aggregate check.
• Marking an asset Pass because its file opens or one requirement succeeds.
• Treating missing evidence as N/A.
• Omitting source, license, reference path, runtime owner, duplicate status, or build inclusion.
• Presenting a recommendation as if it were an observed fact.
• Assigning P1 merely because an asset is visible or uncertain.
• Forcing unique priorities when the available context supports a tie.
• Allowing AI to invent validation evidence.

1215. Independent practice and practical assessment

Complete the linked practical assessment using a small asset set from your exercise or a clearly labeled invented set. Produce:

• A baseline manifest covering every in-scope asset.
• Requirement-level validation records with unique Check IDs.
• Traceable evidence and accurate check results.
• Derived overall asset statuses.
• A corrective action list with priority rationales and missing decision information.
• A short handoff identifying build blockers and evidence suitable for the next build gate.

The practical assessment is scored. An unsupported Pass result prevents passing even if the numerical score would otherwise be sufficient.

1216. Validation and handoff

Before completing the audit, verify that:

• Every asset is represented or covered by a justified grouping rule.
• Identity, version, provenance, license, naming, location, constraints, budget, references, lifecycle ownership, duplicate or unused state, and build inclusion are recorded or explicitly unresolved.
• Every evaluated requirement has its own method, evidence, result, and action.
• Every N/A result includes a rationale.
• Overall statuses follow from individual check results.
• Priorities cite milestone timing, dependency impact, substitute availability, or explicitly missing decision information.
• Facts, assumptions, open questions, and recommendations remain distinct.

Carry the completed manifest, requirement-level validation records, unresolved blockers, and prioritized actions into 3.10 — Build pipeline as candidate build-gate evidence. A build that runs locally may still be unacceptable when required asset checks, license records, references, or build-inclusion evidence remain unresolved.

1217. Knowledge check