> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt. # Revenue Rehearsal Playbook > **Current legacy rehearsal pack（2026-07-15）**：本文验证旧 objective-policy-to-`taskDecisions[]` flow 和 legacy category/result vocabulary，只用于兼容性回归。V3 revenue scenarios 必须按 [Task System Design V3](/product-design/v3/tasks-feature/task-domain-lifecycle.md) 的 Task-specific Outcome、verification 与 versioned Policy 重新定义。 Revenue rehearsal 是 Task Accuracy Foundation 里专门验证 revenue / retention / safety objective 的 executable pack。它不把模型当成可以自由执行的 agent，而是把 agent 拆成可审计的几层： ```text Transcript / Call / Message facts -> Call AI structured facts -> Contacts Analyzer structured output -> Objective policy map -> TaskDecision proposal -> Writer / Policy Guard / DB constraints -> Eval report / demo evidence ``` 这符合 Agent Foundation 的核心概念：AI 只做结构化判断和 proposal；objective policy 负责把高置信业务事实映射到人类工作目标；writer / Policy Guard 才有最终写库权。 ## 对应 GitHub issues | Issue | 要解决什么 | 改动面 | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | `#1168` staging transcript injector | 让我们不依赖 RingCentral / Deepgram，也能把一段 transcript 注入到 staging pipeline，跑 Call AI + Contacts Analyzer，并在需要时写 staging DB | `scripts/revenue-rehearsal/staging-inject.ts` | | `#1169` objective policy map | 把 Contacts Analyzer fallback 从一串 ad-hoc `if` 变成可审查的 policy map：fact、guard、action、rationale | `lambda/contacts-analyzer/src/core/revenue-objective-policy.ts` | | `#1170` scenario registry | 每个 revenue case 不只写 transcript，还写 business rationale、not expected behavior、hard/diagnostic assertions | `scripts/revenue-rehearsal/cases.ts` | | `#1171` eval report artifacts | JSON / Markdown report 要能逐 case 展示 expected、actual facts、task decisions、fallback 是否介入、timing / usage | `scripts/revenue-rehearsal/run.ts` | 这四个 issue 可以放在一个 infra mega PR 里，因为它们是同一条 eval/control surface：scenario registry 产出期望，policy map 定义 fallback，runner/report 验证，staging injector 连接真实 staging path。docs repo 需要 companion PR，因为文档和 infra 不在同一个仓库。 ## Scenario Registry 每个 revenue rehearsal case 至少要回答这些问题： - 业务场景是什么：例如 intro inquiry、upgrade、referral、cancel intent、DNC。 - 这个场景为什么是 material business objective。 - Call AI 应该输出哪些 structured facts。 - Contacts Analyzer 应该输出哪些 `taskDecisions[]`。 - 哪些行为明确不应该出现。 - 哪些 assertion 是 hard failure，哪些只是 diagnostic signal。 示例判断： | 场景 | Hard expected | Not expected | | ---------------------------- | ------------------------------------------------ | -------------------------------------------- | | first-class voicemail | `create_open lead_follow_up` | `[]`、`lead_outreach`、忽略 voicemail transcript | | member upgrade voicemail | `create_open upgrade` | `renewal`、因为客户说不要立刻改 plan 而 no-op | | referral opportunity | `create_open referral` | 给现有会员本人创建 `lead_follow_up` | | cancellation saved same call | `create_closed cancellation_risk / cancel_saved` | 因为当场解决而输出 `[]` | | DNC voicemail | close visible work as `do_not_contact` | close as `not_interested`、创建新 outreach | ## Objective Policy Map Objective policy map 是 `Facts -> Objective -> Action` 的产品可审查层。它不直接写库，也不替代模型；它只在 structured facts 足够强、模型 no-op 或输出形状不合适时，补上 deterministic proposal。 每条 policy 都应该包含： - `structuredFact`：来自 Call AI / Contacts Analyzer 的结构化事实，不靠裸文本猜测。 - `guard`：允许 policy 生效的边界，例如 exact triggering call、visible task、no duplicate、no DNC。 - `action`：唯一允许输出的 `TaskDecision` shape。 - `rationaleZh`：业务和安全理由，给 PM / reviewer 审。 关键设计边界： - create 类 policy 可以使用唯一 recent call fact，解决 voicemail / message trigger 没有 exact call id 的问题。 - close / progress 类 policy 必须要求 exact triggering call，避免 stale evidence 关闭或推进错误任务。 - DNC 是 safety policy，不是 revenue policy；它优先于所有 proactive work。 - writer / orchestrator 仍然负责 store isolation、task ref resolution、duplicate guard、human-authority guard。 ## Report Artifacts Revenue rehearsal runner 应同时产出 machine-readable JSON 和 reviewer-readable Markdown： ```bash bun run eval:revenue-rehearsal -- \ --no-model \ --json artifacts/revenue-rehearsal/report.json \ --markdown artifacts/revenue-rehearsal/report.md ``` 报告里每个 case 应该能看到： - transcript excerpt。 - business rationale。 - expected outcome / not expected behavior。 - actual Call AI facts。 - actual Contacts Analyzer task decisions。 - fallback before / after。 - hard failures 和 diagnostics。 - latency / token usage，能拿到多少就记录多少。 `--no-model` 用来验证 fixture 和 prompt context 是否完整；真实模型模式用来验证 prompt + model + fallback 的当前表现。Demo 前只展示连续稳定通过的 case，不现场赌模型随机性。 ## Staging Transcript Injector staging injector 的目标是从 transcript 往后跑，而不是伪造整条 RingCentral / Deepgram upstream： ```bash bun run eval:revenue-staging-inject -- \ --environment staging \ --store-id \ --store-phone \ --account-id \ --phone \ --transcript-file ./tmp/transcript.txt \ --json artifacts/revenue-rehearsal/inject.json \ --markdown artifacts/revenue-rehearsal/inject.md ``` 默认是 dry-run，只调用 Call AI + Contacts Analyzer 并输出 trace。要写 staging DB 时必须显式加： ```bash bun run eval:revenue-staging-inject -- \ --environment staging \ --neon-ssm-param "$NEON_DATABASE_URL_PARAM" \ --write \ --store-id \ --store-phone \ --account-id \ --phone \ --transcript-file ./tmp/transcript.txt ``` 安全边界： - `environment=prod` 或 SSM param 含 `/prod/` 时必须拒绝运行。 - `--store-phone` 必须来自目标 store 的真实 assigned phone，不能 hardcode 某个 demo store。 - `--write` 必须显式传入 staging/test Neon SSM param。 - injector 只适合 staging/test 验证，不是 production backfill 工具。 ## Review Rubric review 这个 mega PR 时，重点看四件事： 1. Scenario registry 是否把业务目标说清楚，而不是只写 transcript。 2. Objective policy 是否只消费 structured facts，并且 guard 足够保守。 3. Report 是否能让 PM / engineer 不看日志也判断每个 case 为什么 pass/fail。 4. Staging injector 是否有明确 prod guard，并且 dry-run / write mode 分离。 如果这些都成立，这个 PR 就是 Task Accuracy Foundation 的一块地基：它让 revenue objective 先可定义、可测试、可审查，再进入未来的 Vapi / outbound execution。