> For the complete documentation index, see [llms.txt](https://postica.gitbook.io/binding-system-3/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://postica.gitbook.io/binding-system-3/project-tools/diagnostics/validator.md). # Bindings Validator Every binding in the project, resolved and checked before you ship. {% hint style="success" %} **Learn by doing:** [Auditing a Project Before Release](/binding-system-3/tutorials/audit.md) runs this over a real project and works through what it finds. {% endhint %} A broken binding does not throw. It sits in a scene, correctly configured except for the one part that stopped being true, and does nothing until something reads it. In practice that means until somebody plays the scene it lives in, which on a large project can be weeks after the change that broke it. The validator is the pass that finds those. It resolves every serialized binding the way the runtime would, and where the runtime would fail it says so, in words, with a route to the binding.

**Window ▸ Binding System ▸ Bindings Validator** ## What it is not It is worth being clear about the boundary, because there are three project-wide tools in this section and they answer different questions.

Tool	What it answers
Bindings Dependencies	What exists. Every binding in the project, grouped by source and path. Reports the structurally incomplete ones, the empty source and the empty path, because those are visible in the data itself.
Bindings Validator	What is wrong. Walks each path against its source type, checks the direction against the member it lands on, and inspects the converters and modifiers in between. Finds the bindings that look complete and are not.
Refactoring	What to do about a rename. Takes the members the validator found missing and redirects every binding of each, in one decision per member.

The validator finds a binding whose path stopped resolving three components deep. The dependencies window cannot: from the data alone, that binding looks perfectly configured. Neither reports a *wrong value*. A binding pointing confidently at the wrong member is valid. For that, [Live Debug](/binding-system-3/project-tools/diagnostics/live-debug.md) at runtime or [Path Value Preview](/binding-system-3/project-tools/diagnostics/path-value-preview.md) while authoring. ## Choosing a scope The dropdown in the header picks how much is looked at.

Scope	What it covers
Active Scene	The scene you are working in. Fast, and the one to reach for while building something.
Open Scenes	Every scene currently open, which for a multi-scene setup is the useful unit.
Build Scenes	Every scene listed in build settings, open or not. The question "does what ships work".
Whole Project	Every scene, prefab and asset. The release pass.
Selection	What is selected in the Hierarchy or the Project window. Folders contribute everything inside them, so one feature folder is one scope.

**Selection** is also reachable without opening the window first: right click a GameObject, a component header or an asset and choose **Binding ▸ Validate Bindings**. ## Running it Press **Validate**. The button becomes **Stop** and a progress bar appears.

A whole-project run in progress, with the asset it is on and a stop button

A whole-project run is deliberately slow, because it loads things. It is also interruptible at any point, and stopping produces a report of everything reached so far, marked as incomplete rather than pretending to be a clean bill of health. The run happens in three phases, which is why the progress bar moves the way it does: 1. **Collecting.** The asset list, on the main thread. Brief. 2. **Looking for bindings.** Every candidate file is read on background threads and checked for the marker every serialized binding carries. Most assets in a project have no binding in them at all and are dropped here without ever being loaded. This is what makes a whole-project run affordable; the status bar reports how many were skipped. 3. **Validating.** Only the files that survived are loaded and walked, a few per frame, so the editor stays usable. ### It writes nothing A validation reads. It does not save a scene, mark one dirty, or write a single asset, and it never asks permission to start because there is nothing to ask about. That is not just tidiness. Writing an asset runs the import pipeline, an import picks up any script edit sitting on disk, and the compilation that follows ends in a domain reload, which would take the run and everything it had found with it. A tool whose job is to look at a project has no business restarting the editor. The same care applies to the scenes it opens:

The scene is	What the validator does
Open and loaded	Read where it is. Your unsaved edits are read as you see them, which is the point.
In the setup but unloaded	Loaded, read, and unloaded again. It stays in the setup.
Not open at all	Opened additively, read, and removed again.

Because nothing already open is ever unloaded, no unsaved work is ever at risk. While a run is going, Unity's automatic asset refresh is held back, so a script you edit in the middle of a pass compiles when it finishes rather than ending it. If a reload happens anyway, for a reason outside the validator, the run takes itself up again on the other side and the result it had is kept. ### Scenes that are not open A scene has to be open for its bindings to be inspected properly, because a converter or a modifier is a `[SerializeReference]` slot whose contents only exist once Unity has deserialized them. So by default the validator **opens closed scenes one at a time**, validates them, and puts them back exactly as it found them, whether it finishes or you stop it. {% hint style="info" %} If you would rather it did not touch your scenes, turn off **Open closed scenes** in the [options panel](#choosing-what-to-check). Those scenes are then read from their files instead. Broken paths, missing types and direction conflicts are still found exactly, because everything a path needs is written in the file; converters, modifiers and object identity are not looked at. Findings from such a scene say so, both on the row and in the detail panel, and the status bar counts them. {% endhint %} In play mode the validator never opens scenes, whatever the setting says. Nothing can be written while the game runs, and the objects in front of it are clones rather than the assets themselves. ## Reading the result ### The summary Three chips: errors, warnings and hints. Each is also a filter; click one to hide that severity.

Severity	What it means
Error	The binding cannot work as configured. Something will silently do nothing in the build.
Warning	It works, but probably not the way it was meant to. An empty modifier slot, a modifier that never runs, a bind variable nothing declares.
Hint	Never wrong, worth knowing. A long path walked every frame, a method called on every update.

The right-hand chip counts what was actually checked, and the status bar at the bottom carries the rest: how long it took, how many assets were skipped for holding no bindings, how many scenes were read from file only, and whether the run was stopped early. ### The grouping By default findings are grouped **by problem**, not by asset. One member renamed breaks a lot of bindings, and reading the same sentence forty times helps nobody: the group header states the problem once and carries the count. Click a header to collapse it. The **Group** dropdown offers the other useful orderings: **by asset** for a per-scene sweep, **by severity** when you only want to see errors first, and **none** for a flat list. ### The detail panel Select a row.

A broken path, with the segment that stopped the walk marked

Part	What it shows
The explanation	What is wrong, naming the types and members involved.
The suggestion	What can be done about it, in one sentence.
Binding	The source type, the direction, and the path broken into its segments. The segment that stopped the walk is highlighted, which for a long path is the whole answer.
Where	Asset, object, component and field. Enough to find it by hand if you would rather.

**Show me** selects the object and highlights the bound field, opening its scene when needed. That is the button to use; the **Where** block is there so you can also just read it. ## Repairing Each finding offers the repairs that fit it, and only those. Anything that would have to guess what you meant is not offered here; it goes to [Refactoring](/binding-system-3/project-tools/diagnostics/refactoring.md), which asks first.

Repair	What it does
Switch off	Turns the binding off. The field keeps the literal value it already holds, so nothing is lost. Offered for every finding where the binding cannot work at all.
Make read only / Make write only	Narrows the direction to the one the member actually supports.
Remove modifier	Deletes the exact slot the finding is about.
Remove converter	Clears a converter slot whose type is gone.
Clear source	Removes a reference that cannot be serialized, keeping the path.
Delete binding	Removes a proxy binding entirely.

Every repair goes through undo and marks the right scene or asset dirty. ### Repair safe findings The toolbar button applies, in one undo step, every repair that **cannot lose any of your work**: switching off a binding that could never resolve, removing an empty modifier slot, narrowing a direction that was never going to work. You are told how many before anything happens. Repairs that are destructive are deliberately excluded from it. Clearing a source loses the reference; deleting a proxy loses the binding. Those stay one click at a time. ### Refactor renamed members The other toolbar button collects every finding about a member that was **renamed or moved**, hands them all to the [Refactoring](/binding-system-3/project-tools/diagnostics/refactoring.md) window and opens it. One decision per member then redirects all of their bindings at once, including the ones in scenes that were never opened. This is the pairing that matters after a big rename: the validator finds them, the refactor window fixes them. ## Choosing what to check The button beside the scope dropdown slides a panel in over the results.

The options panel, sliding in over the findings

Each group of checks is a toggle with a sentence under it saying what it costs you to turn it off. Everything except **Correctness** is optional: a healthy project can still be full of hints, and a pass that only asks "does this work" is a legitimate thing to want. **Performance** carries one number as well as a toggle, **Deep path after**, which is how many segments a per-frame binding may walk before it earns a hint. Five by default. **Precision** holds **Open closed scenes**, described [above](#scenes-that-are-not-open). Nothing here re-runs anything. Options apply to the next run, and the panel says so; once you have changed one with a report on screen it says something firmer, because findings from a previous run are not an answer to the question you just asked. **Validate again** at the bottom closes the panel and re-runs the current scope. Your choices are remembered between sessions. ## What it checks ### Source

Finding	What it means
No source assigned	Switched on, needs a directly assigned source, and has none.
Source object is missing	The reference points at an object that is no longer in the project. Different from never having assigned one, and worth telling apart.
Source type no longer exists	The script the binding was saved against was deleted, renamed or moved to another assembly.
Source is not of the expected type	The path was authored against one type and the assigned object is another.
Source lookup key is empty	A dynamic source mode is configured with nothing to look the source up by.
The type this binding carries no longer exists	The binding's own declared type is gone, whatever its path does.

### Path

Finding	What it means
Nothing to bind to	Switched on with no path picked.
Path no longer exists	A segment names a member that is gone. The finding says which segment, and on which type. This is the one Refactoring exists for.
Method no longer exists	Same, for a method whose name or parameter list changed.
Accessor provider is not registered	The path goes through an accessor provider that nothing registers any more.
Cast can never succeed / Cast target type no longer exists	A cast segment naming a type the value can never hold, or one that has been deleted.
Bind variable is not declared	No variable by that name is registered. A warning rather than an error, because a variable can be registered from code and only exist once the game runs.

### Read and write direction

Finding	What it means
Member cannot be written	The binding writes to something with no setter.
Member cannot be read	The binding reads something write only.
Write cannot reach the target	The subtle one. Writing `transform.localPosition.x` means writing the whole `Vector3` back into `localPosition`. If a value type halfway down the chain has no setter, the write cannot get home, even though the member at the end is perfectly writable.

### Type conversion

Finding	What it means
No read conversion available	The path produces one type, the binding carries another, and nothing converts between them. Checked separately for each direction, because a read/write binding needs both.
The read converter does not fit	A converter is set but its two ends do not match the types it sits between.
Read converter type is missing	A converter was saved and its class is no longer in the project.

### Modifiers

Finding	What it means
Modifier slot is empty	A slot holding nothing. Skipped at runtime, so a warning.
Modifier type is missing	A modifier was saved and its class is gone. This is the case renaming a modifier class produces, and it is the only tool that reports it.
Modifier cannot handle this value	Applied to a type it does not accept.
Modifier never runs	A read-only modifier on a write-only binding, or the other way round.

### Cross scene references

Finding	What it means
Binding crosses two scenes	Unity does not serialize references across scenes, so this one is lost on save.
Asset binding points at a scene object	Same problem in the other direction: a prefab or asset referring to something that only exists in a scene.

### Proxy bindings A [proxy binding](/binding-system-3/overview/proxy-bindings.md) has two ends, the member it writes into and the value it reads, and they break independently. Every check above applies to the value end. These apply to the other one, or to the pair.

Finding	What it means
Proxy binding has no target	It points at no object at all. It does nothing at runtime.
Proxy binding has no target member	It points at an object but names no member on it.
Proxy binding target no longer exists	The member it writes into was renamed, moved or deleted. This one goes to Refactoring like any other missing member.
Proxy binding was never finished	Switched off, with no source and no path. This is the state Enable Binding leaves behind when somebody adds a binding to a field and walks away, and nothing else reports it, because from the outside it looks exactly like a field with no binding at all.
Proxy binding has no value to read	The same emptiness, but switched on. It runs every frame and writes nothing.
Two proxy bindings drive the same target	The container looks its proxies up by target, so only one of the two is reachable, and which one depends on load order.
Proxy binding reads what it writes	A proxy taking its value from the very member it writes into. At best a no-op, at worst a feedback loop through the modifier chain.
Empty proxy binding slot	The list holds a slot with nothing in it.

{% hint style="info" %} A proxy finding is only ever offered one repair, **Delete binding**, and it is never counted as safe. An ordinary binding can be switched off and keep the literal value the field already holds; a proxy has no value of its own, so there is nothing to fall back to and removing it is the only honest option. Both ends are checked on proxies held by a `ProxyBindings` component in a scene and by a **Proxy Bindings Asset** in the project. {% endhint %} ### Performance hints

Finding	What it means
Long path evaluated every frame	A per-frame binding walking five or more members.
Method called every frame	A per-frame binding whose path goes through a method call.

Neither is wrong. Both are worth a look with the [Bindings Monitor](/binding-system-3/project-tools/diagnostics/bindings-monitor.md), which is the tool that actually measures cost. ## Exporting a report The **Report** menu copies the findings to the clipboard, prints them to the console, or saves them as a text file. The report is grouped by asset, so it reads as a to-do list rather than a log, and it carries the counts, the timing and the note about scenes read from file only. ## Running it on a build machine A broken binding is exactly the kind of mistake continuous integration should catch, so the whole validator is reachable without a window: ```bash Unity -batchmode -quit -projectPath \ -executeMethod Postica.BindingSystem.Validation.BindValidationBatch.ValidateProject ``` `ValidateBuildScenes` is the narrower entry point, covering only what is in build settings.

Argument	What it does
`-bindValidationStrict`	Fail on warnings as well as errors.
`-bindValidationReport <path>`	Write the full report to a file as well as to the log.

The process exits with `0` when nothing is wrong and `1` when there are errors, or when the run did not finish. Progress is written to the log every ten percent. ## Nothing found

An empty list is four different results, and the window tells them apart rather than showing one green tick for all of them. This matters more than it sounds: "nothing is wrong" and "nothing was looked at" produce exactly the same list.

What it says	What it means
No problems found	The real one. It carries how many bindings were checked and across how many assets, which is the number that makes it trustworthy.
No bindings here	Assets were opened and none of them holds a binding. Nothing was validated because there was nothing to validate.
Nothing was scanned	The scope itself was empty. Selection needs something selected, and Active Scene needs a scene that has been saved at least once.
Stopped early	You pressed Stop. Whatever was reached is reported, and the result is explicitly not the whole picture.

### Not everything was read One more, and it is the one to report rather than to act on. Every candidate file is checked for bind data twice, once as text during the scan and again as objects while validating, and the two disagreeing means the second pass has a blind spot. When that happens the window says so instead of claiming a clean result, and the status bar counts the assets involved. Save the report to see which ones they are, and send it on. ## Settings **Project Settings ▸ Binding System ▸ Configuration ▸ Bindings Validator** carries the same two entry points, **Validate Active Scene** and **Validate Project**, so a pass can be started from the place where the rest of the project's binding configuration lives. ## Related pages * [Refactoring](/binding-system-3/project-tools/diagnostics/refactoring.md): what to do about the members it found missing. * [Bindings Dependencies](/binding-system-3/project-tools/diagnostics/dependencies.md): what exists, rather than what is wrong. * [Error Visualization](/binding-system-3/project-tools/diagnostics/errors.md): the same problems, reported on the row while you author. * [Bindings Monitor](/binding-system-3/project-tools/diagnostics/bindings-monitor.md): the tool that measures cost, for the performance hints. * [Auditing a Project Before Release](/binding-system-3/tutorials/audit.md): the full pass, in order.