一条知识关系由一份资料支持。后来资料中的依据被撤销，这条关系还能不能查到？最直接的回答似乎是：从图里删掉，之后自然查不到。
但在需要追溯结论的系统中，如果连同依赖和历史一起清除，就会失去另一个问题的答案：过去为什么出现过这条关系，谁审核过它，当时使用了哪个版本的资料？如果历史报告仍然引用这条关系，只剩一个“找不到”，也不足以解释发生了什么。
TraceWise 因而把两个问题分别处理：历史上存在过什么，以及现在允许使用什么。对已经登记到 Foundation 治理的对象，撤销改变的是当前使用资格；原 Evidence、Graph 历史、提案与审核记录仍然保留。这个区别也影响检索缓存、在途查询和恢复流程。
失效不是“资料旧了”的同义词
一份资料发布日期较早，并不自动意味着它失效。旧版本可以用于解释历史行为，但未必适合回答当前行为。是否仍可作为当前依据，要看对象登记的生命周期、精确 revision 与使用约束。
这里讨论的范围更具体：Evidence 已经通过公开流程登记，图对象声明了适用的必要依赖；之后，该 revision 被撤销或被新 revision 取代。系统因此能够对“这个当前图对象仍然满足依赖吗”作出确定判断。
这与文档里的陈述在现实世界是否正确仍有区别。生命周期检查不代替事实核验，也不因为模型认为另一份资料相似，就允许自动换一份依据继续使用旧关系。它执行的是已经声明并受治理的依赖契约。
业务上哪些资料值得进入产品、实体和关系怎样定义，由 TraceWise 决定。已登记 Evidence 的版本、撤销、有效性，以及启用的 Graph Proposal 约束，由 Foundation 按公开契约维护。这个归属按对象和接入路径成立，不代表所有 TraceWise 数据都已经由 Foundation 接管。
三种“存在”，对应三种不同用途
同一个知识对象可以同时处于“历史可追溯”和“当前不可检索”的状态。它们不是矛盾。
| 层次 | 要回答的问题 | 撤销后的处理 |
|---|---|---|
| 历史记录 | 当时依据什么作出过判断？ | 保留原文版本、提案和审核记录 |
| 当前检索视图 | 现在有哪些对象可以参与搜索？ | 排除必要依赖失效的对象及受影响关系 |
| 已取得的查询结果 | 计算期间，使用的那一代状态变了吗？ | 返回前检查 token，变化则丢弃旧结果 |
保留历史不意味着普通搜索仍然把它当当前知识返回。相反，当前检索集合是经过有效性约束的派生结果，而历史阅读需要明确的版本语境和相应权限。
如果系统另有完整审计存储，物理删除当前图记录也可以是设计选项。本轮选择保留既有历史对象、维护当前可用集合，目的是复用现有依赖与恢复约束；关键不在于必须采用某种删除方式，而在于三个用途不能混为一谈。
Microsoft 的 Materialized View 模式把这类派生视图描述为可以从源数据重建的查询形态，并要求明确更新与一致性策略。这个区分对这里很有帮助：为了改变当前可读集合，不必把源记录一起删除。TraceWise 的具体撤销约束仍由 Foundation 的治理实现承担，不是通用缓存模式自动提供的能力。
撤销究竟影响多大范围
在本次固定本地副本中，图共有 649 个对象。撤销一条 Evidence revision 之后，直接依赖它的对象有 9 个；加上因端点失去当前资格而需要隐藏的关联边，最终退出可检索集合的是 13 个对象。其余 636 个对象全部保留。
为什么不只删除直接依赖？因为一条关系需要它的两个端点都能在当前视图中解释。如果端点已经不可用，仅保留关系会产生一条无法完整展开的连接。与此同时，因端点隐藏的关系，不应被误记为“自己的 Evidence 已经失效”，这会影响之后的恢复判断。
状态解释：当前集合按依赖变化，历史仍然保留；末尾检查负责发现计算期间已经观察到的视图变化，不承诺结果永久有效。
在支持的 SQLite 路径里，Evidence 的终止生命周期变更与相关对象资格更新位于同一事务。撤销提交之后才开始的公开视图读取，不会继续取得撤销前的可用集合；无关视图不因这一条 Evidence 被撤销而全部失效。
范围精确还有一个收益：当系统逐渐积累更多资料，一条证据变化不必把所有用户的查询结果都视为无效。不过，当前实现仍然有源对象预算和依赖策略限制，不能据此推导任意规模图谱的更新性能。
为什么返回前还要检查一次
考虑一个已经开始的查询。它在时刻一读到当前视图，在时刻二完成排序；Evidence 可能恰好在两者之间被撤销。
如果只在读取时检查，排序使用的内容当时有效，但返回时可能已经不具备当前资格。若再读取并重新解释整张图，成本又回到了原来的问题。因此，TraceWise 在评分后、返回前提交第一次读取取得的 view_token，Foundation 检查它是否仍是当前的一代。
实际流程里，撤销后的旧 token 对应 409 graph_retrieval_view_changed。这意味着产品应丢弃旧结果，必要时有界地重新查询，而不是给旧结果加个提示继续作为当前结果使用。token 只是状态标识，不是登录凭证，拥有它也不能省略主体和作用域检查。
但这个检查不能许诺未来。如果撤销发生在末尾检查之后，先前响应仍可能完成。服务不能隔空收回已经传给用户的文本，也不能让一次读取替后续所有操作担保。因此，稍后的写入、审核执行或其他高风险动作，还要检查自己的当前授权与依赖。
这是一处可说明的并发检查点，而不是横跨身份、Neo4j 和 SQLite 的全局原子快照。
“换一条 Evidence”为什么不一定能立即恢复
证据失效之后，管理员补充了一份新资料，内容也能够支持原关系。能否把旧关系自动恢复？这里需要区分技术上的依赖满足与业务上的恢复批准。
当前实现会保留被直接判为失效的映射身份。重建视图、替换 Evidence 或再次验证依赖，本身不绕过既有恢复审核。否则，原来因为重要问题被暂停的关系，可能仅凭一次后台刷新重新出现，而审核人并没有批准这次恢复。
同样，存在若干可替代的支持资料，也不意味着撤销时可以临时搜索一份语义相近的替代品。究竟哪些依据必须合用，哪些可以形成独立充分的支持组，需要预先表达并按适用流程采用；当前路径没有自动切换替代支持组的能力。
这部分的代价是恢复操作更明确，而不是“修一下索引就都回来”。它适用于确实需要治理的对象；临时搜索缓存是否需要同样流程，应按产品用途另外判断。
失败时，是保持不可读还是返回旧资料
Evidence 的事务内失效更新，不代表整个系统拥有跨库事务。Graph Proposal 执行先使旧视图不可读，然后写入 Graph，再维护已准备的视图。如果写图成功而维护失败，图变更已经发生，视图仍然不可读，等待授权修复。这不能描述为 Graph 自动回滚。
原始图源也存在边界：受支持的 Neo4j adapter 写入会改变源标识或 dirty 状态，使旧视图无法继续使用。管理员绕过 adapter 直接执行数据库修改，不属于当前小标识机制可以实时发现的变化。若要支持这类操作，需要额外的接入约束和探测机制。
旧投影读取模式只用于明确兼容和对照，不是维护模式失败时的自动回退。否则，治理路径不可用时改走另一条读法，可能让“保持不可读”的承诺在故障时失效。
实际检查证明到哪里
本次使用未发布的 Foundation post22 候选，在隔离 Neo4j／SQLite 副本上执行公开同进程接口检查。只读主体的撤销请求被拒绝，错误映射为 403 evidence_scope_forbidden；独立写入主体完成撤销后，旧 token 被拒绝，产品查询排除受影响对象，636 个无关对象保持可用。
关闭并重新打开 runtime 后，撤销状态、token 与引用集合保持一致，没有调用准备或旧整图投影。这验证了该副本上的持久状态和公开使用路径，不等于真实 HTTP 凭证全生命周期认证、操作系统崩溃恢复或多租户安全认证。
当前支持 SQLite Evidence、既定 required 依赖策略和最多 2000 个源对象。图变更后的维护仍是完整有界重建。未来若需要更高更新频率、更大规模或其他存储后端，应继续测量维护成本和并发窗口。
对这类系统而言，最有用的区分不是“证据还在不在数据库”，而是“这份证据以哪个版本、在什么状态下，允许支持哪个对象的哪一次使用”。历史可以留下，当前资格可以失去，后续恢复还可以需要新的批准。把这些含义分开，图查询和缓存才能各自承担清楚的责任。