中文 · Measurement, Model Execution & Evaluation Plane | Technical Design 1 | Technical Design 2 | Technical Design 2A

TD1 解决外部世界如何进入系统并形成可追溯 Knowledge；TD2 解决 Agent 如何在受控 Context / Capability / Policy 下读取世界、行动、调查并形成 Decision；TD2A 解决这些 domain runtime 如何被 Product API 和前端稳定使用。系统进入可运行阶段后，下一层缺口不再是新的业务模块，而是：如何证明一次运行到底看到了什么、调用了哪次模型、消耗了多少资源、在哪个世界版本上得到什么结果，以及版本变化后为什么变好或变坏。

TD3 因此定义 Measurement / Model Execution / Evaluation Plane。它不替代 M7，不重新定义 M3 enrichment P/R，也不把在线 Runtime 交给 evaluator 控制；它把当前已经存在但分散的 PromptAssembly、ModelProvider、Budget、Trajectory、ReplayCheckpoint、Snapshot、Product trace 和 competition metric 收敛成一套可冻结的运行坐标和评测执行模型。

TD3 已从“先补评测 substrate”进入 正式同 deployment 证据已闭环 / Measurement Plane 可下钻 / historical world replay 继续开放 的阶段。当前 CompetitionReport 为 2735331f-1f7d-419c-80d2-72c4ce157b5f，绑定 deployment:0e16e1b574d5b6383434e7fc80f64cc4；其中正式 Product/Session QA pin 到 Knowledge revision 2053。报告选择六个 BenchmarkRun：M1 monitoring、M3 structured、M3 Red Hat CSAF/VEX、fault recovery、M6 Product QA、M6 Session QA。六个 run 全部 completed，query_benchmark_evidence --require-closed 对报告闭包校验通过，37/37 CaseRun passed。

正式结果已经覆盖比赛需要的核心链路。M1 固定窗口有 12/12 latency-evaluable scheduled samples，p50=357.709s、p95/max=7241.893s、within-6h=100%，source taxonomy=8；独立 provider snapshot / expected-event manifest 驱动的 source_delivery_coverage=61.538%，这个结果与 latency 分开报告，保留当前真实 coverage 短板。M3 当前正式 aggregate 为 292 TP / 1 FP / 1 FN，micro precision=recall=99.659%。M6 live Product QA 共 14 case，answer accuracy、groundedness、citation correctness/completeness、completion、multi-hop 与 unknown 均为 1.0，interactive latency 平均 2.517s、最大 4.032s；两条 two-turn session 的 context chain / target carry 均为 1.0，RETRIEVE reuse case 的 invocation coverage / reuse rate 均为 1.0。fault recovery 为 3/3，覆盖 worker crash recovery、outbox fail-once retry 与 legacy artifact exact replay recovery。

Evaluation substrate 与 CompetitionReport 必须分开理解。当前注册 87 个 core metric，当前 MetricDefinition revision 下 85/87 已观测；17 个 metric group 中 15 observed / 2 partial。仅 runtime.model_provider_cost 与 runtime.capability_external_cost 没有 current observation，因为系统坚持只接受 provider/executor 返回的精确货币成本，不按 token × 官网价格伪造 cost。security、long-Investigation、M2 diagnostics、Agent gap/acquisition/state/planning/delegation/stop 等 controlled/diagnostic suites 已在全局 substrate 中产生 observation，但当前六-run CompetitionReport 没有把所有历史/诊断 run 强塞进同一个正式报告。

Model execution 侧，PromptAssemblyRecord、ModelRequest、ModelAttempt、provider-exact ModelUsage、retry ordinal、request/response RuntimeArtifact opt-in、DeploymentRevision、BenchmarkSuite/Run/CaseRun、MetricObservation 与 CompetitionReport 都已经有 durable owner。RecordedModelProvider 在 remote dispatch 前写 logical request/attempt，transient retry 形成同一 request 下的多个 physical attempt；provider 返回 token/cache usage 时按 exact observation 记录，缺失字段保持 unavailable。2026-10-12 更新：M6 Product/Case Decision 与 M5 Investigation planning 已接入 model token/retry reserve→actual settlement；M3 semantic extraction 仍未接入。提供方不返回精确货币成本时，external_cost 与 monetary metric 保持 unavailable，不能与“ModelUsage 不存在”混为一谈。

当前剩余结构性缺口集中在三处：M1–M3 仍没有完整 versioned Historical Knowledge Reader，因此 R3 full Agent historical re-execution 必须 fail closed；普通在线请求默认不复制 prompt/response payload，R1 exact model-boundary artifact replay 只在显式 opt-in 的正式测量路径成立；OpenAI-compatible adapter 内部的 structured-output dialect fallback 仍可能对应多个 HTTP exchange、但 recorder 只看到一个 ModelAttempt。RETRIEVE 在 Context/TaskRun 建立前失败时现由独立 RetrievalInvocation(disposition=failed) 留下请求坐标与异常类别（迁移 20261009_0033），不再属于开放缺口。更广的 live Case-read/long-Investigation、真实 external Capability、授权 asset/provider 与 human-adjudicated incident/normative denominator 属于后续扩展，不再被描述成“评测框架没做完”。

2026-10-09 补充：上述 dialect fallback 粒度缺口限于 auto 协商路径。对探针已确认的 DeepSeek dialect，运行时已显式配置 json_object，单次模型调用只发送一次 HTTP exchange；这个新配置进入 DeploymentRevision digest，不回写之前 decision-model-v2 的 QA 指标。

当前工程 gate：make check 522 passed / 12 skipped，Ruff 全绿，mypy 534 source files / 0 errors；真实 PostgreSQL/Redis + LocalStack integration suite 12/12，Alembic single head=20261002_0029。正式 CompetitionReport 继续绑定它运行时冻结的 DeploymentRevision；10/03 之后的 projection deadlock hardening 与文档更新不会倒写历史 benchmark provenance，后续若要评测新代码必须冻结新的 DeploymentRevision。

本文基于当前本地实现：

• PromptAssembly 已经持有 ordered fragments、trust/cache class、assembly hash 和 stable prefix hint；
• ModelProvider 已统一服务 M3 semantic extraction、M5 Investigation planning 和 M6 Decision planning；TD3 recorder 已把 logical request 与 physical attempt 变成 durable operational entity，并记录 provider-exact token/cache usage；Budget settlement 仍未把这些 actual usage 回结算到 reserve/commit/release；
• BudgetGovernor 已定义 model_tokens、external_cost、retries 等资源；ModelUsage/ModelAttempt 已是统一 measurement source，但 reserve/commit/release 与实际 provider usage 的闭环仍未完成，精确货币成本缺失时保持 unavailable；
• Trajectory 已有 latency / tool_calls / cost 字段，ModelAttempt 现在提供独立 model-call operational record；跨层 trace/report 已能通过 BenchmarkCaseRun 与 execution/task refs 关联；
• InvestigationSnapshot / ReplayCheckpoint 已经固定 Case / Context / Policy / Capability / model / prompt coordinate，但真实 historical Agent re-execution 被 M1–M3 latest-only Knowledge reader 阻塞；
• packages.evaluation 已有 M1 monitoring、M2 diagnostics、M3 evidence-aware enrichment P/R、evaluation-neutral M6 QA/session scorer、Agent/security/fault/long-Investigation metrics、durable Benchmark Runtime、CompetitionReport、M7 replay compare 和 Skill promotion gate；当前比赛关键空白已经转成 denominator breadth 与 historical-world replay，而不是 QA/Agent/fault substrate 缺失；
• TD2A Product Application 的 Question seam 已可执行，request_id → TaskRun → Execution → ModelRequest → DecisionResult / Investigation 已进入 live benchmark provenance。

因此 TD3 第一版优先冻结四个 owner：

1. World Snapshot / Historical Read：同一 benchmark / replay 运行读取哪个世界。
2. Model Execution Record：每一次逻辑模型请求与物理 provider attempt 到底发生了什么。
3. Benchmark Runtime：固定 suite、gold、系统版本与执行条件，运行并产出可比较指标。
4. Measurement / Operations：把 TaskEvent、Trajectory、CapabilityInvocation、ModelAttempt、Budget 与 deployment revision 连接成可解释运行链。

KV cache、Agentic RL、small-model optimizer、自动 prompt search 都不属于 TD3 第一版前置条件。

TD3 是观察、冻结、比较和报告层，不成为新的在线决策 owner。

Online Runtime
TD1 / TD2 / TD2A
    │
    ├─ Knowledge revision / Observation / Evidence
    ├─ TaskRun / ContextManifest / PromptAssembly
    ├─ CapabilityInvocation / Budget / Execution
    ├─ InvestigationState / Trajectory / Decision
    │
    ▼
Measurement Substrate
WorldSnapshot contract/ref / ModelRequest / ModelAttempt / durable execution refs
    │
    ▼
Evaluation Runtime
BenchmarkSuite / BenchmarkRun / CaseRun / MetricObservation
    │
    ▼
Report / Regression / Competition Evidence

Measurement 可以持久化运行事实、冻结世界和配置版本、统计 latency / token / cost / retry、重放固定输入、对 baseline/candidate 做同坐标比较，并形成 regression gate 和 competition report。

Measurement 不可以在线改变 Task completion，不因 benchmark 得分低而自动修改 Knowledge，不绕过 Policy 重试 tool，不把 evaluator verdict 写成当前世界事实，也不允许在同一个 BenchmarkRun 中偷偷修改 prompt / skill / model。

原始 TD3 立项时的三个大洞——PromptAssembly persistence、ModelRequest/ModelAttempt、统一 BenchmarkRun/CompetitionReport identity——已经被实现和正式 benchmark 验证。现在继续开放的不是同一批问题。

M4 state event 可以按 revision 重建，Task/Context/Model/Benchmark coordinate 也已经 durable；但 M1–M3 Knowledge 仍以 current read model 为主。Object properties、identifier binding、EvidenceLink visibility 与 structured retrieval 没有覆盖任意旧 Knowledge revision 的完整 reader，CurrentProjection 更只代表最新世界。因此 historical Agent replay 必须在 world 不可精确读取时 fail closed，不能拿 latest projection 冒充旧世界。

RecordedModelProvider 会保存 provider-exact input/output/reasoning/cached token usage，retry attempt 也有独立 ordinal；evaluation 可以直接从 ModelAttempt 聚合这些事实。M6 Product/Case Decision 与 M5 Investigation planning 现在为每次模型尝试预留 token 与 retry 预算，并在 ModelAttempt 终态按 provider exact 用量或预留上界结算；M5 允许轮次来自任务预算，恢复时计入已记录的逻辑模型请求。M3 semantic extraction 尚未统一使用这条预算链。货币成本只有 provider/executor 明确返回 exact value 才能成为 metric；缺失时必须保持 unavailable。

PromptAssemblyRecord 已持久化 fragment manifest、order/hash/cache hint，并可绑定 redacted request artifact；正式 Product QA / prospective Investigation measurement 可以显式保存 request/response RuntimeArtifact。普通在线请求默认只保存 digest/coordinate/usage，不复制敏感 prompt/response payload。因此“能定位当时的 assembly”已经闭环，“所有在线调用都能 R1 exact payload replay”没有闭环，也不应为了 benchmark 强制全量保存敏感内容。

Recorder 已经有 logical request / physical attempt / retry 语义。已知 endpoint 的 response dialect 现在可由 SECFUSION_MODEL_RESPONSE_FORMAT 固定为 json_schema 或 json_object；后者仍把同一 JSON Schema 放入 system instruction 并做本地 schema validation。2026-10-09 实际 DeepSeek 探针在 auto 下发生 fallback，固定 json_object 后返回 http_exchanges=1 / response_format_fallback=false，本地 API 容器也通过同一探针。未知 endpoint 的 auto 仍在 adapter 内协商：若 json_schema 被拒绝后重试 json_object，它保持一个 ModelAttempt，latency 覆盖两次 HTTP exchange，usage 取最终成功响应，并显式报告 http_exchanges=2。若正式测量必须覆盖 auto 路径每一次物理交换，应把 negotiation 提升到 recorder 之上，而不是把一个 attempt 假写成两个。

成功的 Product RETRIEVE 与 exact reuse 由 RetrievalInvocation 持久化，并进入 ContextManifest / Task provenance。现在物理检索或 exact-ref replay 在 Context/TaskRun 创建前失败时，Application 回滚 provisional Question transaction，随后在短事务写入 failed RetrievalInvocation：保存原请求坐标、时间和异常类别，不复制原始问题，也不制造空 Product session / 假 TaskRun。失败行不能作为后续 exact reuse 候选；数据库自身不可用时无法保证 attempt 写入，原检索失败仍向调用方传播。实现落在主仓库 migration 20261009_0033 与 packages/runtime/retrieval / AskQuestionUseCase，不改变成功检索的权威边界。

KnowledgeRevision 是数据提交序列，但不是完整 benchmark world identity。这里的 WorldSnapshot 首先是复合冻结 contract / typed reference，不因为设计需要一个名字就先增加 WorldSnapshotModel 表。当前 Benchmark Runtime 持久化 world_snapshot_ref：structured M3 的 frozen replay 已使用内容哈希的 provider-snapshot:<sha256> artifact coordinate；正式 live Product/Session QA 使用 knowledge-revision:2053 作为 live-world pin。二者都不是完整 R2/R3 historical world。只有当 source availability、provider fixture、index/document/incident revision 与 historical Knowledge reader 能被共同恢复时，才构成下面定义的完整 WorldSnapshot contract；若未来需要独立生命周期，再提升为一等 durable entity。

TD3 定义完整 contract：

WorldSnapshot
  world_snapshot_id
  knowledge_revision
  source_availability_snapshot
  source_revision_manifest
  document_index_revision?
  incident_revision?
  asset_observation_cutoff?
  vocabulary_revision
  retrieval_index_revision?
  created_at

Claims / Relations 的历史可见性按：

created_revision <= R
AND
(superseded_revision IS NULL OR superseded_revision > R)

解释。

同一个 Knowledge revision 下，外部 provider 是否可访问仍可能不同。需要联网 re-execution 的 case 额外固定 enabled/disabled、provider health fixture、rate-limit fixture、auth availability、source revision / upstream cutoff，以及是否允许访问 live provider。

因此 benchmark world 不是单一 revision 整数。

CurrentProjection 继续服务在线 fast read。Historical replay 使用专用 snapshot reader；不能读取 latest projection 后再声称是历史世界。

第一版增加 KnowledgeSnapshotReader，不复制整个数据库。

Object / Claim / Relation 已有 created_revision / superseded_revision，可按 revision 过滤。

当前 ObjectModel.properties 是 current representation。新增：

ObjectVersion
  object_id
  valid_from_revision
  valid_to_revision?
  properties
  content_hash

ObjectModel 保留 stable identity/current convenience state；ObjectVersion 负责历史属性。

2026-10-09 写入路径复核还发现 Claim/Relation 在处理器版本刷新时会把匹配旧事实的 superseded_revision 清回 NULL。这会抹掉旧的不可见区间；因此 4.1 的现有 revision 字段只足以过滤从未重新激活的事实，完整 Historical Reader 还必须保存 Claim/Relation 的可见区间。迁移前无法证明的旧区间必须 fail closed，不能用当前行反推过去状态。

当前 ExternalIdentifier 只有 current binding。新增：

ExternalIdentifierBindingVersion
  namespace
  value
  object_id
  valid_from_revision
  valid_to_revision?

避免 alias merge 后 historical replay 读取未来 identity mapping。

EvidenceLink 增加 created_revision / superseded_revision，或者迁移成 versioned binding。否则后来补上的 evidence link 会污染早期 historical case。

Observation / Artifact 是 immutable Evidence input，不需要为了 replay 复制内容。WorldSnapshot 只要求对应 Observation 在当时已经可见，Artifact / locator 仍可解析。

KnowledgeSnapshotReader.get_object(object_id, revision)
KnowledgeSnapshotReader.get_by_identifier(namespace, value, revision)
KnowledgeSnapshotReader.get_relation(relation_id, revision)
KnowledgeSnapshotReader.resolve_evidence(evidence_ref, revision)
KnowledgeSnapshotReader.read_context_slice(ContextManifest, revision)

必要历史版本不可重建时返回 HistoricalWorldUnavailable，不静默使用最新状态。

“Replay”不再视为单一能力。

复用 TaskEvent、historical M4 state、ReplayCheckpoint、runtime binding；不调用模型，不重新检索。用于检查状态机、Policy invariant、required/forbidden event、stop semantics 和 authority violation。当前实现基本覆盖这一层。

复用已持久化 PromptAssembly / ModelRequest，且要求该次调用显式保留可访问的 request_artifact_ref；不重新跑 Retrieval / Context Materialization，只换 provider/model 或 consumer。用于 model A/B、provider migration、structured output stability。只有 coordinate/digest、没有 request artifact 的普通在线调用不能冒充 R1 exact replay。

从固定 ContextManifest + WorldSnapshot 重新 materialize PromptAssembly，再执行模型。用于 ContextMaterializer、fragment ordering、Skill disclosure、Capability view、summary/reference handoff 实验。

从固定 TaskContract + WorldSnapshot + source availability 开始重跑 Perception、Capability、State、Model、Delegation、Decision。要求 historical Knowledge/index、replayable provider fixture、固定 Capability/Policy/Sandbox revision。

每个 BenchmarkCase 必须声明 replay tier。R0 通过不能被描述为 R3 Agent behavior 可重现。

TD2 的 PromptAssembly 继续作为逻辑对象；TD3 只增加 durable record。

PromptAssemblyRecord
  assembly_id
  assembly_hash
  execution_id
  task_run_id
  task_contract_id
  context_manifest_ref
  context_manifest_revision
  role_revision
  platform_invariant_revision
  execution_profile_revision
  policy_context_revision
  state_projection_revision?
  percept_refs[]
  materialized_fragment_refs[]
  ordered_fragment_ids[]
  materialized_ref_set_digest
  cache_handle_hints[]
  request_artifact_ref
  created_at

Prompt 文本不是唯一 identity。数据库始终记录 refs/revisions/hash/order；只有调用方显式启用 payload persistence 且通过 RuntimeArtifact trust/redaction gate 时，完整 normalized request 才作为 immutable RuntimeArtifact 保存并绑定 request_artifact_ref，用于 R1 exact replay 和审计。

Fragment 内容不要求全部重复写数据库。PromptAssemblyRecord 保存 metadata manifest；允许持久化的完整 request body 走 artifact。未启用 payload persistence 时仍可定位 assembly 与验证 digest，但不能声称能够恢复完整 prompt body。

Trust class 保留，后续可以直接评估 untrusted external fragment 是否诱发越权，而不是只看最终 answer。

一次逻辑模型请求可能有多个物理 attempt。

ModelRequest
  model_request_id
  purpose
  execution_id?
  task_run_id?
  case_id?
  processing_run_id?
  prompt_assembly_id?
  request_schema_digest
  request_artifact_ref
  requested_model
  provider_policy_ref
  budget_ref?
  created_at

ModelAttempt
  model_attempt_id
  model_request_id
  ordinal
  provider
  adapter_revision
  actual_model
  provider_request_id?
  started_at
  finished_at?
  status
  failure_class?
  response_schema_digest
  response_artifact_ref?
  usage
  cost
  cache_usage?

Logical ModelRequest 表示“系统在一个语义步骤上需要一次模型判断”；ModelAttempt 表示对某个具体 provider/model 发出的物理尝试。

purpose 第一版至少包括：

• m3.semantic_extract
• m3.normative_extract
• m5.investigation_plan
• m6.decision
• evaluation.judge（若未来使用）

timeout、429、fallback model 都产生新的 Attempt；失败 Attempt 不被成功结果覆盖。

TD3 不把 token 估算伪装成 provider 真值。

ModelUsage
  input_tokens?
  output_tokens?
  total_tokens?
  cached_input_tokens?
  reasoning_tokens?
  provider_cost?
  measurement_source
    provider_exact
    tokenizer_estimate
    reservation_upper_bound
    unavailable

provider 返回 usage 时标记 provider_exact；只有明确 tokenizer 时才记录 tokenizer_estimate；只有预算 upper bound 时不能进入“真实 token”统计；失败 attempt 若 provider 返回 usage 仍然记录，没有 usage 则保持 unknown，而不是记 0。

当前 BudgetGovernor 已有 MODEL_TOKENS / EXTERNAL_COST / RETRIES。下面是 TD3 的目标结算 contract。截至 2026-10-09（产品仓库 ec85421），M6 Product QA 和 Case 决策已在每次物理 ModelAttempt 前预留 model_tokens，重试 attempt 同时预留 retries；终态按 provider exact usage 结算，没有 usage 时按预留上界保守结算，而 ModelUsage 仍标 unavailable。调用前耗尽 deadline 会释放预留。若实际 usage 超过预留估算，账本记录真实超额、后续剩余额度为零。M3/M5 尚未传入模型 token 预留坐标；provider 也未提供可信货币成本，因此 external_cost 仍未结算，不能把这一段读成全链路完成：

2026-10-12 更新：上段的 M5 状态是 10-09 历史记录。当前 Product 调查接纳为每个允许的规划轮次建立 token/retry 账户，M5 Planner 给 RecordedModelProvider 传递预留坐标；Role 读取账户允许轮次，恢复时从已持久化的 ModelRequest 数量续接。M3 与货币成本仍不在此闭环内；这一修正尚未经过余额不足期间的付费模型实跑。

调用前
estimate upper bound
→ reserve(model_tokens, external_cost, retries)

调用后
exact usage available
→ commit exact
→ release unused

estimated only
→ commit estimate
→ measurement_source = tokenizer_estimate

usage unavailable
→ commit conservative bound
→ measurement_source = unavailable

Budget settlement 是执行控制；Benchmark usage report 是测量事实。预算可以保守，报告必须注明 measurement quality。

当前 ModelProvider.generate_structured 返回结构化 output。第一版不要求一次改完所有 M3/M5/M6 call site。

保持现有 protocol，通过 wrapper：

domain caller
→ RecordedModelProvider
→ concrete ModelProvider

记录 request / attempt / latency / failure，并从 request metadata 获取 execution/task/case/purpose coordinate。

concrete provider 逐步扩展出：

ProviderModelResult[T]
  output
  provider_request_id?
  usage?
  actual_model
  response_metadata

ModelExecutionRuntime 消费 metadata，再把 output 返回现有 domain call site。

M3/M5/M6 全部完成迁移后，再评估是否让 domain 显式依赖 ModelExecutionPort，而非物理 provider。

当前 OpenAICompatibleProvider 不需要因为 TD3 立刻搬包；先建立 recording seam，后续 packaging cleanup 单独处理。

每次在线模型调用至少记录：

purpose
model_request_id
request_owner_ref
prompt_revision

存在时继续记录：

• task_run_id
• execution_id
• case_id
• processing_run_id
• prompt_assembly_id
• budget_ref
• iteration
• selected EvidenceNeed

M5 当前已有 assembly hash / iteration / selected need；M6 已有 case / case revision / prompt revision；M3 可用 ProcessingRun / DocumentRevision / target object 作为 owner coordinate。

TD3 不建立第四套万能 Event Log。

Durable semantic source 继续是：

• TaskEvent：任务协调；
• TrajectoryEvent：Agent 语义行为；
• CapabilityInvocation：工具执行；
• ModelAttempt：模型调用；
• BudgetReservation：资源结算；
• Observation / KnowledgeChange：世界变化。

TraceSpan 只是 observability projection，不是业务 truth。

request_id?
→ case_id?
→ task_run_id?
→ execution_id
   ├─ model_attempt
   ├─ capability_invocation
   ├─ queue/worker
   ├─ sandbox
   └─ state/decision

OpenTelemetry 可以承载实时 trace，但 replay / audit 仍依赖 durable owner record。

Git commit 不是完整系统版本。模型、Policy、source inventory、DB schema、Capability Registry 都可以独立变化。

DeploymentRevision
  deployment_revision_id
  git_commit
  container_image_digest?
  schema_revision
  source_inventory_hash
  vocabulary_revision
  policy_revision
  capability_registry_revision
  skill_registry_revision?
  model_provider_revision
  configuration_digest
  created_at

secret 不进入 digest，只记录 non-secret semantic config。

每个正式 BenchmarkRun 必须关联 DeploymentRevision。

BenchmarkSuite
  suite_id
  suite_revision
  domain
  purpose
  case_refs[]
  gold_revision
  evaluator_revision
  default_world_snapshot_ref
  scoring_profile
  created_at

domain 可取：

• m1_monitoring
• m3_enrichment
• m5_agent
• m6_qa
• security
• product_e2e

Case wording 不变但 adjudication 修正时升级 gold revision；case 集变化升级 suite revision。

BenchmarkCase
  case_id
  case_revision
  input
  execution_profile
  target_refs[]
  world_snapshot_ref
  fixture_refs[]
  expected_behavior
  gold_ref
  tags[]
  latency_class
  replay_tier

一个 Case 默认可单独运行，不依赖前一 Case 的 mutable state。多轮 QA 使用专门 SessionCase。

BenchmarkRun
  benchmark_run_id
  suite_id@revision
  gold_revision
  deployment_revision
  model_config_ref
  world_snapshot_ref
  started_at
  finished_at?
  status
  execution_mode
  warm_cold_condition
  environment

execution_mode 第一版区分：

• offline scorer
• frozen replay
• live controlled
• live external

warm/cold 条件只作为运行条件记录，不为 KV cache 建新调度器。

BenchmarkCaseRun
  case_run_id
  benchmark_run_id
  case_id@revision
  task_run_id?
  execution_id?
  decision_ref?
  replay_checkpoint_ref?
  started_at
  finished_at
  status
  failure_class?
  metric_observations[]
  artifact_refs[]

任何聚合数字都能下钻到 CaseRun，再下钻到 Evidence / Task / ModelAttempt。

当前 M3 scorer 已经定义 EnrichmentFactKey、evidence-aware TP/FP/FN、micro P/R、dimension metrics、gold source policy 与 frozen world semantics。正在进行的 enrichment benchmark 保持原 owner。

TD3 只做：

existing M3 scorer output
→ BenchmarkCaseRun
→ MetricObservation
→ BenchmarkRun aggregate
→ CompetitionReport

不修改 M3 denominator，不为了统一框架重写 scorer。

M6 不能只用“最终答案像不像”做评测。第一版 Case 至少覆盖：

1. Direct fact；
2. Cross-source fact；
3. Conflict；
4. Unknown / abstention；
5. Version applicability；
6. Multi-hop Vulnerability → Commit → Release / Package；
7. PoC 与 known exploitation 分离；
8. Incident relation；
9. Normative applicability；
10. Long investigation：必须新增 Evidence 后才能回答。

QAGold
  acceptable_answer_facts[]
  required_facts[]
  forbidden_facts[]
  required_relation_paths[]
  acceptable_unknowns[]
  required_conflicts[]
  citation_requirements[]
  allowed_assumptions[]
  completion_expectation

正式 gold 优先结构化或人工可 adjudicate evidence。LLM judge 可以做 diagnostic，不单独产生 official gold。

最终结论是否匹配 gold fact / relation。

每个 factual conclusion 是否由当前 Evidence / Relation 支撑。

citation 是否真的支持它附着的 statement。

需要证据的 factual conclusion 是否都有 citation。

gold 要求的中间 relation path 是否正确存在。

证据不足时是否保留 unknown / continue，而非编造。

冲突 source 是否保留 conflict，而非 last-write-wins。

该 DIRECT 的是否直接答；该 INVESTIGATE 的是否真正启动调查；该 CONTINUE 的是否正确产生 EvidenceNeed。

分开记录：

interactive_latency
investigation_wall_latency
time_to_first_status
time_to_final_decision

普通交互式 QA ≤5s 只统计 interactive class，不把长 Investigation 混进同一分布。

model token、provider cost、capability call、external cost、wall time 分开记录，并注明 measurement source。

TD3 把 TD2 已定义的 Agent failure chain落成可执行 metric。

• critical EvidenceNeed recall
• false gap rate

• useful acquisition precision
• redundant acquisition rate
• source-role satisfaction
• freshness satisfaction

• wrong entity attachment
• wrong version attachment
• invalid EvidenceRef
• conflict collapse rate

• capability selection correctness
• argument correctness
• unnecessary denied request
• fallback success

• delegation precision
• child task usefulness
• parent-child budget adherence
• stale child result rate

• stop correctness
• no-progress iteration
• budget/deadline stop
• unnecessary continuation

这些指标用于解释最终 QA 失败，不能替代 final accuracy。

第一版 adversarial suite 固定：

• indirect prompt injection；
• malicious document；
• malicious tool output；
• peer Agent poisoned message；
• memory / Experience poisoning；
• MCP schema drift；
• capability escalation；
• network policy bypass；
• sandbox filesystem escape attempt；
• credential exfiltration；
• side-effect escalation。

除了 final answer，还检查 PolicyDecision、CapabilityInvocation、Sandbox grant、StatePatch、TaskEvent、authority violation 和 secret exposure。

安全 benchmark 失败不能被“最终答案仍然正确”抵消。

M8 自动化与恢复需要固定 fault case：

• source 429 / 403 / timeout；
• model timeout；
• model invalid structured output；
• Redis delivery unavailable；
• worker crash after DB commit；
• outbox redelivery；
• stale Context revision；
• budget exhausted；
• sandbox unavailable；
• child Task timeout。

每个 case 固定：

injected failure
expected degradation
expected retry / no-retry
expected Task terminal state
expected Product state
forbidden data loss / authority violation

现有 architecture gate 不允许 packages.evaluation 任意依赖所有 domain package，TD3 保持这条约束。

packages.evaluation 持有：

• benchmark contract
• gold
• scorer
• aggregation
• regression rule
• durable benchmark result

apps/evaluation_runtime 持有：

• 读取 Product / Decision / Task / Model runtime；
• 转换成 evaluation-neutral prediction；
• 启动 live/replay case；
• 关联 BenchmarkCaseRun。

因此 QA scorer 不需要直接依赖 reasoning package。

例如：

QAPrediction
  case_id
  conclusions[]
  relation_paths[]
  citations[]
  unknowns[]
  conflicts[]
  completion_status
  latency
  execution_refs

apps adapter：

M6 DecisionResult / Product DecisionView
→ QAPrediction
→ evaluation.qa scorer

Product AskQuestionUseCase
→ TaskRun / Execution / RecordedModelRequest
→ DecisionResult | durable Continuation
→ QAPrediction + measured interactive_latency
→ evaluation.qa scorer

Agent runtime 同样先投影成 EvaluationObservation，再进入 scorer。

MetricObservation
  metric_name
  metric_definition_revision
  value
  unit?
  direction
  measurement_source
  case_run_id
  subject_ref?
  evidence_refs[]
  metadata

例如：

• qa.answer_accuracy = 1
• qa.citation_correctness = 0.8
• agent.redundant_acquisition_rate = 0.2
• runtime.model_input_tokens = 4312
• runtime.wall_ms = 1920

聚合报告从 MetricObservation 生成，不从日志文本 grep 数字。

当前实现由 BenchmarkStore.observe_metric() 在写 observation 时解析对应 MetricDefinition，并校验 direction / unit；首次使用某个 metric@revision 时同时写 durable metric_definitions。MetricObservation 只允许追加到 running CaseRun，CaseRun 终止后不能继续补指标。M3 micro_precision / micro_recall 虽然每个 case 都保留局部 observation，但 report 级结果重新由全体 TP / FP / FN 推导，不能平均 per-case ratio 冒充 global micro metric。

指标公式本身也要版本化。

MetricDefinition
  name
  revision
  denominator
  aggregation
  missing_value_policy
  direction
  unit
  definition_digest

报告携带 evaluator revision 和实际使用的 metric_definition_refs[]。当前 metric_definitions 是 durable immutable row；同一 name@revision 内容变化会被拒绝。CompetitionReport 聚合历史 run 时读取 durable definition，而不是拿今天 Python registry 里的最新公式解释旧 observation；同一 report 若混入同名不同 revision 也直接拒绝。公式改变后必须新建 revision，不能把重算数字伪装成同一 benchmark revision。

RegressionRule
  metric
  max_regression?
  min_improvement?
  hard_floor?
  strata?

Hard gate 示例：

• authority violation 必须 0；
• citation correctness 不能低于 floor；
• protocol conformance 不得退化；
• security critical case 不得新增失败。

Soft optimization 示例：

• latency；
• cost；
• redundant tool call；
• context size。

允许显式 tradeoff，不允许靠平均分掩盖硬约束回归。

当前 RegressionGate 已支持 hard_floor / hard_ceiling / max_regression / min_improvement。比较对象是两个显式 CompetitionReport；required metric 缺失、或 baseline / candidate 的 metric-definition revision 不一致时 fail closed。它不会因另一个 soft metric 改善而抵消 hard gate 失败。

CompetitionReport
  report_id
  report_digest
  deployment_revision
  benchmark_runs[]
  metric_definition_refs[]
  generated_at

  M1
    source coverage
    monitoring latency

  M3
    precision / recall
    dimension breakdown

  M6
    accuracy
    groundedness
    citation correctness
    multi-hop
    latency

  Agent
    task success
    tool/delegation metrics

  Engineering
    fault/recovery cases
    deployment / health evidence

  artifact_refs[]
  target_checks[]
  unevaluated_competition_areas[]

每个数字都可下钻到 CaseRun / MetricObservation / Evidence。当前 report 只接受调用方显式指定的 completed BenchmarkRun，并要求所有 run 属于同一 DeploymentRevision；不会自动寻找“最新 run”，也不会因为出现一个 revision 数字更大的等价 run 就静默换口径。generate_and_persist() 用逻辑内容生成 report digest 并写 durable competition_reports，相同逻辑 report 重复导出保持幂等。

比赛 target check 第一版只编码赛题/Requirements 已冻结的直接阈值：source category ≥7、M3 precision / recall ≥0.95、M6 answer accuracy ≥0.95、interactive QA ≤5s。不存在对应 real benchmark metric 时返回 not_evaluated，不补零，也不拿 synthetic smoke 代替正式成绩。M1 ≤6h 当前继续报告 p50 / p95 / max / within-6h rate；赛题没有指定一个唯一 aggregate pass formula，因此不额外发明总 gate。

正式 benchmark / demo 前生成 DeploymentRevision；一个正式 batch 只 freeze 一次，再把同一个 deployment ID pin 给所有 module runner。

deterministic tests
→ architecture gate
→ migration check
→ benchmark smoke
→ selected regression suite
→ freeze DeploymentRevision once
→ M1/M3/M6/... runners pin the same ID
→ each runner re-checks current repo/runtime coordinate
→ full benchmark
→ CompetitionReport

freeze_deployment_revision.py 当前固定 Git HEAD + dirty worktree content digest、Alembic schema、source inventory、vocabulary、runtime policy、seed Skill registry、model/config coordinate。dirty worktree 不伪装成 clean commit。runner 收到 pinned DeploymentRevision 后会重新计算当前 coordinate；若并发开发导致代码/config/schema 漂移，即使数据库里旧 DeploymentRevision 仍存在也 fail closed，不允许继续挂旧 ID 写结果。

benchmark 过程中修改 code、prompt、model、policy、capability registry、vocabulary 或 gold，必须新建 BenchmarkRun / revision，不继续向旧 run 追加结果。正式 report 同样显式选择 run set，因此开发期重复 run、等价高 revision 或 synthetic harness 不会自动混进比赛报告。

TD2A 已定义 health seam，TD3把 M8 生命周期补齐：

build
→ migrate
→ bootstrap
→ ready
→ serve
→ degraded
→ recover
→ drain
→ upgrade
→ rollback
→ restore

Build 记录 git/image/schema/config revision；Bootstrap 检查 migration、source inventory、policy/capability registry 和 required dependency；Degraded 允许部分 provider 失败但核心能力仍可定义；Drain 停止新 long task 并让既有 run 到 safe terminal/checkpoint；Rollback 必须考虑 schema compatibility；Restore 分别验证 PostgreSQL、object storage 和可重建 Redis state。

Redis cache / stream 可以重建，durable Event / Knowledge 不允许依赖未备份 transient Redis。

2026-10-12 M8 恢复补充：原 scheduler 仅恢复超时 running 采集，已投递但未被 worker 启动的 queued 任务会长期占住该来源的 active-run 门。现在对已超时、没有待投递事件且最近未重投的 scheduled queued run，以原 run ID 重新产生 collection.requested outbox 事件；启动与落库仍保持幂等。真实数据库中 certcc-vulnerability-notes 曾存在自 10 月 8 日起的此类滞留记录；修复上线后原 run 被重新执行并以 success 终结，后续定时运行也以 no_change 正常完成。

同日补齐 Task Event Plane 的对应恢复边界：Celery 投递返回成功、Redis 事件已确认，但 worker 始终未 claim 的 Role TaskRun 也可能永久停在 queued。Task Runtime 现在按绝对 ExecutionEnvelope deadline 先分流：过期写入 timed_out，缺失或损坏的 envelope 写入 blocked；未过期且无待投递或近期已投递事件时，以原 run ID 追加可审计的补投 TaskEvent，经正常 outbox/Redis/Celery 路径恢复。即使原 Celery 消息迟到，worker 的原子 queued → running claim 仍只允许一次进入 Role handler。补投是派发恢复，不绕过 M4/M5 State 与 Policy gate，也不意味着调查成功。

同一执行恢复 owner 还按绝对 deadline 收束长期停留在 running 的 canonical Role episode，覆盖进程中断后没有写终态的同步 DecisionRole。只在 TaskRun 足够久未更新、ExecutionRun 仍为活动态且 envelope 可验证并已过期时写入 timed_out；不重新调用模型，不从缺失/损坏的执行记录推断超时。现场两条自 10 月 2 日起停在 running 的 DecisionRole 已由调度器收束为 timed_out，stop_reason=deadline_exceeded_without_terminal_result；同时四条过期 queued InvestigationRole 收束为 timed_out，现场没有剩余 queued/running TaskRun。

第一版先冻结 metric owner，不提前写虚假的 SLO 数值。

• request latency
• error rate
• accepted async rate

• queue lag
• dispatch delay
• task duration
• retry rate

• TaskRun terminal distribution
• no-progress stop
• budget exhaustion
• WATCH wake latency

• attempt latency
• success/error
• token usage
• cost
• rate limit
• fallback
• cache usage when exact

• invocation success
• policy deny
• timeout
• provider health

• outbox backlog
• projection lag
• source freshness
• index readiness

• benchmark pass/fail
• regression count
• metric drift

真实运行分布形成后再定 SLO threshold。

PromptAssembly 已有 stable prefix hint。TD3 第一版只做：

• 保持 stable ordering；
• 记录 assembly hash；
• 记录 provider exact cache read/write usage（若 provider 返回）；
• 保留 cache handle hint；
• 比较 warm/cold latency。

不做跨 provider KV cache abstraction、KV block migration、cache-to-cache scheduling，也不把估算命中冒充 exact cache usage。

只有真实 workload 证明 cache 是主要成本后再开独立设计。

持久化 Prompt / Request 会增加敏感面。

默认可以持久化：

• refs / revision / hash；
• 非敏感 runtime metadata；
• benchmark fixture；
• 脱敏 request artifact。

默认不能明文持久化：

• API key；
• Authorization header；
• credential material；
• 未经 policy 允许的 sensitive tool output。

ModelRequest artifact 写入前经过 RuntimeArtifact trust / redaction gate。Evaluation 不因“为了 replay”绕过访问控制。

第一版新增：

packages/
├── runtime/
│   ├── model/
│   │   ├── contracts.py
│   │   ├── service.py
│   │   └── storage.py
│   └── ...
│
├── intelligence/
│   └── knowledge/
│       └── historical.py
│
└── evaluation/
    ├── benchmark/
    │   ├── contracts.py
    │   ├── storage.py
    │   ├── service.py
    │   ├── metrics.py
    │   ├── report.py
    │   └── regression.py
    ├── qa.py
    ├── m1_m3.py
    └── ...

apps/
├── model_runtime.py
└── evaluation_runtime.py

benchmarks/
└── qa/
    └── smoke-v1.json   # synthetic harness only, not competition evidence

packages.runtime.model 只依赖 shared/runtime contract；packages.evaluation 保持 offline measurement owner。跨 domain composition 放 apps/evaluation_runtime。

agent_metrics.py / security.py 与正式 Agent/security frozen suites 仍是后续工作，不能因为 TD3 设计里已有 metric taxonomy 就画成已实现 package。

当前已新增：

model_requests
model_attempts
prompt_assembly_records
deployment_revisions
benchmark_suites
benchmark_cases
benchmark_runs
benchmark_case_runs
metric_definitions
metric_observations
competition_reports

其中 model execution / prompt assembly 对应 migration 0021 / 0022，Benchmark Runtime / metric-definition revision / evaluation provenance 对应 0023 / 0024 / 0025。

仍待 Historical World Slice 补齐：

object_versions
external_identifier_binding_versions
EvidenceLink revision visibility / versioned binding

第一版不把 TraceSpan SQL 表做成新的事实库；OpenTelemetry span 属于 telemetry substrate。

远程模型 HTTP 调用不能被长数据库 transaction 包住。

DB transaction
  create ModelRequest
  create Attempt(status=started)
commit

remote provider call

DB transaction
  finish Attempt
  persist usage / failure / response artifact ref
  settle Budget
commit

如果进程在 provider 已返回、finish Attempt 之前崩溃，Attempt 标记为 unknown_after_dispatch 并进入 reconciliation，而不是假设“没有调用过”。

当前实现的迁移状态并不一致。M5 Investigation planner 已经先在短事务中读取 Context / Skill / PromptAssembly，退出 session transaction 后再调用 provider，这是目标形态；M3 DocumentSemanticService 当前会在持有调用方 session 的处理流程中逐 chunk 调用 provider，M6 Product/Workbench Decision path 也可能在读取 M4 state 后保持 session transaction 直到模型返回。TD3 Slice A 落地时需要把这两条链改成 staged read → remote execute → guarded write：

M3
read immutable DocumentRevision / Chunk / Evidence coordinate
→ close transaction
→ model attempts
→ open transaction
→ verify input revision / processing identity
→ EvidenceBackedKnowledgeWriter

M6
read InvestigationState@revision + CitationSource
→ close transaction
→ model attempt
→ open transaction
→ DecisionCommit(base_case_revision)
→ stale revision => conflict / re-evaluate

这样远程模型延迟不会扩大数据库锁/连接占用；模型返回期间世界发生变化时，也通过既有 revision gate 处理，而不是依赖一个跨网络调用的长事务维持“假一致性”。

failure class 第一版：

• timeout_before_response
• network_error
• rate_limited
• auth_error
• provider_5xx
• invalid_json
• schema_validation_failed
• unknown_after_dispatch

Retry policy仍由 online owner决定；Measurement 保存所有 attempt。

当前 OpenAI-compatible provider 在 json_schema 400/422 后 fallback 到 json_object。TD3要求至少记录 response_format fallback，避免这次实际 provider行为在 measurement 中消失。

R3 replay 不仅需要 historical Knowledge，也需要历史 Retrieval surface。

从 historical Knowledge row 重建，优先支持。

按固定 DocumentRevision 构建 benchmark-local index。

固定 embedding model、dimensions、document revision、index revision。如果旧 index 不保留，可以在固定 fixture 上重建；不能换新 embedding model 后仍声称同一 replay。

使用 replay fixture，或明确标记 live_external mode。

多轮 Product QA 使用独立 SessionCase：

QASessionCase
  initial_context
  turns[]
    user_input
    expected_profile?
    gold_ref
  state_carry_policy

检查 follow-up 是否复用已有 evidence、是否重复检索、是否把旧 conflict 当 confirmed、新 world revision 后是否 refresh/rebase。

当前 executable slice 将“是否重复检索”拆成三个不同事实：session_retrieval_overlap_rate 只描述 chunk exposure 重合；session_retrieval_invocation_coverage 检查 follow-up RETRIEVE 是否存在唯一 durable invocation；session_retrieval_reuse_rate 读取 invocation 的 executed/reused disposition，描述 Product 是否实际跳过新的 lexical search。复用资格由 RetrievalRequestCoordinate 的 digest 决定，至少固定 operator revision、query digest、Knowledge revision、limit 与 source scope；world 或 operator 变化后不能复用旧结果。旧 chunk ref 只有在 exact DocumentRevision 全部可重读时才可 replay，缺失时执行 fresh search。这样性能优化仍然被 world/revision/provenance 约束，不把 Session history 变成第二检索真相库。

单轮与 session benchmark 分开报告。

PromptAssembly 已经可直接度量：

• materialized fragment count；
• input bytes / token；
• stable prefix ratio；
• dynamic fragment ratio；
• untrusted external ratio；
• Skill disclosure；
• Capability schema disclosure；
• Context reuse；
• Context refresh frequency。

这些属于 diagnostic metric，不直接作为比赛评分。

Reference vs Summary 使用 R2 frozen-context replay：

same TaskContract
same WorldSnapshot
same Model
same Skill / Capability
only context_handoff_mode changes

比较 task success、token、latency、stale/conflict error、citation correctness。

当前 SkillPromotionGate 已经有 support / counterexample / regression replay。TD3统一记录：

• selected Skill；
• Skill disclosure cost；
• applicability；
• task success delta；
• regression；
• counterexample failure。

Experience 不能因为一次成功自动晋级；BenchmarkRun / Replay result 继续是 promotion evidence。

AdjudicationRecord
  item_ref
  annotator_ref
  annotation
  evidence_refs[]
  created_at
  supersedes?

正式 gold 的争议项保留 annotation history、final adjudication、supporting evidence 和 gold revision。不要求一开始就建复杂标注平台；versioned YAML/JSON + review script 也可以。

允许：

• open-ended answer diagnostic；
• style/completeness 辅助；
• 生成候选错误分类；
• 人工 adjudication 辅助。

不允许单独决定：

• enrichment official gold；
• citation factual support；
• security critical pass/fail；
• 唯一 QA correctness gold。

使用 judge 时固定 judge model / prompt revision，并把输出标为 measurement source，而不是 truth。

现场 demo 不维护一套“漂亮但不可评测”的 shadow workflow。Demo case 从固定 benchmark suite 选择，额外要求 evidence 可展开、Agent activity 可展示、failure/recovery 可解释、最终 Decision 可引用、运行时间适合现场。

同一个 case 的 demo output 和 benchmark result 相互证明。

• ModelRequest / ModelAttempt / RecordedModelProvider 已持久化；
• latency / failure / retry ordinal / M3-M5-M6 purpose metadata 已可下钻；
• provider-exact token/cache usage 已进入 measurement；
• request/response artifact 为显式 opt-in，不把敏感 payload 默认全量持久化；
• 仍开放 Budget actual settlement；adapter-internal HTTP exchange 粒度只在 auto fallback 路径开放，已知 dialect 应在部署前固定。

• PromptAssemblyRecord、M5 assembly link、M6 input coordinate 已持久化；
• 正式测量路径可绑定 redacted request artifact；
• universal R1 exact payload replay 仍因默认 privacy policy 保持 opt-in。

• BenchmarkSuite / Case / Run、QAGold / QAPrediction 与 evaluation-neutral scorer 已落地；
• 正式 14-case Product QA + 2-session live batch 已执行并进入 CompetitionReport；
• accuracy / groundedness / citation / multi-hop / unknown / completion / latency 均可下钻到 CaseRun。

• deployment identity、run binding、metric definition revision、aggregate/report、evidence closure 与 regression gate 已落地；
• 报告禁止跨 deployment 偷换 run，后续代码变化需要新 DeploymentRevision。

• historical M4 state 已可重建；
• M1–M3 Object/identifier/EvidenceLink/structured retrieval 的任意旧 revision reader 仍未完整闭环；
• R2/R3 在无法精确读取 frozen world 时继续 fail closed。

• Agent gap/acquisition/state/planning/delegation/stop metrics 已有 frozen controlled cases；
• fault injection 与 security suite 已产生 current-revision observations；
• 当前正式 CompetitionReport 只选择与本轮比赛证据一致的 run，不用无关历史 run 填满报告；
• 真实 external Capability、live Case-read、human-adjudicated incident/normative 等更难 denominator 继续扩展。

• degraded/health、fault recovery、artifact replay、retry/bounded-termination measurement 已有实现与评测；
• drain / upgrade / rollback / restore 的更完整 deployment acceptance 与外部 trace backend 仍是后续运维面工作。

• KV cache scheduler；
• cache2cache；
• self-hosted inference runtime；
• Agentic RL；
• online self-modifying prompt；
• 自动 Skill activation；
• 复杂实验平台 UI；
• Kubernetes operator；
• 跨云 trace backend；
• 全量 historical vector index 永久保存。

这些必须由当前系统真实数据证明值得引入。

TD3 第一版完成后，应能不靠人工猜日志回答：

1. 某个 Decision 使用了哪个 WorldSnapshot？
2. 它实际 materialize 了哪个 PromptAssembly？
3. 发出了几个逻辑 ModelRequest、几个物理 ModelAttempt？
4. provider 返回多少 exact token，哪些只是 estimate？
5. failed retry 是否计入 latency / cost？
6. 某次 benchmark 使用哪个 code/schema/policy/model/prompt/gold revision？
7. M6 accuracy / groundedness / citation / multi-hop 数字来自哪些 case？
8. 一个 case 失败发生在 source、retrieval、context、model、tool、state 还是 decision？
9. baseline/candidate 是否在同一 frozen coordinate 比较？
10. historical replay 是否读取旧世界而不是 current projection？
11. 比赛报告数字能否下钻到 CaseRun / Evidence？
12. 系统升级后能否指出 regression 与具体 revision 变化的关系？

如果这些问题仍需要“看代码大概推断”，Measurement Plane 还没有完成。

截至 2026-10-04，Model/Prompt/Task/Decision/Benchmark/Metric/Evidence 的正式链路已经可以从 CompetitionReport 下钻，不再依赖人工猜日志；仍为 partial 的核心是第 1/10 项对应的完整 Historical WorldSnapshot/旧世界读取，以及第 4/5 项中 provider 未返回 exact monetary cost 或 adapter 内部 HTTP negotiation 时的物理粒度。

TD1
世界如何进入系统并形成可信 Knowledge

TD2
Agent 如何读取世界、行动、调查并形成 Decision

TD2A
这些能力如何被 Product API / Frontend 稳定使用

TD3
系统如何冻结世界、记录模型执行、评测结果、定位回归并证明有效

TD3 不增加新的“智能故事”。它把已有智能和工程能力变成可重复验证、比较和交付的系统事实。