art（4.3節）で指定された絵の名前。未指定ならundefined（＝型の識別子をそのまま使う）。
art_by_stage（6.4節）で指定されたプロパティ名。未指定ならundefined。
bound_to_owner（7.9節）。単独では存在できない型か。
covers（7.5節）。身につけたとき覆う部位のタグ名。未宣言なら空。
storage（7.12節）。物を溜める入れ物として使う型か。traitと自分自身の宣言はORで合成する。
layer（7.5節）。重ね着の階層の名前。未宣言ならundefined。
stackable。同種と束ねてよい型か（既定true）。束ねない宣言が1つでもあれば束ねない。
読んだ時点でmappingとして確かめてある（どの宣言に書かれていたかは、その時点でしか分からない）。
非公開removeremove_slots（7.14節）で挙げられた、この型が持たないスロットの名前。混ぜ終わってから落とすので、 他のtraitが配ったスロットも落とせる（海が location の items を持たない、voyage.yaml）。
resists（7.13節）。成立している間、土地以外の親へ移れなくなる条件の並び。宣言が無ければundefined。 条件の意味解釈はマージ後に行うので、ここでは生YAMLノードのまま持つ。
visible_slots（7.11節）で並べられたスロット名。未指定なら空。
trait 由来の本体を宣言順に混ぜ、自分自身の宣言を最後に重ねた結果（5節）。
resistsの並びは暗黙のANDで結ばれた1つの条件木なので、連結すると書いた覚えのない
合わせ技になる——どれが効くかを混ぜる順序に頼らせない。宣言から各フィールドを取り直す。読む側はここ1箇所で、object_def と trait で分かれない。 未知キーの判定も宣言全体に対してここで行うので、持ち主は自分で読むキー（object_defの素性など）を ownKeysで名乗ること——名乗らなければ綴り間違いとして弾かれる。
object_def と trait が共有する「混ぜ込める宣言一式」（GameElementDefinition.md 5節）。 trait はこれだけのもので、object_def はこれに素性（globalId・traits・recipes・variation_axes）を 足したもの。
trait 合成がまだ起こりうるフィールドは、意味解釈済みの型にせず生YAMLノードのまま持つ。 いつ読み直すかは持ち主が決める——object_def は patch（3.4節）のたびに読み直し、trait は一度きり。