As design work continues towards a prototype, which will be simultaneously available as a development kit, the increasing number of parts is beginning to need an planned method of organisation; and one that can be used indefinitely, even as parts change and are refined.

As I want to make the whole project open source, meaning open access to the design documents, that means I have to use a parts definition that is easy to understand; is extendible for more parts to be created; and, because this is a continual design/refinement process, allows for parts revisions.

I’m intending to use a numerical format split by parts group (sub-assembly), part number within that group, and a version number, each one being three numeric characters.

This gives a format of:

A_P_V This way, updating a part just means updating the version number. An entire assembly or group of parts would be specified by:
A_V Which defines a versioned set of parts (part and version number -- because a group of connected parts is likely to need to be revised togther, but some may remain unaltered). And each vehicle version can be identified just by:
V Which specifies a set of versioned assembly numbers. This format should make it easier to find parts than just a set of sequential numbers with no context. This way part numbers relate to position or function on the vehicle as well as show the specific part revision. It should be easy to find a part number by it's position. Find the area or structure where the part is, and find the part number on an exploded diagram. And it should also be fairly clear from a part number where it goes: steering wheel mounting plates will all have the same assembly number, which is different from chassis parts, or front axle assembly parts. Obviously where assemblies join and parts could be in either assembly group, they would only have one part number, but might appear in two diagrams. _Can anyone see a particular problem with that specification, or suggest a better one (before I have _too_ many parts to re-number)?_ The whole point of this is to make it easier for anyone to find the details of the parts of Atomic Duck, and this includes having a publicly accessible parts database. Each part version then gets to have it's own page with details, specification, technical drawings and CAD models; all organised by vehicle version, assembly type, assembly version and part version. Obviously, this is the kind of thing that databases were made for (!) but it needs to be human readable. I'm using TikiWiki for the parts databse, MediaWiki is a little too democratic enough for a top down project like this, and TikiWiki has more fine-grained permission controls. This also give me the right kind of space to start constructing the build instructions…