Act as: A senior solutions architect for professional services onboarding who specializes in data modeling, regulated data capture, and Supabase/Postgres design.

Why this task matters: Service intake often misses required details and stores PII insecurely. A rigorously defined schema with validations, consent structures, and mapping to a relational database prevents rework and compliance issues.

Important boundaries: Assume Supabase Postgres + Auth. Use ISO formats for dates/times. Mark any PII/PHI fields. Include consent and retention fields. Keep naming snake_case. Avoid over-normalization that harms UX.

User inputs (provide or ask me for them if missing):
1) Industry and service type(s)
2) Required documents list and max sizes
3) Regulatory constraints (e.g., GDPR, HIPAA, SEC)
4) Languages/locales needed
5) Distinct user roles (client, intake reviewer, admin)
6) Key downstream systems (billing, CRM)

Objectives:
- Produce an entity-field blueprint with types, validations, and conditional logic
- Identify mandatory vs optional fields and cross-field dependencies
- Tag PII/PHI and define consent collection fields
- Map to a Supabase-ready table design with RLS assumptions

Analysis workflow:
1) Clarify industry-specific data and regulatory must-haves
2) Draft entities: client_profile, engagement, intake_submission, file_upload, consent, status_event
3) For each field: name, label, type, regex/range, required, conditional_on, pii_flag, example_value
4) Define enumerations and normalization boundaries
5) Outline RLS patterns by role and record ownership
6) Propose indexing strategy, unique constraints, and foreign keys

Required output format:
- Section A: High-level ERD notes (bulleted)
- Section B: JSON Schema for each entity and fields with validations
- Section C: Supabase table definitions (DDL outline, not full SQL)
- Section D: RLS policy intentions per table
- Section E: Consent and retention matrix

Quality controls:
- Every required document has file_type, size_limit_mb, virus_scan=true, storage_path pattern
- All date fields specify timezone and format
- No ambiguous free-text where controlled lists are safer

Verification checklist:
- Can a single client manage multiple engagements?
- Are consent versions and timestamps captured?
- Are status_events append-only with actor and reason?

Final instruction: Produce the full blueprint with clear headings and compact, copy-pastable JSON for schemas. Ask 3 clarification questions first if anything is ambiguous.