Validation and the authored-system checklist

Authored data can be wrong in ways code never is: a missing reference, a negative cooldown, two items with one ID. A validation pass finds that in the Editor, before Play mode or a build does.

The validation pass

• ONE-VALIDATOR-PER-DATA-TYPE (HARD). Every authored data type gets a validator: a plain static method that takes the asset and returns a list of problems (asset path, field, message). It has no UI of its own, so the same method runs from a menu item, an editor window, a test and an agent's automation.
• Validate the whole project from one entry point. A menu command finds every asset of each validated type (AssetDatabase.FindAssets("t:TypeName")), runs its validator and prints one line per problem with the asset path, so clicking the log line leads to the asset. The agent runs this command after every content change and reports the count.
• What to check. Missing required references; values out of their allowed range; duplicate IDs across assets of a type; references to assets in a folder that is not shipped; enum or ID values that no longer exist; empty lists that must not be empty; prefab variants whose base is missing.
• Show it where the human looks. The custom inspector or editor window for a type calls the same validator and shows its problems at the top. A human who opens the asset sees what is wrong without running anything.

OnValidate is for clamping, not for the pass

• OnValidate is useful for keeping a single changed value in range. The OnValidate reference states it is called when the script loads or a value changes in the Inspector, at stages such as loading scenes, building a player and entering Play mode, possibly from threads other than the main thread, and that it should only validate the data that changed, not create objects or call other non-thread-safe Unity API.
• So OnValidate clamps and normalises one asset's own fields. Cross-asset checks (duplicate IDs, missing targets) belong in the validator pass, not in OnValidate.

Gate builds and commits on it

• Run the project validator before a build and fail the build on any problem, the same way the compile check gates code.
• An agent never reports a content change as done while the validator reports problems it introduced. Pre-existing problems are listed separately in the report, not silently fixed in the same change.
• Before committing, check that every new or moved asset has its .meta file. The Asset metadata page states references to an asset break when its .meta is lost.

The checklist an agent runs before building any new system

Run this before writing the first line of a new system, and record the answers on the system's blueprint (see the system blueprint page). Every "no" is either fixed in the design or asked about in the user's CLI before work starts.

1. Can a human see this system's data in the Editor without entering Play mode? If the data only exists at runtime, move it into an asset or bake it.
2. Can a human change every tunable value in the Inspector, without editing C#? Name the asset and field for each tunable.
3. Is each piece of content its own asset (or prefab, or variant), with a Create menu entry or a duplicate path?
4. Are references between assets serialized fields or AssetReferences, not strings looked up at runtime?
5. If content comes from outside Unity, does an importer turn it into visible assets, with its settings in the Inspector?
6. If anything is generated, are its parameters an authored asset, and is its output baked into committed assets (or, for per-session generation, inspectable through a debug view)?
7. Does a validator exist for each new data type, and does it run from the project-wide validation command?
8. Is everything text-serialized (Force Text) with its .meta committed, so the change is a readable diff?
9. Is there an editing surface (default Inspector, custom inspector, drawer or window) a designer can use, per the Editor tooling page?
10. Is the procedure for making the next instance written down? For a category with more than one instance, record it as a content pipeline.

If any answer is "no" and the user has not accepted it, the system is not ready to build.

Questions the agent asks in the CLI

The site does not collect answers. When the checklist needs a decision, the agent asks in the user's CLI, for example:

• "Should this data be edited in the default Inspector, or do you want a dedicated editor window for the whole catalog?"
• "This generator could bake its output into a prefab you can edit, or run fresh every session. Which do you want?"
• "Do you use Addressables in this project, or should these be direct references?"

Related

• Authored over generated: the default this checklist enforces.
• Unity programming: C# standards and object lifetimes for the code that reads the data.