Trust-OS 北極星目標設計

日期：2026-03-12 決策：定義 Trust-OS 的雙軌北極星目標，寫入 CLAUDE.md 作為所有後續開發的指導方向

總願景

Trust-OS 的最終目標是成為高監護移動場景的信任基礎設施——一個彈性 SaaS 平台，能適應各種服務場景（共乘、活動接駁、校車、企業通勤、包車），同時透過 RCA 評分框架持續收集信任資料，最終讓 RCA（Reliability · Courtesy · Affinity）成為政府機構認可的行業標準。

雙軌結構

產品軌：Trust Platform SaaS

階段	目標	說明
Phase 1 — 統一流程	合併 bearbubu + dauding	將兩套系統的流程收斂為 unified-flows-detail 定義的統一架構，以服務方案（M1）為核心，透過模組開關適應 B2B/C2C 場景
Phase 2 — 多租戶 SaaS	一套系統服務多個客戶	多租戶隔離、RBAC 權限、Feature Flags，讓不同機構（教育、長照、企業、政府）能獨立設定自己的服務方案
Phase 3 — 場景擴展	覆蓋更多高監護場景	從兒童接駁擴展至長者接駁、偏鄉微型運輸、大型活動疏運等，每個新場景透過服務方案設定而非程式碼改動來支援

信任軌：RCA 行業標準

階段	目標	說明
Phase 1 — 資料收集	建立 RCA 資料基礎設施	在行程執行流程（M4）中嵌入 R/C/A 三維度資料收集點：R 由 Driver App log 自動計算、C 由家長/乘客每趟評分、A 由選填 kudos 捕捉
Phase 2 — 信任回饋環	RCA 驅動供給側行為改變	司機看到可解釋的分數並改善、車行依 RCA 管理旗下司機、Corporate Client 合約納入 RCA 條款
Phase 3 — 行業標準	RCA 成為可引用標準	累積足夠資料量與案例後，推動 RCA 框架被同業採納、進入政府採購與監管的評估語言，Dauding 從服務提供者升級為標準定義者

兩軌交叉依賴

• 產品軌 Phase 1 → 信任軌 Phase 1：統一流程完成後，RCA 資料收集點才有標準化的嵌入位置（M4 行程執行、M5 結算回顧）
• 信任軌 Phase 2 → 產品軌 Phase 2：RCA 回饋環運作後，多租戶 SaaS 才能以「內建信任管理」作為差異化賣點
• 產品軌 Phase 3 ↔ 信任軌 Phase 3：每個新場景擴展同時帶來更多 RCA 資料量，資料量支撐 RCA 成為行業標準的說服力

設計決策記錄

• 為什麼是雙軌而非單一路線圖：產品軌和信任軌的推進節奏不同，但有明確的交叉依賴。雙軌結構讓未來的開發者能理解「為什麼這個流程需要收集這個資料點」
• 為什麼不綁定具體時間：時間一過就需要更新，維護成本高。階段目標比日期更持久
• 來源文件：bearbubu-flows-detail/（既有 C2C 流程）、dauding-flows-detail/（既有 B2B 流程）、unified-flows-detail/（目標統一架構）、Dauding_RCA_MRD_v1.4.docx.md（RCA 框架定義）