Datastore Fields and Template Fields

A datastore item's fields can come from two places, and each assumes something.
• The Datastore's own Fields. Every item has them, whether or not it has a page, and wherever it is shown. A datastore whose items never have pages needs its fields here.
• The template's custom fields. The template that reads a FieldID defines it (see Where Custom Fields Belong), and the field is composed onto the form of every item whose page uses that template. These values are saved only for an item that has a URL and a template (see Defining Pages), so a field defined by a template is not saved for an item without a page.

What belongs where
A datastore's own fields should cover what the item needs wherever it is shown: the card on a listing, a picker on another page, the detail page, any template that reads it. Image, eyebrow, and short description are typical.
The detail page's body can belong to the partials the detail template includes, so editing the overview means editing one partial, not every item. That placement works well when each item has a page, and it assumes it does.

Several datastores, one partial
When several datastores render through one partial (one card partial for Equipment, Materials, and Industries), the partial reads fixed FieldIDs, so each datastore must define them. Declaring the shared FieldIDs once and reusing that same set on every datastore avoids drift; redeclaring them by hand per datastore invites a field missing on one, whose cards then render blank. Family-specific copy can differ and live on that family's detail partial.