[!info] related notes

• 所属 MOC: bodysense-moc、agent-moc
• 前置概念: agent-decision-authority、agent-safety-envelope
• 并列概念: treatment-temporal-validity-and-reauthorization、bodysense-treatment-aggregate-and-immutable-revisions
• 易混淆概念: Human confirmation vs business authorization
• 相关资源: bodysense-treatment-vertical-slice

Treatment 的 Proposal、Acceptance 与 Execution Authority

一句话定义

Treatment 中至少存在三个不同语义层次：模型提出方案（Proposal）、业务把方案接受为当前版本（Acceptance）、被接受方案中的 Intervention 进入可执行生命周期（Execution）。它们不能由同一个 LLM 输出一次性跨越。

[!important] 核心不变量 Can propose ≠ can accept ≠ has executed.

模型有资格提出一条 Intervention，不代表这条 Intervention 已成为用户当前方案；方案被接受，也不代表系统已经观测到用户实际执行。

为什么 Treatment 是从“AI 内容”进入“现实行动”的分水岭

Diagnosis 的主要产物仍然是 epistemic artifact：

“系统认为哪些解释可能成立？”

Treatment 开始回答：

“用户接下来可能应该做什么？”

一旦输出包含：

• 动作；
• 负荷；
• 次数；
• 频率；
• progression；
• stop condition；

它就不再只是“文本内容”，而是在影响现实世界行为。

因此从 Treatment 开始，一个很关键的架构变化是：

Semantic Generation
必须和
Action Authorization
分开

为什么 Diagnosis 里没有这么明显的三段式

Diagnosis 主要处理 epistemic artifact：

LLM Candidate Proposal
→ Runtime / Policy
→ Authorized Diagnosis Result

它的核心问题是：

“这次分析结果是否有资格被交付？”

Treatment 开始处理 action-oriented artifact：

AI Proposal
→ 可审核方案
→ 用户/业务接受
→ Intervention 成为当前计划的一部分
→ 用户实际执行
→ Outcome

一个动作越接近现实世界，越不能把“生成文本”与“授权执行”混成同一步。

三种 Authority 实际回答三个不同问题

Proposal Authority
“现在允许 AI 生成一个方案草案吗？”

Acceptance Authority
“这个已经生成的草案，现在仍允许成为 current Treatment 吗？”

Execution Authority / Execution Evidence
“这个已接受的 Intervention 现在允许继续执行吗？用户实际上执行了吗？”

注意第三层还有两个不同问题：

allowed to execute
≠
actually executed

前者是权限；后者是事实观察。

第一层：Proposal Authority

Proposal Authority 回答：

在当前 durable inputs 下，系统是否允许 AI 生成一个 Treatment proposal？

当前 BodySense 的 generation facts 会检查类似：

DiagnosisStatus
CandidateCount
DiagnosisFreshness
BodyState SafetyState
CandidateAssessmentReady

只有满足 deterministic policy：

→ allow-proposal

Python Treatment Agent 才进入 reasoning。

这一步的目标不是批准一个长期方案，而是确认：

“现在让 AI 提一个方案”这件事本身是合理的。

为什么先做 generation gate，再调模型

如果 Durable Domain 已经明确：

Diagnosis not ready
or
active safety concern
or
candidate assessments incomplete

就没有理由让 LLM 生成一个看起来很完整的普通干预方案，再事后删除。

这和 Diagnosis 的 pre-agent safety gate 是同一种控制思想：

确定性已知 blocker
→ 不浪费 stochastic reasoning

这不仅是省 token，更是减少危险中间产物

如果系统明知：

new red flag = true

仍然调用模型生成完整训练计划，虽然最后 policy 可能删除，但中间会产生：

• raw proposal；
• logs；
• debug UI；
• cache；
• accidental delivery risk。

所以能在 deterministic boundary 提前阻断的，最好不要制造本来就无权生成的 action proposal。

第二层：AI Proposal 本身没有“当前生效”权力

Python contract 明确：

TreatmentAgentOutput.status = "proposed"

并且不生成：

• durable Treatment ID；
• durable TreatmentRevision ID；
• durable Intervention ID；
• current=true；
• acceptance timestamp。

LLM 可以提出：

exercise
mobility
habit
self_test
education
monitoring

以及 prescription：

sets
reps / duration
frequency
progression
stop_conditions

但这些仍然只是：

TreatmentInterventionDraft

不是已经获准执行的 durable Intervention。

[!tip] Ownership Python owns semantic proposal；Go owns durable business transition。

为什么 Durable IDs 不能让模型生成

如果模型输出：

{
  "intervention_id": "I-123",
  "current": true
}

它事实上在声称：

“我拥有数据库 identity 和状态转移权限。”

这会把 semantic proposer 和 durable authority 混在一起。

更安全：

Python:
TreatmentInterventionDraft

Go/domain:
AcceptRevision
→ create Intervention I123
→ assign durable identity

这和 Diagnosis 中 Python 不拥有 Analysis/Candidate durable ID 是同一原则，但 Treatment 的后果更现实。

Proposal 可以被保存，但仍然不是 Current Truth

保存 proposed revision 是合理的，因为需要：

• UI review；
• audit；
• replay；
• acceptance；
• comparison。

但持久化并不等于生效：

Persisted
≠
Accepted
≠
Current

这是数据库系统里非常值得记住的一个边界：durable artifact 不一定是 current business truth。

第三层：Acceptance Authority

Acceptance Authority 回答：

这个已经生成并保存为 proposed 的 TreatmentRevision，在“现在”这个时刻，是否仍有资格成为 current Treatment？

这与 generation authority 不能合并，因为二者之间可能经过：

• 几秒；
• 几小时；
• 几天；
• 多个新的 BodyState revisions。

因此 acceptance 再次读取当前事实，包括：

proposal acceptance state
current BodyState revision
source BodyState revision
source Diagnosis
Diagnosis freshness
candidate assessments
current SafetyState
material changes since proposal

只有：

→ allow-acceptance

才把 revision 接受为当前计划。

这就是为什么当前 policy 有两个 phase：

generation
acceptance

而不是一个通用 allow=true。

为什么 Acceptance 不能只信“Proposal 当时通过了”

考虑：

10:00
R50 + D20
→ P3 generated safely

15:00
R51 contains new material change

15:10
user clicks Accept P3

如果 Acceptance 只看：

P3.generation_decision = allow-proposal

就会把过去的授权错误地当成永久授权。

正确模型是：

Past generation authorization
≠
Current acceptance authorization

详见 treatment-temporal-validity-and-reauthorization。

用户点击 Accept 为什么不是最终 Authority

用户明确同意很重要，但不能自动覆盖系统安全事实。

User Intent
= “我想接受这个 proposal”

而服务器还要检查：

Is acceptance still authorized now?

例如已经出现新的 red flag 时，即使用户点击 Accept，系统也不能因为“用户自己确认了”就绕过安全 gate。

因此：

Human Intent
≠
Business Authorization

HITL 不是把所有责任交给用户，而是把用户输入纳入一个受控 transition。

第四层：Acceptance 后才 materialize executable Intervention

AI 输出里的 intervention 是 draft：

TreatmentInterventionDraft

Accepted Revision 才对应 durable：

Intervention
├─ intervention_id
├─ treatment_id
├─ treatment_revision_id
├─ prescription
├─ status
├─ started_at
└─ ended_at

这条边界非常重要，因为 durable Intervention 可以被后续系统引用：

• Training Log；
• Outcome；
• 当前执行状态；
• review；
• audit。

因此：

Semantic draft
→ Acceptance boundary
→ Durable action identity

比让 Python 自己生成 intervention UUID 安全得多。

为什么 Intervention 应绑定 Accepted Revision，而不是只绑定 Treatment

如果只记录：

Intervention I7 → Treatment T1

未来 T1 已经有 R3/R4/R5 时，就不知道 I7 的 prescription 到底来自哪个版本。

更完整：

I7
→ Treatment T1
→ TreatmentRevision R3

这样 Outcome 才能准确归因：

O12 → I7 → R3

历史不会因为 current revision 切到 R4 而变模糊。

第五层：Execution 是事实，不是 Acceptance 的同义词

即使用户接受了方案：

TreatmentRevision accepted
Intervention I7 active

也不能推导：

用户已经做了 I7

是否执行需要新的 execution / observation evidence，例如：

• training log；
• user confirmation；
• sensor data；
• explicit Outcome source identity。

所以完整链条是：

Proposal
→ Accepted Plan
→ Executable Intervention
→ Actual Execution Evidence
→ Outcome

每一个箭头都代表不同的业务 transition。

Execution Authority 仍可能需要持续重新检查

即使 Intervention 已经 active：

I7 active at R60

后来：

new Outcome → BodyState R61
new safety concern

也可能需要：

pause / review / supersede

所以现实 action system 常见：

one-time acceptance
+ ongoing authorization

而不是一次 Accept 永久有效。

为什么这属于 HITL，但不只是“加个确认按钮”

Human-in-the-loop 的真正意义不是：

LLM output
→ 弹窗“确定？”

而是把人类输入放在一个重新验证上下文的业务命令边界上：

AcceptProposal(revision_id)
        ↓
reload current durable state
        ↓
re-evaluate authority
        ↓
commit acceptance atomically

用户点击 Accept 是 trigger，不是 authority 本身。

真正 authority 仍由当前 durable facts + versioned policy 共同决定。

Command 与 Query 的边界

GET proposal

只是查看，不应该改变 acceptance state。

真正改变业务的应该是显式命令：

AcceptTreatmentRevision(revision_id)
RejectTreatmentRevision(revision_id)
PauseTreatment(...)

这可以让 authority 和 side effect 集中在 command boundary，而不是 UI 打开某个页面就偷偷生效。

Generation DecisionTrace 与 Acceptance DecisionTrace 为什么分开

同一个 TreatmentRevision 至少需要回答两个不同历史问题：

Generation Trace

“为什么 10:00 系统允许生成 P3？”

Acceptance Trace

“为什么 15:00 系统仍允许 P3 成为 current Treatment？”

如果只留一份通用 trace，就难以解释中间 BodyState 是否变化。

所以当前模型分别保存：

GenerationDecisionTrace
AcceptanceDecisionTrace

这本质上是不同时间点的不同授权事实。

Acceptance 与 Current Pointer 必须原子提交

真正 acceptance 常常不只是：

revision.acceptance_state = accepted

还要：

Treatment.current_revision = R3
materialize Interventions
possibly supersede old current revision

如果这些分开提交：

revision accepted ✅
current pointer update ❌

系统出现双真值。

因此这个 transition 通常需要 transaction：

validate current facts
→ Decision allow
→ accept revision
→ switch current pointer
→ create/activate interventions
→ persist AcceptanceDecisionTrace
COMMIT

并发 Acceptance 为什么还需要 Revision Guard

两个请求可能同时：

Accept R3
Accept R4

或者在 validation 后 BodyState 又变化。

所以除了业务 policy，还可以使用：

• optimistic locking；
• current BodyState revision guard；
• transaction lock；
• unique/current pointer invariant。

这解决的是并发一致性，和 temporal validity 是互补关系。

Behavioral Contract

Treatment 可以把以下规则直接转成 deterministic evaluators：

AI output status must be proposed

unaccepted proposal
→ must not become current Treatment

proposal_not_proposed
→ acceptance forbidden

active safety concern
→ proposal/acceptance forbidden

material related BodyState change
→ old proposal acceptance forbidden

model confidence
→ cannot bypass generation/acceptance policy

再加：

accepted revision
→ current pointer must atomically agree

Outcome
→ must reference durable Intervention, not draft text

Proposal Quality 与 Acceptance Eligibility 也不是同一维度

一个 proposal 可能语义质量很高：

Grounding excellent
Prescription clear

但因为 current BodyState drift：

Acceptance blocked

反过来，current state 可能仍允许 acceptance，但 proposal grounding 本身不合格，也不能接受。

所以 acceptance facts 可以综合：

Proposal validity
+ Current temporal/safety validity

而不是只看其中一边。

一个完整例子

R60 + D31
Diagnosis fresh
Assessments ready
Safety clear
        ↓
GenerationPolicy
        ↓ allow-proposal
Python proposes P7
        ↓
Go stores TreatmentRevision R1
acceptance_state = proposed
        ↓
BodyState changes R60 → R61
        ↓
User clicks Accept
        ↓
AcceptancePolicy reloads current facts
        ↓
material change detected
        ↓ BLOCK

这里不能说：

“P7 是错误 Proposal。”

更准确的是：

P7 在 R60 的 generation context 下可能完全合法，但在 R61 的 acceptance context 下已经失去资格。

第二个例子：Accepted 不等于 Executed

TR5 accepted
→ Intervention I20 active

用户三天没有训练记录。

系统只能知道：

I20 is authorized/available

不能写：

I20 was performed for 3 days

直到出现：

TrainingLog L90
or sensor/user observation

这条边界对 Outcome/causality 极其重要。

测试这三层 Authority 应覆盖什么

Proposal Gate

Diagnosis stale → no Agent generation
Safety blocker → no ordinary proposal

Proposal Contract

Python output status=proposed
no durable IDs/current flag

Acceptance Reauthorization

source state unchanged → may accept
material current change → block

Transaction

acceptance + current pointer + interventions + trace
all commit or all rollback

Concurrency

two acceptance commands
→ no impossible dual current state

Execution Evidence

accepted intervention without log
→ do not infer executed

Ongoing Review

new worsening Outcome
→ current Treatment review triggered

自测题

1. Proposal Authority、Acceptance Authority、Execution Evidence 分别回答什么？
2. 为什么允许生成 proposal 不等于允许它稍后被接受？
3. 为什么用户点击 Accept 仍不是最终 Business Authority？
4. AI 为什么不应该生成 durable Intervention ID？
5. Persisted proposal 为什么不等于 current Treatment？
6. Intervention 为什么必须绑定 exact TreatmentRevision？
7. Accepted 为什么不能推导 Executed？
8. Acceptance 和 current pointer 为什么需要 transaction？
9. Temporal validity 与 optimistic locking 分别解决什么问题？
10. 为什么长期 action system 还需要 ongoing authorization？

最终心智模型

Reasoning Authority?      No
LLM only proposes

Generation Authority
→ Is proposal generation allowed now?

Acceptance Authority
→ Is this stored proposal still valid to become current now?

Execution Authority
→ Is this accepted action still authorized under current state?

Execution Evidence
→ Did the user actually perform it?

Outcome
→ What happened afterward?

这条分层是从“AI 生成内容”走向“AI 参与现实行动系统”时非常关键的一步。