家族图谱数据模型：跨产品共用的 Schema 设计

B 方向·OPC 最佳实践（架构维度，收束篇）。多课题挂着同一个待办——「家庭图谱 schema 设计」——本篇一次收束：这是全部产品线的数据地基。

背景与问题

防诈、回忆录、见守、介护、防灾、终活全线都建立在「家庭关系数据」上，但 schema 没定义过。设计原则是什么？

发现（各课题已经隐含的需求汇总）

• 节点：Person（老人/子女/配偶/孙/第三者）、关系边（双向+角色）、Org（家族外机构：ケアマネ/寺院/事业部所）。
• 事件：命日与法事节点（japan-hoji-calendar-tool）、退院（japan-hospital-transition-module）、异常告警（japan-ai-welfare-call）、可疑接触（elder-ai-scam-guard）、支出异常（japan-elder-finance-watch）——事件统一为 append-only 的 timeline，各产品只写自己的事件类型。
• 授权状态机（japan-appi-data-compliance 三层同意）：每条数据×每个人「未请求/已同意/已拒绝/撤回」——同意是数据级而非用户级（声纹同意≠照片同意）。
• 代行操作（japan-refund-cancellation-design）：「谁以谁的名义做了什么」需要代理关系+操作日志两层。
• 可迁移性（opc-exit-microacquisition）：同意状态字段可随资产交割导出。

推测（设计原则）

1. 单一租户=家族（family_id），不是个人——所有表挂 family_id，产品线切换不换数据底盘。
2. 最小写入：每个产品只写自己 domain 的事件，读需要显式同意——跨产品读通过「家族内可见性矩阵」控制。
3. 端侧优先的镜像设计（on-device-ai-app-opportunities）：云上有 family_id 的元数据，敏感 payload（语音/照片/对话内容）留端侧或加密 blob，云只存指针。
4. APPI 可删除性：Person 级删除级联设计（被遗忘权对应）——schema 设计时留 soft-delete+purge job 位置。

结论

可行动启发：

1. 六表骨架定案（首个 MVP 的数据库设计直接用）：families / persons / relationships / consents / events(timeline) / audit_log——用 D1（japan-app-launch-basics 的 Cloudflare 栈）起步，JSON 列存扩展属性。
2. consents 表是法律合规的产品化：person_id × data_type × scope × state × granted_at——三层同意（一般/声纹/医疗）直接映射 japan-appi-data-compliance 的设计。
3. 「家族图谱是唯一护城河」的工程落地：竞品抄功能容易、抄 33 年法事日历+3 层告警史+照片档案的合并数据不可能——schema 从第一天按「永久保存+跨产品」设计，不走「单产品独立库」的弯路。
4. schema 文档进仓库：本笔记是设计说明，DDL 进仓库（首个 MVP 建库时执行）——待办收束。

待办 / 下次继续

• DDL 初版写入仓库（首个 MVP 建库时点：防诈首发排期确定后）。
  
• 「家族内可见性矩阵」的默认值设计（默认最小可见，逐项放开）。
  

关联

• 收束待办：japan-family-caregiver-app、japan-family-disaster-app、opc-exit-microacquisition、japan-appi-data-compliance、opc-terms-of-service-template（代行条款）；端侧架构 on-device-ai-app-opportunities。