It tells you what is wrong.
It does not stop you.

Case does not matter, so .PNG is a texture. What does matter is the gap in the last row: the file dialog offers .fbx and .obj under "Models", and the model importer accepts both — both verified — but the type detector has no case for either.

So those two import successfully, appear in the index, and are labelled unknown. Nothing is broken and nothing warns; they simply will not be found by anything looking for a model. Convert them to glTF before importing and the problem disappears.

The two doing the most work are output and hash. A relative output path means the index survives the mod being moved or shared; a real content hash means a consumer can tell a changed asset from an unchanged one without opening it. That pairing is how Vault does change detection.

Verified with a queue of four, of which two finished: the index held exactly two entries. The other two left no trace in it at all — not an entry marked failed, simply nothing.

Which means a queue that looks mostly successful can produce a much shorter index, and the queue is the only place the failures are visible. If a consumer cannot see an asset you are sure you imported, the index is the place to look first and the queue is the place to look second.

All of them go through the same shared reader, and so does Refinery when it merges — deliberately, so that what the writer sees is exactly what the consumers see rather than two parsers that could disagree.

It also means an asset's absence from the index is felt across five tools at once, which is why the failure modes on this page are worth recognising early.

What the checks produce is warnings on a successful import. They are advice attached to a result, not conditions on it, which makes them easy to miss precisely because nothing went visibly wrong.

That is a reasonable design for an asset pipeline — refusing an artist's file because it is 100 pixels wide would be worse. But it means the warnings column is the only place problems appear, and a run of thirty assets that all say "done" can still be carrying thirty warnings.

So this one is real: the switch genuinely governs whether the check runs, and the check genuinely notices. Both imports succeeded either way — the switch controls the advice, not the outcome.

There is a second size check that is always on: a texture larger than Max texture size warns at import regardless. Note that the warning and the resizing are different steps — the importer notices the size, and the optimisation processor is what actually changes the pixels. You can get the warning without the resize if resizing is switched off.

The setting is read and the code does enter its branch — and the branch is empty, its one line commented out with a note that a full UV probe is expensive. So the toggle survives in the interface and in every saved preset, and has no effect on any run.

This matters more than a dead switch usually would, because an unwrapped model is a real problem and this is the control that appears to guard against it. It does not. Canvas's own ladder covers what an unwrapped model does once you try to paint it — and that is where you will find out, not here.

All three produce an error status, and — from tier one — an errored asset gets no line in the index at all. So the queue is the only record that it was ever attempted.

Within one sitting the queue survives, so a second run still held the first run's assets and nothing looked wrong. But the queue starts empty on launch. So importing on Monday and again on Tuesday meant Tuesday's run wrote an index containing only Tuesday's assets — and Monday's files sat untouched on disk, unlisted.

Because five tools read this file, those assets simply stopped existing for all of them at once, and only came back by being imported again. The most ordinary workflow there is triggered it, and nothing failed while it happened.

The key is the output path, not the name. Re-emit the same path and the old entry is superseded rather than duplicated — verified, including that the recorded hash changed to match the new file. That is precisely what a consumer's change detection is watching, so the replacement is the mechanism by which "this asset was updated" travels.

It also means two different sources emitting to the same output path are one entry, with the most recent run's version winning. And the same source emitted to two different paths is two entries.

Delete an emitted file by hand and run another import: the deleted asset is still listed, verified, alongside the newly imported one. No step walks the assets folder to confirm that listed files still exist.

This is deliberate rather than an oversight, and it is a genuine design question — is the index a mirror of the folder, or a record of everything that was ever produced? The tool takes the second view, consistently: it also tolerates a file it cannot hash rather than failing.

What it means for you is simple. The index is a record of imports, not an inventory of files. If you remove an asset, remove its entry too, or the tools that read it will keep offering something that is not there.

All four verified: after deliberately corrupting an index, the next run succeeded, the new asset was listed, and the previously-listed one was not. Nothing failed and something was lost — which is exactly why the log line exists.

Recovery is straightforward and manual: re-import the assets that vanished. Their files are still on disk; only the ledger forgot them.