Each ship in the VS universe is a hierarchical construct, both in-universe and in-engine.
At the highest level, it is a ship - an in-game object with certain properties. In order to be a ship, it must have some certain subcomponents
All VS ships, even the simplest missiles, have the above three pieces. This is as true for a Rlaan battleship as for an Andolian missile.
Of these, the drives and chassis are visible components, whereas a reactor is an indicated component. That is, the presence of a reactor in a specific part of the ship is indicated by the shape and volume of some part of the chassis.
Each of these components may also be a hierarchical object, and a system may comprise several components. More on that later.
Now, if your ship is more than just a missile, it will also have several other key elements
Cooling systems are a mix of indicated and visible components. Most of the pumps and radiator fluid reservoirs are probably indicated components built into the chassis, whereas radiators will often be discrete components.
Depending on the size of the vessel, the cockpit will either be an indicated component (a fundamental part of the chassis) or a bridge component, that, if never seen apart from the chassis, is a child of the chassis rather than a part of the chassis in the hierarchy.
Thrusters should be distinct components, but will be replicated. Similarly so for sensors
A vessel with these seven systems is a pilotable vessel. However, you may not want to pilot it without the following
Of these, the FTL drives are barely even indicated components. They can be safely ignored for most designs save for having sufficient internal volume for the devices to be present.
Armor is a trickier one. For most ships, it will be an indicated component, a presumed part of the chassis. For larger vessels, it may be aesthetically pleasing to have distinct pieces of armor plating in at least some parts of the ship so that they can be beautifully destroyed by incoming fire.
Shields are fairly ubiquitous, and almost all vessels should have shield emitters. The Rlaan require shield emitters, as those are their drive and thrusters as well. These are visible and distinct components.
Weapon mounts are the most optional, but the most fun. These will be a mix of indicated and visual components. Internal mounts will be part of the chassis (a hole in which to put a weapon) and external mounts will be glued to the chassis.
So - let us assume that you have a library of parts containing one component (these components themselves are hierarchical objects, but more on that in the next section) for each of the following bins:
The chassis will have a number of attachment points. Each of the points will have a type, that is, it will only accept certain types of components to be glued on.
To build a ship, you would do the following -
Attach at least one drive component to each end of the primary mobility axis of the ship (i.e. both accel and decel engines)
Place as many thrusters around non-primary mobility axes as you see fit
Place sensors around the ship, presumably in such a way as to indicate a 360 degree arc of information retrieval.
Place shield emitters on all sides of the vessel. If desired, cluster into hemispheres, quadrants, or other presumed logical groupings. With Rlaan, be sure to get good coverage, as these are also the thrusters.
Glue an external weapon mount or two somewhere on the ship.
Attach radiator parts onto the ship in places where the emitting side doesn't all face back to the ship.
Congratulations, you've assembled a vessel...
But... how do we populate the part library so we can build more than one vessel?
Answer - recursion!
Each component can itself be a hierarchical object.
Let's briefly consider the nature of these hierarchies.
At top level is a ship. A ship is a collection of logical objects, that is, entities that the game engine is aware of that interact in some particular manner to emulate a whole. I say collection, rather than a hierarchy, because there may be both peer and child objects -- the exact representation is yet to be defined. Suffice it to say, a ship is a composite object from the perspective of the game engine.
Each component comprises at least one logical object. It may itself be a hierarchical entity. In the simplest case it is a single logical object. In this case, the object corresponds to exactly one in-engine entity, and some visual representation. However, the visual representation can itself be non-singular. As a hypothetical, consider a component that is one logical object, an enormous 4-spoked wheel 4 kilometers across. This logical object, due to size and symmetry should have a visual representation that is divided into multiple meshes, each with independently triggering LODs. Due to the symmetry of such an object, all of these can be identical, with a spatial transform applied. In asymmetric cases, they'll have to be independently constructed.
Now, many components will be composite objects constructed out of multiple logical objects. Just like the chassis that had certain glue points, these components will have glue points where they can be attached to other logical objects to produce a new, composite object. Unlike the chassis, most of these glue points are unlikely to be typed.
The most commonly composite of objects will be the chassis. Even if the chassis has a single primary component giving it a basic shape, the addition of common sockets, common surface features, and purely aesthetic components from a faction style library will tend to cause it to be a composite object.