Maria 在一家小型软件公司负责客户支持。一天早上，一位客户提出投诉。他说公司现在适用的取消规则，从来不在他注册时接受的条款里。Maria 去查。公司今年已经改过三次条款。那么这位客户接受的是哪个版本，又是哪一天？注册记录显示了他加入的日期，但那天的条款文本早在几个月前就被替换了。此刻，公司无法证明他当时究竟看到了什么。
每一场条款争议背后的问题
当客户质疑你的条款时，你必须拿出他当初接受的那个确切版本。
大多数网络和软件公司都会在注册时要求用户接受条款与条件。这段文本会随时间改变。你加一个条款、改一处错误，或调整一个通知期。每次改动都产生一个新版本。如果客户日后对某个条款提出异议，真正的问题很简单。他点击接受的那天，在线的是哪个版本，上面写了什么？如果你只保留今天的条款，就答不上来。
瑞士法律真正要求什么
合同在双方达成一致时成立，而主张某条款的一方必须证明它。
根据《债法典》第1条（OR），合同需要当事人相互一致的意思表示。这种意思可以是明示的，也可以是默示的，所以点击一个接受按钮也可能算数。根据OR 第11条，只有法律规定时，合同才需要特定形式。普通的条款与条件不需要签名，因此在线接受也可以具有约束力。但有一个关键点。根据《民法典》第8条（ZGB），凡从自己主张的事实中引出权利的人，必须证明这些事实。说白了，如果你想依据某个条款，就要由你来证明它是约定的一部分。
为什么「我们更新了条款」还不够
你当前的条款页面，并不能显示过去的用户在点击接受时看到的内容。
在线的条款页面只显示一件事：今天的文本。你发布新版本时，旧文本通常就没了。收件箱里的一张截图很容易被质疑。变更日志里的一行，只是你自己写下的一条记录。这些都无法把那个时间点固定下来。在争议中，对方可以说文本原本不同，或者是后来加上去的。没有带日期的记录，就是各执一词。
为条款的每个版本标注日期
封存每个版本，会为当时存在的确切文本生成一份带日期的记录。
当你封存一份文件时，平台会把它的一个加密哈希，也就是一段简短的指纹，按照 RFC 3161 发送给一个可信的时间戳机构。你会收到一个时间戳，把这段确切文本绑定到那一刻。改动一个字符，指纹就会变。于是你条款的封存版本就被锁定在它的日期上。如果你在发布每个版本时都封存它，就会建立一条简单的时间线。一月的第一版。四月的第二版。九月的第三版。每一版都有日期，任何人都可以通过一个公开链接核对每一版，无需账户。
封存能显示什么，不能显示什么
封存显示某个时间存在的是哪段文本，而不是谁写的，也不是谁点了接受。
要把界限讲清楚。封存显示你条款的某个具体版本在某个具体日期存在，且此后未曾改变。它不显示文本是谁写的。它本身也不能证明某个具名用户点击了接受。为此，你仍然需要自己的注册日志，它记录了用户以及向他显示的版本。封存承担的是那些日志做得不好的那一部分。它证明那个日期的条款文本是真实且未被改动的。两者协同工作。你的日志把用户和某个版本联系起来。封存固定下那个版本写了什么。
每次更新的一套简单流程
在发布每个版本之前封存它，并把带日期的记录和你的注册日志放在一起。
一套简短的流程能保护你：
- 在发布新版本之前，封存最终文本。
- 把公开验证链接连同该版本一起存入你的档案。
- 确保你的注册流程记录每个用户接受了哪个版本，以及何时接受。
- 保留旧的封存版本。发布新版本时不要删除它们。
这每次发布只需几分钟。它把未来的争议从猜测变成一份你能拿出来的带日期的记录。
回到 Maria
Maria 的公司现在会在条款每个版本上线当天就把它封存。下次有客户问他注册时适用的是哪些规则，支持团队就能指出那个日期的封存版本和一个任何人都能核对的公开链接。工作发生在发布的时候，而不是争执的时候。在发布每个版本之前封存它，让文本和它的日期在还容易证明的时候就被固定下来。你可以在 swisstrustlayer.com 开始。
