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 的平均最终合规审核从接近两小时降到约五十分钟。他没有用报告数量翻倍来衡量成功。真正重要的是：他能够在客户之间复用自己的方法，同时保持事实、语言和证据分离；当边界检查失败时，错误会在文件离开电脑之前出现。