Perhaps most illuminating have been the unexpected complexities of even the ``simple'' inventory task. ``Software'', understood loosely as data stored in a digital medium, breaks down our notions of physical commodities, because it can be replicated ad infinitum with a simple copy command. On a practical note, this means that inventorying existing assets in a software environment may present formidable problems in sorting out true variant versions from different copies of the ``same'' piece of software. For example, in cataloguing sounds on the KORG WaveStation, I found that approximately one third of the inventory consisted of duplicate or multiple copies. There are many and varied reasons for copying sounds in the studio environment: touring disks, temporary ``palettes'' created for composition, or ``fly-in'' recordings for sessions. The problem is aggravated by copies that have been ``tweaked'' at a level of granularity far below their overall size (like two giants differing by a toenail). Duplication and redundancy can also be the result of automated system activity: some locations were filled with automatic loads from other banks within the machine; in addition, some seeming inventory was in fact empty (though misleadingly titled ``Unnamed''!)—an ``artifact'' of the hardware. All these variants must be catalogued and sifted through in order to isolate the library assets proper. These sorts of problems apply to more than the artifacts themselves. One machine that provided an on-line database with user-definable categories sabotaged most advantages of the category field, simply by neglecting to provide a way of viewing the list of categories themselves; this resulted in many spurious variants of category names, making the database extremely error-prone to use. Similar issues are likely to arise in any software inventory activity.