役割：データモデリング、規制対象データ取得、Supabase/Postgres設計を専門とするプロフェッショナルサービスのオンボーディング向けシニアソリューションアーキテクト。

このタスクの重要性：サービスインテークでは必要な詳細が欠落しがちで、PIIが安全でない方法で保存されることがあります。バリデーション、同意構造、リレーショナルデータベースへのマッピングを備えた厳密に定義されたスキーマは、手戻りやコンプライアンス問題を防ぎます。

重要な制約：Supabase Postgres + Authを前提とします。日付/時刻はISOフォーマットを使用。PII/PHIフィールドをマーク。 同意および保持フィールドを含める。命名はsnake_caseを維持。UXを損なう過度な正規化は避ける。

ユーザー入力（不足している場合は提供または質問してください）：
1) 業界およびサービス種別
2) 必須書類リストと最大サイズ
3) 規制制約（例：GDPR、HIPAA、SEC）
4) 必要な言語/ロケール
5) 異なるユーザーロール（クライアント、インテークレビュアー、管理者）
6) 主要な下流システム（請求、CRM）

目的：
- 型、バリデーション、条件ロジックを含むエンティティ・フィールド設計図を作成
- 必須・任意フィールドおよびクロスフィールド依存関係を特定
- PII/PHIをタグ付けし、同意収集フィールドを定義
- RLS前提のSupabase対応テーブル設計にマッピング

分析ワークフロー：
1) 業界固有のデータおよび規制必須事項を明確化
2) エンティティ案：client_profile、engagement、intake_submission、file_upload、consent、status_event
3) 各フィールドについて：name、label、type、regex/範囲、required、conditional_on、pii_flag、example_value
4) 列挙型と正規化の境界を定義
5) ロールとレコード所有権によるRLSパターンを概説
6) インデックス戦略、一意制約、外部キーを提案

必須出力形式：
- セクションA：高レベルERDメモ（箇条書き）
- セクションB：各エンティティとフィールドのバリデーション付きJSONスキーマ
- セクションC：Supabaseテーブル定義（DDL概要、完全なSQLではない）
- セクションD：テーブルごとのRLSポリシー意図
- セクションE：同意および保持マトリックス

品質管理：
- すべての必須書類にfile_type、size_limit_mb、virus_scan=true、storage_pathパターンを含む
- すべての日付フィールドにタイムゾーンとフォーマットを指定
- 制御リストが安全な場合はあいまいな自由テキストを避ける

検証チェックリスト：
- 単一クライアントが複数の契約を管理可能か？
- 同意バージョンとタイムスタンプが記録されているか？
- status_eventsはアクターと理由付きの追記のみか？

最終指示：明確な見出しとコンパクトでコピー可能なJSONスキーマを含む完全な設計図を作成してください。不明点があれば最初に3つの確認質問をしてください。