Editing Content Center at the XML level

There is a category of work that almost never makes it to LinkedIn: the boring kind. Nobody posts screenshots of a change log or celebrates a backup that restored correctly. And yet, when I look back at the projects I have seen saved in the final stretch, they were almost always saved by something boring: a backup copy, a preview report, a record of what changed and when.

This is the story of one of those tools: the Content Center Smart Editor, a Python tooling for editing Inventor Content Center families at the XML level. Zero AI, and for good reason.

The problem: days of clicking

The Content Center is the library an entire company's designs depend on: fasteners, profiles, piping, standard components. There are adjustments that, through the UI, mean opening family after family, field after field, for days. Changing a property across dozens of families, fixing a naming convention, correcting values that came out wrong after a migration. Nobody wants to do that work by hand, so it gets postponed. And postponed. Until a project needs it urgently and the days are no longer available.

Underneath that interface sits a perfectly editable XML structure. Content Center families can be read, modified and written with code, in batch, in minutes. The question is not whether it can be done: it is how to do it without breaking the library everyone depends on.

Three non negotiable rules

Automatic backup before touching any family. It is not optional and it does not depend on anyone remembering: the tooling does it by itself, always. If a change goes wrong, the previous state exists and can be restored. The difference between a scare and a catastrophe is exactly that copy.

Batch preview. Before executing, the report: which families will be touched, which fields, what the values are and what they will become. Execution comes after reading that report, not before. If the change pattern is badly designed, you find out on paper, not in the library.

A log of every change. Which family, which field, what the value was and what it became. Traceability is not bureaucracy: it is what lets you answer, six months later, the question of why a component behaves differently. Without a log, that question gets answered with archaeology and guesswork.

Why zero AI

If you follow me, you know I build AI agents for these very products. I did not use it here, and the reason is the same one I repeat every time someone asks whether AI fits everything: this was a clear rule problem. The changes could be described exactly, there were no exceptions to negotiate and no judgment to apply mid-execution. And clear rules get automated with deterministic code, which is cheaper, more auditable, and does not hallucinate.

I suspect that is exactly why it worked so well. The right tool for that problem was not the most modern one: it was the most traceable one. Backup, preview, log. The boring work that saves projects.