AI が承認なしに書き込む「提案／候補」を、確定済みの本体と同じ場所に status 列（draft/active 等）で同居させるか、別テーブルに隔離するかは、下流の消費者の性質で決める。

判断基準

• 確定本体を読む下流（埋め込み生成・類似／全文検索・集計・公開出力など）が多く、かつ作成・更新時に自動で取り込む（例: 本体作成のたびに自動で embedding 生成）なら、別テーブルで隔離する。status 列での同居は、全消費者に「未確定を除外するフィルタ」を新設・維持させることになり、1 つでも漏れると未確定提案が検索・集計・公開へ流出する。別テーブルなら消費者はフィルタ不要で常に確定知識だけを見る＝隔離はデフォルト安全、status フィルタはデフォルト危険。
• 特に「作成時に自動で索引／埋め込みされる」下流があると、未確定を本体テーブルに入れた瞬間に索引へ載るため、フィルタ漏れの事故面が最大化する。隔離を『フィルタ条件』でなく『テーブルが別』で成立させると、型・経路レベルで安全側に倒れる。
• 逆に下流が少なく取り込みが明示的（status を必ず見る単一経路）なら、status 列での一元管理（既存メモ #508）の方が二重実装を避けられて軽い。両者はトレードオフで、消費者の数と自動取り込みの有無で選ぶ。

補足（重複検出の検索空間）

別テーブルにしても、棄却済みを重複検出の検索空間にそのまま残すと「過去の棄却に似ている」だけで新規が黙ってスキップされる。重複判定は生存中（pending/active）のみを対象にし、棄却への照合は「再提案するか」のゲートへ分離する。

検証

未確定提案を 1 件だけ作り、確定本体を読む各下流（検索・埋め込み・集計・公開）に現れないことを確認する。status 列方式を採るなら、消費者を 1 つずつ「フィルタを外したら漏れるか」で点検する。