Note: prototypes aren't a fixed feature—not all notes have prototypes. A note only uses a prototype is its $Prototype attribute is set. So for notes with no prototype, this part of the inheritance cascade is ignored.
A way to think of a prototype in Tinderbox is as a pre-customised note. Any note may be made into a prototype at any time (or indeed cease to act as a prototype); more details here. As well as ordinary notes, container notes, agents, adornments and separators may all use a prototype (N.B. prototype adornments can only be seen in map view, just as with normal adornments).
Should a prototype's attribute values differ from higher-level inherited defaults, notes using the prototype inherit the prototype's value rather than the higher level default.
A prototype's customisation is achieved by setting (non-inherited) values for some attributes. These become the inherited defaults for that attribute for any notes using the prototype. Customisation does not need to be visual, though it often helps if some inherited visual feature (e.g. note colour or badge) indicates a note is using a prototype.
A note inherits the contents of a prototype's Displayed Attributes table via the $DisplayedAttributes system attribute.
Remember that intrinsic attributes are excluded from inheritance via prototypes.
The status of a note acting as a prototype is stored in the attribute $IsPrototype. The prototype, if any, that is being used by a note is set in that note's $Prototype attribute. Both settings can easily be viewed/set via the Properties Inspector's Prototype tab.
Not something to try from first use, but be aware prototypes can inherit from other prototypes. So in the diagram here, 'Prototypes' might be zero, one or several (inheriting) prototypes. Note that be it a note, agent, etc. or prototype, any project can only have zero or one prototypes (which is stored in $Prototype).
Prototype attribute values cascade to note 'local' level…
See also—notes linking to here: