Jon 在下午 6:18 發現了錯誤，距離他計劃發送報告只剩十二分鐘。
這份文件要交給 Haversham Components——一家希望減少包裝線換型時間的家族製造商。但第十七頁的停機原因圖表下面，AI 寫作助手使用了“North Ridge 運營模式”這個詞。North Ridge 是 Jon 的另一個客户。
報告中沒有出現 North Ridge 的數據。這個詞來自 Jon 可複用的諮詢模板。即便如此，錯誤依然嚴重。它説明當一個獨立顧問在四個項目中使用相同 AI 工具時，方法、語言和客户信息多麼容易混在一起。
正是這次事故，讓 Jon 後來圍繞“隔離”而不是“方便”配置 onemind。他的公司 Mind 只保存通用諮詢方法：如何組織觀察、驗證計算、撰寫建議和標記不確定性。每個客户擁有獨立受限 Project。Haversham Project 包含自己的術語、獲批利益相關者、安全規則、來源目錄、保留政策和兩個進行中的合作。它能繼承 Jon 的方法，卻不能搜索或繼承 North Ridge 的內容。
三個月後，Jon 到 Haversham 工廠參加主管工作坊。錄音前，他在 onemind 中打開正確合作。屏幕用大字顯示當前客户、會議敏感度、參會人和是否已取得錄音同意。只有工廠經理確認同意後，onemind 才允許會議分析工作流啓動。
會議錄音文本以來源材料進入 onemind，而不是直接變成公司記憶。會議 Agent 收到工作坊目標、Haversham 偏好的詞彙、流程圖 Schema，以及必須區分觀察事實和參與者觀點的指令。它返回四項候選決策、七項觀察和三個未解決問題，每句話都連接到準確時間戳。
Jon 拒絕一項候選決策，因為維護主管當時只是在頭腦風暴，並沒有授權改變。他修正兩個人名，接受在三號線試用圖示作業説明的決策。Agent 還提出一條經驗：主管對帶標註照片的接受速度快於長篇流程文字。Jon 只在 Haversham 三號線 Project 中接受它，並把複查時間設在試驗之後。onemind 沒有把它推廣給其他客户。
第二天早上，Jon 打開表格 Agent。onemind 只提供獲批生產數字、Haversham 使用的單位、約定基線週期和 Jon 的驗證流程，不允許 Agent 讀取整個會議文本或其他客户目錄。Agent 計算出方案每月可能恢復 2.8 至 4.1 個生產小時，取決於是否把兩次異常停機納入計算。因為結果對該選擇很敏感，Agent 輸出兩種情景並標明假設。
隨後 Jon 讓 Claude 起草流程和培訓材料。onemind 同步了 Jon 的寫作標準、Haversham 術語、正式試驗決策、獲批表格文件、圖示説明經驗和保密頁腳。Claude 引用了表格情景，沒有編造一個看似確定的單一節省數字。
下午 5:54，Jon 點擊“準備外部交付”。onemind 導出 Hook 阻止了文件。這一次不是客户名稱錯誤，而是一張照片裏的白板寫着員工電話號碼。Hook 顯示具體頁面、識別出的敏感字段、觸發政策，並提供三個選擇：刪除圖片、遮擋號碼，或向客户負責人申請有記錄的例外。Jon 遮擋號碼並重新檢查。第二次通過了保密、術語、引用、計算和必要頁腳檢查。
報告的證據包記錄 Haversham 來源版本、正式決策、表格結果、Claude 版本、onemind 工具包版本、導出檢查和 Jon 的批准。工廠經理後來問為什麼節省量是範圍而不是單一數字，Jon 可以直接打開具體假設和會議證據，不必搜索舊聊天。
合作結束時，onemind 把 Project 轉為只讀保留，客户文檔目錄訪問到期。本地 App 在移除 Haversham 分析 Plugin 和緩存工具包前請求 Jon 批准。有一個手工下載的來源文件無法驗證是否已刪除，所以結束報告顯示“需要用户處理”，而不是假裝清理已完成。
接下來一個季度，Jon 的平均最終合規審核從接近兩小時降到約五十分鐘。他沒有用報告數量翻倍來衡量成功。真正重要的是：他能夠在客户之間複用自己的方法，同時保持事實、語言和證據分離；當邊界檢查失敗時，錯誤會在文件離開電腦之前出現。