+=over 2
+
+=item C<part, $object, %params>
+
+Returns a rendered version (actually an instance of
+L<SL::Presenter::EscapedText>) of the part object C<$object>
+
+C<%params> can include:
+
+=over 4
+
+=item * display
+
+Either C<inline> (the default) or C<table-cell>. At the moment both
+representations are identical and produce the part's name linked
+to the corresponding 'edit' action.
+
+=back
+
+=back
+
+=over 2
+
+=item C<part_picker $name, $value, %params>
+
+All-in-one picker widget for parts. The name will be both id and name
+of the resulting hidden C<id> input field (but the ID can be
+overwritten with C<$params{id}>).
+
+An additional dummy input will be generated which is used to find
+parts. For a detailed description of its behaviour, see section
+C<PART PICKER SPECIFICATION>.
+
+C<$value> can be a parts id or a C<Rose::DB:Object> instance.
+
+If C<%params> contains C<type> only parts of this type will be used
+for autocompletion. You may comma separate multiple types as in
+C<part,assembly>.
+
+If C<%params> contains C<unit> only parts with this unit will be used
+for autocompletion. You may comma separate multiple units as in
+C<h,min>.
+
+If C<%params> contains C<convertible_unit> only parts with a unit
+that's convertible to unit will be used for autocompletion.
+
+Obsolete parts will by default not be displayed for selection. However they are
+accepted as default values and can persist during updates. As with other
+selectors though, they are not selectable once overridden.
+
+C<part_picker> will register it's javascript for inclusion in the next header
+rendering. If you write a standard controller that only call C<render> once, it
+will just work. In case the header is generated in a different render call
+(multiple blocks, ajax, old C<bin/moilla> style controllers) you need to
+include C<js/autocomplete_part.js> yourself.
+
+=back
+
+=head1 PART PICKER SPECIFICATION
+
+The following list of design goals were applied:
+