Retaintive

    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 的 Task-specific Outcome、verification 与 versioned Policy 重新定义。

    Revenue rehearsal 是 Task Accuracy Foundation 里专门验证 revenue / retention / safety objective 的 executable pack。它不把模型当成可以自由执行的 agent，而是把 agent 拆成可审计的几层：

    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 DBscripts/revenue-rehearsal/staging-inject.ts
    #1169 objective policy map把 Contacts Analyzer fallback 从一串 ad-hoc if 变成可审查的 policy map：fact、guard、action、rationalelambda/contacts-analyzer/src/core/revenue-objective-policy.ts
    #1170 scenario registry每个 revenue case 不只写 transcript，还写 business rationale、not expected behavior、hard/diagnostic assertionsscripts/revenue-rehearsal/cases.ts
    #1171 eval report artifactsJSON / Markdown report 要能逐 case 展示 expected、actual facts、task decisions、fallback 是否介入、timing / usagescripts/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 expectedNot expected
    first-class voicemailcreate_open lead_follow_up[]、lead_outreach、忽略 voicemail transcript
    member upgrade voicemailcreate_open upgraderenewal、因为客户说不要立刻改 plan 而 no-op
    referral opportunitycreate_open referral给现有会员本人创建 lead_follow_up
    cancellation saved same callcreate_closed cancellation_risk / cancel_saved因为当场解决而输出 []
    DNC voicemailclose visible work as do_not_contactclose 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：

    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：

    bun run eval:revenue-staging-inject -- \
  --environment staging \
  --store-id <store-id> \
  --store-phone <store-phone> \
  --account-id <account-id> \
  --phone <customer-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 时必须显式加：

    bun run eval:revenue-staging-inject -- \
  --environment staging \
  --neon-ssm-param "$NEON_DATABASE_URL_PARAM" \
  --write \
  --store-id <store-id> \
  --store-phone <store-phone> \
  --account-id <account-id> \
  --phone <customer-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。