Your override edits do not always survive the next open

A library override is the only way to change a linked asset inside your ownscene: move it, add a modifier, give it your own material. Blender recordsevery one of those changes as an override edit, and holds them on to thelibrary by name.

Rename that object in the asset file, and the next time your scene opensBlender cannot match the old override. It builds a new one from the library,and everything you did on top of it is gone. Measured on a single file: sixrecorded edits became zero, the position went back to the library value, anadded modifier disappeared, a material reverted. No error, no warning, nothingin the status bar.

OverrideProof reads the library files on disk and tells you what the nextopen would destroy — before it happens. And if it already happened, it comparesyour file against a snapshot it kept inside the .blend and names every editthat is gone.

Before it happens

While your file is open it still holds the old names in memory. The libraryon disk may already be different, because someone else on the team saved it.OverrideProof lists the names inside the library file without linking anything,compares the two, and says which overrides no longer stand on anything:

the next open destroys 6 edits — and, for each one, the object, thenumber of edits, and the reason: the library no longer holds that object.

After it happens

Ask it once to remember your edits. The snapshot goes into a text blockinside your .blend, because between before and after the file is closed — thatis when the loss happens. Later, one button compares the file against it:

6 of 7 remembered edits are gone. The library renamed Prop to PropA.Blender could not match the old override, built a new one from the library, andit carries 0 edits instead of 6: position moved by 5.000; modifier MySubsurfgone.

It does not cry wolf

Libraries change all the time, and most changes are harmless. Moving anobject into a sub-collection of the library keeps every edit — measured, andthe add-on stays quiet. Adding and removing other objects in the library doesnot touch your edits, and it stays quiet about those too. Renaming the overrideinside your own file is your business, not a loss, and it is silent about thatas well.

It speaks when the thing your override was built on is no longer in thelibrary. That is the case where edits die.

What it will not do

It does not fix anything and it does not touch your libraries. Whether torename the asset back, restore an edit by hand or accept the loss is a decisionabout someone else's file. It does not change your scene either: the only twothings it ever writes are the snapshot and the report, both text blocks insideyour own .blend, and both only when you ask.

When it cannot check something, it says so. A library it could not read isreported as a library it could not read — never as everything matching.

Measured

• renaming an object in the library destroys every override edit on the nextopen: 6 recorded edits to 0, position 5.0 to 0.0, added modifier gone, materialreverted
• moving the same object inside the library keeps all six — no falsealarm
• the loss is named in advance, while the file is still open
• one asset placed twice counts as two, and the edits of both are counted
• a local rename of your own override is not reported as a loss
• a missing library is reported as not checked, not as matching
• 89 checks on Blender 4.2, 5.1 and 5.2, and nineteen deliberate breakages ofthe add-on that all turn the suite red

Works on Blender 4.2 and up. Entirely local, no telemetry.

Whole deliveries, not one file at a time

• Check a folder. Point it at a delivery and every .blend inside is checked, each in its own background Blender. The scene you have open is not touched — not opened over, not saved, not changed. A file that hangs or crashes takes only its own process down; the other thirty-nine still get checked.
• A report you can send. One self-contained page: verdict first, one sentence a lead can read, then the numbers, then every finding with its address. No internet, no fonts to load, no dependencies — it opens in six months on a machine with no network, which is exactly when someone asks what you delivered.
• Runs without a person. A single command from your pipeline writes the report and returns a code: clean, something blocking, or could not be checked. Those are three different codes on purpose — a check that did not run has not passed, and a gate that treats them the same is worse than no gate at all.
• Remembers last time. Save today's numbers as a baseline and a later run tells you what moved, in which direction, and which findings are new. A measurement that went up is not automatically bad: each product says which way is worse for its own numbers.
• One verdict for the whole delivery. If you own more than one of these tools, one run puts every check you have over every file and answers the only question that matters before you send it: can this go out? Each file is opened once and all the checks see the same state of it.