每一个严肃的采购流程都会问连续性问题：如果这家供应商倒闭、被收购或停掉产品，我们会怎样？对大多数软件来说，答案是一次数据导出加一个迁移项目。对一个完整性供应商来说，这个问题更加尖锐，因为它的整个价值主张就是持久、长寿命的证据——而一份依赖于某一家公司持续存在的证据，根本谈不上持久。唯一令人信服的答案是结构性的。
为什么这个问题对完整性供应商更难回答
如果你的 CRM 供应商消失了，你失去的是一个工具，并迁移你的数据。痛苦，但可以挺过去。如果你的完整性供应商消失了，而你的证明只能在它的系统内部得到验证，那么你失去的就不只是一个工具——你失去的是证明自己多年前锚定的记录至今仍完好无损的能力。证据恰恰会在多年之后、你为审计或争议而需要它的那一刻，变得无法验证。
这正是当年一项大型云账本服务被关停时，整个行业学到的那条集中度风险教训：任何验证依赖于单一提供方的证据层，都会继承那个提供方的“必死性”。解决之道不是换一家更大的供应商，而是让验证彻底独立于供应商。
“独立于供应商”需要什么
要让你的证据在创造它的供应商之外存续下去，必须同时成立三项属性：
- 公开锚定——完整性树根被写入一条公有区块链，而非供应商掌控的私有账本。这个参照点独立于公司而存在，无论公司是否还在，它都保持可读。
- 自包含的证明包——对每一条记录，你都持有其哈希、默克尔路径以及链上引用。这个包足以仅凭该记录和公开可得的数据，就对照公开锚点完成验证。
- 开放、有文档的验证方法——校验一份证明所用的算法是标准且公开的，因此任何称职的工程师、或一个独立的开源工具，无需供应商配合或软件，就能确认通过或失败。
诚实的现状
有必要精确区分今天已有的与路线图上的，因为供应商连续性恰恰是过度宣称会摧毁信任的话题。上面那些架构属性是真实存在的：锚定面向的是一条公链，证明包是自包含的、构建在标准的默克尔验证之上。
一个完全开源的验证 CLI——你自己运行的单个工具，输入一份证明包，无需 Certyo 介入即返回通过或失败——是路线图上一项已承诺交付的内容，而不是我们会声称已经发布的东西。我们今天能够安心做出的持久性保证，建立在架构之上，建立在合同中的源码可得与托管（escrow）条款之上，也建立在这样一个事实之上：公开锚点与标准证明格式并不要求我们继续经营下去。
独立验证是什么样子
终态是一条完全不触及供应商任何基础设施的验证流程：
请注意，供应商的服务器在那条流程里压根没有出现。你持有证明包，公链持有锚点，而比对是任何人都能完成的算术。正是这一点，把最令人胆寒的尽职调查问题——“你们要是倒了怎么办？”——变成了一个不成问题的问题：那份证明从一开始就不依赖我们还活着。
如何对任何完整性供应商进行压力测试
把这三个问题带给任何以证据为产品的供应商，也包括我们：
- 锚点在哪里？ — 如果完整性参照点活在供应商掌控的私有账本里，那么你的连续性风险就等于他们的公司风险。坚持要求公链。
- 我能不靠你来验证吗？ — 请他们演示仅凭证明包和公开数据来验证一份证明的全过程。如果答案离不开他们的 API，那这份证据就不是独立于供应商的。
- 白纸黑字写了什么？ — 源码可得、托管（escrow）以及一份有文档的证明格式，能把口头上的“我们会一直在”，变成能比供应商活得更久的条款。
把最大的风险变成护城河
连续性问题通常被框定为一个年轻供应商需要去招架的弱点。它其实是最能用来竞争的地方。一个平台若能诚实地说出“你的证据不依赖我们的存续，这里就是不靠我们来验证它的确切方法，这里就是我们白纸黑字承诺过的内容”，它就把自己被感知到的最大风险，转化成了一项结构性优势——而那些验证活在自家云里的老牌厂商，是无法与之匹敌的。把这个问题问给每一家供应商。好的供应商会乐于回答它。
“你要是消失了怎么办？”这个问题的正确答案不是“我们不会”，而是“你的证明从一开始就不依赖我们还活着——这里就是不靠我们来验证它的方法”。