让Agent整理业务资料、更新团队记录，价值在于其他人不用再翻原始材料，就能接着使用这些信息。但一条数据经过审核、合并，进入正式业务表之后，仍可能被发现有误：原始资料读错了，审核时漏看了一项，或者后来找到了更可靠的依据。
这时，直接把值改掉虽然快，接手的人却难以理解为什么改；把整条记录恢复成旧版本，又可能覆盖错误发生后其他人已经确认的更新。如果旧值还进入过报告或导出文件，只修表里的一个字段也未必结束了这件事。
在Busabase里，记录保留当前内容和历史，ChangeRequest记录变更及审核过程。纠错可以沿着这条线继续：找到错误从哪次变更进入，依据可靠资料提出范围明确的修正，再核对正式记录和已知下游。这样修好的既是数据，也是团队下一次使用它时的判断依据。
先让错误停止扩散
发现正式业务表中的值有错，先确定哪些人和任务仍在使用它。把相关自动执行暂停在你有权管理的环节，通知记录负责人暂缓依赖该值做决定。暂停范围要明确：一条记录有问题，不必把整个知识库都判为失效。
随后保存记录入口、当前版本、出错字段和发现依据。不要立即恢复成某个看起来熟悉的旧值：原变更之后可能已有合法更新。纠正的目标是让当前记录重新准确，同时留下可追溯的解释。
在记录与原提案之间找到错误来源
Busabase的记录有当前内容和历史；ChangeRequest保存变更及审核状态。合并推进记录的commit指针，历史提交保留。因此，已经合并的错误适合通过新的纠正变更处理。
打开记录详情与历史，找到引入问题的变更，核对原值、新值、提交来源及审核过程。再对照可靠的业务依据：原始合同、系统回执或数据负责人确认。一个Agent说“上次填错了”是线索，仍需找到足以支持替换值的证据。需要引用附件时，可以沿用来源与交付证据的组织方法。
把纠正建成有范围的提案
可以复用原业务Base，再增加一个建议的“数据纠正”Base：标题用人能识别的问题，关联字段指向受影响业务记录，另存问题字段、当前值、建议值、证据位置、原变更链接、纠正变更链接、负责人、处理状态和下游复验结果。这是可按现有schema调整的起步设计，不是要求每次修改都另建系统。
给连接到Busabase的Agent一条明确指令：“读取这条记录的当前版本与指定证据。列出需要纠正的字段，保留其他已确认字段，说明原变更与本次变更的关系。先展示差异，再按允许的权限提出ChangeRequest；不要删除历史，也不要撤销无关更新。”
使用REST API集成时，从最新读取结果取得相应版本依据，再提出字段增量。提交前发现记录已变化，先重新读取并核对差异。合并前的版本竞争可以参考多Agent并发更新，它和合并后的事实纠错是两个不同环节。
让审核决定对应具体改动
审阅者要看到哪个字段为什么错、拟改成什么、证据在哪里、哪些字段继续保留。变更说明应写业务原因，并链接原变更和纠正跟踪记录。不要把“恢复正常”当作足够的说明。
API密钥权限影响提案是否停在审核队列：changeRequest级别可以读和提案，不能自行合并；write级别的写入可以即时合并。需要人工把关时，用相应权限及明确的review设置落实，不能只靠聊天里的“请先审核”。
合并以后，还要确认谁已经用过旧值
回读正式记录，逐字段核对纠正值及应保留的字段，并确认原变更、纠正变更和当前记录能互相追踪。在纠正跟踪记录中写回核验结果，再交由负责人确认处理结束。
原值可能已经进入报告、导出文件或另一个Agent的工作上下文。列出已知消费者、需要重算或重新生成的产物、负责人与复验结果。相关外部系统须通过已有集成、脚本或人工通知处理；保存一条纠正记录不会自动刷新所有下游。
这也是纠正与回滚的区别：旧版本可以帮助理解经过，但整条恢复可能覆盖随后有效的改动。对当前状态做有依据的修补，通常更容易说明影响范围。不要把可查历史理解为已经具备一键全链回滚。
完成的标准是记录与使用都能被复核
让负责人能回答四个问题：现在的正确值是什么，依据是什么，历史经过在哪里，已知下游是否处理。未知消费者留作明确的剩余风险。先从一条真实错误记录走通纠正、合并与回读，再把可复用检查写进Doc或Skill。下一次Agent读取时，就有机会同时看到可靠的当前值和这次纠正留下的指导。