アトリビュート・リスト では、最低限、以下の 4つの項目を記述しなければならない。

　　（1） データ 値 （データ の定義）
　　（2） 前提 （バリデーション・ルール）
　　（3） セキュリティ （照会・更新の権限）
　　（4） 計算式（導出規則）

　「前提 （baseline ともいう）」 は、自らが帰属する entity を起点にして、以下の 2つを対象として ルール を検証する。

　　（1） ターゲット entity のなかに記述されている アトリビュート
　　（2） 自らが帰属する entity のなかに記述されている アトリビュート

　（数学的な） 「順序 （並び）」 は以下の 3つである。

　　（1） 小さい （a ＜ b）
　　（2） 等しい （a ＝ b）
　　（3） 大きい （a ＞ b）

　「event-対-event」 では、時系列の 「順序対」 が成立する。
　したがって、同じ性質の アトリビュート であれば、以下の検証をすればよい。
　（49ページ 「event の並び」 を参照されたい。）

　　（1） 小さい （たとえば、受注日 ＜ 請求日、受注数 ＜ 出荷数 など）
　　（2） 等しい （たとえば、受注日 ＝ 請求日、受注数 ＝ 出荷数 など）
　　（3） 大きい （たとえば、受注日 ＞ 請求日、受注数 ＞ 出荷数 など）

　ただし、「event-対-resource」 や 「resource-対-resource」 では、「順序対 （並び）」 が成立しないので バリデーション・ルール の検証は 「機械的に」 判断できない。

　たとえば、「event-対-resource」 として、（「請求」 entity の） 「請求金額」 と （「顧客」 entity の） 「住所」 では、請求の際に、物品代金のほかに、配送地域という観点から、「送料」 が付随費用として算入されなければならないという ルール を 「機械的に」 導出することはできない。

　また、たとえば、「resource-対-resource」 として、（「地域」 entity の） 「名称」 と （「商品」 entity の） 「名称」 では、「地域限定 （かつ、期間限定）」 の セールス が適用されるという ルール を 「機械的に」 導出することはできない。

　あるいは、たとえば、「event-対-event」 でも、異質の アトリビュート を対象とすれば、（「受注」 entity の） 「受注日」 と （「請求」 entity の） 「請求金額」 では、或る期間内の受注日は 「特売日」 なので割引が適用されるという ルール を 「機械的に」 導出することはできない。

　そういう ルール を思い浮かぶかどうかという点は、（財務会計論・原価計算の通論を読んで） 「付随費用」 の知識を習得しているかどうか、あるいは、（マーケティング の通論を読んで） セールス・プロモーション の知識を習得しているかどうか、という点に負う。言い換えれば、システム・エンジニア の FOR （Frame Of Reference、参照枠） 次第である。FOR の拡大は、（直接的な 「体験」 ではなくて） 読書量と思考力に依存することは間違いない。なぜなら、直接的な体験は領域も質も量も限られているから。