新しい分類軸（enum / lookup / タグ）を、ある下流目的（公開対象か、課金対象か、通知するか、サマリー素材か等）のために導入したとき、その目的の真偽を「軸とは別の boolean フラグ列」で持たせたくなることがある。だが軸の値集合そのものがその目的の区別と一致しているなら、フラグは情報を増やさない二重符号化になる。

判断基準

• 軸の値を「目的に該当する値の集合」と「しない値の集合」に分けたとき、その分割が軸の意味から自明（値を見れば判定できる）なら、別フラグは冗長。目的は軸の値の意味に内包させ、消費側（クエリ・プロンプト・分岐）はその値集合を直接参照する。
• フラグが非冗長になるのは「該当でも非該当でもない第3の値」を足したとき、または「同じ値でもレコードごとに目的が変わる」ときだけ。前者は値集合を増やす、後者はレコード属性として持つ、が素直。
• フラグを足す前に「この目的を実際に読む消費者は誰か。その消費者は値集合（型キー等）で判定できないのか」を確認する。消費者が値集合で判定しているならフラグは誰にも読まれない dormant 列になる。

落とし穴

• 「将来この目的でフィルタするかもしれない」で先にフラグを足すと、消費者ができるまでノイズと二重管理だけが残る。第一級化＝下流が実際に filter/集計に使うこと。消費側が実在してから列を足す。
• 値集合と重複したフラグは、片方だけ更新されて不整合になる保守コストを生む。

検証

導入予定のフラグについて「この真偽は軸の値だけから決まるか」を問う。Yes なら列を作らず、消費側ロジックか軸の値の意味の文書化に一本化する。No（値だけでは決まらず実レコードに依存する）のときだけ列として持つ。