不可变保管库
任何内容都不会被覆盖。
其他所有保管库都采用就地编辑。更改密码后，旧密码便随之消失——没有存在过的记录，也无法证明上周二的真实状态。Clavitor 不会覆盖。每次更改都会写入新修订版本。历史记录得以保留。记录完整无缺。
自始至终采用仅追加模式。
Clavitor 中的凭据不是供您编辑的单行数据，而是一个修订版本栈。更新密码时，保管库会插入新版本——绝不会触碰旧版本。最新修订版本即为当前值；之前的每个修订版本依然按顺序完整保留。
01 — 写入
每次均生成新修订版本
每次更新都是 INSERT，绝非 UPDATE。条目保持单一稳定的标识；版本号递增。读取凭据时返回最高版本——即您预期的值——而之前的每个版本都保持写入时的原样。
02 — 保留
贯穿保管库生命周期的历史记录
只要保管库存在，旧修订版本就会被保留。轮换历史、泄露前的值、任意日期的字段状态——均不会被丢弃。过去并非您寄希望于他人保留的日志，而是数据本身。
03 — 删除
是墓碑记录，而非彻底抹除
删除凭据会写入一个标记其已删除的新修订版本。该条目停止解析——但其存在过的记录以及被移除的时间依然保留。可证明的删除比不留痕迹的删除更有价值。
为什么这很重要
可变保管库无法回答的问题。
当每次编辑都会破坏之前的内容时，整类问题都将变得无法回答。不可变性通过其底层构造回答了这些问题。
“事件发生当天的密钥是什么？”
经过轮换的机密通常在被替换的瞬间就会消失。而在 Clavitor 中，在该时间窗口内生效的值仍保留在保管库中，处于其对应的版本，并带有可证明的时间戳。取证不再是考古。
“谁更改了此项，更改前的内容是什么？”
每次更新、删除、作用域更改和智能体更改都会写入一个与新修订版本关联的审计事件。历史记录与操作者记录是同一故事的两种表述方式——且两者都无法被悄悄回滚。查看防篡改审计轨迹 →
“我们能直接撤销该操作吗？”
错误的轮换、误触导致的编辑、受损智能体覆盖了字段——当没有任何内容被破坏时，恢复先前的值只需读取早期版本，而不是恢复备份并祈祷它足够新。
“在我们没注意的时候，有什么内容被更改了吗？”
它无法被悄悄更改。不存在会被遗漏的就地修改。当前状态是一个带有编号、作者和时间戳的修订版本——之前的每个状态也是如此。
一项原则，贯穿整个保管库。
不可变性并非强加于凭据之上的功能，而是 Clavitor 中每条记录的构建方式。您的条目、审计日志、包装密钥记录，乃至这些页面的具体内容——全部采用仅追加模式，方式完全一致。系统中没有任何地方的真实数据会被覆盖。
无冲突复制
由于修订版本只写入一次且从不更改，将其复制到地球另一端非常简单：使用仅向前游标，并在行数据落地时提供明确确认。无需协调编辑，无需解决冲突，也不存在“哪个副本正确”的问题。仅追加数据有且仅有一条历史记录。
保留密文——而非泄露明文
保留的历史记录在静态时会被加密，与实时值的加密方式完全相同，且密钥绝不会到达我们的服务器。保留过去不会增加任何暴露风险：被盗磁盘上存放的旧密文和新密文同样无法读取。加密工作原理 →
唯一的例外
我们记录了唯一进行就地更新的地方。
诚实是设计的一部分。有且仅有一个字段是就地写入而非作为新修订版本写入的：verified_at，即记录凭据上次生效时间的标记。它是使用元数据，而非内容更改——因此它直接更新最新修订版本，且每次更新本身都会被记录在审计日志中。我们在此告知您这一点，因为未记录的例外会使不可变性声明变得空洞。这是唯一的例外。
正确执行删除。
仅追加并不意味着您永远无法被遗忘。它意味着遗忘是刻意的、彻底的，且有据可查的。按修订版本的墓碑记录可处理日常情况。当需要真正抹除时——如 GDPR 请求、账户关闭——删除操作将针对整个保管库且不可逆，作为刻意执行的操作运行，绝非悄悄进行的逐字段覆盖。您绝不会被悄悄编辑；当您被移除时，这是有意且彻底的移除。
诚实的保管库会保留其历史记录。
不可变性只是故事的一半。另一半是谁接触了什么的记录——链式关联、经过见证且可证明。