> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# AI Objective / Evidence 数据模型目标态

> **Superseded for Task domain（2026-07-15）**：本文的 Objective-first / Task-as-action 模型未被采用。Task 领域不新增 Objective/Case 层，现行 contract 是 Task / Next Action / Activity / Outcome；见 [Task System Design](/product-design/v3/tasks-feature/task-domain-lifecycle.md)。本文仅保留为历史 exploration。

**Date**: 2026-06-25
**Status**: Draft
**Scope**: objective 数据模型、客户可见 sources、AI decision ledger、tool execution、registry、从 task-first 到 objective-first 的演进路线

## 0. 一句话判断

retaintive 长期不应该只是“AI 生成 task”。它应该是一台 **Evidence-backed Revenue Objective Engine**：

```text
call / SMS / voicemail / lead / CRM / policy / regulation / web signal
  -> evidence
  -> AI proposal
  -> policy decision
  -> objective
  -> task / approval / automation / outcome
```

`task` 是执行动作，`objective` 才是客户愿意付钱的业务对象。

客户真正要买的不是“有 AI”，而是：

- 哪些客户现在有 revenue opportunity 或 revenue risk。
- 为什么系统这么判断，有哪些 source。
- 谁应该处理，什么时候处理，逾期了没有。
- 处理以后是否真的产生 outcome。
- 对 VIP、高价值客户、合规敏感场景，系统有没有更高等级的保护和升级机制。

所以数据库不要设计成“存一个 AI 返回的大 JSON”。应该设计成：

```text
Typed core schema
  + versioned registry
  + JSONB details
  + append-only ledger
  + external trace/artifact pointer
```

固定 schema 负责产品、权限、查询、计费、审计；开放式 JSONB 负责模型细节和未来扩展。两者缺一不可。

## 1. 先定边界：AI 输出不是一种数据

AI 输出看起来千奇百怪，但落库时要先分成三类。

| 类别                          | 例子                                                           | 存哪里                                                             | 给客户看吗         |
| --------------------------- | ------------------------------------------------------------ | --------------------------------------------------------------- | ------------- |
| 业务事实 / 业务状态                 | objective status、task status、owner、due date、VIP priority、DNC | typed product tables                                            | 看             |
| AI proposal / decision fate | AI 想创建什么 objective、为什么被接受或拒绝、guard reason                    | append-only decision ledger                                     | 内部看；部分可转成客户解释 |
| 调试 trace / raw payload      | prompt、model response、token、tool args、latency、provider id    | Langfuse / Traceplane / object storage + lightweight DB pointer | 不直接看          |

最重要的原则：

> 客户页面永远读 **normalized product state**，不要直接读 raw AI output。

raw output 可以保留，但它不是产品契约。产品契约必须是稳定的 typed schema。

## 2. Fixed schema 和 flexible schema 怎么取舍

不要在 “全 fixed schema” 和 “全 JSONB” 之间二选一。正确答案是 hybrid。

### 2.1 必须 fixed 的东西

这些字段会被权限、列表、筛选、排序、报表、计费、SLA、通知和审计依赖，所以必须是 typed columns 或 typed enum：

- `tenant_id` / `store_id`
- `customer_ref` / `contact_phone`
- `objective_id`
- `objective_type`
- `status`
- `priority`
- `confidence_band`
- `risk_level`
- `estimated_value_band`
- `owner_type` / `owner_id`
- `due_at`
- `created_at` / `updated_at`
- `source_visibility`
- `decision_status`
- `approval_status`
- `execution_status`
- `idempotency_key`
- `trace_id` / `ai_run_id`

这些字段不能只藏在 JSONB 里。否则以后会出现三个问题：

1. 列表页查不快。
2. 权限和隔离容易漏。
3. 数据分析和计费会变成解析半结构化垃圾。

### 2.2 可以 flexible 的东西

这些内容变化快、行业差异大、还在探索期，适合放 `jsonb`：

- objective 的行业专属 detail。
- AI reasoning 的结构化片段。
- tool result 摘要。
- policy evaluation 的 extra context。
- source-specific metadata。
- 实验性字段。
- 模型输出的原始 normalized proposal。

但 JSONB 也要有规矩：

- 必须有 `schema_version`。
- 必须有 `producer`。
- 必须有 `visibility`。
- 高频查询字段要提升成 typed column 或 expression index。
- 不把 secret、完整 prompt、完整客户隐私文本随便塞进去。

PostgreSQL 的 `jsonb` 支持 GIN index 和 containment 查询，适合半结构化扩展；但它不是替代 relational schema 的理由。官方文档也把 `jsonb` indexing 描述为对 key / key-value / jsonpath 查询的加速能力，而不是“所有字段都进 JSONB”的建议。

## 3. 目标数据模型

最终态可以分成八组表。名字可以调整，但职责边界不要混。

### 3.1 Signal / Evidence 层

这一层记录“系统看到了什么”。

```text
evidence_items
knowledge_sources
knowledge_chunks
```

`evidence_items` 是统一证据表。它可以指向 call、SMS、voicemail、lead、CRM event、policy doc chunk、regulation doc chunk、web result、manual note。

核心字段：

| 字段                       | 含义                                                                                 |
| ------------------------ | ---------------------------------------------------------------------------------- |
| `evidence_id`            | 证据 ID                                                                              |
| `tenant_id` / `store_id` | 隔离边界                                                                               |
| `customer_ref`           | 关联客户                                                                               |
| `source_type`            | `call` / `sms` / `lead` / `crm` / `policy_doc` / `reg_doc` / `web` / `manual_note` |
| `source_id`              | 原始系统里的 ID                                                                          |
| `source_uri`             | 可回跳的 internal URI 或 object storage pointer                                         |
| `occurred_at`            | 事情发生时间                                                                             |
| `observed_at`            | 系统看到它的时间                                                                           |
| `excerpt`                | 可展示短摘录                                                                             |
| `content_hash`           | 防篡改 / 去重                                                                           |
| `strength`               | `hard_fact` / `fresh_intent` / `behavior` / `policy_rule` / `inferred_context`     |
| `freshness_bucket`       | `fresh` / `recent` / `stale`                                                       |
| `visibility`             | `customer_visible` / `internal` / `restricted`                                     |
| `metadata`               | source-specific JSONB                                                              |

这张表是 Perplexity-style sources 的地基。但它不是 trace table。它存的是业务证据，不是 prompt 和 token。

### 3.2 Objective 层

这一层记录“系统认为应该达成什么”。

```text
objectives
objective_sources
objective_events
```

`objectives` 是未来最重要的主表。它比 `tasks` 更接近客户价值。

核心字段：

| 字段                        | 含义                                                                                                                                  |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| `objective_id`            | 目标 ID                                                                                                                               |
| `tenant_id` / `store_id`  | 隔离边界                                                                                                                                |
| `customer_ref`            | 哪个客户                                                                                                                                |
| `objective_type`          | `lead_conversion` / `renewal` / `upgrade` / `churn_risk` / `complaint_recovery` / `referral` / `reactivation` / `compliance_review` |
| `title`                   | 客户可读标题                                                                                                                              |
| `summary`                 | 客户可读摘要                                                                                                                              |
| `status`                  | `proposed` / `open` / `waiting` / `needs_review` / `escalated` / `closed` / `dismissed`                                             |
| `priority`                | `low` / `normal` / `high` / `urgent`                                                                                                |
| `confidence_band`         | `low` / `medium` / `high`                                                                                                           |
| `estimated_value_band`    | `unknown` / `low` / `medium` / `high`                                                                                               |
| `risk_level`              | `none` / `watch` / `risk` / `critical`                                                                                              |
| `owner_type`              | `staff` / `manager` / `ai_agent` / `system`                                                                                         |
| `owner_id`                | 当前负责人                                                                                                                               |
| `due_at`                  | SLA / 应处理时间                                                                                                                         |
| `opened_at` / `closed_at` | 生命周期时间                                                                                                                              |
| `outcome_type`            | `booked` / `renewed` / `upgraded` / `saved` / `lost` / `not_interested` / `invalid`                                                 |
| `details`                 | JSONB，行业专属 detail                                                                                                                   |

`objective_sources` 是 objective 到 evidence 的引用关系：

| 字段                       | 含义                                                                                 |
| ------------------------ | ---------------------------------------------------------------------------------- |
| `store_id` / `tenant_id` | `store_id` 是查询隔离键；`tenant_id` 记录租户归属                                               |
| `objective_id`           | 目标                                                                                 |
| `evidence_id`            | 证据                                                                                 |
| `role`                   | `created_from` / `supported_by` / `contradicted_by` / `blocked_by` / `resolved_by` |
| `weight`                 | 对判断影响                                                                              |
| `display_order`          | UI 展示顺序                                                                            |

`objective_events` 是 append-only lifecycle stream：

```text
created
accepted
assigned
task_created
progress_recorded
escalated
approved
rejected
closed
reopened
outcome_recorded
```

它回答“这个 objective 怎么一路走到现在”。

### 3.3 Task 层

`tasks` 继续存在，但定位改变：

> task 是实现 objective 的一个具体 action。

一个 objective 可以有多个 task：

- 给客户回电话。
- 发 pricing options。
- manager review。
- 等待 CRM sync。
- 安排 VIP follow-up。
- 让 AI 草拟短信但先等人工批准。

目标态关系：

```text
objectives 1 -> N tasks
tasks N -> N evidence_items through task_sources
```

现有 `task_sources` 继续保留。短期内不要把它删掉或替换，因为它已经承担 accepted task provenance。未来可以让它引用 `evidence_items`，而不是只引用原始 call/message/lead id。

### 3.4 Decision Ledger 层

这一层记录“AI 想做什么，系统最后怎么裁决”。

```text
decision_attempts
```

它应该覆盖 task proposal 和 objective proposal，而不是只覆盖 task：

| 字段                                         | 含义                                                                                |
| ------------------------------------------ | --------------------------------------------------------------------------------- |
| `attempt_id`                               | 一次 proposal 尝试                                                                    |
| `store_id` / `tenant_id`                   | `store_id` 是查询隔离键；`tenant_id` 记录租户归属                                              |
| `target_kind`                              | `objective` / `task` / `contact_update` / `tool_action`                           |
| `action`                                   | `create` / `update` / `close` / `reopen` / `record_progress` / `request_approval` |
| `proposal_json`                            | normalized proposal JSONB                                                         |
| `source_refs`                              | 模型原始引用                                                                            |
| `resolved_evidence_ids`                    | 代码解析后的 evidence IDs                                                               |
| `decision_status`                          | `allowed` / `rejected` / `needs_review` / `skipped`                               |
| `decision_reason`                          | guard reason                                                                      |
| `write_status`                             | `not_attempted` / `written` / `zero_rows` / `error`                               |
| `written_objective_id` / `written_task_id` | 成功写入后的目标                                                                          |
| `ai_run_id`                                | 关联 AI run                                                                         |
| `execution_bundle_id`                      | 关联 prompt/model/schema/policy 版本组合                                                |
| `idempotency_key`                          | retry 去重                                                                          |

这层补的是当前最危险的黑洞：AI 提了，但最后没出现在页面上。

客户一般不直接看 `decision_attempts`。但客户可见解释可以从这里派生：

- “这个建议被创建，因为它引用了这些 sources。”
- “这个建议没有自动执行，因为需要 manager approval。”
- “这个建议被系统拒绝，因为客户是 DNC。”

### 3.5 Tool Execution 层

未来 read-only tools / write tools 都要进这一层。

```text
tool_executions
```

核心字段：

| 字段                        | 含义                                                             |
| ------------------------- | -------------------------------------------------------------- |
| `tool_execution_id`       | 系统真正执行的一次 tool                                                 |
| `tool_call_id`            | 模型提出的 tool call                                                |
| `tool_name`               | 工具名                                                            |
| `tool_version`            | 工具版本                                                           |
| `tenant_id` / `store_id`  | 执行隔离                                                           |
| `actor_type` / `actor_id` | 谁触发                                                            |
| `capability_scope`        | 本次允许访问的范围                                                      |
| `input_redacted`          | 脱敏输入                                                           |
| `output_summary`          | 脱敏输出摘要                                                         |
| `status`                  | `authorized` / `denied` / `succeeded` / `failed` / `timed_out` |
| `evidence_ids_created`    | tool result 产生了哪些 evidence                                     |
| `trace_id` / `span_id`    | observability join key                                         |

关键点：tool result 不应该只作为一段 transient prompt text 存在。只要它影响了 objective / task，就要变成 evidence 或 decision ledger 的引用。

### 3.6 AI Run / Trace Pointer 层

产品数据库里只保轻量 join key：

```text
ai_runs
ai_observation_refs
```

大 payload 交给 Langfuse / Traceplane / object storage。

`ai_runs` 负责：

- `ai_run_id`
- `store_id` / `tenant_id`
- `trace_id`
- `external_trace_url`
- `stage`
- `model`
- `provider`
- `prompt_version`
- `prompt_hash`
- `schema_version`
- `execution_bundle_id`
- token / cost / latency summary
- status

Langfuse 的核心数据模型是 traces、observations、sessions。OpenTelemetry 和 OpenAI Agents SDK 也把 LLM generation、tool call、guardrail、handoff 这些看成 trace/span/observation。Retaintive 应该顺着这个行业方向：内部调试看 trace，产品状态看 Neon。

### 3.7 Approval / Automation 层

未来 AI 能执行更多动作时，必须有：

```text
approval_requests
agent_executions
automation_runs
```

第一版可以只做 `approval_requests`：

| 字段                 | 含义                                                           |
| ------------------ | ------------------------------------------------------------ |
| `approval_id`      | 审批 ID                                                        |
| `target_kind`      | `objective` / `task` / `tool_execution` / `outbound_message` |
| `risk_level`       | 风险等级                                                         |
| `requested_action` | 请求执行什么                                                       |
| `requested_by`     | AI / staff / system                                          |
| `approver_role`    | 需要谁批                                                         |
| `status`           | `pending` / `approved` / `edited` / `rejected` / `expired`   |
| `decision_reason`  | 人类或系统裁决原因                                                    |

这和 LangChain Human-in-the-Loop / LangGraph persistence / Temporal durable workflow 的方向一致：高风险动作不能只靠模型自觉，要能暂停、等人、恢复、审计。

### 3.8 Registry 层

现在很多东西不规范，本质是 registry 不清楚。

目标态要有四类 registry：

| Registry                 | 管什么            | 例子                                                              |
| ------------------------ | -------------- | --------------------------------------------------------------- |
| Vocabulary Registry      | 业务枚举和 taxonomy | `objective_type`、`source_type`、`outcome_type`                   |
| Policy Registry          | 规则和阈值          | DNC、VIP SLA、approval threshold、tenant-specific compliance       |
| Tool Registry            | AI 可以用什么工具     | `customer_lookup`、`task_lookup`、`knowledge_search`、`crm_lookup` |
| Prompt / Schema Registry | AI 输出契约        | prompt version、Zod schema version、output contract               |

registry 不一定第一天全做成 DB 表。早期可以是 typed code + versioned config。关键是：

- 每个 registry entry 有 stable key。
- 每次 AI run 记录使用的 registry version。
- prompt 里的 label 可以变，但 stable key 不能随便变。
- tenant override 不能污染 global default。
- deprecated value 不能马上删除，要有迁移期。

## 4. 客户到底看到什么

客户不应该看到 AI 的内部链路。客户应该看到一个稳定、可解释、能行动的 product surface。

### 4.1 Customer profile 页面

展示：

```text
Open Objectives
  - Renewal discussion likely needed
  - Cancellation risk needs manager review
  - VIP follow-up overdue

For each objective:
  - status
  - priority
  - owner
  - due date
  - confidence band
  - estimated value / risk
  - evidence cards
  - related tasks
  - outcome
```

### 4.2 Objective detail 页面

展示：

```text
Objective
Why it matters
Recommended next step
Sources
Related tasks
Timeline
Outcome
```

source cards 可以长这样：

```text
Source 1: Call on 2026-06-24
"Customer asked whether membership can be extended."

Source 2: SMS on 2026-06-23
"Send me the renewal options."

Source 3: Policy
Renewal outreach is allowed within 30 days of expiration.
```

注意：source excerpt 要短、脱敏、可点击回原始上下文。不要把完整 transcript 大段塞进 objective 页面。

### 4.3 Manager / owner dashboard

展示：

- New revenue objectives detected.
- VIP objectives needing review.
- Objectives overdue.
- Objectives by type and store.
- AI-created vs human-created objective outcome.
- Top sources driving objectives.
- Rejected / needs-review proposals for admin audit.

这才是客户愿意付钱的地方：不是“AI 很聪明”，而是“我知道哪里在漏钱、谁该处理、证据是什么、最后有没有处理成”。

## 5. VIP 应该怎么进系统

VIP 不应该只是 contact 上的一个 badge。VIP 应该影响 workflow。

```text
VIP signal
  -> objective priority
  -> SLA
  -> routing
  -> approval threshold
  -> automation permissions
  -> manager visibility
```

VIP 目标态：

| 场景                   | 普通客户                               | VIP 客户                                             |
| -------------------- | ---------------------------------- | -------------------------------------------------- |
| cancellation intent  | 创建 retention objective             | 创建 critical retention objective + manager approval |
| unanswered follow-up | staff task                         | manager-visible overdue objective                  |
| pricing question     | send info task                     | manager-reviewed response if high LTV              |
| complaint            | complaint recovery objective       | immediate escalation + stricter source pack        |
| AI outbound          | low-risk can draft/send if allowed | draft-only or approval-gated                       |

VIP 不是“把任务布置给 VIP”。任务仍然分配给 staff、manager、AI agent 或 system。VIP 的作用是让系统更谨慎、更快升级、更重视 outcome。

## 6. Tool calling 和 orchestrator 怎么接

数据模型不要绑定某个 agent framework。Mastra、LangGraph、AI SDK、自研 loop 都只是 runtime 选择。

最小 loop 可以是：

```text
initialize run
load execution bundle
load current evidence window
call model
if model asks for read-only tool:
  authorize tool
  execute tool
  store tool_execution
  convert useful result into evidence_items
  call model again
if model proposes objective/task:
  write decision_attempt
  pass Policy Guard
  write objective/task if allowed
  attach sources
```

框架可以换，但这几个写入点不能换：

- `ai_runs`
- `tool_executions`
- `evidence_items`
- `decision_attempts`
- `objectives`
- `objective_sources`
- `tasks`
- `task_sources`

AI SDK 的 `ToolLoopAgent` 提供 `stopWhen` / `prepareStep` 这类 loop control。LangGraph 有 checkpointer 和 store，可以支持 pause/resume、human-in-the-loop、fault tolerance。Temporal 适合更长周期、跨天、需要 crash-proof execution 的 workflow。它们都不替代产品数据库里的 objective / evidence / ledger。

## 7. 分阶段演进路线

### Phase 0：现在已经有的地基

现状已经有：

- `tasks`
- `task_sources`
- `contact_timeline`
- `contactAnalysisRunId`
- `promptVersion` / `promptHash`
- Traceplane
- Policy Guard
- task accuracy harness

这说明方向已经对了。不要推倒重来。

### Phase 1：先把 task 解释清楚

目标：

- accepted task 一定能展示 sources。
- rejected / skipped / zero-row proposal 不再消失。
- AI run 能 join 到 prompt/model/schema/version。

要做：

- 补 `decision_attempts`。
- 扩 `task_sources` 读取 API。
- Task detail 展示 evidence cards。
- Langfuse / Traceplane 接 trace id。

做到后效果：

> 员工能回答“这个 task 为什么存在”；工程能回答“为什么该有的 task 没出现”。

### Phase 2：Objective shadow mode

目标：

- AI 同时输出 `taskDecisions[]` 和 `objectiveProposals[]`。
- objective 先 shadow write，不改变现有 task 行为。
- PM / engineer 用 dashboard 对比 objective 是否比 task 更稳定。

要做：

- 新增 `objectives` / `objective_sources` / `objective_events`。
- 让现有 task 可以 optional 关联 `objective_id`。
- 对一通 call 产生多个 task 的场景，验证一个 objective 下挂多个 task 是否更清晰。

做到后效果：

> 系统开始从“派活”升级为“识别业务目标”。

### Phase 3：Objective-first write path

目标：

- 新 signal 先生成 objective proposal。
- task 由 objective 派生。
- task 不再承担所有业务语义。

要做：

- writer 支持 objective accepted/rejected ledger。
- task dedupe 改为 objective-aware。
- close task 不等于 close objective；objective 关闭需要 outcome。

做到后效果：

> 一个客户的业务机会不会被拆散在多个孤立 task 里。

### Phase 4：Read-only tools + tenant knowledge

目标：

- AI 可以主动查 customer、task、call、SMS、lead、tenant policy、reg docs。
- 所有 tool result 都有 tool\_execution 和 evidence。

要做：

- Tool Registry。
- Tenant Knowledge Registry。
- Read-only tool authz。
- Prompt injection 防护。
- Cost / rate limits。

做到后效果：

> AI 不再只能吃预先塞好的 context，而是能在受控范围内自己补上下文。

### Phase 5：Approval-gated automation

目标：

- AI 可以提出 outbound message、manager escalation、CRM write、VIP handling。
- 高风险动作必须 approval。

要做：

- `approval_requests`。
- `agent_executions`。
- side-effect tool policy。
- human edit / approve / reject flow。
- outcome 回流。

做到后效果：

> AI 从“建议员工做事”升级为“在授权范围内推进工作”，但仍然不绕过人和代码。

### Phase 6：Durable workflows for long-running objectives

目标：

- 对跨天、跨周、需要等待客户回复或审批的 objective，支持 durable workflow。

候选：

- 继续自研 state machine。
- LangGraph persistence。
- Temporal workflow。

选择标准：

- 是否需要跨进程 crash recovery。
- 是否需要长时间 sleep / resume。
- 是否有复杂 approval。
- 是否需要多步骤 side effects。

做到后效果：

> objective 不只是数据库里的一行，而是能长期推进、暂停、恢复、审计的 workflow。

## 8. Final State 图

```text
Signals
  calls / SMS / voicemail / leads / CRM / docs / web
    |
    v
Evidence Layer
  evidence_items / knowledge_chunks
    |
    v
AI Runtime
  model calls / read-only tools / RAG / tool loop
    |
    v
Decision Layer
  decision_attempts
  policy guard
  approval gate
    |
    v
Business State
  objectives
  objective_sources
  objective_events
  tasks
  task_sources
    |
    v
Product Surface
  objective detail
  task detail
  customer timeline
  manager dashboard
  VIP escalation
    |
    v
Feedback
  outcomes
  staff edits
  customer replies
  eval scores
  prompt / policy improvement
```

横切全链路：

```text
tenant isolation
idempotency
trace_id / span_id
ai_run_id
execution_bundle_id
Langfuse / Traceplane
cost / usage
retention / privacy
```

## 9. 不要做的事

- 不要把 AI 原始 JSON 当产品主表。
- 不要把所有 flexible 字段都藏进 JSONB。
- 不要为每个行业一开始就建一套独立 schema。
- 不要让 prompt 里的中文 label 成为数据库里的永久 key。
- 不要把 Langfuse / Traceplane 当业务 system of record。
- 不要让 tool result 只存在 prompt 历史里。
- 不要让 rejected proposal 静默消失。
- 不要让 VIP 绕过 approval；VIP 应该更谨慎，不是更随意。

## 10. 推荐的近期开工顺序

第一优先级：

1. `decision_attempts`：先补“AI 提过但没落库”的黑洞。
2. Task sources UI/API：把现有 `task_sources` 变成客户可见信任能力。
3. `ai_runs` lightweight ledger：把 prompt/model/schema/cost/trace join key 固化。

第二优先级：

1. `objectives` shadow mode。
2. `objective_sources`。
3. objective detail 的 internal prototype。

第三优先级：

1. Tool Registry。
2. read-only customer/task/call/message/knowledge tools。
3. Langfuse traces 和 DB `ai_run_id` / `trace_id` 对齐。

第四优先级：

1. VIP policy。
2. approval queue。
3. outbound / CRM write side-effect tools。

这条路线的核心是：先把“为什么”存清楚，再让 AI 更自主。否则 AI 越自主，系统越不可解释。

## 11. 参考资料

本设计基于以下已有文档和官方资料：

- [系统世界观](/product-design/system-worldview.md)
- [AI 决策可追溯性：把 AI 做事过程变成可查的账](/system-design/ai-decision-traceability.md)
- [AI Agent Foundation 最终态与当前缺口](/ai/product/ai-agent-foundation-final-state.md)
- [retaintive LLM 平台架构终态与 Traceability](/ai/product/2026-06-24-llm-platform-architecture-and-traceability.zh.md)
- [Langfuse Observability data model](https://langfuse.com/docs/observability/data-model)
- [Langfuse Scores data model](https://langfuse.com/docs/evaluation/scores/data-model)
- [OpenTelemetry trace semantic conventions](https://opentelemetry.io/docs/specs/semconv/general/trace/)
- [W3C Trace Context](https://www.w3.org/TR/trace-context/)
- [PostgreSQL JSON Types](https://www.postgresql.org/docs/current/datatype-json.html)
- [AI SDK Loop Control](https://ai-sdk.dev/docs/agents/loop-control)
- [LangGraph Persistence](https://docs.langchain.com/oss/python/langgraph/persistence)
- [LangChain Human-in-the-loop](https://docs.langchain.com/oss/python/langchain/human-in-the-loop)
- [OpenAI Agents SDK tracing](https://openai.github.io/openai-agents-python/tracing/)
- [Temporal Durable Execution](https://temporal.io/blog/what-is-durable-execution)