The way I found to make it non-disfunctional was basically "let's focus on cataloguing things for which we have a practical task at hand". E.g. it makes sense to catalogue services because our platform has tools to manage the dev cycle, ci, cd etc. of those services. The issue is.. if you're building such tool, then the catalogue is part of that tool already. You're not building a catalogue but a platform that contains a catalogue. This logic can only be avoided if you think of the catalogue as "generic". BUT, this is the gateway to building an inventory of things in the company disconnected from a practical purpose. Because you literally end up with an inventory of everything (people, users, teams, services, rooms, chairs.. ) that is integrated with nothing (the platform, hr systems, office management systems, etc. that actually do something with those items). Said integration turns out to be really hard because well.. those tools have their own inventory. And you end up with your grand project for an Über inventory, but no usage.

i've been in the industry long enough to remember when "CMDB" was "essential" (built/managed a few of those) and in larger cloud orgs where "we need to be able to know who owns X / what dependencies X has so let's service catalog" and more recently in a smaller/mid-sized shop where we inverted this principle a bit and let "service catalog" become a natural outcrop of "SLO dashboard" (all the things we cared about had SLO and execs wanted to see that rolled up on one dashboard so it sort of become "the service catalog of things we manage that are valuable") ... which is a long way to say i've seen various approaches and not dogmatic in any way, mostly a lot of pros/cons. watching to see where this goes, so thanks all for the conversation.