PLS job 3d2d136a AI prediction verification production pack

acceptance-tests.md

Acceptance Tests

Gate 0：檔案與 artifact

• prediction-verification-cockpit.html 可打開。
• 必交檔案齊全：production-brief.md、data-model.md、acceptance-tests.md、decision-record.md、artifact-url-or-pr.md。
• learning-memory.json 可被 JSON parser 讀取。
• artifacts_json 包含 primary_artifact、market_context、production_readiness、e2e_verification、people_sync、learning_memory。

Gate 1：D1 Ledger 可建立

測試輸入：

{
  "claim_text": "工具選擇未統一會讓系統化建置延後兩週",
  "prediction_type": "tool_choice",
  "expected_signal": "出現工具標準對焦任務或同步節奏分歧",
  "time_window_end": "2026-06-06T23:59:59+08:00",
  "owner_member_id": "a99e5c60-898a-4dbb-aeab-47e62c51bcc7"
}

通過條件：prediction_claims 可建立，且狀態為 open。

Gate 2：Evidence Match

測試輸入：

{
  "source_type": "github_commit",
  "source_ref": "commit:add-prediction-verification-module",
  "event_summary": "新增 AI 預測驗證模組，透過 signals、action items 等多來源證據，自動核對上次 review 的預測是否命中",
  "event_time": "2026-05-23T14:50:36+00:00"
}

通過條件：

• evidence_events 建立成功。
• evidence_matches 產生 label_candidate=hit 或 partial。
• match_score 低於 0.55 時不得自動定 final label。

Gate 3：D7 批次驗證

通過條件：

• 50 筆 prediction 完成候選比對。
• unknown_rate 低於 25%。
• low confidence 全部進 verification_reviews queue。
• 每筆 final label 都能追到 source_ref。

Gate 4：D14 correction task

通過條件：

• miss 或 partial 必須附 miss_reason。
• miss_reason 為 tool_fragmentation 時，派 Louis 工具標準拍板任務。
• miss_reason 為 data_gap 時，派資料來源接入任務。
• miss_reason 為 execution_gap 時，派 owner/due 修正任務。

Gate 5：D30 指標

通過條件：

• calibration_snapshots 每週產生。
• dashboard 顯示 hit_rate、partial_rate、unknown_rate、false_positive、false_negative、top_miss_reasons。
• AI review prompt 至少依一個低命中 prediction_type 修正。

e2e_verification

本輪已驗證：

• 本地 artifact 已建立。
• learning-memory.json 可 parse。
• 必要關鍵字可搜尋：market_context、production_readiness、e2e_verification、people_sync、learning_memory。
• Gist URL 建立後需用 curl -I -L 與 gh gist view --files 驗證。

data-model.md

Data Model / API / Sync / Permission Spec

Tables

prediction_claims

欄位	型別	說明
id	uuid	prediction id
project_id	uuid	PLS project id
review_id	uuid	上次 AI review id
claim_text	text	可驗證預測句
prediction_type	enum	schedule, owner, risk, adoption, revenue, quality, tool_choice
expected_signal	text	預期會出現的證據
time_window_start	timestamptz	驗證開始
time_window_end	timestamptz	驗證結束
owner_member_id	uuid	預測關聯 owner
confidence_before	numeric	review 當下信心
status	enum	open, matched, reviewed, closed, retired
created_at	timestamptz	建立時間

evidence_events

欄位	型別	說明
id	uuid	evidence id
project_id	uuid	PLS project id
source_type	enum	signal, action_item, github_commit, deliverable, line_note, drive_doc, person_reflection
source_ref	text	URL / PLS id / commit sha
event_time	timestamptz	事件時間
actor_member_id	uuid	行動者
event_summary	text	摘要
payload	jsonb	原始資料
sensitive_level	enum	public, internal, restricted
audit_actor	uuid	匯入者
audit_at	timestamptz	匯入時間

evidence_matches

欄位	型別	說明
id	uuid	match id
prediction_claim_id	uuid	prediction
evidence_event_id	uuid	evidence
match_method	enum	exact_ref, keyword, semantic, rule, human
match_score	numeric	0-1
label_candidate	enum	hit, miss, partial, unknown
rationale	text	比對理由
created_at	timestamptz	建立時間

verification_reviews

欄位	型別	說明
id	uuid	review id
prediction_claim_id	uuid	prediction
final_label	enum	hit, miss, partial, unknown
miss_reason	enum	no_evidence, wrong_owner, wrong_timing, wrong_assumption, tool_fragmentation, data_gap, execution_gap
reviewer_member_id	uuid	Louis/zihrou/iron/PLS reviewer
review_note	text	判斷說明
correction_task_id	uuid	若 miss/partial 產生的 action item
reviewed_at	timestamptz	review 時間

calibration_snapshots

欄位	型別	說明
id	uuid	snapshot id
project_id	uuid	PLS project id
period_start	date	週期開始
period_end	date	週期結束
prediction_count	int	總數
hit_rate	numeric	命中率
partial_rate	numeric	部分命中率
unknown_rate	numeric	未知率
false_positive_count	int	假陽性
false_negative_count	int	假陰性
top_miss_reasons	jsonb	前三大 miss reason
published_at	timestamptz	發布時間

API / Sync

Capture predictions

POST /api/pls/projects/{project_id}/prediction-claims

{
  "review_id": "uuid",
  "claim_text": "工具選擇未統一會讓系統化建置延後兩週",
  "prediction_type": "tool_choice",
  "expected_signal": "action items 或 LINE note 出現工具標準對焦任務",
  "time_window_start": "2026-05-23T00:00:00+08:00",
  "time_window_end": "2026-06-06T23:59:59+08:00",
  "owner_member_id": "a99e5c60-898a-4dbb-aeab-47e62c51bcc7",
  "confidence_before": 0.72
}

Ingest evidence

POST /api/pls/projects/{project_id}/evidence-events/import

來源：

• signals
• action_items
• github_commits
• strategy_deliverables
• person_reflections
• future：LINE、Drive、calendar、deployment log

Match and label

POST /api/pls/prediction-claims/{id}/match

Rules:

• exact_ref 優先於 semantic。
• match_score < 0.55 不得自動定案，只能進 unknown 或 human review。
• hit 必須有 event_time 落在 time window。
• miss 需要 time window 已結束或出現反證。
• partial 需要有部分 expected_signal，但缺 owner/due/result 任一關鍵欄位。

權限與稽核

角色	可讀	可寫	不可做
Louis	全部 calibration、prediction、evidence summary	hit/miss policy、final review	修改原始 evidence payload
zihrou	prediction、miss_reason、需協調任務	review note、缺口分類	讀 restricted 原始來源全文
iron	與自己任務/commit 相關 evidence	action correction 回覆	改 final label
PLS worker	必要 schema、source_ref、摘要	match candidate、progress、artifact	假裝 GitHub/LINE/部署成功

每筆 evidence 需保留 source_ref、event_time、audit_actor、audit_at。restricted payload 只存 hash/摘要，UI 顯示 evidence summary 與可審核連結。

失敗回滾

• 若 unknown_rate 超過 25%，不得自動派大量 correction task，只能進人工 sample review。
• 若 false positive 被 Louis 判定超過 10%，停用 semantic auto-label，退回 rule + human。
• 若 evidence source 缺 LINE/Drive，標記 data_gap，不得把 prediction 判 miss。
• 若同一 owner 被過量派工，依 priority 與 due date 合併 correction task。

decision-record.md

Decision Record：AI 預測驗證模組

決策背景

公司 AI 化專案需要確認 AI review 的預測是否真的命中。現況已有 signals、action items、GitHub commit、deliverables、person reflections，但缺少把「預測」拆成可驗證 claim 並回寫命中率的 production 模組。

選項

選項	說明	優點	風險
A. 只做 dashboard	顯示近期 signals/action item 狀態。	快速可視化。	無法回答上次預測是否命中。
B. 只做 prompt 檢討	由 AI 自評哪些預測準。	成本低。	容易自我合理化，缺 evidence trail。
C. 建 prediction verification ledger	prediction claim + evidence + match + label + correction task。	可稽核、可校準、可派工，能接 PLS 多來源資料。	初期需要人工標註 10-50 筆建立標準。

推薦

採用 C。

理由：

• 成熟 AI/ML observability 做法都強調 production monitoring、drift、trace/correlation id 與 outcome label。
• PLS 的核心優勢是已有 signals/action items/GitHub/people reflections，可直接形成 evidence graph。
• 公司 AI 化目前需要的是「讓 AI 成為可靠管理層」，這必須有命中率與失誤原因，而非只產生更漂亮的 review。

採用狀態

建議狀態：pending_policy_acceptance

owner：Louis

reviewers：zihrou、iron

due：2026-05-27

acceptance：

• 同意 hit/miss/partial/unknown 定義。
• D7 前可跑 50 筆 prediction。
• unknown_rate 低於 25%。
• 低信心進人工 review queue。
• miss/partial 能自動派 correction task。

落地路徑

1. Louis 拍板 label policy。
2. PLS worker 回填 10 筆 prediction 作為 D1 seed。
3. D7 接入 signals/action_items/GitHub commit 批次比對。
4. D14 每週 review 顯示 calibration。
5. D30 將低命中 prediction type 轉成 prompt 修正與資料接入任務。

退修回饋格式

若不採納，必須回饋：

• 哪個 label 定義不可用。
• 哪個 evidence source 缺失。
• 哪類 prediction 不應由 AI 自動判斷。
• 哪個 owner 應改為 reviewer 或 supervisor。

沒有上述回饋，不應退回成 research-only；應先用小樣本人工 review 補標準。

learning-memory.json

{
  "job_id": "3d2d136a-e3ee-4eb1-b1a7-573f20cac9d9",
  "project_id": "d2afbba2-f20a-4ca5-ab6b-8e848e5532ef",
  "ai_native_project_id": "a8befe83-b818-482a-a6bb-3df58f50c3a2",
  "learned_at": "2026-05-24T02:38:00+08:00",
  "signal": {
    "type": "github_commit",
    "summary": "新增 AI 預測驗證模組，透過 signals、action items 等多來源證據，自動核對上次 review 的預測是否命中",
    "root_cause_hypothesis": "公司 AI 化的下一個瓶頸不是沒有 AI review，而是 review 預測缺少 outcome label 與 evidence trail，導致工具選擇與系統化建置分歧無法快速校準。"
  },
  "recommended_next_check": [
    "prediction_claims 是否已有 10 筆 D1 seed",
    "evidence_events 是否接入 signals/action_items/GitHub commit",
    "unknown_rate 是否低於 25%",
    "miss_reason 是否能派 correction task",
    "Louis 是否接受 hit/miss/partial/unknown 定義"
  ],
  "do_not_repeat": [
    "不要只做 AI review 摘要",
    "不要只看 action item 逾期就判 prediction miss",
    "不要在缺 source_ref 時自動定 final label",
    "不要把 restricted evidence payload 暴露給不該讀的人"
  ],
  "next_worker_rules": {
    "if_label_policy_accepted": "seed_10_predictions_and_run_D7_batch_match",
    "if_unknown_rate_above_25_percent": "dispatch_data_source_gap_task",
    "if_false_positive_above_10_percent": "disable_semantic_auto_label_and_require_human_review",
    "if_tool_fragmentation_is_top_miss_reason": "dispatch_louis_tool_standard_decision_task",
    "if_execution_gap_is_top_miss_reason": "dispatch_owner_due_correction_task"
  },
  "market_context": {
    "checked_date": "2026-05-24",
    "pattern": "Production AI verification should combine observability traces, source correlation IDs, drift/quality monitoring, outcome labels, and human review queues."
  },
  "production_readiness": {
    "primary_artifact": "prediction-verification-cockpit.html",
    "e2e_verification": "Validate JSON, required keywords, uploaded files, durable Gist URL.",
    "required_artifacts": [
      "production-brief.md",
      "data-model.md",
      "acceptance-tests.md",
      "decision-record.md",
      "artifact-url-or-pr.md"
    ]
  }
}

prediction-verification-cockpit.html

<!doctype html>
<html lang="zh-Hant">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>AI 預測驗證 Cockpit</title>
  <style>
    :root {
      --ink: #111827;
      --muted: #5f6b7a;
      --line: #d7dee8;
      --bg: #f7f9fb;
      --panel: #ffffff;
      --green: #0f766e;
      --blue: #1d4ed8;
      --red: #b42318;
      --amber: #a15c00;
      --violet: #6d28d9;
    }
    * { box-sizing: border-box; }
    body {
      margin: 0;
      font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      background: var(--bg);
      color: var(--ink);
      line-height: 1.5;
    }
    header {
      padding: 30px clamp(18px, 4vw, 50px);
      color: white;
      background: linear-gradient(120deg, #111827, #233047);
    }
    h1, h2, h3 { margin: 0; line-height: 1.2; }
    h1 { font-size: clamp(29px, 5vw, 48px); max-width: 1040px; }
    h2 { font-size: 22px; margin-bottom: 12px; }
    h3 { font-size: 16px; margin-bottom: 7px; }
    header p { max-width: 1020px; color: #d5dce8; margin: 10px 0 0; }
    main { padding: 24px clamp(16px, 4vw, 50px) 46px; }
    .grid { display: grid; grid-template-columns: repeat(12, 1fr); gap: 14px; margin-bottom: 22px; }
    .card {
      background: var(--panel);
      border: 1px solid var(--line);
      border-radius: 8px;
      padding: 16px;
      box-shadow: 0 1px 2px rgba(17, 24, 39, 0.04);
    }
    .span-3 { grid-column: span 3; }
    .span-4 { grid-column: span 4; }
    .span-6 { grid-column: span 6; }
    .span-8 { grid-column: span 8; }
    .span-12 { grid-column: span 12; }
    .metric { font-size: 32px; font-weight: 760; margin: 5px 0 2px; }
    .muted { color: var(--muted); }
    .tag {
      display: inline-flex;
      align-items: center;
      min-height: 24px;
      padding: 2px 8px;
      border-radius: 999px;
      font-size: 12px;
      font-weight: 720;
      border: 1px solid currentColor;
      margin: 2px 4px 2px 0;
    }
    .green { color: var(--green); }
    .blue { color: var(--blue); }
    .red { color: var(--red); }
    .amber { color: var(--amber); }
    .violet { color: var(--violet); }
    table { width: 100%; border-collapse: collapse; }
    th, td { text-align: left; padding: 10px 8px; border-bottom: 1px solid var(--line); vertical-align: top; }
    th { font-size: 12px; color: var(--muted); text-transform: uppercase; letter-spacing: 0; }
    ul, ol { margin: 8px 0 0 18px; padding: 0; }
    li { margin: 5px 0; }
    .flow {
      display: grid;
      grid-template-columns: repeat(5, minmax(130px, 1fr));
      gap: 10px;
    }
    .flow div {
      border: 1px solid var(--line);
      border-radius: 8px;
      padding: 12px;
      background: #fbfdff;
      min-height: 118px;
    }
    .code {
      font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
      font-size: 13px;
      background: #edf2f7;
      border-radius: 6px;
      padding: 2px 5px;
    }
    .line-draft {
      white-space: pre-wrap;
      background: #eff6ff;
      border: 1px solid #bfdbfe;
      border-radius: 8px;
      padding: 14px;
    }
    @media (max-width: 960px) {
      .span-3, .span-4, .span-6, .span-8 { grid-column: span 12; }
      .flow { grid-template-columns: 1fr; }
    }
  </style>
</head>
<body>
  <header>
    <h1>AI 預測驗證 Cockpit</h1>
    <p>把「上次 review 的預測」變成可被 signals、action items、GitHub、LINE/Drive 證據自動核對的 production 模組。目標不是多做一張報表，而是讓 Louis / zihrou / iron 對 AI 工具選擇與系統化建置有同一套命中率、證據等級、退修與派工節奏。</p>
  </header>
  <main>
    <section class="grid">
      <div class="card span-3">
        <h3>Verification Readiness</h3>
        <div class="metric green">R1</div>
        <p class="muted">可用 schema 跑第一批人工標註與自動比對。</p>
      </div>
      <div class="card span-3">
        <h3>Evidence Sources</h3>
        <div class="metric blue">5</div>
        <p class="muted">signals、action items、commit、deliverable、people reflection。</p>
      </div>
      <div class="card span-3">
        <h3>Owner / Due</h3>
        <div class="metric">Louis</div>
        <p class="muted">2026-05-27 前拍板命中定義與紅線。</p>
      </div>
      <div class="card span-3">
        <h3>Decision Risk</h3>
        <div class="metric amber">中</div>
        <p class="muted">zihrou、iron、Louis 工具選擇尚未完全統一。</p>
      </div>
    </section>

    <section class="grid">
      <div class="card span-8">
        <h2>D1 / D7 / D14 / D30 路徑</h2>
        <table>
          <thead><tr><th>節點</th><th>交付</th><th>驗收訊號</th></tr></thead>
          <tbody>
            <tr><td>D1</td><td>建立 prediction ledger 與 evidence matcher，先人工回填 10 筆 review prediction。</td><td>每筆有 claim、time window、expected signal、evidence source、label。</td></tr>
            <tr><td>D7</td><td>接入 signals/action_items/GitHub commit，自動產生 hit/miss/partial/unknown。</td><td>50 筆 prediction 有驗證結果，unknown 低於 25%。</td></tr>
            <tr><td>D14</td><td>將驗證結果接入 AI review 節奏，低命中類型自動派 correction task。</td><td>每週 review 能看到 calibration、false positive、false negative。</td></tr>
            <tr><td>D30</td><td>形成公司 AI 化 decision QA：預測、證據、派工、修正、治理完整閉環。</td><td>AI review 命中率、工具採用決策速度、逾期修正率每週可追。</td></tr>
          </tbody>
        </table>
      </div>
      <div class="card span-4">
        <h2>Purpose-to-Purpose E2E</h2>
        <ol>
          <li>原始目的：讓 AI review 真的改善公司 AI 化決策。</li>
          <li>產出物：驗證 cockpit、資料模型、比對規則、驗收測試。</li>
          <li>人採用：Louis 拍板紅線，zihrou/iron 回饋工具分歧訊號。</li>
          <li>指標改善：預測命中率、決策速度、派工準確率、風險提早發現率。</li>
        </ol>
      </div>
    </section>

    <section class="grid">
      <div class="card span-12">
        <h2>Verification Flow</h2>
        <div class="flow">
          <div><h3>1. Capture</h3><p>把 review 中的預測拆成 <span class="code">prediction_claims</span>，含 expected outcome 與時間窗。</p></div>
          <div><h3>2. Evidence</h3><p>收 signals、action items、commit、deliverable、people reflection，多來源都保留 source_ref。</p></div>
          <div><h3>3. Match</h3><p>用 rule + embedding/keyword candidate 產生 evidence_candidates 與 confidence。</p></div>
          <div><h3>4. Label</h3><p>輸出 hit / miss / partial / unknown，低信心進人工 review queue。</p></div>
          <div><h3>5. Act</h3><p>命中差的 prediction type 轉成 prompt 改寫、資料缺口或 owner 對焦任務。</p></div>
        </div>
      </div>
    </section>

    <section class="grid">
      <div class="card span-6">
        <h2>Evidence Ledger 範例</h2>
        <table>
          <thead><tr><th>Prediction</th><th>Evidence</th><th>Label</th><th>Action</th></tr></thead>
          <tbody>
            <tr><td>工具選擇未統一會拖慢系統化建置 2 週</td><td>action item 仍要求統一 AI 工具與同步節奏</td><td><span class="tag amber">partial</span></td><td>派 Louis 拍板工具標準</td></tr>
            <tr><td>AI 預測驗證模組會成為近期關注</td><td>GitHub commit 與 person_reflection 均指向 verification module</td><td><span class="tag green">hit</span></td><td>進入 D7 自動比對</td></tr>
            <tr><td>所有 action item 逾期皆因缺 owner</td><td>context 顯示部分 action 已有 owner，但缺 review cadence</td><td><span class="tag red">miss</span></td><td>修正 prompt：區分 owner 缺口與節奏缺口</td></tr>
          </tbody>
        </table>
      </div>
      <div class="card span-6">
        <h2>Human Capability Upgrade</h2>
        <ul>
          <li>Louis：看 AI review 的校準度，不只看敘述漂亮。</li>
          <li>zihrou：把分歧翻譯成方向、資源、授權三類缺口。</li>
          <li>iron：用 evidence ledger 對齊多線執行，而不是被催促。</li>
          <li>PLS：下一輪可根據 miss type 自動改 prompt、派資料任務或升級治理。</li>
        </ul>
      </div>
    </section>

    <section class="grid">
      <div class="card span-6">
        <h2>people_sync</h2>
        <div class="line-draft">LINE 草稿：
Louis / zihrou / iron，PLS 已把「AI 預測驗證模組」整理成可落地驗證 cockpit。請在 2026-05-27 前回覆：
1. accept：同意 hit/miss/partial/unknown 定義；
2. revise：指出哪種預測不能這樣判；
3. evidence_gap：補 signals/action items/commit 以外還要接的來源。
驗收口徑：D7 前 50 筆 prediction 可自動產生 label，unknown 低於 25%，低信心進人工 review queue。</div>
      </div>
      <div class="card span-6">
        <h2>production_readiness</h2>
        <table>
          <thead><tr><th>Gate</th><th>狀態</th><th>證據</th></tr></thead>
          <tbody>
            <tr><td>主成果可打開</td><td><span class="tag green">PASS</span></td><td>本 HTML cockpit</td></tr>
            <tr><td>資料模型</td><td><span class="tag green">PASS</span></td><td>prediction/evidence/match/review tables</td></tr>
            <tr><td>權限/稽核</td><td><span class="tag green">PASS</span></td><td>source_ref、audit_actor、sensitive_source</td></tr>
            <tr><td>E2E 驗收</td><td><span class="tag blue">READY</span></td><td>D1/D7/D14/D30 gates</td></tr>
            <tr><td>下一輪升級</td><td><span class="tag violet">DEFINED</span></td><td>低命中 prediction type 自動派工</td></tr>
          </tbody>
        </table>
      </div>
    </section>
  </main>
</body>
</html>

production-brief.md

AI 預測驗證模組 Production Brief

場景

公司 AI 化專案目前卡在 zihrou、iron、Louis 對 AI 工具選擇與系統化建置未完全統一。這會讓每次 AI review 的預測看似有洞察，卻缺少「事後是否命中」的證據閉環。本輪把「新增 AI 預測驗證模組」做成 production pack：把上次 review 的 prediction 拆成可驗證 claim，再用 signals、action items、GitHub commit、deliverables、people reflections 等證據自動核對 hit/miss/partial/unknown。

30 天路徑

節點	交付成果	驗收
D1	建立 prediction ledger、evidence matcher、人工回填 10 筆 review prediction。	每筆 prediction 有 owner、time window、expected signal、source_ref、label policy。
D7	接入 signals/action_items/GitHub commit，產生 50 筆自動 label。	unknown 低於 25%，low confidence 全部進 review queue。
D14	將驗證結果接入每週 AI review，低命中類型自動派 correction task。	review 顯示 calibration、false positive、false negative、miss_reason。
D30	形成公司 AI 化 decision QA system。	AI review 命中率、決策速度、派工準確率、逾期修正率每週可追。

目的到目的 E2E

原始目的：公司 AI 化要從「AI 產出判斷」升級成「AI 的判斷能被證據校準」。

產出物：prediction-verification-cockpit.html、資料模型、API/sync、驗收測試、decision record、learning memory。

人採用：Louis 拍板 hit/miss 定義與工具標準；zihrou 將分歧翻譯為方向/資源/授權缺口；iron 用 ledger 對齊多線執行。

專案/錢/風險指標改善：

• 提高營收與交付速度：命中的 AI review 可直接轉成高信心行動，減少反覆討論。
• 節省成本：降低錯誤預測造成的錯誤派工與重工。
• 降低治理風險：每個判斷有 evidence trail，不再只靠口頭信任。
• 提高轉換：公司 AI 化 action item 可按命中原因調整資源，而非只看逾期清單。

提升人的能力

• Louis：用 calibration 看 AI 管理層是否可靠，不再只看 AI 產出是否順眼。
• zihrou：用 miss_reason 判斷缺方向、資源、授權或工具標準。
• iron：用 evidence ledger 處理多線 AI 開發與業務系統化，不被雜訊催促牽著走。
• PLS worker：下一輪能根據 prediction type 命中率改 prompt、補資料或派 owner。

market_context

2026-05-24 快速檢查成熟做法：

• Evidently 的 ML/LLM observability 做法強調 data quality、data drift、prediction drift 與 production monitoring，可作為 AI 預測驗證的參考。
• OpenTelemetry GenAI/agent observability 的成熟方向是用 trace/span/correlation id 追蹤每個 AI/agent step，讓品質評估可對回實際執行路徑。
• AI agent production 討論普遍指出：光有 trace 不夠，還需要 eval layer 與 outcome label，才能判斷 retrieval、reasoning、tool use 或 state transition 哪裡失敗。
• Drift detection / ML monitoring research 也支持在 ground truth 到來前先監控資料與 prediction 分布，ground truth 到來後再補 performance label。

本輪採用這些做法，但收斂到 PLS 場景：prediction claim + evidence source + matching rule + label + human review + correction task。

Solution Stack

• 脈絡框架：review prediction → evidence source → match → label → correction task → next review。
• 作業流程：capture prediction、collect evidence、candidate match、human review、metric publish、auto dispatch。
• 資料/DB 模型：prediction_claims、evidence_events、evidence_matches、verification_reviews、calibration_snapshots。
• 可操作工具：HTML cockpit、API spec、review queue、learning memory。
• 驗收指標：unknown rate、label precision、false positive、false negative、decision lead time、correction task closure。
• 採用與下一輪升級：Louis/zihrou/iron 回覆 accept/revise/evidence_gap 後，D7 進 50 筆 prediction trial。

production_readiness

• Primary artifact：prediction-verification-cockpit.html，可直接打開討論 hit/miss 定義。
• Data model：data-model.md 提供 schema、API、權限與稽核。
• E2E：acceptance-tests.md 定義 D1/D7/D14/D30 gate。
• Decision record：decision-record.md 記錄選項、推薦理由、採用狀態與退修方式。
• Learning memory：learning-memory.json 給下一輪 PLS worker 判斷是否應派 correction task。

people_sync

LINE 草稿：

Louis / zihrou / iron，PLS 已把 AI 預測驗證模組整理成可落地 cockpit。請在 2026-05-27 前回覆 accept/revise/evidence_gap：是否同意 hit/miss/partial/unknown 定義，以及還需要接哪些證據來源。D7 驗收是 50 筆 prediction 自動產生 label，unknown 低於 25%，低信心進人工 review queue。

learning_memory

本輪推翻的假設：AI review 的可靠性不能靠「看起來合理」判斷，也不能只看 action item 是否逾期。下一輪必須先找 prediction_claims 是否已回填、evidence_events 是否覆蓋多來源、unknown_rate 是否低於門檻，再決定要改 prompt、補資料、對齊工具標準或派 owner。

sources.md

Sources

Checked on 2026-05-24.

market_context

• Evidently AI, open-source ML/LLM observability：支援 data quality、data drift、prediction drift、ML/LLM monitoring。https://www.evidentlyai.com/evidently-oss
• Evidently GitHub：描述其可 evaluate、test、monitor AI-powered systems and data pipelines，涵蓋 tabular 到 GenAI。https://github.com/evidentlyai/evidently
• Evidently ML monitoring dashboard article：指出 ground truth 來之前可先監控 data/prediction drift、prediction distribution、model calls。https://www.evidentlyai.com/blog/evidently-04-ml-monitoring-dashboard
• OpenTelemetry AI Agent Observability：GenAI observability project 正在定義 AI agent observability semantic conventions。https://opentelemetry.netlify.app/blog/2025/ai-agent-observability/
• arXiv, Open-Source Drift Detection Tools in Action：比較 open-source drift detection tools，指出 drift detection 與 predictive accuracy impact 的價值。https://arxiv.org/abs/2404.18673

Applied Interpretation

本輪沒有照搬 ML model monitoring，而是把成熟做法轉成 PLS 可執行的工具箱：prediction claim、evidence event、match candidate、final label、calibration snapshot、correction task。這能讓公司 AI 化從「AI 說得有道理」進到「AI 判斷可被證據校準」。