Your override edits do not always survive the next open

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

Rename that object in the asset file, and the next time your scene opens Blender 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: six recorded edits became zero, the position went back to the library value, an added modifier disappeared, a material reverted. No error, no warning, nothing in the status bar.

OverrideProof reads the library files on disk and tells you what the next open would destroy — before it happens. And if it already happened, it compares your file against a snapshot it kept inside the .blend and names every edit that is gone.

Before it happens

While your file is open it still holds the old names in memory. The library on 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, the number 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 block inside your .blend, because between before and after the file is closed — that is 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, and it carries 0 edits instead of 6: position moved by 5.000; modifier MySubsurf gone.

It does not cry wolf

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

It speaks when the thing your override was built on is no longer in the library. 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 to rename the asset back, restore an edit by hand or accept the loss is a decision about someone else's file. It does not change your scene either: the only two things it ever writes are the snapshot and the report, both text blocks inside your own .blend, and both only when you ask.

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

Measured

• renaming an object in the library destroys every override edit on the next open: 6 recorded edits to 0, position 5.0 to 0.0, added modifier gone, material reverted
• moving the same object inside the library keeps all six — no false alarm
• 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 of the 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.