0. 数据表与系统分工明确十四张表的边界与拆分依据

离线分析读取来源，形成生活事实、计量、分析和长期理解。App 读取已发布结果。在线对话读取当前事实、结果、记忆和计划，用户确认后才经受控入口修改。三个平面复用同一套对象与依赖，个人记忆保持独立。

产品库 14 张业务表，另有 1 张鉴权辅助表 auth_sessions（见 1.11）。评测隔离实例复用其中 5 张的结构（accounts 只放一行存根），另加 1 张逐样本结果表。评测采用相同事务身份方案时，再有 1 张鉴权辅助表；仅用实例登录角色隔离时不建该表。选择必须先于评测 DDL 定稿，见第 6 节。
事务身份的用途：数据库要知道「这一步操作代表哪个用户或哪个任务」。如果只靠会话变量，任何服务都能改写它、冒充别的用户。这张表不存业务数据，只有函数能写；事务结束后这一行即失效，定时任务做物理清理。
拆表只看五条。每条都要写出「不拆会坏在哪里」：
1. 存储方式不同：二进制文件和行数据不同。
2. 生命周期不同：有版本的对象、只增的记录、原地更新的运行状态，三者不同。
3. 量级不同：相差两个数量级以上，分区和保留期也不同。
4. 安全区不同：跨用户读取的数据、隔离的评测实例。
5. 结构不同：常用列和业务唯一键不同。合表后，大量列只对一部分种类有意义，唯一约束只能写成按种类的条件约束。
同一用户的数据、只是写入服务不同时，不拆表。改用按种类的行级权限和受控函数。
按第 5 条，facts 和 results 不合并：facts 以时间区间为中心（轨道、生活日、观察状态、用户保护）；results 以「对象 + 周期 + 方法」为中心（定义版本、发布状态、数据截止）。

#	表	放什么	写法	主键
1	accounts 账户	登录身份、状态、数据序号、权限序号、删除代次	原地更新	id
2	assets 文件	原图、音频、IMU 块、对话附件、分享专用副本、导出包、声纹、知识包、脱敏 Trace	内容不变，状态可变	(owner_id, id)
3	source_records 来源记录	HealthKit 样本、位置点、天气、外部日程、姿态识别分段、设备上报（含组件标识）	只增；一行是来源端的一个版本	(owner_id, id, retention_class, start_at)
4	facts 生活事实	一天、醒睡区间、观察空白、计量姿态轨道、情境轨道、事件、餐食子项、活动阶段、瞬时行为、自评、个人地点和路线、设备状态区间	身份行 + 修订	(owner_id, id, revision)
5	definitions 定义	评分和统计定义、分类词典、Agent 和提示词、JSON 结构、奖章条件、知识包版本、重算和发布策略、采样策略、评测运行配置	身份行 + 修订（全局）	(id, revision)
6	results 结果	事件呈现、事件分析、事件计量、饭后窗口、每日选源、每日统计、可提醒时长、分数、Balance、Balance 贡献、Balance 基准、事件影响、习惯评价、身体结果、当日解释、趋势、转折、发现、候选归因、候选习惯和计划、建议、提问、风险提醒、计划机会检查、复盘、提醒响应、奖章、推荐、预测、个人基线、机主与质量门、情绪观察	身份行 + 修订	(owner_id, id, revision)
7	record_links 来源与依赖	精确输入、读取范围、证据、合并拆分、提议关系、记忆来源、冲突、消息来源、附件、导出映射	只增；计算依赖 active 和读取范围进度可变	(owner_id, id)
8	memories 个人记忆	不按键执行的理解：喜好、情境规律、反馈原因、用户说过的事	身份行 + 修订	(owner_id, id, revision)
9	directives 用户设定与意图	档案、偏好、授权、设备与数据连接、奖章可见性、目标、计划、变更组、单次改期、Crush 规则	身份行 + 修订	(owner_id, id, revision)
10	actions 操作与回执	决定、反馈、Later、展示、收藏、确认、撤销、开关、授权确认、Agent 判断、守门结果、对象状态变化、设备回执、任务尝试、删除回执、回答	只增	(owner_id, id)
11	messages 对话消息	用户、助手、工具消息；会话是消息分组	身份行 + 修订	(owner_id, id, revision)
12	jobs 任务	每个逻辑任务一行	状态原地更新	(owner_id, id)
13	social_relations 社交关系	小组、好友、成员、分享开关、分享对象、点赞	身份行 + 修订	(id, revision)
14	publications 分享快照	分数快照、动态、奖章分享、评论	身份行 + 修订	(id, revision)
评测	隔离实例	accounts 存根、definitions、jobs、assets、actions 的结构 + evaluation_results（只增）	—	—

各表承担的职责和独立存储依据每张表按生命周期、结构或安全边界独立存储

accounts：所有私有表的所有者指向它；它是同一用户写入的串行点；删除和撤权的代次在这里。
assets：二进制在对象存储里。上传校验、外部副本、物理删除自成一套（标准 1）。
source_records：外部和识别的原始记录不会改，每天几千到上万条（标准 2、3）。放进 facts，每条多一行身份行，依赖也要逐条登记。
facts：会被纠正、要版本、以时间区间为中心的生活记录（标准 5）。
definitions：全局内容，不属于任何用户（标准 4）。它存定义正文，不是版本登记表。
results：系统得出、会因输入变化而重算、以「对象 + 周期 + 方法」为中心（标准 5）。
record_links：要能反向查「谁用了这个输入」。分散在各表 JSON 里，重算和删除就要扫全库（标准 5）。
memories：有召回、强化、确认、冲突、用途限制。常用列（权重、用途、确认方式、向量）和其他表都不同（标准 5）。
directives：用户定的、约束未来行为、带待确认提议（标准 5：业务键 + 提议基准 + 时区模式）。
actions：已经发生、不可改的交互和回执（标准 2）。
messages：有流式状态、会话顺序和重新生成（标准 2、5）。
jobs：租约、重试、进度一直在变（标准 2）。
social_relations、publications：唯二跨用户读取的表（标准 4）。私有表对社交服务完全不授权。

1. 通用约定统一修订、时间、缺失、权限和发布

1.1 对象身份保存当前状态，内容修订保留历史每个对象有稳定身份和不可变修订

revision = 0 是身份行；revision ≥ 1 是不可变的内容修订。id 用 UUIDv7。
所有权分四种：
- 个人：owner_id = 用户账户。
- 全局：owner_id = 固定的系统账户「global」（accounts 里有这一行）。用于全局知识包文件、定义发布状态的操作记录。
- 评测：评测实例里 owner_id = 固定的系统账户「eval」。
- 共享：definitions、social_relations、publications 用 (id, revision) 主键，没有 owner_id；共享对象的回放顺序用对象自己的 lock_version，不用账户序号。
私有表主键 (owner_id, id, revision)。
身份行三类列：
1. 不变的身份列：kind、业务键。业务唯一键建在身份行上（部分唯一索引 WHERE revision = 0）。
2. 当前状态：current_revision、lock_version、lifecycle、changed_seq、stale_since_seq、processed_seq、deleted_at、consent_basis。
3. 当前修订的查询副本：start_at、end_at、day_id、local_date、status、lookup_keys、embedding、embedding_model、embedding_next、embedding_model_next（换模型时新旧并存，算完一条语句切换）。
修订行：kind（冗余）、identity_rev（生成列，恒为 0）、schema_def、data_sequence、recorded_at、effective_at、previous_revision、restored_from_revision、writer、change_reason、pending（待确认）、provisional（当天临时）、idempotency_key（对话提议用）、changed_range（轨道类）、consent_basis、memory_lineage、body、protected_fields。
约束：
- 修订行的复合外键 (owner_id, id, identity_rev, kind) 指向身份行上的 UNIQUE (owner_id, id, revision, kind)。这样保证同所有者、同对象、同种类，行级策略也能直接看 kind。
- current_revision 用可延迟外键 (owner_id, id, current_revision) 指向本对象的修订。
- 所有「指向身份行」的引用（parent_id、place_id、group_id 等）都配一个常量 0 列；「指向修订」的引用加 CHECK (rev >= 1)。
- 时间：CHECK (end_at >= start_at)。接入层遇到倒挂的时间先修正并标 time_trust，修不了就拒绝。没有时间的种类起止都为空，查询必须带 kind。进行中的事件设最长时长，超时自动闭合，标「结束时刻未知」。
私有身份行上的状态变化包括 lifecycle、day_id、deleted_at，以及接受待确认修订造成的指针切换。它们按一次状态事件登记：
1. SECURITY INVOKER 的 BEFORE INSERT / UPDATE 触发器判断是否创建身份或改变上述状态。它经对应发号入口取得序号并写入 NEW.changed_seq。调用方不能指定序号；未改变状态时保留旧号。
2. 专用所有者的 SECURITY DEFINER AFTER 触发器只插入一条 actions（kind = state_change），使用已落入身份行的同一个序号，保存旧值、新值和事务身份。不再 UPDATE 身份行，因此没有递归更新。
3. actions 的发号触发器只有在 kind = state_change 且 current_user 是状态记录触发器的专用所有者时才复用该号。其他写入一律重新发号；普通角色不能直接插入 state_change，也不能拥有该触发器所有者角色。
4. 状态记录函数只作触发器入口，不能作为普通函数调用。服务无建触发器或修改触发器的权限。跨账户换绑沿用 NEW.owner_id 和对应账户的序号，状态记录所有者有专用的跨账户插入策略。
5. 首次 INSERT 身份行也走这两阶段。普通新修订按自己的 data_sequence 回放，不另写 state_change。同事务的不同状态事件各取新号，身份行与它的动作共享事件号。
身份行和修订行都有 writer 列，由 SECURITY INVOKER 的 BEFORE INSERT 触发器填入 current_user。它记录实际执行 INSERT 的服务登录角色或业务函数所有者，不记录内层发号函数所有者。调用方不能自报。
previous_revision 和 restored_from_revision 是软引用，不建外键（临时修订会被压缩）。
待确认的修订可以存在，但不能成为当前修订。修订行有 pending 标记（待确认为真）。
- 插入身份行时，current_revision 只能为空，或指向同一事务里、同一写入方写的非待确认修订（用提交时检查的约束触发器校验）。用户消息经 post_message 函数一次写完身份行、修订和指针。
- BEFORE UPDATE 触发器检查：新的 current_revision 指向的修订，writer 必须属于该种类、该切换路径允许的修订写入方。切换执行方另行校验。待确认修订只经接受类函数生效，具体矩阵见 1.11。
回放合并两条流，只读截止序号以内的记录：
1. 非待确认修订：在自己的 data_sequence 生效。
2. 待确认修订：只在把它设为当前的那条 state_change 的序号生效；在那之前的回放点上，它不存在。
- 例子：序号 100 写入待确认计划，序号 200 接受。回放到 150 时，当前仍是旧计划。
更新目标对象时做条件更新：提交读到的 lock_version，不一致就重读。只改运行状态（连接的同步游标、last_seen_at）时不加 lock_version，也不拿账户序号。

1.2 回退、撤销、用户保护保留用户改动，按字段检查冲突

回退：复制旧修订，写一个新的非待确认修订，restored_from_revision 指向旧修订。它按自己的序号生效，不属于「不按顺序的指针切换」。
撤销某次操作：只改回这次操作改过的字段。先检查这些字段之后有没有被别的操作改过；改过就提示冲突。
不能回退的种类：授权、连接绑定、账户状态、删除状态。恢复授权必须由用户重新授权。
用户可改的值只存在 facts、directives、memories。results 只放系统得出的内容；要用用户值时，从 facts 读。
protected_fields：每个字段路径（用稳定子项 ID，不用数组下标）保存一串保护记录，按顺序记操作 ID。撤销时只去掉被撤销的那一条，保护退回上一次用户操作。整串去掉后，字段才恢复自动更新。
自动任务发布前检查保护字段。
页面区分补录、纠正、自动分析和外部导入时，读取受控 change_reason、触发操作的 actions.actor 和 protected_fields 引用。writer 仅是数据库角色，不能充当用户 ID 或用户修改标签。event、meal_item、stage 共用这条追溯规则。
所有事件标题共用读取顺序：用户标题优先，其次是对应专业 facet 的当前可用标题，最后是 main 的当前可用标题。时间线、封面、列表与详情不得各自绕开用户标题。
确认和撤销用同一套字段级检查：要改的字段在基准修订之后，既没有被别的操作改过（看 protected_fields 的保护记录和修订的 writer），值也和基准修订相同。只比较值不够：「改成别的值又改回来」也算被改过。进行中的用餐事件不断出新修订，只要相关字段没动，也能确认。

1.3 时间按生活日分配时间和归属

时刻用 timestamptz；时长存秒。
区间左闭右开 [start, end)。时点（喝水、吸烟、回执）用 [t, t]。索引和查询统一用表达式 tstzrange(start_at, end_at, CASE WHEN start_at = end_at THEN '[]' ELSE '[)' END)。
一天 = facts 里 kind = day 的对象：主要起床到下一次主要起床；起床时的 IANA 时区；边界来源（用户纠正 → HealthKit 睡眠 → 设备静卧 → 补录）和边界修订；结算状态；day_index。
- day_index 是用户内不重排的稳定序号；生活日撤销时留下空号。
- 按日的结果，subject 指向 day 对象，不用开始时刻。
- 窗口取「最近 N 个已结算、未撤销的生活日」。
- 归周：按这一天自己时区的 local_date 落在哪个周一到周日。同一个 local_date 有两个生活日时，两天都归这一周，页面分开显示。
- 缺少下一次起床时，保持未结算。
其他事实的 day_id（事件开始所在的生活日）放身份行，是查询副本。lookup_keys 存全部相交的 day_id。
- 「当天开始的事件」按 day_id 查询。「当天经过的事件」和每日统计按 lookup_keys 加实际时间交集查询，跨起床事件在两个生活日分别保留相交部分。
- 分数所属日与输入窗口都引用生活日对象。输入窗口通过精确输入关系引用实际生活日及边界修订，日期和时区从该修订读取。正文保留窗口顺序和跨日分配值。「下一日」指下一生活日，不做自然日期加一天。
- 边界变化同时刷新 day_id、lookup_keys 和依赖结果。相同 local_date 的两个生活日不合并，撤销生活日不进入完整日窗口。
每份按日结果通过 record_links.input 保存实际使用的生活日和边界修订。正文只保存顺序和跨日分配值，每项指向相应输入关系。起床时刻改了，原生活日、新生活日和相关窗口一起重算；历史结果仍能说明当时算进了哪一天。
计划和 Crush 规则声明时区模式：跟随（按当天的时区解释本地时刻，换时区不出新修订）或固定（存 IANA 时区）。夏令时里不存在的钟点顺延到下一个有效时刻；重复的钟点取第一次。Activity 当前 Crush 使用保存时的固定 IANA 时区，缺时区不允许保存。通用能力支持跟随模式不改变这项已定行为。

1.4 未知区分缺失、覆盖和真实的零

每个可缺失的指标：value、unit、lower、upper、observation_state、missing_reason、observed_duration、expected_duration、eligibility。
只有充分观察且确认没发生时，才写 0。
时间水位分开保存：observed_until 是真实采集到的事件时间上界；processed_until 是本次已经处理的输入时间上界；data_cutoff 是本次结果实际纳入统计的时间上界。它们均不是页面打开时刻，水位前也可能有缺口。
有效覆盖必须有已处理、质量合格的区间证据。先取这些区间与醒着区间的交集，再排除同数据类型的缺口、冲突和待处理区间。不能只用「醒着时长减空白」，也不能用一个最大时间戳证明整段已观察。
没有上传时水位可以为空。迟到处理后写新修订并更新覆盖。页面可以把时间轴画到现在，但未知尾段不得延长当前姿态或计入时长。IMU 完整而摄像缺失时，动作覆盖不受摄像缺口误伤。
原始记录超过保留期后，相关时段标「原始记录已过期，不可重算」。不把过期读成没有数据。
重算时能不能沿用旧的派生值，由每个指标在定义里登记复用条件。例如：只有运动时段没变，旧距离才能沿用；时段被用户改过、原始位置又已过期，就保留旧修订，新结果标「无法重算」，不能把旧值包装成新结果。

1.5 依赖记录直接输入并传播需要重算的变化

record_links 的关系分三类，只有第一类参与重算传播：

计算依赖（当前有效的）：
- 精确输入（input）：有版本的输入，登记对象、修订，以及读取时的状态序号（changed_seq）。轨道类再加时间范围。只列直接输入，不复制祖先链。另记读取方式：current（读当前修订）或 period（按结果周期读，用于「只影响以后」的设定和记忆）。
- 来源水位（source_watermark）：source_records 只登记「来源种类 + 时段 + 水位」。来源为空，必须填 source_kind、time_range、watermark。
- 读取范围（read_range）：订阅以后落进来的新数据。只允许 definitions 里登记的筛选规则。带 active 和 watermark；目标出新修订时旧范围置为失效，输出不变时原地前移 watermark。
历史追溯：已失效的计算依赖、export_map、attachment、message_source。删除和撤权时要查，但不触发重算。
业务关系：证据（支持、反例、背景、缺口）、合并拆分、提议关系、记忆来源、冲突。用于展示和业务检查，不触发重算。

规则：

record_links 是输入依赖的唯一真源。生活日及边界修订、每日选源修订登记为 input；来源种类、时段和水位登记为 source_watermark。结果正文保留实际分配值、顺序、计算结果和输入哈希，不再复制这些依赖。分配项引用对应关系 ID，不另存可独立修改的对象或修订清单。
输入哈希按定义登记的规范序列化规则，从不可变的输入描述计算：精确对象与修订、读取时状态序号、采用时段、来源种类与已用水位，以及读取范围的稳定筛选条件。active 和 read_range 的运行水位不进入哈希。结果保存摘要，发布时用同一输入描述复核。公开接口可以拼接依赖，但不因此重复持久化。原修订的依赖须保留，来源过期后仍能说明输入；能否重算按 1.4 判断。
用户设定和记忆的依赖：每个结果种类在定义里写明变更重算当天，还是只影响以后。计算、失效匹配和发布共用同一份周期解析规则。
- 解析输入包括结果周期、读取截止序号和已登记的生效策略版本。普通修订以自身序号进入可见集合，待确认修订以接受动作的序号进入，未接受的提议不进入。
- 对「只影响以后」的输入，在周期起点先取此前已生效的修订，再纳入周期内生效的修订，形成带适用区间的修订集合。周期结束后生效的变更不改变该集合。相同生效时刻按生效序号排序。
- 输入登记保存解析后的修订、适用区间和相关状态；没有有效修订时也登记空集合和对应读取范围。规则停用、有效期结束、接受提议和新对象出现同样参与解析。
- 写入方比较变更前后的解析集合。集合有变化才使相关结果失效；历史周期的集合不变时，保留原依赖作追溯。发布阶段重做同一比较，不能只查周期内部的新生效时刻。
计算依赖必须无环。definitions 登记每个种类的输入种类，CI 检查依赖图没有环。例如设备静卧只读 source_records 的识别分段，不读计量轨道，所以生活日和轨道不会互为上游。
记忆：读了记忆的分析必须把用过的记忆修订登记为精确输入。事实、结果和消息的修订都带 memory_lineage（直接读过的记忆 ∪ 全部输入的 memory_lineage），抽取时用它排除自我强化（见 2.8）。记忆变化默认只影响以后的分析，不重算历史。
删除和撤权时的反查：按用户扫描三类关系的全部行（不管 active），找全下游。来源水位、边界与选源修订只从这些关系读取，不再扫描第二份正文清单。

1.6 写入和重算协议核对最新输入后才发布结果

要拿账户序号的写入：facts、source_records、results、directives、memories、record_links，以及影响计算的 actions（决定、反馈、状态变化、回执）。序号由 BEFORE INSERT 触发器调用发号内核填写（见 1.11）；state_change 复用身份状态事件号，唯一例外见 1.1，调用方没有 accounts 的 UPDATE 权限，不能回拨或自报序号。
不拿序号的写入：jobs 的租约和进度、流式输出的中间状态、last_seen_at、展示的批量写入、社交写入。流式输出只写 jobs 检查点，完成时写一次消息修订。大批导入分成小批提交。
全局加锁顺序：
1. 先不加锁读出涉及的全部跨账户资源（例如账户名下的 Pin）和全部账户。
2. 按资源键排序，逐个拿 advisory lock（两参数形式，第一个参数区分资源种类）。
3. 再按账户 ID 升序拿账户锁。
4. 涉及既有任务时，最后按任务 ID 排序锁任务行。租约绑定入口内部也遵循资源、账户、任务的顺序。
5. 加锁后重读；资源或账户集合变了，就回滚并重试整个事务。
6. 数据库报死锁（40P01）或序列化失败（40001）时，用同一个幂等键重试。
写入方（同一事务内，通过协议函数）：
1. 用新旧两个版本（轨道用 changed_range，身份行变化用变化前后的值）匹配：当前有效的计算依赖、运行中任务登记的读取范围和精确输入。
2. 命中的结果打 stale_since_seq，并沿当前有效的计算依赖一路给下游打上。不沿历史追溯和业务关系传播。
3. 每个被打标记的结果，必须得到一个任务（按触发序号去重），或一条「已核对」记录，或明确的「只标过期」终态。按 definitions 的重算策略决定是哪一种。
计算方：
1. 计算阶段：开始时登记读取范围、起始水位、精确输入（含状态序号）、删除范围序号，然后在一个可重复读快照里读输入、做计算。这个快照只用于计算。
2. 发布阶段：另开一个短的读已提交事务。先拿账户锁，再重新读取最新的输入状态、授权代次和删除范围，然后检查：
  - 精确输入：读取方式为 current 的，仍是当前修订、状态序号没变（撤回、归日变化、删除都会被发现）；读取方式为 period 的，按 1.5 重新解析周期有效输入，其修订集合、适用区间和相关状态与计算时登记的完全一致。
  - 轨道输入只看登记的时间范围：之后所有修订的 changed_range 都不和它相交，就算通过。
  - 读取范围里没有序号大于起始水位的修订、墓碑或状态变化。
  - 没有有效删除范围命中输入或待提交输出。事件抑制必须按输出种类和时段检查，见 1.8。删除、撤权、用户保护和任务租约检查不可由 data_cutoff 发布例外跳过。
  - 用到的上游没有 stale 标记。
3. 不满足时按种类的发布策略：输入少的结果放弃并重排；因上游 stale 等待时不消耗重试次数；重排次数用完，显示「结果过期」，不留在「更新中」。
4. 长窗口和 LLM 结果可以按 data_cutoff 发布：清除 stale_since_seq，另记 cutoff_seq（截止到的序号）和未处理的序号。cutoff_seq 小于最新变更序号时，下一次定时任务补算。
5. 截止传播是独立检查：只要任一输入带截止标记，下游就必须在自己的修订里记下并继续传播这个截止时刻（取所有输入里最早的）。清除 stale 不能免除这一步。
6. 输出和上一修订相同：不写新修订（例外：日终定稿必须写一个非临时的定稿修订）；来源、授权依据或定义版本变了时仍写新修订。两种情况都清除 stale_since_seq（前提是 processed_seq 覆盖了截至提交时的全部待处理变更），并给直接下游建任务，让等待者被唤醒。
7. 结果修订、依赖、状态变化、后续任务在同一事务提交。
汇合结果（各领域分、Balance、当日解释）按同一条规则：只读没有 stale 的上游，或带截止标记的上游（同时标出「数据截至」）。
已核对：输出不变时写一条 actions（kind = checked，带 processed_seq），作为下游可以继续的依据。
切换当前修订用一条 UPDATE 同时改 current_revision、查询副本和 consent_basis，保证页面和索引看到的是同一版。
页面状态对应 PRD 的共同状态：立即重算、合并再算 → 「分析中」；定时补算、只标过期 → 「结果过期」，并显示数据截至时刻。
临时修订：今天的计量轨道事实和结果白天按批次发布的修订，修订行标 provisional（由计算方写，change_reason = intraday）。
- 每个临时修订都登记计算依赖，下游和页面才能消费它。出新的临时修订时，上一版的计算依赖置为失效。
- 日终写定稿修订（输出相同也写）。定稿修订的 previous_revision 指向上一个定稿修订。之后由压缩服务清理临时修订，这是只增规则的受控例外：
  1. 只有压缩服务能执行 compact_provisional。专用所有者只获 facts、results、record_links 的必要 SELECT 和 DELETE 权限。facts 仅允许 posture_track、context_track 的 provisional 修订；results 仅允许定义里登记为可压缩的 provisional 修订。身份行、当前修订、待确认修订和定稿修订都不能删除。
  2. 保留集合：被这一批以外任何行引用的临时修订都保留，包括任何种类的 actions、消息、分享、提议、定稿修订、jobs，以及 export_map、memory_source、证据、附件、消息来源关系；再沿计算依赖把保留修订的全部上游一起保留。当前修订永远不进压缩候选。
  3. 只有同一批待压缩的临时修订之间的计算依赖不算引用。
  4. 在账户锁内重读引用并计算保留集合，先删候选内部关系，再按下游到上游删修订。所有新增引用和压缩都拿同一账户锁，避免保留集合核对后又出现新引用。外键仍为 RESTRICT。
  5. 白天时点的回放只精确到被保留下来的修订。
- 容量按「每批都登记」估算（见第 3 节）。

1.7 授权限定数据用途并处理撤权

授权存在 directives（kind = consent）：数据类型 × 用途 × 范围（来源或时段）。修订正文固定包含告知版本、确认操作 ID、生效时间、失效时间。
撤回时，同一事务提升 accounts.auth_epoch。
consent_basis：一组「数据类型 × 用途 × 范围 × 授权修订」。修订行和身份行都有：身份行用于当前读取，修订行用于历史视图。规则：依据 = 全部上游依据的并集 ∪（原始输入的数据类型 × 本种类登记的用途）。写入时核对 jobs.purpose 和定义里登记的用途一致。
可单独返回的字段或内容块（例如封面、相机识别的菜品）各自带依据。
过滤分三级：
1. 完全依赖已撤回授权的对象，整行不返回。
2. 混合来源、可分离的对象照常返回，去掉受影响的块，标「部分受限」。和 Activity 规定的「撤回摄像期间，事件照常显示，封面换文字卡」一致。
3. 不可分离的分析文字（当日解释、发现的结论句）只要用到已撤回的授权，就整体停止使用，等重算。
资产按原始数据类型直接拦截。assets 分开记「文件用途」（例如分享副本）和「原始数据类型」。
对话回答、导出包、分享快照走同一套检查。社交服务读不到私有授权，通过只读函数 check_share_visible() 拿判断结果。
普通业务任务记执行用途、授权快照和 auth_epoch；提交时 auth_epoch 变了就放弃。删除清理不用已撤回的业务授权作为执行许可，而用用户已登记的删除范围与当前删除代次；它只能缩减或清理数据，规则见 1.8。
撤权后，后台任务重算只用剩余数据也能成立的结果，撤回受影响的分享快照。已有派生结果的保留政策由隐私负责人定，未定前停止使用。
账户删除后，授权只留最小凭证（数据类型、用途、告知版本、时间），写进库外删除账本，保留期由隐私负责人定。

1.8 删除阻止已删除内容被重建或恢复

删除范围记录：directives 的 kind = deletion_scope（不可回退；删除服务能写全部类型，接入服务只能写外部键类型）。
- 身份行 start_at、end_at 记时段；business_key 记范围类型和值（账户、数据类型、来源、外部键、对象 ID、时段、事件抑制）；记登记时的序号和删除时刻（作为采集时间的上界）。
- 正文不存内容。建 GiST 索引 (owner_id, 范围类型, 时段)。
- 保留到「在线拦截期」和备份过期两者中较晚的那个。
- 来源端删除了、但我们从没收到原记录的样本（例如 HealthKit 删除通知只有 UUID），也登记一条「外部键」范围，挡住以后迟到的这条样本。这一种由接入服务在同步事务里调用 register_deletion_scope 登记（只限外部键类型，正文不存内容）；其他类型只能由删除服务登记。
- 每次删除都建一个新的范围对象，不参加 directives 的业务唯一键（唯一索引带条件 kind <> 'deletion_scope'）。重复删除只会增加范围，不会覆盖仍有效的旧范围。
- 按类型匹配：

范围类型	怎样命中
账户	这个账户的全部数据
对象	对象 ID
外部键	provider + external_key，不看时间
来源	连接 ID + 采集时段
数据类型	数据类型 + 采集时段（上界是删除时刻）
时段	采集时间落在时段内的全部数据
事件抑制	同账户、同事件类型，且事件区间与抑制区间相交；对新旧对象 ID 均生效

不可修改的来源（HealthKit、位置）：每写一个墓碑，同一事务登记一条外部键范围。墓碑随分区清理以后，这条范围仍然保留，继续挡住旧样本重传。
日历这类可修改的来源不登记永久范围：删除写成墓碑，之后顺序更高的恢复记录可以取代它。
删除单个事件时，同一账户锁内登记对象范围和事件抑制范围。事件类型取事件事实中的稳定分类码，并记录分类定义版本，不是表级 kind = event。事件类型未确定时，抑制采用「未知事件类型」码，不能换成宽泛的全部事件。
主 Agent 生成事件前检查抑制范围。最终写入 facts 时，数据库提交守门动作再次检查全部有效抑制范围与候选事件的类型、时段。删除期间已经运行的任务也受此限制，新对象 ID 不能绕过。
事件子项按父事件检查。修改时间、拆分、合并和分类迁移仍带来源事件与分类映射；不能借改名绕过抑制。相邻但不重叠的事件、同一时段的其他类型不命中。明确恢复已删事件需要用户重新确认；未实现恢复入口前，不自动解除抑制。

拦截：
- 账户删除入口在同一事务把 accounts.state 改为 deleting、提升 deletion_generation、登记账户删除范围并创建删除根任务。任务目标固化账户、范围引用和本次删除代次。重复请求复用同一逻辑删除任务，不重复提升代次。
- 上传、同步去重及普通业务任务提交都按上面的类型匹配表查删除范围。命中范围或账户不是正常状态时，业务输出一律拒绝。下面列明的清理控制记录可以写入，但不能借此写回新的业务内容。
- 普通任务开始时记下这个用户的删除范围序号。提交时重新查全部有效范围；序号只能加速找到增量，不能免去对待写输出的匹配。任一输入或输出命中时拒绝发布，记录原因并结束或重排任务。受限清理只读完成删除所需的定位信息与状态，不将这些内容作为新的业务输入发布。
- 删除检查和提交在同一把账户锁下进行。
删除任务（jobs 父子任务）逐类清理：修订、文件、向量、缓存、外部供应商副本、分享快照、评测副本、备份。每步回执写 actions（删除服务有插入 deletion_receipt 的权限）。
受限清理身份：删除服务通过 bind_cleanup_job 绑定已领取的删除任务。鉴权辅助表记 actor_kind = cleanup、目标账户、job_id、删除范围引用、deletion_generation、lease_generation、登录角色和过期时刻。普通 current_owner() 不返回 cleanup 身份，普通业务入口也拒绝这种身份。
- 专用入口校验真实 session_user 是删除登录角色，任务属于清理种类白名单，purpose = cleanup，任务所有者、任务目标和删除范围账户一致。任务、身份及账户的删除代次必须一致。还要校验领取角色、令牌哈希、租约代次、任务运行状态、任务期限与 clock_timestamp() 未超过租约。
- 账户为 deleting 时，只执行本次账户删除范围的清理。账户为 normal 时，只允许已登记的局部删除范围，不允许用普通身份放行账户级删除。账户为 deleted 时，只允许备份清理及迟到回执对账。其他状态拒绝。
- 领取、绑定、续租、检查点、清理提交、子任务、删除回执和任务完成均使用同一个校验内核。绑定按资源、账户、任务顺序加锁；之后一直持锁到提交。任务完成清空令牌。续租只能延长仍有效的本次租约，不能让过期租约复活；过期后要重新领取并换代次、换令牌。
- 允许的操作只有范围内数据删除或失效、文件与外部副本清理、清理检查点、同范围子任务、job_attempt、deletion_receipt 和账本确认。子任务继承账户、范围与删除代次，种类从父任务允许的步骤生成。不能创建普通计算任务，不能插入新来源、事实、分析、记忆、消息或分享内容。
- 清理身份的辅助行只由专用身份登记函数写入。清理入口有独立执行权限和行级策略，不给删除登录角色直接业务表写权限。回执发号使用只授予清理记录函数的专用发号入口，按清理身份取得目标账户序号；普通发号入口不接受该身份。动作触发器仅允许这个受控路径写 job_attempt 和 deletion_receipt，不能由调用方自报序号或伪造任意动作。
- 清理写入和任务终态都有提交时约束触发器，在真实 COMMIT 时重验事务身份、范围、删除代次、租约代次和到期时间。不能只在绑定或回执函数开头校验。本事务已合法完成并清空令牌的任务，以本事务先前验证并锁住的租约身份校验；账户级根任务刚把账户改为 deleted 时，仅允许提交该次合法完成。账户级删除范围仍拦截全部业务输出；清理例外只覆盖上述控制记录及删除操作，不是跳过所有删除检查。
完成与迟到回执：账户级删除根任务只允许绑定账户范围，局部删除不能借此把账户变为 deleted。账户级根任务只有在库外账本确认成功、在线清理完成、外部供应商回执及评测回执齐全后，才能在账户锁内把账户从 deleting 改为 deleted。任一证据缺失时仍为 deleting，不能只凭任务结束写完成。
- deleted 表示在线及所列外部副本清理已确认。备份到期是独立步骤；尚未到期时显示「备份等待到期」，不能声称物理副本全已删除。
- 迟到回执不再绑定已完成的旧任务。受限清理调度入口按既有命令映射、当前删除代次和来源端稳定回执 ID 创建 receipt_reconcile 子任务；只接受本次已登记目标且来源验证通过的回执。同一回执重传复用任务，不同迟到回执各有幂等任务，即使前一对账任务已完成也不丢失。deleted 状态只允许此类对账与 backup_cleanup。回执不能恢复业务状态。
- 重试沿用稳定外部命令 ID，其组成绑定账户、删除代次、目标和步骤，不能包含当前租约代次或尝试次数。发送超时保持「外部待确认」，通过原命令查询或重试；供应商不支持幂等或状态查询时，清理团队核对真实结果后补凭证，不臆造成功。
- 账户存根保留 ID、删除状态与代次及必要审计标识，业务正文清空。存根、范围、任务、回执和账本按已批准的最长相关保留边界保留，并等待所有清理、迟到回执对账及备份步骤结束。保留政策未定前不物理移除这些控制标识。
- 备份不因账户变为 deleted 就立即覆写。按批准的备份策略等待到期并记回执；恢复备份先重放删除账本再开放访问。进度分别显示在线、外部、评测和备份，不合成提前完成的总状态。
库外删除账本：对象存储的一次写入区，记删除范围、时间和最小授权凭证，保留到在线拦截期和备份过期两者中较晚的时刻。正式期限未定前，只能验证流程，不能宣称隐私删除验收完成。恢复备份时先重放账本，再开放访问。
删除回执和删除任务不随账户级联删除，正文只存对象 ID 和步骤。只有删除角色能清理 actions 正文。
评测副本：
- 导出样本时，在 record_links 登记 export_map（目标是评测样本的软引用：eval_instance、eval_sample_id、eval_sample_revision，不建外键）。
- 生产把删除名单和撤回名单（包括撤回研究用途）写到交换区；评测侧拉取、清理、标记受影响的运行，再把回执写回交换区。
记忆阻止键：记忆被停用或删除时，记一个不含内容的阻止键（内容摘要 + 来源范围）。抽取时跳过命中阻止键的候选，直到用户重新确认。

1.9 引用完整性检查对象、修订与所有者一致

多态引用用「每张目标表一组列，只填一组」，例如 src_fact_id/rev、src_result_id/rev、src_memory_id/rev、src_directive_id/rev、src_message_id/rev、src_definition_id/rev、src_action_id、src_asset_id、src_source_record_id/retention_class/start_at。
- CHECK 按关系分开写：普通关系 num_nonnulls(各组) = 1；read_range 和 source_watermark 允许来源为空，但必须填 source_kind 和 time_range（水位行还要 watermark）；export_map 的目标填评测软引用组。
- 有版本对象的引用分两种：对象身份（配常量 0 列）和不可变修订（id + revision，CHECK rev >= 1）。两列成对非空。
- 外键 ON DELETE RESTRICT，按「先找下游、再删关系、最后删来源」的顺序删除。
- 指向 source_records 只用软引用（id + retention_class + start_at），删除时按用户扫描。
私有引用必须同属一个账户。指向 definitions 和社交表的引用是明确的例外，用不带 owner_id 的外键组。
业务唯一键中的多态目标用 NULLS NOT DISTINCT。
子对象写入时检查同账户、父对象种类和时间边界。meal_item 的父对象只能是用餐 event；stage 的父对象只能是 event，写入责任再按父事件的分类分开，见 2.4。

1.10 JSON 结构登记正文结构并按版本迁移

代码是唯一真源。CI 把每个 (kind, schema_version) 的 JSON Schema 发布成 definitions 的一条修订；修订行用 schema_def 指向它。没登记的种类和版本写不进去。
所有 JSON 列都有结构版本，包括 actions、jobs、record_links 的筛选条件。
迁移默认在读取时升级。升级函数同时映射字段路径，保护字段和依赖路径随之迁移。
只有证明业务含义不变的迁移，才能写 change_reason = migration 且不触发重算。计量含义变了，就是方法换版：建新的方法分支，旧结果继续引用旧定义。
新结构先放开读取，再放开写入。

1.11 写权限按能力入口限制实际写入

原则：每个服务一个数据库登录角色；终端用户从不直接连数据库；表所有者不做业务写入。规则按三层落实：

第一层：数据库自己保证的规则（触发器，调用方绕不过）

发号：所有要拿序号的表，BEFORE INSERT 触发器调用发号内核（SECURITY DEFINER，归 seq_owner，有 accounts.id、data_sequence 的 SELECT 权和 data_sequence 的 UPDATE 权。普通发号入口只允许给当前身份的账户发号，跨账户路径见第二层）填 data_sequence；state_change 仅按 1.1 复用已分配的状态事件号。
写入方：身份行和修订行的 writer 由 SECURITY INVOKER 触发器填 current_user，不接受参数或会话变量覆盖。
状态变化：BEFORE 触发器写 changed_seq，AFTER 触发器只记同号 state_change。初次 INSERT、普通更新、跨账户换绑与防伪造规则统一见 1.1。
指针检查：插入身份行时 current_revision 为空，或指向同一事务、同一写入方的非待确认修订（提交时检查的约束触发器）；UPDATE 时分别检查修订写入方与切换执行方。普通发布允许 1.11 角色表中该种类的服务登录角色及业务写入函数所有者创建的非待确认修订；切换方只能是该种类获授权的发布服务或业务函数。接受待确认修订时，修订写入方必须在下方提议白名单内，切换方必须是对应接受函数的所有者。Coach 写的计划提议可以被接受，Coach 自己不能让它生效。
列和旧值：限定可改的列、stale 只能由对应计算方清除，用 BEFORE UPDATE 触发器和列权限。
行级策略只管「能看哪些行、能写成什么样的新行」，按 kind 白名单；一律写成 (SELECT current_owner())。

第二层：按能力划分的提权入口

每个入口用 SECURITY DEFINER 和专用 NOLOGIN 所有者。除明确列出的基础设施例外外，入口同时核对事务身份、任务目标和用途，不能只核对 owner_id。入口名称、函数体、执行权限和行级策略一起固定其能力。内层 current_user 只代表内层所有者，不能拿它推断调用路径；session_user 仅核对登录服务，不能代替路径授权。
普通入口要求 owner 参数等于事务身份。按能力生成专用入口，例如 create_job_online 固定三类在线任务，add_links_metering 固定计量产出，add_links_message 固定当前任务的消息。入口不接受角色名、权限集合或任意 SQL 参数。调用方只有 EXECUTE，没有内核底表写权限，也不能 SET ROLE 成函数所有者。
mark_stale 的入口按允许变更的上游种类区分。它从真实变更记录取得对象和序号，按登记依赖传播，并按定义决定下游任务种类。它不能接受任意下游对象或调用方自报的任务种类。失效传播所有者可调用固定的下游建任务入口，普通服务不能调用该入口。
advance_read_range、log_checked、log_job_attempt 同样按目标或任务能力限制。业务函数嵌套授权逐条授给专用所有者，例如回答函数可执行记忆处理、接受提议和计划转换。不要开放一个可自报路径的通用提权入口。
跨账户写入单独处理：连接换绑入口验证设备归属证明，枚举并按 1.6 锁住旧、新账户，重读连接后再换绑。仅此函数所有者可执行跨账户发号与状态记录入口。跨账户内核有专用行级策略或 BYPASSRLS，但只授必要表列权限；SQL 均显式限定已核对的账户和连接。普通入口不接受这个例外。
写入方和指针触发器保持 SECURITY INVOKER。在调用提权函数前，触发器可按已知 current_user 选择普通或换绑专用入口；数据库执行权限仍会阻止未授权调用。换绑产生的旧主人状态记录使用旧主人的序号和所有者，不能沿用新主人的事务身份。
调度入口、租约入口、身份登记和受限清理入口属于明确的基础设施例外，范围见下方身份规则。业务服务不能获得这些所有者的角色成员资格。每个入口必须有正常调用、直接越权调用和跨账户参数的拒绝测试。

第三层：业务函数（SECURITY DEFINER，每类一个 NOLOGIN 所有者）

列表见下。它们调用第二层内核，不直接拥有跨角色的表权限。
跨账户业务函数只有社交写入和连接绑定两类。基础设施另有身份读取、队列领取、租约绑定、到期扫描和受限清理入口。每类使用独立所有者，不能共用一个全权角色。社交及连接的业务检查、内部调用范围和跨用户拒绝测试同时生效。

身份

身份写进鉴权辅助表 auth_sessions（见 2.16），只有 fn_identity 能写。它对业务表只读：按凭证查账户、按设备凭证查连接。任务的锁和租约验证由独立的租约所有者执行，再调用只授给该所有者的 register_job_identity。登记函数本身不能由业务登录角色执行。
用户请求：用户 API 每个事务第一条语句调用验证函数，验证登录凭证后写入身份。
服务任务：
- 领取：claim_jobs(种类列表, 数量) 归队列所有者，只锁任务、不再等待账户锁，按 (state, run_after) 跨用户领取。用 SKIP LOCKED 跳过正被处理的任务，只返回 session_user 白名单中的种类。每次领取递增租约代次，生成不可猜的令牌，仅返回给领取者；jobs 保存令牌哈希和领取登录角色。续租、完成各有受控函数，重新校验角色、令牌、代次和截止时间。重领轮换令牌，完成或取消清空哈希。明文令牌不进日志、任务检查点或文档。
- 普通业务任务每个事务第一条语句调用 bind_job(job_id, 租约令牌)。删除任务只用下述 bind_cleanup_job，不能走普通入口。专用租约所有者有任务租约列的 SELECT 和 state 列的 UPDATE 权，以取得行锁；服务登录角色没有这些写权限。
- 绑定先无锁查任务与目标资源，再按 1.6 取得资源锁、账户锁和任务 FOR UPDATE 锁。重读后校验账户 state = normal、身份不是 cleanup、登录角色、普通任务种类、令牌、代次和 clock_timestamp() 仍在租约内，再登记任务身份。锁持有至事务结束，续租、完成无需从共享锁升级。重领必须等待或跳过，不能与旧发布并发。
- 计算不持有这个短事务。发布另开事务重新绑定；输出写入的最终守门动作再次检查租约，过期即回滚。租约结束不意味着外部副作用可重发，外部命令仍按稳定命令 ID 去重。
- 定时扫描调用 schedule_due(cursor)。调度登录角色只有该函数的 EXECUTE 权，不需要用户身份，也不能传入任意账户或任务种类。
- 调度函数归专用 NOLOGIN 所有者，通过列权限和只读行级例外枚举正常用户、待处理水位、结果到期时刻、生活日结算状态及临时修订标记。读取范围只服务于定时补算、发现过期和日终压缩，不返回私有内容。
- 每次调度调用最多处理一个账户，返回下一次扫描游标；调用方提交后再调用下一次，函数不在内部提交。函数锁账户、重查可用状态和到期条件，再调用仅授给调度所有者的建任务入口。幂等键由账户、目标、任务种类、到期周期及触发水位确定，不使用本次扫描时间。停用、删除中和已删除账户不建任务。删除清理走删除服务自己的专用入口，不经过这项排除普通工作的扫描。
删除任务使用独立的 claim_cleanup_jobs、bind_cleanup_job、renew_cleanup_job、complete_cleanup_job 和清理提交入口。只授给删除登录角色或对应清理函数所有者，统一调用 1.8 的校验内核。到期扫描发现 deleting 账户的未完成根任务时可创建缺失清理子任务；deleted 账户只补备份与回执对账。该扫描不经过普通 schedule_due，也不能对任意账户创建清理工作。
同步请求（接入、绑定、授权服务）带用户凭证，走同一个验证函数。
Pin 上传：按设备凭证 → 连接 → 账户的顺序找到所有者。
系统账户（global、eval）只允许发布服务和评测服务用服务凭证取得；系统账户的登录凭证列为空（CHECK）。
current_owner() 标 PARALLEL RESTRICTED；CI 检查它的并行属性，并有一条并行查询的行数测试。

函数加固清单

REVOKE EXECUTE FROM PUBLIC；每个函数只授给列出的调用方；每新增一个函数所有者，同一个迁移里加 ALTER DEFAULT PRIVILEGES FOR ROLE。
SET search_path = pg_catalog, pg_temp；表名写全模式名。
函数内设种类白名单，核对目标修订的 writer、确认凭证和幂等键。
比较一律用 IS DISTINCT FROM。
不按参数拼表名。
迁移时用 SET ROLE 对应所有者建函数。
CI 检查全部非系统模式里 PUBLIC 能执行的 SECURITY DEFINER 函数为零，并检查 pg_default_acl 覆盖了全部函数所有者。
REVOKE TEMPORARY ON DATABASE FROM PUBLIC。

业务函数

accept_suggestion：用户 API 调用。第一次在建议卡上点 Accept 时，按建议的稳定 ID 和 basis_hash 检查（建议对象仍有效、basis_hash 一致、发现状态仍是生成时的状态、在有效期内），不要求修订号一致；再按建议的模板生成计划修订，同一事务写 decision 和提议关系、切换指针。用户看到的精确修订另记，供追溯。
accept_proposal、reject_proposal：用户 API 和 answer_question 调用。接受时检查完整依据（见 2.9）；拒绝只写 decision，不切换指针。
confirm_chat_change、undo_change：用户 API 调用；字段级检查（见 1.2）。确认事实提议分两种：
- 基准修订仍是当前修订：把指针切到待确认修订。
- 基准已过时、但字段级检查通过：写一个新的非待确认修订（当前修订加上提议改的字段），decision 记「已合并」；待确认修订本身永远不生效。
set_memory_state：用户 API 和 answer_question 调用；确认、修改、停用、恢复、删除记忆，写阻止键。
grant_consent、revoke_consent：只有授权服务调用。
set_share_setting、publish_share：用户 API 和分数发布任务调用。
answer_question：用户 API 调用；按提问目标分流（事实新修订、set_memory_state、计划转换内核 + accept_proposal）。
计划转换内核：归计划服务的函数所有者；把候选计划转成待确认计划修订。
set_wear_config、correct_fact、set_directive、toggle_crush_rule、rename_place：用户 API 调用。
bind_connection、unbind_connection：绑定服务调用；跨账户。
post_message：用户 API 调用；先对「账户 + 会话」加 advisory lock，再算序号，一次写完消息的身份行、修订和指针。
register_deletion_scope：删除服务调用；接入服务只能登记外部键类型。
social_write：社交服务调用；跨账户。
compact_provisional：压缩服务调用；具体候选、权限、保留集合和加锁规则统一见 1.6。
用户 API 可以直接插入的只有不改变任何对象状态的记录：feedback、later、impression、save。用户消息只经 post_message。决定、确认、撤销、状态变化只能由函数和触发器产生。
待确认修订的写入方（按函数所有者或服务登录角色列，不按「服务」泛称）：
- 在线 Agent：profile、preference、goal、plan、change_set，以及事实中用户可改的种类（event、meal_item、stage、instant、day 的边界）。
- 记忆服务：profile、preference。
- Coach：plan、change_set。
- 计划转换内核所有者：plan（来源 = 候选）。
- 计划服务的后台角色：plan（依据变化后的重新提议）。
- 对话提议的 idempotency_key = 来源消息 + 目标对象 + 变更项；directives 和 facts 的待确认修订上都建部分唯一索引。
- 授权、连接、Crush 规则开关、删除范围不能有待确认修订。
计划生效只经 accept_suggestion、accept_proposal、set_directive 三个函数。confirm_chat_change 遇到计划提议时转交 accept_proposal，不自行切换计划指针。计划服务只写待确认修订。

种类到写入角色（不在表里的种类一律拒绝）：

角色	facts	results	其他
用户 API（只经函数或直接插入用户操作）	补录和纠正	—	actions 中 actor = 当前用户；messages 的用户消息
接入、绑定服务	observation_gap、device_state_span	—	assets、source_records、设备回执；外部键删除范围（只经 register_deletion_scope）
主 Agent	day、awake_span、event、instant、place、普通活动的 stage	事件呈现（标题、封面、亮点），facet = main	—
计量服务	posture_track、context_track	事件计量、饭后窗口、每日统计、选源结果、可提醒时长	—
饮食 Agent、运动 Agent	饮食写 meal_item；运动写运动事件的 stage	餐食分析、运动分析、事件呈现 facet = diet / exercise（页面优先用专业 Agent 的）	—
评分服务	—	分数、Balance、贡献、基准、事件影响、逐餐饮食影响（候选）、习惯评价、身体结果、奖章	—
解释服务	—	当日解释、趋势、转折	—
洞察 Agent	—	—	actions：agent_judgment
守门和发布服务	—	发现和它的建议（同一事务写）、候选归因、候选习惯和计划	actions：guard_result、state_change
Coach	—	非发现来源的建议、提问、风险提醒、复盘、计划机会检查、个人基线、预测	directives 待确认修订（plan、change_set）
计划服务	—	—	directives：计划的待确认修订（依据变化后的重新提议）；候选转提议由计划转换内核完成
压缩服务（只经 compact_provisional）	只删 posture_track、context_track 的可压缩临时修订	只删定义允许的临时修订	只删候选内部关系；保留引用链
调度角色（只经 schedule_due）	—	—	枚举入口按到期规则建白名单任务；登录角色无表权限
提醒服务	—	起身响应	jobs：Crush 触发
情绪服务	自评（经用户 API）	机主与质量门、情绪观察	—
推荐服务	—	推荐	—
记忆服务	—	—	memories；directives 待确认修订
在线 Agent	用户可改种类的待确认修订	—	messages；目标是消息的 record_links；directives 白名单种类的待确认修订；对话、Coach、推荐三类任务
社交服务	—	—	social_relations、publications（只经函数）
删除服务（仅受限清理入口）	范围内删除，不写新事实	范围内删除，不写新结果	deletion_scope；同范围任务、检查点、删除回执和账本确认；动作正文仅按清理政策清理

2. 各类数据的存储和读写边界逐表说明列、约束、读写与生命周期

2.1 账户保存身份与权限代次（accounts）保存登录身份和权限序号

auth_issuer + auth_subject 唯一；state（正常、停用、删除中、已删除）；data_sequence；auth_epoch；deletion_generation；created_at。
已删除账户保留最小存根，正文清空。状态转换、迟到回执、备份及最终移除条件统一见 1.8，不能只按备份日期删除仍被清理流程需要的存根。

2.2 文件保留媒体与外部副本状态（assets）保存原始素材的位置和处理状态

source、usage（文件用途：raw、thumbnail、chat_attachment、share_copy、export、voiceprint、knowledge_pack、trace）、data_type（原始数据类型：camera、audio、imu、user_upload…；分享副本和缩略图沿用原文件的值）、media_type、object_key、checksum、size、captured_from、captured_to、wear_config_ref、component_id、parent_asset_id、replicas、processing_state、state、data_sequence。
内容、校验值、对象地址不变；上传、处理、删除、副本状态可以更新。
分享时复制一份 share_copy，带 publication_id；社交服务只读这一类。撤回动态时同一事务设为不可访问。
全局知识包文件的 owner_id 是系统账户「global」。
声纹模板只允许机主识别服务读取；授权用「生物识别」数据类型；保留期由隐私和法务负责人定（列入第 6 节）。

2.3 来源记录保留输入版本与同步顺序（source_records）保留外部输入和识别原始版本

kind：healthkit_sample、location_point、weather、calendar_event、posture_recognition、recognition_run（识别代次的完成标记）、device_report（原始上报，含组件标识）。整理后的设备回执写 actions。
retention_class = 清理方式 × 保留期。同一类别里所有来源种类的保留期必须相同；保留期不同的来源种类各用一个类别。识别完成标记单独一个类别。
列：owner_id、retention_class（保留和清理方式的类别）、provider、provider_source（HealthKit 里的设备或 App 包名）、connection_id、external_key、replacement_group（识别分段用：IMU 块 ID + 方法版本）、source_version、source_order、run_generation、op（upsert、tombstone、generation_complete）、start_at、end_at、value、unit、body、wear_config_ref、component_id、data_sequence。
主键 (owner_id, id, retention_class, start_at)；唯一键 (owner_id, retention_class, provider, external_key, source_version, start_at)。
两级分区：一级按 retention_class（清理方式 × 保留期，见上），二级按 start_at 月份。不同类别的来源不共用一个分区，整块清理不会连带删掉别的来源的新版本或墓碑。
每个来源的对象键、版本和顺序：

来源	external_key	source_version	source_order（可排序）
HealthKit 样本	样本 UUID	常量 v1；墓碑为 tombstone	同步批次序号（锚点查询的批次）
日历事件	日历 ID + 事件 ID	内部转换版本 = 连接代次 + 同步批次序号 + 批内事件序号；upsert 和墓碑都用此规则。同批重试复用，原始 etag 放 body 仅作内容比较	连接内持久递增的转换顺序（source_order）；外部修改时间仅供内容比较
姿态识别	IMU 块 ID + 方法版本 + 段序号	run_generation	run_generation
位置、设备上报	来源给的 ID	常量 v1	同步批次序号
历史观测天气	提供方 + 地点 + 观测时刻的稳定键	来源版本；无版本时用持久转换序号，同批重试复用	同步批次序号

写入规则：
- 不可修改的来源（HealthKit、位置）：外部键一旦有墓碑，以后的 upsert 一律拒绝，不比较顺序。同版本的重复行用 ON CONFLICT DO NOTHING 跳过。
- 可修改的来源（日历）：每个有效状态转换都获独立内部版本，包括相同 etag 的删除后恢复。新旧连接代次不能复用版本命名空间。连接换绑后，目标账户新建自己的同步代次。
- 同步批次 ID、批内顺序和转换序号分配保存在现有连接运行状态与同步任务检查点中，和来源写入、游标前移同事务提交。失败回滚时复用批次；成功后重试从持久检查点恢复，不能临时重发一组版本号。
- 同一批内多个操作按供应商给出的稳定顺序处理。source_order 对同一外部键全序且不复用，upsert 与墓碑都拒绝低于当前顺序的输入。相同顺序、相同内部版本和内容视为幂等重试；相同顺序但内容冲突则隔离并记拒绝原因，不能靠 data_sequence 决定胜者。供应商不能给出可靠顺序时暂停该对象同步并完整对账，不能伪造恢复。
- 拒绝的意思是跳过这一行并记一条 actions（计数和原因），批次照常提交，不整批回滚。
- 墓碑写成新行，start_at 取原记录的值，落在同一分区。
- 找不到原记录时：不可修改的来源不写墓碑，改由接入服务登记「外部键」删除范围；日历写一个墓碑（start_at 取删除时刻），之后顺序更高的恢复记录可以取代它。
- 不可修改的来源每写一个墓碑，同一事务也登记一条外部键范围（见 1.8）。
- 不可修改来源同批按「新增、修改、删除」处理；可修改来源遵循上述稳定转换顺序。新增、墓碑、同步游标和下游失效一起提交。重复批次按幂等键跳过。
通用读取规则（顺序不能换）：
1. 在水位以内，先按外部键确定每个对象的最终状态：source_order 最大的那一行，平手时 data_sequence 最大。
2. 再去掉墓碑。
3. 最后按时间范围过滤。
- 先过滤墓碑会读回删除前的行；先过滤时间会读回已经改到别的时间的旧日程。
姿态识别不走通用读取规则：
- 一个 IMU 块的一次识别 = 一个代次。代次写完后写一行 recognition_run（op = generation_complete，带分段数，可以为 0）。
- 完成标记就是这一代识别结果的发布事件：写它的同一事务里，用整个块的时段调用 mark_stale，让这段时间的消费者（轨道等）失效。空结果走同一流程。
- 当前集合 = 每个 replacement_group 里已完成的最新代次的全部分段。没写完的代次不可见；空结果也有完成标记，旧代次因此退出。
- 完成标记在自己的保留类别里，按块清理：这个块的全部分段都过期后才清除。跨月的块不会因为某个月的分区先过期而提前不可见。
天气：历史分析采用的已观测天气写 source_records，保存提供方、地点、观测时间和实际采用值。来源纠正时追加新版本，使依赖分析失效。临时查询与预报走缓存；推荐保存所采用的外部快照、取数时刻和有效期。缓存过期是未知，不代表晴天或零。保留期由对应能力和隐私负责人登记，未定前不启用长期历史天气分析。
保留：不可修改的来源和识别分段按分区整块清理；可修改的来源（日历）按外部键清理全部版本和墓碑；识别完成标记按块清理。每个来源种类登记保留期和「可重算截止」。
指向 source_records 的软引用是 (id, retention_class, start_at)。

2.4 生活事实统一时间线与用户纠正（facts）保存可纠正的生活记录

kind 和写入方见 1.11。
观察空白（observation_gap）：正文必须带 data_type，说明哪段时间、哪种数据没有观察到，原因是未佩戴、滑盖合上、离线待传、处理中还是数据丢失。由接入服务写入。时间线、Today 的缺口说明、负债上下界都读它。
轨道（posture_track、context_track）：每个生活日一个对象，正文是按时间排序的分段数组；带 method_key 和定义引用；修订行有 changed_range。
- 今天的轨道只由计量服务产生：最新一段写 Redis，按批次节流写修订，日终结算写定稿。页面、Crush 触发、起身响应都只读计量的产出。
- Redis 里的实时计量带方法版本、来源水位、观测截止、处理截止和过期时间。过期后页面显示「未知」，不把旧姿态当成当前状态。
- 计量服务在识别完成标记落库后、醒睡边界变化后，为受影响的生活日建计量任务。轨道登记来源水位，并把所属生活日对象和边界修订登记为精确输入。
- 方法换版时建新的方法分支，旧轨道保留。
- posture_track 是活动计量统一生成的四姿态计量轨道。原始识别仍保存在 source_records。计量在原始标注之上执行已定的 60 秒规则：两段 move 之间连续、可信且不超过 60 秒的停留计入 move，同时从原姿态扣除。缺口、冲突或未确认区间不能跨过。
- 每日统计、事件 Moving、最长移动和四姿态时间线共用这份轨道，不各算一遍。原始标注的 10 秒规则保留在来源层，不改写原始分段。实时尚未出现后续 move 时不预判合并；新证据成立后发布带 changed_range 的修订，并按依赖更新消费者。
- context_track 的每段保留 dimension、分类码和词典版本。活动标签和场景标签不能只凭同一个 code 合并。多标签展示可以重叠，总时长按区间并集去重。
事件：类型、时段、地点（place_id）、路线（route_id）、来源、用户改名、备注。身份行 lifecycle（active、merged、split、retracted、conflict）。
餐食子项（meal_item）：parent_id 指向用餐事件，一样菜一个对象；整盘量和个人实际摄入是两组字段，各带未知状态；用户改过的营养值写在这里并受保护。营养估计留在餐食分析结果里。
活动阶段（stage）：复用同一事实种类，保留稳定阶段 ID、父事件和用户保护。父事件属于运动分类时由运动 Agent 写，普通活动阶段由主 Agent 写；分类取已登记的 taxonomy，不能由写入方自报责任范围。用户新增或修改阶段经 correct_fact。
- 父对象必须是同账户、当前有效的 event。阶段必须落在已确认的父事件边界内；父事件仍在进行时只写已确认部分，不补造结束时刻。
- 器械等用户可改字段也放在阶段修订，自动重算不能覆盖受保护内容。用餐子项仍用 meal_item，不伪装成阶段。
- 阶段事实不保存独立可写的 has_gps。运动分析按实际轨迹与阶段时段生成 GPS 覆盖，读取时按稳定阶段 ID 和修订匹配。阶段改时段、位置晚到或纠正后，使该分析失效。没有对应分析时保留未知。
可纠正区间的身份：awake_span、observation_gap、device_state_span 的业务键不能包含可改的开始时刻。首次创建时，用来源的稳定段标识或首次创建动作的幂等标识登记对象 ID；重试复用该标识和已有输出 ID。
- 后续修正必须带已有对象引用，时间变化只出新修订。重新分段先匹配既有对象；无法一一对应时显式合并或拆分，并写关系，不靠新的开始时刻另建重复当前段。
- 主 Agent 负责醒着区间，接入负责观察空白和设备状态区间。各接入协议须证明其来源标识跨重试稳定；没有稳定标识时，用已持久化的创建动作标识，不能用当前处理时间替代。
合并和拆分：
- 关系只写在 record_links（merged_into、split_into），身份行不再存后继列表。
- 存续身份：用户先保护过的那个事件保留 ID；都没有保护时保留开始早的。另一个改为 merged，保留后继入口。
- 保护字段按子项 ID 或时间重叠迁移；对不上就进 conflict，请用户确认，暂停受影响结果的发布。
- 旧事件退出统计、新事件进入统计、迁移保护在同一事务完成。只有 lifecycle = active 的事件进入汇总。
一杯饮料只有一个身份：吃饭时喝的是餐食子项；独立的瞬时行为用 parent_id 指向餐食时，只引用子项 ID。
个人地点和路线（place）：主 Agent 聚类生成，路线带方向；用户可改名，改名受保护；记下对应的供应商地点 ID。
自评（origin = 用户）和模型观察分开种类。
佩戴形态：用户确认的佩戴配置是连接（directives 的 connection）的内容修订，经 set_wear_config 写入。设备上报组件标识。组件和已确认配置对不上的时段，写一条 facts 的设备状态区间「形态未知」；个人基线和跨形态比较排除这些时段。用户事后确认时，由任务把这段区间改为确认后的配置（新修订）。

2.5 定义保存方法与发布门（definitions）发布算法、分类和结构版本

全局，主键 (id, revision)。namespace、definition_key、kind、body、artifact_ref、content_hash、validation_ref、source_manifest。
kind：score_definition、stat_definition、taxonomy、agent、prompt、json_schema、medal_rule、knowledge_pack、recompute_policy、publish_policy、range_selector、sampling_policy、eval_set、eval_run_config、release_approval。
发布状态（草案、研究、已验证、仅记录、停用）的每次变化写一条 actions（owner_id = 系统账户「global」，target = 定义修订）；身份行放当前状态副本。
写入角色按 kind 分开：评分和提示词由能力负责人发布；JSON 结构由 CI 发布；知识包由知识服务发布。外部导入服务不能发布评分和提示词。
读取：所有服务角色可读已发布的定义和全局知识包（只读策略）；系统账户「global」的凭证只给发布服务。
知识：食品知识按整包发布，正文在 assets；饮食结果引用包的版本。地点、营业时间、天气不进 definitions。临时查询与预报用时拉取并缓存；推荐保存所采用的外部快照、取数时刻和有效期。历史天气按 2.3 保存已观测来源，不能用后来的预报替代。
正式发布门：发布服务只认 release_approval（绑定能力、数据、代码、模型、提示词、适用范围）。没有批准时，结果只能以「研究」或「数据不足」状态发布。

2.6 结果保存分析与发布依据（results）保存计算结论及其输入版本

身份行业务键：(owner_id, kind, facet, subject, period_key, method_key, instance_key)，NULLS NOT DISTINCT。
- facet 区分同一种类的不同层，例如当日解释的 balance 层和 activity 层。
- instance_key 区分同一周期里的多个对象，每个种类在定义里登记取法：发现取守门判为「新增」时生成的稳定发现 ID（由守门结果动作的幂等键用 UUIDv5 确定性生成，重跑得到同一个 ID；细化关系只放在 record_links 的 refines）；推荐取外部来源 ID；提问和风险提醒取去重键；按日的结果留空。subject 用「每张表一组列」；按日的结果 subject 指向 day 对象，period_key = day_index。
列：domain、mode（观测、研究、预测、反事实）、availability、lifecycle、definition 引用、observed_until、processed_until、published_at、score_day（day 对象）、data_cutoff。
正文保存计算值、顺序、跨日分配值及输入哈希。分配项引用对应输入关系；依赖和来源水位统一从 record_links 读取（见 1.5）。
事件 Moving：计量服务只保存 event_metrics.posture_seconds.move。它取统一计量轨道与事件、醒着区间的交集，跨生活日按实际交集分配。60 秒规则已在轨道执行，不再加一次停留。moving_seconds 是同一结果修订的读取别名，不独立写入。没有有效姿态为 null；部分覆盖保留已观测下界与覆盖状态，显示 Recorded moving；完整覆盖且未移动才为 0。速度和配速仍须通过距离、GPS 与姿态覆盖检查。
评分项满分：只保存在所用评分定义修订。分数保留评分项键、实际得分、输入读数、档位和定义引用，取消满分副本；接口按该精确修订提供 components.max_points。被引用定义必须保留。缺定义时标为无法解释，不套用最新权重。旧副本只作历史兼容，停止双写。
阶段 GPS 覆盖：运动分析引用阶段修订及位置来源，生成每个阶段的完整、部分、无轨迹或未知状态。无轨迹须有接入核对证据；尚未核对保持未知。页面只画实际存在的轨迹；覆盖不足不出速度或配速。运动与接入负责人交付覆盖规则、采样门槛和真实样例前，正式速度与配速继续阻塞。状态随分析修订保存，不新增表或种类。
每日选源（activity.source_selection，计量服务写）：这一天的步数用 HealthKit 还是设备、HealthKit 里取哪个来源、去重版本。事件计量和每日统计引用同一次选源结果。删除当天最后一条 HealthKit 步数后，整天重新选源，所有事件一起换来源。
分数和贡献分开：Activity 事件影响只用于排序和筛选，不能相加；Balance 贡献的合计必须等于页面净变化；Balance 引用各领域分的具体修订；Balance 基准是独立种类，当天固定，写明输入有效日和纠正的传播范围。
逐餐饮食影响（diet_meal_effect）是候选结果种类，由饮食评分方负责。它表达一餐对饮食领域分的影响，subject 指向该餐，输入引用餐食事实、饮食统计、评分定义及所用基准。它与 Balance 贡献、Activity 事件影响分别存取，不能互相替代。
- 饮食评分负责人提交公式、基准、可加性约束、最低覆盖和评测证据后，才允许正式发布 points 与原因句。此前不显示正式饮食分影响，Mock 必须标明演示。已有 Balance 贡献不能拿来填这张卡。
当日解释（day_narrative）：facet = balance 和 facet = activity 各一条，subject 是生活日；用到的授权一旦撤回就整体停用（不可分离）；重算策略为「合并一段时间再算」；Activity Today in Focus 的最后一句只用实时数据现算，不存。
饭后窗口（after_meal_window）：subject 是餐食事件；精确输入登记餐食修订、下一餐、醒睡边界、轨道修订和时间范围；保存整段久坐的真实边界和窗口内的部分。
建议：稳定 ID、有效窗口、来源（发现、计划、当天事实）、读取范围依赖（日历、当天事实）。Activity 的发现正好指向一条建议。
提问和风险提醒：目标对象、能改变的结论、有效期、去重键；回答走 answer_question。
- answer_question 在同一事务里：写回答（actions）、把提问设为终态（已回答、不清楚、否认、过期）、更新目标（事实新修订、记忆状态，或候选计划转成待确认提议）、建后续重算任务。
- 「不清楚」只关闭提问，目标保持未知；「否认」写进目标的保护记录；过期由定时任务写。
候选习惯和计划：用户选「作为长期计划」或「先试一段时间」时，计划服务在 answer_question 里把候选转成一份待确认计划修订（来源 = 候选），再走 accept_proposal 的同一套检查。非发现来源的计划，不要求发现修订和发现状态动作。
发现：lifecycle（active、withdrawn、suppressed、expired）在身份行；每次状态变化（含首次发布的 active）写一条 actions，带原因和判断 ID；expired 由定时任务写。结论、建议句或证据变了都出内容修订；但计划依据只看结论和建议句（basis_hash 不含证据），只有证据变化不触发计划再确认。
计划机会检查：区分没有机会、观察不足、已执行、未执行、用户保留原计划；保存计划修订和实际证据。
推荐：外部来源快照、取数时刻、有效期、商业合作标记。到期由任务写 expired；展示前复查有效期；许可到期由任务清理快照。
机主与质量门：每个语音片段的门槛判断和证据，未通过的片段说明原因。
向量只在身份行（当前修订）；检索按 (owner_id, kind, embedding_model) 过滤后精确计算；换模型由后台任务重算，切换前新旧并存。
奖章授予在这里；隐藏写 directives。

2.7 来源关系支撑追溯和重算（record_links）连接精确输入、证据和后续结果

target 和 source 都用「每张表一组列」；另有评测样本的软引用组（eval_instance、eval_sample_id、eval_sample_revision）。
relation 分三类（见 1.5）：
- 计算依赖：input（含读取时的 changed_seq，轨道类含 time_range）、source_watermark、read_range。
- 历史追溯：export_map（生产来源 → 评测样本）、attachment（消息 → 文件）、message_source。
- 业务关系：evidence_support、evidence_counter、evidence_background、evidence_gap、refines、merged_into、split_into、proposal_for（提议修订 → 建议修订）、supersedes（新提议 → 旧提议）、memory_source、conflict（带适用时段和情境）。
读取范围列：source_kind、time_range、selector（只允许 definitions 里的 range_selector）、watermark、active。
合并读取路径时保留选择条件。input 必须明确目标对象及修订、来源表与种类、相关时间范围。业务证据可以带采用时段，但不得因此冒充计算依赖。
HealthKit 的 value 必须和样本类型、单位、外部键、提供方及已选来源修订一起读取。心率与步数不能因字段同名混读。选源优先级仍由计量与接入验证，未定时不混加。
文档中的 assets.raw 表示 usage = raw，record_links.input 表示 relation = input；点分路径不是新增物理表或任意 DDL 列。共享读取选择器由对应能力登记到 definitions，并用正反样例验证。
只增；计算依赖的 active 可随失效更新，只有 read_range 的运行 watermark 可以前移。input 的精确修订、读取时状态与采用范围，以及 source_watermark 的已用水位均不可变。新计算使用不同输入时登记新关系，历史记录不覆盖。

2.8 个人记忆保留理解与独立证据（memories）保留经过确认的个人理解

kind：preference、context_pattern、feedback_reason、user_statement。
列：statement、state（候选、有效、停用、冲突）、confirmation（用户明确表达、用户确认、系统提取）、purposes、valid_from、valid_until、weight、reinforcement_count、protected_fields；身份行上有 embedding。
按键执行的信息不进记忆：出生年、身高、饮食限制、通知时段、回复风格存在 directives。记忆服务抽到这类信息时，写 directives 的待确认修订。
用户改过的状态写进 protected_fields。强化时遇到用户停用的记忆，只登记新来源，不改状态，需要时生成一条提问。召回只取有效的记忆。
冲突用 record_links 的 conflict 连起来，生成一条提问。用户自述、明确限制、系统观察不互相覆盖。
强化按独立来源去重。用户修改、停用、删除走 set_memory_state。
防止自我强化：事实、结果和消息的修订行都带 memory_lineage（影响它的记忆 ID 集合 = 直接读过的记忆 ∪ 全部输入的 memory_lineage）。抽取时，候选的证据里已经含有同一条记忆，就不算新证据；来源说不清时，一律不增加强化次数。

2.9 用户设定维护授权与待确认意图（directives）保存用户约束未来行为的决定

kind：profile、preference、consent、connection、medal_visibility、goal、plan、change_set、plan_exception、crush_rule、deletion_scope。
不能回退、不能有待确认修订的种类：consent、connection 的绑定、deletion_scope。
业务唯一索引 (owner_id, kind, business_key) 带条件 kind <> 'deletion_scope'；删除范围每次新建一个对象，范围类型和范围值用生成列，供 GiST 和过滤使用。
列：business_key、timezone_mode、body、basis_hash、proposal_base_revision、trigger_action_id（触发这份提议的状态变化）、valid_until、protected_fields。
连接：身份行有绑定状态、凭据引用（不存密钥）、sync_cursor、last_seen_at（按分钟节流）。跨账户部分唯一索引：(kind, business_key) WHERE kind = 'connection' AND revision = 0 AND 绑定有效，保证一个 Pin 只绑一个账户。实时状态（连接、电量、滑盖此刻）放 Redis，设过期时间；过期即显示「未知」。状态变化写 facts 的设备状态区间。
计划提议：
- 同一计划可以有多份待确认修订，按「来源 + 依据」区分。
- 提议用 record_links 的 proposal_for 指向建议修订，用 supersedes 指向被取代的旧提议。
- 提议的状态：pending → accepted、rejected、superseded、expired、voided。状态由最新一条 decision 或 state_change 推出。
- 接受时检查全部条件（变更组里每个目标都要满足）：
  1. 提议仍是 pending，还没有任何决定。
  2. proposal_base_revision 等于计划的 current_revision。
  3. 有发现来源时，依据没有实质变化：当前发现和建议的 basis_hash（结论 + 建议句）等于提议记下的值。只改证据不算变化。提议同时记下当时的精确修订，只用于追溯。
  4. 有发现来源时，trigger_action_id 就是这条发现最近一次状态变化（按动作 ID 比，不按状态名比；「撤回 → 恢复 → 再撤回」时，第一次撤回生成的提议不会复活）。
  5. 在有效期内。
    非发现来源按来源种类登记其依据检查，不能伪造发现或跳过计划基准和确认检查。任一适用条件不满足就作废，按新基准重新生成。
- 不同依据变化的处理：发现撤回或结论反转 → 生成待确认提议并通知；只有建议句变 → 生成待确认提议，不通知；压下 → 不改原计划；细化出新发现 → 不改旧发现的计划。
- 拒绝只写 decision，不切换计划指针，原计划保持不变。
- 发现状态变化时，按 record_links 反查以它为依据的计划和提议，同一事务建复查任务。
对话里的修改提议只存一处：改设定和计划，存为 directives 的待确认修订；改事实（事件时间、菜品摄入等），存为 facts 对应对象的待确认修订。消息用 message_source 引用它。幂等键 = 来源消息 + 目标对象 + 变更项。确认走 confirm_chat_change。记忆服务按同一个幂等键去重，只跳过已经处理过的那一项，不跳过整条消息。
变更组（change_set）：一次提议改多份计划；接受时同一事务写全部目标修订和一条 decision。
单次改期（plan_exception）：机会身份 = 计划 ID + 锚定时区的本地日期 + 当日序号。锚定时区在计划修订生效时固定；当日序号按重复规则里的时段顺序编号，规则不变就不变。多次改期更新同一个对象。修改重复规则时保留已有改期并检查冲突；完整替换计划时，只清除基准版本之前的改期。
Crush 规则：改内容出新修订；只切开关只改身份行（enabled、enabled_sequence），并写 actions。
- 机会 ID = 规则 ID + 内容修订 + 锚定时区的本地日期 + 触发窗口序号。触发窗口序号 = 当天这条规则第几次满足触发条件（从生效时段开始数）。Pin 和云端用同一算法生成。
- 一个机会可以有多次尝试和多条回执。actions 只增，delivery_receipt 的幂等键取「来源端身份 + 稳定回执 ID」，不再直接取机会 ID。回执保存 opportunity_id、命令 ID、内容修订、开关序号、结果和可信送达时刻。
- 失败后成功会保存两条不同回执。同一回执重传只存一次；多个成功回执仍按 opportunity_id 只计一次送达。读当前送达状态时，只要存在有效的可信成功回执，晚到的失败回执不能把它覆盖。
- Pin 本地触发也可直接上报回执，job_id 为空，不伪造云端任务尝试。云端 jobs 的执行尝试另记 job_attempt。固件和提醒服务必须实现跨重启稳定的回执标识、统一机会算法和真实送达证明；缺任一项时只保留原始上报，正式送达统计仍阻塞。
- 云端期望配置和设备已确认配置分开记（后者来自 config_applied_receipt）。可提醒时长按设备实际生效的区间算。
- 起身响应用可信的送达时间。窗口内有可信站或移动证据可判起身；只有足以排除起身的完整有效观测才能判未起身。部分观测、时间不可信或待补传分别保持观察不足或等待对账。晚到数据重算结果，不能修改原始回执。正式比例分母仍待产品与活动计量确定。

2.10 操作记录保留决定和真实回执（actions）

不可变。(owner_id, idempotency_key) 唯一；外部回执按来源身份和稳定回执 ID 去重，不能把同一机会的不同回执合成一条。全局动作（定义发布状态）用系统账户「global」。
列：actor、data_sequence、kind、target（每张表一组列）、job_id、parent_action_id、occurred_at（设备时间）、received_at、time_trust、outcome、body（带结构版本）、supersedes_action_id。
kind：decision（outcome：accepted、rejected、adjust_requested、continued、ended）、feedback、later、impression、save、confirm、undo、toggle、consent_confirm、agent_judgment、guard_result、state_change、checked（核对后输出不变）、ingest_rejected（来源记录被拒绝的计数和原因）、delivery_receipt、config_applied_receipt、job_attempt、deletion_receipt、answer。
「忽略」= 展示后在规定窗口内没有操作，现算。
提议状态按最新一条 decision 和 state_change 推出（和 2.9 一致）。decision 的 outcome 另有 merged（事实提议按字段合并）。
guard_result 的 effect 记录当时是否实际应用。评测通过以后，新判断可以写 applied；历史 log_only 动作不修改。重新处理旧候选时，重读当前输入、重新守门并写新动作，用新的输入和判断幂等键去重。历史回放不能出现当时未执行的变化。

2.11 对话消息保留会话与内容历史（messages）保存会话内的消息及其修订

conversation_id、ordinal（(owner_id, conversation_id, ordinal) 唯一）、role、reply_to_id、client_message_key（唯一）、job_id、state、body。
附件用 record_links 的 attachment 关联；附件处理状态在 assets。附件删除时，用到它的回答标为受限。

2.12 任务维护执行、租约和重试（jobs）跟踪执行租约、进度和重试

一个逻辑任务一行，状态原地更新。
列：parent_job_id、kind、idempotency_key（含触发它的序号）、target、purpose、definition_ref（代码提交、模型、提示词修订、参数）、read_ranges、start_watermark、exact_inputs（含状态序号）、consent_snapshot、auth_epoch、deletion_generation、deletion_scope_seq、state、run_after、expires_at、lease_until、lease_generation、lease_token_hash、lease_login_role、checkpoint、progress、error_code、trace_id、usage、output_refs。
领取生成租约代次；续租和提交都校验代次。每次尝试写一条 actions。
过期普通任务（例如过期的 Crush 提醒）放弃执行，写 actions。删除任务过期不代表删除完成；按当前删除代次重排或转人工对账，沿用原外部命令 ID。
外部动作带稳定命令 ID。PostgreSQL 是真源；Upstash 负责唤醒和排队，漏投的由扫描补发。
设备采样指令：jobs 发送，设备回执写 actions；滑盖合上和授权撤回优先于任何指令。
只能通过 1.11 的专用建任务入口建任务。各入口固定种类白名单；调度和失效传播的内部入口不授给普通服务。删除任务的 target 明确账户及 deletion_scope 引用，purpose 固定为 cleanup，deletion_generation 固定为创建时的当前代次；子任务不得改变范围。

2.13 社交关系决定参与者与可见范围（social_relations）管理好友、小组和可见范围

主键 (id, revision)；参与者列 user_id、peer_user_id、group_id、publication_id；行级权限按参与者判断。
kind：group（不挂个人归属）、friend、member（带 role）、share_setting（四项分数、活动、奖章各自的开关）、share_audience、reaction。
好友按排序后的两个用户 ID 唯一；成员按小组 + 用户唯一。
创建者删号只删他自己的成员行；小组没有成员时才删除。
小组分享按「当前成员」判断可见性（产品可改）。
社交写入不拿账户锁；共享对象按自己的 lock_version 做条件更新和回放。
成员可见性用 SECURITY DEFINER 辅助函数判断。

2.14 分享快照隔离公开与私有内容（publications）发布允许跨用户读取的内容

主键 (id, revision)；author_id。kind：score_share、activity_share、medal_share、comment。
快照按字段白名单生成，带 consent_basis。只经 publish_share 生成。
- 分数快照：分数、所属日、档位、方法版本、是否可用。
- 活动快照：标题、类型、日期、用户选的封面副本、用户选的数字（时长、距离）。不含私人备注、GPS 轨迹、心率、原始菜品和证据。
- 奖章快照：奖章名和日期。
开关变化走 set_share_setting：同一事务写开关、撤回或刷新快照。读取时再按开关复核。
评论继承父帖可见范围；写和删按评论作者检查。
来源授权撤回时，撤权任务撤回受影响的快照；读取时也经 check_share_visible() 过滤。
排行榜只读 publications 和 social_relations。

2.15 隔离评测实例保存样本与逐次结果

表清单：accounts（存根，只有系统账户 eval 一行）、definitions、jobs、assets、actions（只用 job_attempt）、evaluation_results。复用列，不复用外键：外键只能指向实例里的这 6 张表；jobs 的 target 和 actions 的 target 只保留 jobs、definitions、assets 三组，其余目标组固定为空并加 CHECK；assets 的 publication_id、wear_config_ref 固定为空。
definitions：评测集契约（任务、指标、门槛、切分规则、分组键、去重簇）、运行配置（代码提交、模型、提示词修订、参数、随机种子、切分、阶段、基线、实际读取的样本清单），不可变。
jobs：运行状态。assets：样本清单、真值文件、输出。
evaluation_results：带 owner_id（固定为 eval）；(owner_id, run_id) 指向 jobs；sample_id + sample_revision 是样本清单里的软引用；评测侧的删除角色可以删除这张表的行；(run_id, sample_id, sample_revision, repetition, scorer_version) 唯一；prediction、metrics、error_type、state、usage、latency、cost、trace_ref。只增。重新打分只加 scorer_version，沿用原预测。
模型执行器只读本轮输入；封存真值只给独立评分器。
泄漏检查：运行前检查训练材料、提示示例、检索材料、特征处理的来源清单，分别禁止验证集和测试集进入训练用途。生产提示词和检索库的 source_manifest 由发布流程单向送进评测实例核对。
生产发布门只接收 release_approval，不接收真值。
评测业务表有 6 张，其中 evaluation_results 是唯一的新业务表种。沿用事务身份时总计 7 张物理表；仅用实例登录角色隔离时是 6 张。此选择未定，不能把评测物理 DDL 宣称为已冻结。

2.16 事务身份约束数据库访问（auth_sessions）

不存业务数据，不计入 14 张业务表。
一行 = 一个事务代表谁。主键 xact_id（xid8）。current_owner() 同时核对当前事务、backend_pid、session_user 和 expires_at，缺失或过期时拒绝私有访问；同一事务不得重新绑定。列：backend_pid、actor_kind（user、job、device、system、cleanup）、owner_id、job_id、deletion_scope_ref、deletion_generation、lease_generation、login_role、expires_at。清理身份专用读取函数只授给清理内核，普通 current_owner() 排除 actor_kind = cleanup。
只有 fn_identity 能写；其他角色不能读写。
生命周期只有一种说法：事务结束后这一行即失效（current_owner() 只认 xact_id 等于当前事务 ID 的那一行，旧行不会被下一个事务误用）；物理删除由定时任务清理。
登记身份单独占一条语句；所有请求都走主库的读写事务。需要只读副本时，另定身份方案（列入第 6 节）。
评测实例同样有 auth_sessions，或者评测实例不用行级策略、只用登录角色权限（二选一，由评测平台负责人定）。

3. 关键索引（身份行上的部分索引：WHERE revision = 0 AND deleted_at IS NULL）列出查询索引和容量验证前提

facts：(owner_id, kind, day_id) WHERE lifecycle = 'active'；GiST (owner_id, kind, 区间表达式)；GIN (lookup_keys)；待确认修订的 (owner_id, idempotency_key) 部分唯一索引。
results：唯一 (owner_id, kind, facet, subject, period_key, method_key, instance_key) NULLS NOT DISTINCT；(owner_id, kind, score_day)；(owner_id, kind, lifecycle)。
directives：唯一 (owner_id, kind, business_key) WHERE kind <> 'deletion_scope'；删除范围 (owner_id, 范围类型, 范围值) WHERE kind = 'deletion_scope'；待确认修订的 idempotency_key 部分唯一；连接的跨账户唯一索引；删除范围 GiST (owner_id, 范围类型, tstzrange(start_at, end_at))。
source_records：唯一 (owner_id, retention_class, provider, external_key, source_version, start_at)；(owner_id, kind, start_at)；(owner_id, provider, external_key, source_order DESC, data_sequence DESC)；识别 (owner_id, replacement_group, run_generation DESC)。
record_links：来源反查 (src_*)；GiST (owner_id, source_kind, time_range) WHERE active；(owner_id, relation) 供删除时按用户扫描。
actions：(owner_id, target_*, kind, data_sequence)；(owner_id, kind, occurred_at)；唯一 (owner_id, idempotency_key)。
messages：唯一 (owner_id, conversation_id, ordinal)；唯一 (owner_id, client_message_key)。
jobs：(state, run_after)；(lease_until) WHERE state = 'running'；(owner_id, kind) WHERE state = 'running'；唯一 (owner_id, kind, idempotency_key)。
publications：(kind, published_at)；social_relations：(peer_user_id, kind)、(group_id, kind)。
容量估算的前提和控制：
- source_records：每用户每天数千到上万行（心率、步数、识别分段）。
- facts、results：每天几十个对象。今天的对象白天按批次出临时修订，日终定稿；临时修订在定稿后压缩清理。
- record_links：只登记直接输入；临时修订每批都登记。按每天 50 个结果、每个 40 个直接输入、每天 10 批估算，每天约 20,000 行，其中有效行约 2,000；临时修订压缩后，留存约 2,000 行加被引用的部分。这只是估算，预算和压测见第 6 节。
- auth_sessions：每个已鉴权事务新增一行，页面读取也计入。预算按事务量计算，并包含主库写入、WAL、到期清理和索引成本。不得按业务对象数量代替。
- actions：每天几十到几百行（state_change 只记 lifecycle、day_id、deleted_at 和不按顺序的指针切换）。
- 这些都是估算，不是实测。上线前由后端负责人给出目标用户量、修订频率、保留期和写入预算，并压测账户锁持有时间、失效传播规模和关键页面的查询延迟（列入第 6 节）。

4. 各领域的最小数据合同定义各领域的输入、产出与发布门

领域	写入方	facts	results	准入和发布条件
饮食	饮食 Agent、计量、评分	事件、meal_item（整盘量、个人摄入、未知项）	餐食分析、饮食每日统计、饮食分、逐餐饮食影响（候选）、Balance 贡献	引用食品知识包版本；最低覆盖和曲线由饮食评分负责人定；未达标显示「数据不足」
活动	主 Agent、计量、运动 Agent、评分、Coach	轨道、事件、stage、place	事件计量（唯一的 Moving）、饭后窗口、每日选源、每日统计、活动分、事件影响、个人基线	评分只读每日统计；有效日门槛按定义；IMU 强度和设备步数未验证时为空
习惯	主 Agent、评分、Coach	瞬时行为、事件	习惯评价（公共风险、个人规律、用户目标分开；机会、观察情况）、风险提醒	没有机会、观察不足不算失败；用户目标版本在 directives
身体	接入、评分	—	身体结果	只用授权且实际存在的 HealthKit；样本带来源身份和墓碑
情绪	接入、情绪服务	自评	机主与质量门、情绪观察	未通过机主和质量门不进分析；不进评分；授权用途单独
洞察	洞察 Agent、守门和发布、解释服务	—	趋势、转折、候选归因、发现、候选习惯和计划	支撑至少 4 天；证据分支持、反例、背景、缺口；评测达标前 LLM 单独的更新和撤回只记日志
Coach	Coach、计划服务	—	建议、提问、复盘、机会检查	目标、计划、提议、变更组、改期在 directives
Crush	提醒服务、接入、计量	—	起身响应、可提醒时长	规则在 directives；云端触发在 jobs，Pin 本地触发按真实设备回执接入；回执在 actions；触发权未定前，正式统计阻塞
对话	在线 Agent	—	—	messages、jobs、record_links、actions、assets
记忆	记忆服务	—	—	memories；按键信息在 directives
Social	社交服务、评分服务（奖章）	—	奖章	social_relations、publications、分享专用 assets
M3 推荐	推荐服务、主 Agent（place）	place	推荐	外部来源快照、有效期、商业标记；位置未授权或依据不足时不输出具体商家

5. 扩展性通过种类和定义扩展能力

新领域：加 facts / results 的 kind、结构定义、授权用途、写入角色白名单。不加表。
新分析：加 results 的 kind、结构、重算策略、发布策略。不加表。
新 Agent：加 definitions 的 Agent 定义、jobs 的 kind、写入角色。不加表。
新 Crush 规则：加 crush_rule 的规则种类（触发条件、响应定义、观察不足的处理），响应仍写 results。不加表。
新记忆来源：加抽取入口和 record_links 的来源关系。不加表。

6. 发布条件与待验证能力明确责任、阻塞范围与验收交付

事项	负责	是否阻塞	临时做法
Crush 由 Pin 还是云端触发，双端交接规则	提醒服务、固件	阻塞正式提醒统计	只用 Mock 验证页面；机会 ID 算法先定
Crush 响应比例的分母	产品、活动计量	不阻塞建表	分别保存起身、未起身、观察不足、等待对账
撤权后派生结果的保留政策；阻止键保留什么	隐私负责人	阻塞隐私删除验收	停止使用受影响部分
授权最小凭证和声纹的保留期	隐私、法务	阻塞美国发布	声纹功能不上线
删除粒度（类型、时段、单个事件）在页面上开放哪些	产品	不阻塞建表	后端先全部支持
小组分享按当前成员还是发布时成员	产品	不阻塞	按当前成员
Activity 七日分怎样进入当天的 Balance	产品、评分负责人	阻塞正式 Balance	Balance 只显示已成立的领域结果
M3 是否需要地点知识表	推荐负责人	不阻塞	地点放 Redis 缓存
容量预算和压测（目标用户量、修订频率、保留期、写入预算、关键查询延迟）	后端负责人	阻塞上线，不阻塞建表	按第 3 节的控制规则实现
每个指标在原始记录过期后的复用条件	各计量负责人	不阻塞建表	不确定时一律标「无法重算」
在线拦截期（删除范围在线保留多久）、删除账本保留期	隐私负责人	阻塞隐私删除验收	先按备份保留期
只读副本的身份方案	后端负责人	不阻塞建表	所有请求走主库

上述待定项在能力开发前需要以下交付。未通过之前，临时显示和接口不得宣称正式能力可用：

公共权限实现：后端权限与队列负责人把 1.11 的能力入口落成明确的函数签名、GRANT、列权限、行级策略和触发器迁移；接入、绑定和各计算服务配合。必须验证边界用例和实际调用链。架构协议可作为开发输入，完整生产 DDL 和权限验收仍取决于真实迁移。
各结果的身份和父对象：能力负责人提交 facet、period_key、instance_key 取值及合法父类型清单，后端配合约束与正反例测试。缺清单阻塞对应种类写入。临时只能使用已有合同的种类，不能自由填字符串。定稿影响该种类业务键、引用校验和迁移测试。
选源、过期复用和路线执行：接入、计量和推荐负责人分别提交 HealthKit 优先级及重叠去重规则、逐指标过期复用条件、路线匹配版本及真实执行关联。用户纠正和晚到数据必须有重算样例。缺规则时保持缺失或无法重算；收藏、接受建议不算执行。正式规则进入定义版本，影响来源选择、事件计量、每日统计及其下游。
采样与 Crush：固件、接入、提醒团队提交配置代次、离线沿用、恢复对账、双端交接和稳定机会 ID 的真机记录；产品与活动计量确认统计分母。仍可保存规则和回执，正式提醒统计受阻。切正式方案时核对设备协议、回执去重、机会计算、统计接口与历史对账。
Balance 与 Activity：产品、评分团队提交有效日门、历史不足、基准纠正传播和 Activity 七日分接入方案；以标注数据和窗口边界用例验收。没有统一方案时只展示已成立的领域结果，不合成正式 Balance。变更影响评分定义、基准依赖、贡献解释、历史重算及页面状态。
隐私保留：隐私与法务确定删除范围、账本、授权凭证、声纹和记忆阻止键的期限，后端、接入和评测配合跨保留边界重传及备份恢复测试。当前流程测试不能替代隐私验收。正式政策影响清理调度、在线拦截、历史可用性和外部副本回执。
评测鉴权与容量：评测平台负责人选择六表角色隔离或七表事务身份，交付完整建表及越权测试；后端负责人提供账户锁、鉴权写入、引用留存、队列扫描和关键查询的压测。选择前不定稿评测 DDL，压测前不宣称可支撑上线规模。
逐餐饮食影响：饮食评分负责，计量和前端配合。交付统一公式、输入基准、可加性、最低覆盖和逐样本评测；未通过前阻塞正式影响卡及原因句。正式方案进入评分定义版本，重新核对 points、依赖、页面读取和历史重算，不借用 Balance 贡献。