一個 Automation Case 失敗後,群組裡很快貼出了四份東西。
第一份是 SOP。
上面寫著:
Step 3
Upload package
Step 4
Start execution
第二份是 Ticket。
裡面要求:
The new package should be used for this run.
第三份是 Source Code。
工程師找到一段 Function,看起來確實會先 Upload,再 Execute。
第四份是當次 Run Log。
Log 裡沒有看到 Upload 完成的紀錄,直接進了 Execution。
很快,討論變成:
「SOP 才是標準流程。」
「但 Code 明明有做。」
「Ticket 才是這次真正的 Requirement。」
「可是 Runtime 根本不是這樣跑。」
四份資料都是真的。
問題是,大家把「是真的」理解成了「可以證明全部事情」。
很多企業 AI 做 Knowledge Search 時,會把各種來源放進同一個入口。
文件、Issue、Code、Log 都可以查。
這很方便。
但「都可以被查」很容易讓人下一步產生另一個假設:
它們都是同一種 Evidence。
其實不是。
在這個案例裡:
SOP
→ Intended procedure / prerequisite
Ticket
→ Requested change / scope / owner
Source Code
→ Implementation
Run Log
→ Actual execution evidence
SOP 可以證明團隊希望流程怎麼跑。
它不能證明昨晚那一次真的有走到 Step 3。
Source Code 可以證明某條 implementation path 存在。
它不能單獨證明 Runtime 當下真的走了那條 path。
Run Log 可以證明那次執行看到什麼。
但如果拿它去回答「設計上本來應該怎麼做」,它也不夠。
如果 AI Search 只做一件事:
Query
→ Retrieve all relevant chunks
→ Summarize
它可能會得到一段很完整的回答:
系統依 SOP 與 Source Code 會先 Upload package,之後執行;本次 Ticket 也要求使用新 Package。
每一句都有來源。
但這段話仍然沒有回答真正的問題:
昨晚那一次,到底有沒有成功 Upload?
這題最有資格回答的是 Runtime Evidence。
如果 Log 沒有看到,不能拿 SOP 或 Code 來補成「應該有,所以有」。
這也是 Source Responsibility 的意義。
不是判斷哪個 Source 比較高級。
而是先問:
你現在要證明的是哪一種事情?
事件後,團隊沒有訂一個簡單規則:
Log > Code > Ticket > SOP
因為這樣還是錯。
如果問題是「這次實際執行了什麼」,Log 最重要。
如果問題是「這次需求要改什麼」,Ticket 才是主要 Source。
如果問題是「現在 implementation 怎麼寫」,要看 Source Code。
如果問題是「正式操作前應有哪些 prerequisite」,SOP 仍然有自己的責任。
所以他們只留下了一張很小的對照:
Source Responsible for
------------------------------------
Procedure Intended process
Request / Issue Requested work
Repository Implementation
Run result / Log Actual execution
之後 AI 回答時,也不只列「參考了哪些文件」。
還要能說:
這個 Claim 是由哪一類 Source 支持的。
當天的 Case 最後查到:
Code 裡確實有 Upload path。
SOP 也沒有寫錯。
但那次 Runtime 因為當前條件走了另一條 Execution Path。
真正要修的不是把其中三份資料標成「過時」。
而是不能再拿它們互相代替。
隔天的 Review Board 上,原本只有一欄:
Evidence
後來被拆成:
Procedure Evidence
Requirement Evidence
Implementation Evidence
Runtime Evidence
資料沒有變多。
只是從那天開始,大家不再用「我找到一份相關文件」直接跳到「所以事情就是這樣」。