CONTINUUM：7条受影响记录为何重审？

一个上线申请批了，决策也归档了，客户那边的交付日期都承诺出去了。然后安全侧的一个前提条件变了。原来的批准还在，但它依赖的假设已经不成立。哪些决策需要重审？哪些里程碑和客户承诺挂在它下面？现在该谁接手，又拿什么证据解释这个结论？

这是 CONTINUUM 想回答的问题。它是 Team OmegaRuby 在 WeMakeDevs 与 FalkorDB 主办的 Graph Hacks 中提交的项目，参加的是第三赛道「Company Brain」。做法是把决策、带版本的证据、前提条件、负责人和承诺，全部连进 FalkorDB 里，再顺着记录下来的变更去追后果，把需要明确复核的后续动作准备好。

它抓住的核心区别只有一句：一个历史决策可以继续被解释清楚，同时它当下的就绪状态需要重审。

搜一份上线文档，回答的是「这个决策记在哪」。CONTINUUM 问的是另一个问题：什么东西依赖了那个决策的前提，其中一个前提被撤掉之后，哪些东西跟着变。

演示用的是一家虚构公司 Northstar Systems，旗下有 Atlas、Beacon、Orbit 三个项目。它的 Markdown 来源和带类型的关系都是人工整理的合成数据，不是真实客户记录，也不是从任意文本里自动抽取出来的关系。

Atlas 场景里，一条出口审批支撑一个出口决策，出口决策支撑一道关卡，关卡再支撑 Atlas 的上线决策和下游承诺。把那条审批撤回，这套固定数据里会标出 7 条受影响的记录。这个数字是已知的场景结果，不是普遍的性能结论。

应用会保留旧审批，也保留当初支撑原决策的证据。它改的是当下的就绪评估，状态变成 review_required；它不会宣布那个决策是错的，也不会自动取消上线。

图里有 Decision、Assumption、Project、Milestone、Commitment、Person 和不可变的 DocumentVersion 节点，也存了 ChangeEvent、ResponsePlan、ProposedAction、ActionItem 和 RestorationReview 这些操作记录。最关键的建模选择是关系的含义。一条示例依赖链是：客户承诺 → Atlas 可用性 → Atlas 决策 → 出口关卡 → 出口决策 → 出口审批，每一个箭头都表示 DEPENDS_ON。

影响排查从被改动的那个前提出发，找指向它的依赖路径。归属关系、团队关系、文档链接都不传播影响，否则同属一个团队或共用一份来源，就可能让不相关的项目看起来也被波及。

这是项目查询参考里的核心当前影响查询：

MATCH p=(n)-[:DEPENDS_ON*1..8]->(a {id:$id})WHERE (n:Decision OR n:Milestone OR n:Commitment OR n:Project)AND all(r IN relationships(p) WHERE coalesce(r.current,true)=true)RETURN n.id AS id, n.name AS name, labels(n) AS labels,[v IN nodes(p) | v.id] AS path,[e IN relationships(p) | properties(e)] AS edges,length(p) AS depthORDER BY depth, id LIMIT 201;

查询里的八跳上限是刻意的。应用最多保留 200 条路径，把第 201 条当作截断信号，另外单独检查深度边界之外还有没有活跃依赖。排查不完整就阻断响应计划的生成。一个有边界的结果，不该悄悄变成「所有后果都找到了」的结论。

负责人这块也留了冲突。Atlas 的固定数据里故意放了一份较早的项目简报写着 Ethan Park，而当前权威登记册写的是 Maya Chen。CONTINUUM 会把两份来源和它们的冲突一起返回。负责人解析会比较有效且有来源的记录，按配置的权威性和生效日期判断；同级记录必须一致，解不出来的归属不会变成一个猜出来的指派。

理由很直接：一份看起来合理的响应发给了一个已经过时的负责人，流程照样是断的。稳定的人员 ID 也能防止同名的人被悄悄合并。

完整流程是这样走的：先看项目的就绪状态、依赖路径和来源版本；记录一次明确标注为合成的提前撤回；查看受影响记录和解析出的负责人或冲突；生成响应计划并挑选拟定的后续动作；显式批准这次选择，才会生成持久化的行动项；最后记录替代证据，完成一次单独的恢复复核。

提案会记下图的版本号和支撑上下文的指纹。批准时会重新核对这两个值，建任务时用原子化的图版本比较。证据、依赖或归属一变，旧提案就过期。重复批准不会产生重复任务。

完成一个后续动作，并不等于恢复了那条安全审批。恢复需要替代证据，并对受影响记录做显式重新验证。早先的来源、任务和事件都留着可查，跨多轮变更也能解释。应用会准备沟通草稿，但不对外发送任何消息。

模型这边只给了八个带类型、只读的图工具，可以取证据、追影响、解析归属、评估就绪度。它不能执行不受限的 Cypher，不能批准计划，不能改图记录，也不能发通知。返回的答案要对照检索到的来源 ID 和完整图路径做检查，非法的工具参数、编造的引用、虚构的路径都会被拒。这些检查建立的是结构性依据，并不能证明每一句自然语言都被证据蕴含，这仍是评估缺口，也是要去看引用来源的理由。

本地推理通过 Ollama 支持。部署版用 Groq Free 的 openai/gpt-oss-120b 验证过。部署时踩到一个具体的坑：最初把 JSON 响应模式和工具调用放在一起，被拒了；去掉 JSON 模式后又冒出另一个失败，模型有时会去调一个不存在的 json 工具来收尾。现在的集成提供了一个带答案 schema 的 finish_investigation 函数，返回经过校验的答案，不改动记录，来源、路径、检索优先和版本这几道检查照旧生效。

技术栈是 React 加 TypeScript、FastAPI 和 FalkorDB。一个 Docker 应用在 Railway 上从同一个 HTTPS 源提供前端和 API，FalkorDB 私有运行，挂了持久卷并开启只追加持久化。目前是单 worker、单副本，因为会话和部分限额是进程内的，横向扩展需要额外的共享基础设施。

云端验证报告里记了这些检查：129 个自动化测试通过，GitHub Actions 里的容器生命周期检查也通过；认证、来源限制、CSRF 处理、角色限制和带认证的图读取都通过；一次云端演练追出 7 条受影响的 Atlas 记录，批准并完成一个后续动作，再通过单独的替代证据复核恢复就绪状态；一次真实的 FalkorDB 重启后完整摘要仍在，重启前后的 SHA-256 哈希一致；一次实时的 Beacon 模型排查返回了预期的依赖路径和全部四个必需的来源版本。

这些都是针对这套实现和它的合成场景做的检查，不构成企业级规模、完整安全审计或任意模型答案语义正确性的证明。

项目总结出三条设计经验：关系的方向和含义就是产品行为，图连上了不代表每条连接都意味着运营影响；时间和权威性要放进数据模型，「最新文本提到了某人」对判断当前归属或批准来说太弱；提案、已批准任务和恢复后的就绪状态需要分开的状态，把它们揉在一起，行政进度就会冒充成新的证据。

下一步想做的是面向真实来源的权限感知连接器、更强的答案蕴含评估，以及多副本所需的共享会话和配额。当前接入只接受经过审阅、带整理元数据的合成 Markdown。线上部署用的是 Railway 试用资源和 Groq Free 推理，可用性取决于剩余试用额度、服务限额和模型访问权限，完整的本地搭建在仓库里。

CONTINUUM 的目标说得很朴素：让一个被改动的假设变得可见，解释它的后果，再给对的人一个可复核的下一步。