[!info] related notes

• 所属 MOC: bodysense-moc、agent-moc
• 相关概念: treatment-proposal-acceptance-execution-authority、bodysense-treatment-aggregate-and-immutable-revisions
• 易混淆概念: Proposal prediction vs observed Outcome
• 关系笔记: association-vs-causation-in-intervention-outcomes

Intervention → Outcome → BodyState Feedback Loop

一句话定义

BodySense 的 Treatment 闭环不是“生成一个方案就结束”，而是把实际可执行 Intervention 之后发生的 Outcome作为新的 durable observation，再把其可接受的语义影响投影回 BodyState，形成新的 revision，并重新检查当前 Treatment 是否仍适用。

BodyState
→ Diagnosis
→ TreatmentRevision
→ Intervention
→ Outcome
→ BodyState Revision +1
→ Review Current Treatment

这条链把系统从“AI 给建议”推进成真正的 longitudinal feedback system。

为什么没有反馈闭环的 Treatment 仍然只是内容生成器

如果系统只有：

User state
→ AI plan
→ display

它不知道：

• 用户有没有做；
• 做了多少；
• 做完发生什么；
• 是否恶化；
• 是否需要调整；
• 哪个 Intervention 更值得保留。

即使生成质量很高，也仍然是一次性 advice generator。

真正 longitudinal 的关键是：

Action
→ Observe
→ Update durable state
→ Re-authorize next action

也就是把现实世界反馈重新送回 decision loop。

Diagnosis 与 Treatment 的闭环差异

Diagnosis 的主要闭环是 epistemic：

BodyState
→ reasoning
→ DiagnosisAnalysis

Treatment 增加了 action feedback：

已有状态
→ 采取行动
→ 观察行动之后发生什么
→ 把新观察纳入状态
→ 再决定下一步

可以理解为：

Sense
→ Reason
→ Act
→ Observe
→ Update State
→ Re-evaluate

其中 Act → Observe 是 L2 真正新增的领域复杂度。

Closed Loop 中至少有五种不同 Truth

1. Proposal
   系统建议什么

2. Accepted Action Identity
   什么动作获准进入当前计划

3. Execution Evidence
   用户实际做了什么

4. Outcome Observation
   做完之后观察到什么

5. BodyState Projection
   这些观察怎样改变当前 durable health state

如果把它们压成一个字段：

"treatment_result": "better"

后续几乎无法可靠推理。

Intervention：被接受后才拥有稳定 Action Identity

AI Proposal 中的：

TreatmentInterventionDraft

只是语义草案。

只有 Proposal 被接受后，系统才 materialize durable Intervention：

Intervention I7
├─ TreatmentID
├─ TreatmentRevisionID
├─ kind
├─ prescription
├─ status
├─ started_at
└─ ended_at

稳定 Intervention ID 让后续事实可以准确引用：

Outcome O9
→ intervention_id = I7

而不是模糊地记录：

“做了上次那个肩部训练以后……”

为什么 Action Identity 比动作名称重要

动作名：

臀桥

可能在不同 revision 里有不同 prescription：

I7: 2×8, low load
I18: 3×12, progressed load

Outcome 只写：

exercise = 臀桥

无法知道它对应哪一个 action version。

所以：

semantic action name
≠
durable action identity

Execution Evidence：被批准做，不等于真的做了

Accepted Intervention 只是：

authorized / available

真实执行需要新 evidence：

• TrainingLog；
• user confirmation；
• sensor/measurement；
• device sync；
• therapist observation。

因此：

Accepted
≠
Executed

这条不等式是 Outcome attribution 的前提。

如果用户根本没执行 I7，却把之后的改善绑定成 I7 Outcome，整个闭环就从第一步开始错了。

Outcome：记录“发生了什么”，不是“模型认为会发生什么”

Treatment Proposal 里的 expected_timeline 属于预测。

Outcome 属于现实反馈：

predicted effect
≠
observed outcome

Outcome 可以携带：

source_type
source_key
kind
concern_key
body_region
value
notes
occurred_at
provenance
intervention_id

它应尽量回答：

谁/什么来源，在什么时间，以什么方式，观察到了什么？

而不是直接回答：

“为什么发生？”

“为什么”属于更高层推断。

Observation First：先存原始观察，再做解释

一个很重要的数据工程原则：

Raw/structured observation
→ durable
→ domain interpretation/projection

而不是：

LLM interpretation
→ only persisted truth

例如用户说：

“今天做完以后右腿麻的范围更大了”

应该尽量保存：

• 原 observation / structured observation；
• occurred_at；
• source；
• linked Intervention。

然后 domain policy 再决定它对 BodyState 和 current Treatment 的意义。

为什么 Source Identity 很重要

当前 RecordOutcome 要求：

source_type
source_key
kind

原因是 Outcome 也需要幂等和 provenance。

例如手机端重复提交同一次训练反馈：

source_type = training_log
source_key = log-2026-08-22-001

系统应该识别它是同一个现实 observation，而不是创建两个独立 Outcome。

所以：

Outcome identity
≠
random request identity

它应该尽量绑定真实来源。

Source Identity 与 API Idempotency Key 也不是同一个概念

HTTP idempotency key

解决同一个请求重试。

Outcome source identity

解决“现实世界同一个 observation 是否已经被记录过”。

两个不同 API 请求也可能代表同一个 TrainingLog，所以仅靠 request UUID 不够。

为什么先 Persist Outcome，再投影 BodyState

当前实现的事务顺序非常值得学习：

1. CreateOutcome
2. BodyState.RecordOutcome
3. UpdateOutcomeBodyStateRevision
4. EvaluateCurrentReview

它体现了一个重要原则：

先保存原始业务事实，再保存从事实推导出的 projection。

Outcome 是：

“我们观察到什么”

BodyState revision 是：

“这个观察经过 domain policy 后，如何改变当前用户状态”

如果直接先改 BodyState、却没有 durable Outcome，未来就失去 provenance：

“这个状态变化到底从哪里来的？”

为什么 Projection 必须可追溯回 Outcome

BodyState R81 中新增：

pain trend improving

未来最好能追到：

R81 change
← Outcome O15
← TrainingLog L90
← Intervention I12
← TreatmentRevision TR3

这形成纵向 lineage。

如果 state transition 没有 source identity，就无法做可靠 audit/causal reasoning。

Outcome 不一定自动变成 BodyState Fact

一个 Outcome 可以表示：

疼痛评分从 6 → 4

但它是否应该成为：

• accepted Fact；
• Observation；
• Hypothesis evidence；
• 仅 audit record；

仍由 BodyState domain policy 决定。

所以：

Outcome
→ input to BodyState transition

not

Outcome
= BodyState Fact automatically

这和 Diagnosis 中：

External Evidence
≠
User Fact

是同一种 ownership 思想。

为什么 BodyState 不应该只是 Outcome 的“复制粘贴区”

BodyState 是长期语义模型，可能需要：

• normalization；
• conflict handling；
• recency；
• source precedence；
• trend aggregation；
• observation vs fact 区分。

如果每个 Outcome 全部直接 append 为 Fact，BodyState 很快会成为噪声日志。

正确：

Outcome event history
+
BodyState curated/current semantic projection

Transaction：为什么 Outcome 与 BodyState Link 要一致提交

当前实现把：

Outcome persistence
+
BodyState projection
+
Outcome.body_state_revision link
+
current Treatment review

放在同一个 Unit of Work / transaction 中。

原因是如果出现：

Outcome saved ✅
BodyState projection failed ❌

但系统仍对外表示成功，就会出现半状态：

• Outcome 存在；
• BodyState 没有反映它；
• review 没执行；
• 下次 retry 又不知道该做什么。

事务 + idempotent source identity 可以让 retry 更可靠。

为什么 Review 也最好包含在同一个一致性边界

Outcome 已经 material 改变 BodyState，却没有触发 current Treatment review：

BodyState says worsening
Treatment still active as if nothing happened

这会让 action state 和 health state 不一致。

所以如果 review policy 是同步且确定性的，把 projection + review status transition 放进同一 UoW 很有价值。

如果未来 review 异步化，也需要 outbox/event + retry，不能静默丢失。

Duplicate Outcome 为什么需要 Repair Semantics

当前测试甚至覆盖：

Outcome 已存在
but
BodyStateRevision link missing

此时不能简单返回：

duplicate, ignore

而应该继续修复：

existing Outcome
→ project into BodyState if needed
→ link produced revision

反过来，如果 Outcome 已经：

stored + linked to BodyState revision

重复请求就不应该再次创建 revision。

这体现了一个更成熟的幂等概念：

Idempotency 不只是拒绝重复，而是保证重复执行最终收敛到同一个完整业务状态。

Idempotent Convergence 比 409 Duplicate 更重要

简单 duplicate protection：

看到 source_key 已存在
→ return 409

可能把一个中途失败的半状态永久卡住。

成熟模式：

identify already completed stages
→ execute missing deterministic stages
→ converge to complete state

这对 durable workflow 很重要。

Outcome 如何触发 Treatment Review

记录 Outcome 后：

BodyState R70 → R71

当前 Treatment 不应继续假设世界没变。

因此系统执行：

EvaluateCurrentReview

可能得到：

active

或者：

review_recommended

如果出现更强安全变化，还可能进一步：

paused / superseded

具体 policy 可以演化，但核心原则是：

Outcome 不只是统计报表；它会进入未来行动授权。

Review Policy 应该关注 Material Change，而不是所有 Outcome

例如：

“今天完成了动作，感觉差不多”

可能只记录 Outcome，不改变 Treatment state。

而：

new radiating pain
marked worsening
new safety concern

可能需要 review_recommended/paused。

这和 Temporal Validity 的 materiality 思想一致。

Read Projection 与 Write Boundary 分开

当前实现还区分：

PreviewCurrentReview

和：

EvaluateCurrentReview

前者：

pure projection
→ 看“如果现在评估，会显示什么状态”

后者：

explicit write boundary
→ 真正持久化 status/reasons

这避免 GET/read-model 因为“读取页面”就偷偷产生 domain mutation。

[!important] Query 不应因为被读取而改变业务事实。

为什么 Read Mutation 很危险

如果打开 Treatment 页面就触发：

GET /treatment
→ recompute
→ update status

会导致：

• observability 难解释；
• cache/read replica 行为奇怪；
• 同一个 read 多次产生 side effect；
• 无明确 command/event 解释状态变化。

所以写 transition 应由明确 command/event 触发。

反馈闭环中有哪些不同 Truth

Action Intent

Accepted TreatmentRevision

系统计划做什么。

Action Unit

Intervention

具体可执行单元。

Execution Evidence

training log / user confirmation / sensor record

是否真的做了。

Outcome

做完以后观察到了什么

BodyState Transition

这些 Observation 对当前 durable health state 产生了什么被接受的语义影响

不能把这五层压成一句：

“AI 推荐了训练，用户做了，然后好了。”

多个 Intervention 同时存在时，Outcome attribution 更困难

一个 TreatmentRevision 可能包含：

I1 mobility
I2 strength
I3 habit change

用户整体变好时，不一定能准确说：

Outcome caused by I2

Outcome schema 可以：

• 绑定一个明确 source action；
• 绑定多个 related interventions；
• 或只绑定 Treatment/episode-level observation。

不要为了数据模型方便强行制造单一因果来源。

Outcome 也可能没有 Intervention

例如用户自然状态变化：

new symptom appeared before executing plan

它仍可能是 BodyState observation，但不是 intervention outcome。

因此：

Outcome/Observation domain

不应该被设计成“必须有 Intervention ID 才能存在”的万能容器，除非业务明确区分了普通 Observation 和 Treatment Outcome。

一个完整例子

R80
Diagnosis D40
↓
TreatmentRevision TR3 accepted
↓
Intervention I12
3 × 10 low-load exercise
↓
TrainingLog L90 says completed
↓
Outcome O15
pain = 4/10
occurred_at = 2026-08-22
causality = association_only
↓
BodyState.RecordOutcome(O15)
↓
R81
trend = improving observation
↓
EvaluateCurrentReview
↓
Treatment remains active

第二周：

Outcome O18
new radiating symptom
↓
BodyState R82
↓
review policy detects material change
↓
Treatment.status = review_recommended

旧 TR3 不修改；系统可能生成 TR4。

为什么 Outcome 不应该直接修改旧 TreatmentRevision

Outcome 描述“后来发生了什么”；Revision 描述“当时接受的计划是什么”。

所以：

Outcome worsening
→ review current aggregate / create new revision

而不是：

edit old TR3 to add new warning / remove action

这保护 historical immutability。

为什么这是 Longitudinal Agent 的关键闭环

没有 Outcome loop 的系统更像：

AI content generator

有了：

Action
→ durable observation
→ state update
→ policy review
→ new action

才真正变成一个随现实反馈持续演化的 decision system。

这个闭环如何成为未来 Eval 数据

真实 Outcome 可以帮助构建：

production observation slices

例如统计：

• 哪类 Intervention 经常触发 review；
• 哪类 proposal 后续被用户拒绝；
• 哪类 state change 导致 stale proposal。

但不要直接把 Outcome 当作模型“准确率标签”，尤其不能忽略因果问题。详见 association-vs-causation-in-intervention-outcomes。

测试 Feedback Loop 应覆盖什么

Identity

Outcome source identity duplicate
→ one durable outcome

Convergence

Outcome exists but projection missing
→ retry repairs missing projection

Atomicity

projection failure
→ no misleading partial success

Lineage

Outcome → BodyState revision link persists

Review

material worsening → review_recommended
non-material outcome → may remain active

Read purity

Preview/GET does not mutate current Treatment

Historical immutability

new Outcome does not rewrite accepted old Revision

自测题

1. 为什么 Accepted Intervention 不等于 Executed Intervention？
2. 为什么 Outcome 应先作为 durable observation 保存，再投影 BodyState？
3. Outcome Source Identity 和 HTTP idempotency key 有什么区别？
4. 为什么 Outcome 不自动变成 BodyState Fact？
5. Idempotent repair 为什么比简单“duplicate ignore”更成熟？
6. Outcome 为什么会影响未来 Treatment authorization？
7. 为什么 GET/read projection 不应该修改 domain state？
8. 多 Intervention 下为什么不能轻易做单一 attribution？
9. 新 Outcome 为什么不应修改旧 TreatmentRevision？
10. 为什么 Outcome 不能直接当作模型正确率的 causal label？

最终心智模型

Proposal predicts
Intervention authorizes action identity
Execution Evidence tells what was done
Outcome observes
BodyState integrates
Policy reauthorizes

这些动词分别属于不同层，不能互相替代。