Vercy · 附加式配置
给你已经在用的记忆，加 11 个字段。
这份配置不替换任何记忆存储。它指出基准测试发现真正承重的那些字段，并说明每个字段在人们已经在跑的存储中落在何处。
为什么是配置，而不是格式
协作记忆基准原本要检验：治理信息该放在记忆记录内部，还是放在旁边的一层。结果没有区别——放在记录内部得 95.2%，同一张图配单独治理目录得 93.5%，用散文承载同样事实的团队 wiki 得 96.8%，两两比较全部 p = 1.00。这些信息放在哪里并不重要。
真正重要的是它们存不存在。给双时态图加上治理信息，把它从 77.4% 提到 93.5%，p = 0.039。因此值得发布的不是又一个存储、又一种序列化，而是这套字段本身，并且表述成可以加到图、向量记忆、目录、wiki 或数据表上，而不必搬动任何数据。
字段
每个字段都列出它承载的能力，以及有它与没它之间的实测差异，数值取自测得该结果的那项研究已发布的结果文件。PDB 是个人维度基准，CMB 是协作记忆基准。
| 字段 | 级别 | 要求 | 含义 | 实测：无 → 有 |
|---|---|---|---|---|
| record_id | 1 | MUST | 记录自身的稳定标识符，短到可以手写。 | 0.0% → 100.0% (CMB) |
| valid_from | 1 | MUST | 该陈述开始为真的日期。不是它被记录下来的日期。 | 0.0% → 100.0% (PDB) |
| valid_to | 1 | MUST | 该陈述不再为真的日期。该字段必须存在；值为 null 表示至今仍然成立。 | 20.0% → 100.0% (PDB) |
| source | 2 | MUST | 该陈述的出处，以可追查的标识符表示。 | 33.3% → 100.0% (PDB) |
| concept_owner | 2 | MUST | 对这个概念含义负责的唯一一方。每个概念只有一个。 | 80.0% → 100.0% (CMB) |
| owner_role | 2 | SHOULD | 该方内部的责任角色，使请求能落到具体的人。 | 68.8% → 100.0% (CMB) |
| conflict_policy | 2 | MUST | 一条规则，每个存储声明一次，用于在覆盖同一日期且相互矛盾的记录之间做选择。 | 33.3% → 100.0% (CMB) |
| applies_to | 2 | 任何陈述规则的记录均为 MUST | 该规则所管辖的问题类别。没有写明适用范围的规则，会悄悄管到作者本意之外。 | 58.3% → 70.8% (SGB) |
| does_not_apply_to | 2 | 任何陈述规则的记录均为 MUST | 该规则明确不管辖的问题类别。单独写出，因为读者无法从肯定推出否定。 | 79.2% → 83.3% (SGB) |
| release_to | 3 | 只要有受限记录即为 MUST | 获准读取本记录的各方。该字段缺失并不等于许可。 | 59.1% → 100.0%; 严重越界 2 → 0 (CMB) |
| supersedes | 3 | SHOULD | 本记录所替代的那条记录的标识符，使更新永远不必通过改写历史来表达。 | 0.0% → 66.7% (PDB) |
| expected_concepts | - | 实验性 | 存储本应包含的概念清单，使完全缺失的概念也能被发现。尚未验证。 | 33.3% → 100.0% (R5) |
三个级别
级别按各自解锁的能力排序，因此一个存储可以分阶段采用本配置，并清楚每一步换来了什么。
能回答关于任意日期的问题，并让一次更新说出自己替代了什么。
以规则而非猜测解决分歧，并把变更请求送到负责的一方。
判断什么可以跨越边界，既不泄露也不过度拒绝。
每个字段落在哪里
五种目标形态加上原生形态。琥珀色的格子表示该目标没有现成位置容纳这个字段，格中说明如何添加。其余的在那里本来就有，只是名字不同。
| 字段 | 双时态图 | 向量记忆 | 数据目录 | wiki 或文档 | 关系表 | Vercy 维度 |
|---|---|---|---|---|---|---|
| record_id | edge uuid | memory id | term or asset identifier | a short tag written in the line, for example [D-102] | primary key | id |
| valid_from | valid_at | add: metadata field, distinct from the created-at timestamp | add: usually only the asset has versions, the statement does not | stated in the sentence | date column | valid_from |
| valid_to | invalid_at | add: metadata field | add: same | stated in the sentence | nullable date column | valid_to |
| source | the episodic node the edge was extracted from | metadata field | lineage link to the source asset | named in the sentence | foreign key to a source table | source |
| concept_owner | add: OWNED_BY edge from the entity to a party node | add: metadata field | owner field, native | a page listing who owns what | foreign key to a party table | concept_owner |
| owner_role | add: role attribute on that OWNED_BY edge | add: metadata field | steward or accountable role, native | the role named on that page | column on the party table | owner_role |
| conflict_policy | add: one graph-level property, or a single policy node | add: one pinned memory, or application configuration | add: a policy document linked from the glossary | a page stating how disagreements are settled | one row in a policy table, referenced by the store | conflict_policy |
| applies_to | add: attribute on the rule edge, or SCOPES edges to entity classes | add: metadata list on the memory holding the rule | policy scope, native in most catalogues | the sentence says which questions the rule governs | join table of rule to question class | applies_to |
| does_not_apply_to | add: EXCLUDES edges from the rule edge | add: metadata list, kept separate from applies_to | add: catalogues usually state inclusion only | a second sentence saying what it does not govern | the same join table with an excluded flag | does_not_apply_to |
| release_to | add: VISIBLE_TO edges, or a list attribute on the fact edge | add: metadata list, applied as a retrieval filter | classification and purpose policies, native | stated in the line that holds the restricted statement | join table of record to party | release_to |
| supersedes | add: SUPERSEDES edge between fact edges | add: metadata field holding the prior memory id | term version history, native | the tag of the superseded line, named in the new line | self-referencing foreign key | supersedes |
| expected_concepts | add: entity nodes marked as expected but unpopulated | add: a separate register, not a memory | add: a list of required terms | a checklist page | a table of required concepts | not yet in the specification |
格子中使用各目标系统自己的词汇，在所有语言版本中一律保留英文，以便本表、profile.yaml 与 mappings.csv 表述一致。wiki 那一列不是退而求其次：在协作记忆基准中，用普通句子承载这些字段的 wiki 得到 96.8%，是所有受测表示中最高的。
实施时最常弄错的四点
- 本配置是附加式的。这里没有任何一处要求你搬动数据或更换存储。
- valid_from 不是你的存储里已有的那个时间戳。记录时间与生效时间是两回事，这些基准中每一项历史结果都取决于这一区别。
- 缺少 release_to 不等于许可。字段缺失时，安全的读法是这条记录不可对外给出。
- 每个存储一条冲突政策，声明一次。在每条记录里重复它，等于邀请两条记录对“分歧如何解决”本身产生分歧。
这一切建立在什么之上
三项基准、1,926 次模型调用、一个模型家族、工具全程关闭，每项研究一个人工撰写的世界。上述效应量来自对上下文中记录的推理；检索、排序与数据接入都不在范围内，而这正是若干记忆产品视为自身主要贡献的部分。expected_concepts 字段是从一处实测盲区推出的假设，不是结果：还没有任何研究检验过它。每个数字都能回溯到已公开的原始运行。
如何记录一次变更
两项基准在每个场景中都给出了正确的新值，却有三分之一到五分之一的场景把边界日期写错了。解决办法不是更好的提示词，而是更窄的操作：写一条新记录，给它新陈述开始生效的日期，指明它所替代的记录，并且不去动被替代的那条记录。
superseded record, left untouched:
{
"record_id": "D-802",
"concept": "data_retention",
"value": "customer records are kept for five years after the contract ends",
"valid_from": "2026-06-01",
"valid_to": null,
"source": "LEG-POL-04",
"concept_owner": "legal",
"supersedes": "D-801"
}
new record:
{
"record_id": "D-806",
"concept": "data_retention",
"value": "customer records are kept for three years after the contract ends",
"valid_from": "2026-10-01",
"valid_to": null,
"source": "LEG-POL-06",
"concept_owner": "legal",
"supersedes": "D-802"
}
被替代区间的结束由读取时推导，而不是写下来：某条记录在某个日期生效，当它覆盖该日期，且没有任何替代它的记录在该日期或更早开始。修改旧记录，或者手工计算它的结束日期，正是实测错误发生的地方。
唯一一个原本只是假设的字段，以及对它的检验
expected_concepts 当初是作为一项由实测盲区导出的提议发布的：在语义落地基准中，完全不在目录里的定义，是散文与结构都从未发现过的唯一一处缺口。一份写明存储本应包含哪些概念的登记表，能把这种缺席变成可以指认的东西。发布时它尚未被检验。现在检验过了：在同一份有缺陷的目录上，带与不带登记表各跑一遍，共 60 次调用。
| 指标 | 没有登记表 | 有登记表 |
|---|---|---|
| 发现完全缺席的那个概念 | 33.3% | 100.0% |
| 发现六处预设缺口中的任意一处 | 83.3% | 100.0% |
| 在四个没有缺口的问题上的误报 | 8.3% | 8.3% |
这个字段在它被设计要解决的那个情形上确实有效，而且关键对照也守住了：如果登记表让智能体开始凭空捏造缺口，那就比没有它更糟，而误报率没有变化。但六处缺口中只有两处发生变化，因此对该族的精确符号检验为 p = 0.5。一次小规模实验不足以形成要求，所以该字段仍标为实验性。原始运行与配置一并公开。
用更少的上下文承载同样的字段
在后两项研究中，维度都是上下文最长的一种，而准确率只是持平，因此这份配置不应该为了表达同样的内容而付出两倍的上下文。固定字段顺序、每条记录一行，可以去掉其中大部分开销。下面的数字是在构建时对已发布的参考存储实测得到的，而不是断言。
| 序列化方式 | 字符数 | 节省 |
|---|---|---|
| 每行一个 JSON 对象 | 6,064 | - |
| 紧凑行格式 | 1,860 | 69.3% |
# record_id|valid_from|valid_to|source|concept_owner|owner_role|supersedes|release_to|value D-101|2025-01-01|2026-03-31|FIN-POL-04|finance|Head of Finance
节省的另一半来自挑选。在个人维度基准的组装赛道中，被要求挑出问题所需记录的智能体召回了全部所需记录，从 41 条中平均只选 1.2 条，并把提供的上下文从 10,332 个字符压到 473 个，准确率没有可测量的变化，p = 0.34。压缩是实测的；准确率提升不是，也不应当被主张。
按级别检查一个存储
检查器接受 JSON 数组或每行一条记录，以及一份把你自己的字段名映射到配置角色的对照表。它会报告该存储满足的最高级别，并指出每项要求下未通过的记录。低于级别 1 时以非零码退出，因此可以接入构建流程。
python check.py store.jsonl python check.py store.jsonl --map record_id=uuid,valid_from=valid_at,valid_to=invalid_at,source=episode
旁边还发布了两份样例。参考存储达到级别 3。同样的记录以双时态事实边的形式呈现时只达到级别 1，并且报出的正是协作记忆基准发现缺失的东西：没有概念归属方，也没有冲突政策。